Introduction

A Kinetic development environment is a combination of Agile methodologies and practices, with an on-premise cloud. The on-premise cloud contains services and operators that surface dynamic provisioning of Kubernetes resources. Taken together, each cloud instance can be configured as a single unit that can be deployed individually into development, QA, operations, etc. Each cloud instance comes with the capability of communicating with another cloud instance, thereby forming a pipeline. A common example of the pipeline is an SDLC. But there are other ways to configure cloud pipelines to be adapted to many organizational structures and still provide an Agile environment that promotes Agile methodologies.

Some of the examples below illustrate how Kinetic can be adapted to different organizational structures. In each example Kinetic cloud instances promote upfront integration, dynamic provisioning, collaboration and communication.

The Whole Nine Yards

In this scenario an organization adopts the full Kinetic approach for development, nightly builds, system QA, internal releases and operations.

Typically having multiple cloud instances is not feasible or practical for most organizations. Firstly, it would be far too expensive and in many instances would not be required. The situation changes when smaller private clouds enter the picture. Because of their low price point and high functionality, an organization can now use them for development, QA, nightly builds, operations and internal releases. The motivation for this approach is that different departments in an organization now have the option to use the cloud to build different parts of their system and have them integrated in a nightly build.

Having the flexibility to have multiple cloud instances and using them to form an organizational pipeline may be suitable for larger, legacy organizations.

• A development team can use it to integrate with a database, search engine, or other infrastructure components.
• A UI team can use it to integrate with the services provided by the infrastructure.
• The nightly build can be used as an integration test bed for the product.
• An internal release can be used to validate functionalities, track progress and experience the product as it goes through its lifecycle.
• A QA team can use it to test performance and scalability.
• An ops team can use it to validate deployment scripts and strategies.

Basically, all the use cases above suggest that there can be multiple cloud  instances developing different parts of the system which can then be integrated in nightly builds, QA, etc. How the cloud is used in these organizations depends entirely on their needs. And being able to customize your development and integration environment promotes the adaptability of Agile methodologies and practices into the organization without forcing structural changes.

The Night Watchman or Rolling Integration

The Night Watchman scenario is associated with nightly builds.  Nightly builds usually run unit tests. However if the nightly build can dynamically provision an on-premise cloud then it can become a center for integration testing. So besides using unit tests, a nightly build can provision a cloud so it can also run integration tests.

This is especially important because it validates system functionality instead of unit test functionality and in those instances where developers only wish to work on their local machines, then the nightly builds can help the individually developed components to work together in an integrated environment.

As a consequence all locally developed artifacts will always be tested in an integrated environment. Most often these tests can be run as part of the nightly build. Depending upon the organization, this nightly build can also occur during the day at predefined intervals.

Because the build and tests run in an integrated environment, developers working on cross functional user stories will naturally communicate, collaborate and coordinate so that they don’t break the build.

Using nightly builds or periodic builds during the day may be preferred in organizations in which developers are in different departments and do not wish to manage their own instances of the cloud. In this case a dedicated team can set up the builds so that developers at different times and indifferent locations can push their code to Git so it can be integrated and tested in the cloud.

There is a caveat to this approach:

• The build process doesn’t just build the code and the images but it provisions the cloud components on demand.
• The cloud provisioning therefore needs to take place in a relatively short time period.
• Failures in the build must be handed gracefully and reporting structures need to highlight where tests fail.
• The turnaround time from failure to the next iteration must be calibrated so that developers can fix bugs and push them into the next build.

Though this is not an optimum solution, it can work if there is a strong adherence to using APIs for each system artifact and a clear understanding of the data being exchanged through these APIs. In this case the periodic builds can help validate the interoperability of product artifacts and optimize the turnaround time to fix bugs and enhanced their functionality. In essence, the build becomes the place where there is continuous deployment and continuous integration.

DevOps

This scenario is for an organization with small development teams which are responsible for their entire development lifecycle. These teams are often called DevOps. In affect a single team changes its role as the software goes through its lifecycle and is responsible for development, QA, operations and product launch.

It is demonstrably true that upfront integration using a cloud dramatically speeds up development and improves quality. However not all organizations can afford to spend the money for AWS, Google Compute or other major cloud offerings.

An on-premise cloud lowers the barrier to entry for building cloud native applications. Smaller teams can use Kinetic with its on-premise cloud for the entire software development lifecycle.

• They can use it to build out user stories.
• They can use it for up-front integration testing.
• They can use it to simulate some part of their production environment.
• They can use it for QA and performance and scalability testing.
• They can use it to develop scripts and strategies for deploying their product into production on public cloud offerings.

The benefits of this approach is that the organization gets to experience developing applications in a cloud native environment without the burdensome cost associated with the cloud.

Research teams, proof of concept teams and any relatively small organization that needs a shorter runway for product launch can use Kinetic to build a cloud native product and make it generally available.

Summary

The Kinetic ecosystem can be adapted to many different organizational structures. Each cloud instance and its supporting operators and services are modular and can be linked together. This pattern of modular cloud instances arises from the Agile principle of taking a big thing like a pipeline and decomposing it into its essential component parts. But there is a difference between a Kinetic cloud instance and a pipeline:

• A Kinetic cloud instance lives by itself as a self-contained unit.
• Each Kinetic instance may be linked to another instance to form pipelines.
• Kinetic pipelines have feedback loops for in flight corrections.
• Cloud instances can form an ecosystem for product development.
• Cloud instances can be used to integrate development across  different departments.

In this environment Kinetic adapts Agile to individual organizational structures and promotes collaboration, transparency while its Agile methodologies turbocharge the development process, reduce risk, mitigate uncertainty and promote quality while lowering cost and reducing time to market.

Ideate Iterate Innovate