Introduction to the Cloud-Native Development Evolution Model

The ways in which we are working together to build software or technology in general are an ever changing organism constantly evolving to become a better version of itself.

With the rise of cloud computing, not just the way we distribute technology or store data has been democratized but also the way we want to or should develop applications for this new area of computing is ever evolving.

In the last few years the term “Cloud Native Development” was coined describing a way of development that moves the creation of code closer to the way that code will later be distributed as an application via cloud services.

Unfortunately the development side often gets a little bit overlooked when it comes to going truly cloud native for companies. And clearly, becoming a truly cloud native company is no easy feat. It takes, you guessed it, evolution. But what stages of evolution do companies have to go through to arrive at the desired stage? And what does that stage entail? That’s what we are going to look at here.

Stage 1: Normalisation

• Application development teams use version control
• Application development teams use standard development procedures

This happens for example by using Git or SVN. There is a main branch and individual feature branches making it easier to keep control of the application code. There is also versioning for release procedures.

If you have not yet arrived at this stage you must have lived under a rock for the last 20 years. Go and get version control implemented. Now.

Stage 2: Standardisation

• Teams build on a standard set of technology
• Teams deploy to a standard operating platform

Standardisation drastically increases the efficiency of your organisation. That’s not only true for your tech team. But for those guys it means working with container technology such as docker, docker-compose or Kubernetes.

This stage is the groundwork for moving towards the cloud native organisation.

Stage 3: Expansion

• Applications consist of multiple smaller moving parts, loosely coupled services
• Applications are designed for scale, resiliency and pace of change

Your organisation is using service oriented architectures, message brokering, event streams and loosely coupled (REST-, GraphQL-, etc.) interfaces. This helps for implementing specialist teams, faster development and better handling of complex applications by applying the “divide and conquer”-principle.

To arrive at this stage, it is important to already plan out your application as a structure consisting of individually developed services from the get go as splitting up a monolithic application structure later on is a real struggle.

Stage 4: Automated Application Delivery

• Teams reuse deployment patterns
• Version control for deployment patterns and configurations
• Automated development environment provisioning
• Teams use standard set of build and test systems
• Service discovery is used in applications
• Security teams are involved in design and deployment
• Automated code and manifest security profiling

Technologies and principles you may have implemented in stage 4 could include Helm, Quay, GitHub Actions, Continuous Integration, ArgoCD, Service Mesh, Network Policies, Pod Disruption Budget.

Applications, or better yet, resilient small services have a high release cadence. End-to-end automated deployment patterns (e.g. using Helm for all parts) with GitOps are in place. A “push” to the source management system triggers traceable changes to the infrastructure and applications. All team members (with special focus on developers) know the pivotal elements of the continuous integration pipeline and solve challenges on their own. Besides, members of a dedicated security team are involved in the creation of architectures and services. Security fixes are rolled out just as fast as they appear.

Stage 5: Automated Application Lifecycle Management

• Development teams can access all services for development
• Production can be replicated to development
• Applications use advanced operating platform patterns
• Applications manage themselves and the operating platform

Examples: Operators, CRD (Custom Resource Definitions), Auto Scaling, Probes

Your development team hunts a complex bug which embarrassingly sits between all of your services? - No problem, since in stage 5 your teams are able to provision the complexity of your production environment with the flick of a finger. In addition, all services manage their own lifecycle without the need for manual intervention. There is an update which requires a data migration? No problem for your Kubernetes Operator which detects the available update in your registry and automagically applies the needed scripts in order to keep your application’s data consistent. Applications itself tell Kubernetes about their health - are they ready to process requests or is there more capacity required? May we scale down a bit in order to save money? In stage 5, that’s nothing your team has to take care of anymore. 

Are you at Stage 5 yet? Yes? Congratulations! But if not, don’t worry. From our own assessment there are still very few companies that have truly arrived at stage 5 already. We feel that every organisation should do its best to arrive at stage 3 sooner rather than later and immediately start looking towards the mid-term goal of reaching stage 4. If that is the strategy, you are on a good way to be set up for future success.

Credits

I'd like to thank the unikube team for providing me with valuable input and support. The "Cloud-Native Development Evolution Model" is inspired by Puppet's annual state of DevOps report.