Becoming a truly cloud-native company is not easy. It takes evolution. But what stages of evolution do companies have to go through to arrive at the desired stage? And what does that stage entail? Take a look with us!

Stage 1: Normalisation

This happens for example by using Git or SVN. There is the main branch and individual feature branches make 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

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

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, since splitting up a monolithic application structure later on is a real struggle.

Stage 4: Automated Application Delivery

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 a 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

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

Your development team hunts a complex bug that embarrassingly sits between all of your services? No problem, since in stage 5 your teams can 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 that requires a data migration? No problem, for your Kubernetes Operators which detect the available update in your registry and automatically apply the needed scripts in order to keep your application’s data consistent. Applications themselves 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 in 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.

If you want more insights into the Kubernetes ecosystem, feel free to follow Michael Schilonka on LinkedIn.