Community guest post by Danielle Cook, Simon Forster, John Forman, and Robbie Glenn of the Cartografos Working Group
You’ve heard the benefits of containers, microservices and this thing called Kubernetes. You’ve investigated, you understand the business and technology benefits and now want to embark on the transformation to cloud native technologies? All you need is to figure out where to start and what steps to take to achieve your goals.
Tools like the CNCF cloud native landscape and trail map provide some resources as you work through this journey. But understanding what to do when is often a challenge for some organizations. That’s exactly what the Cartografos Working Group aims to solve. The Group is providing tools to help adopters and end-users navigate the CNCF landscape and the wider cloud native ecosystem. It wants to educate and inform users with effective and practical guidance to help them understand the cloud native ecosystem.
Creating a Cloud Native Maturity Model
Its first project was to create the Cloud Native Maturity Model. Members of this group all authored separate maturity models around the journey to cloud native, and Kubernetes. The goal was to combine these models into an all encompassing one that spans the entire cloud native ecosystem.
As the maturity model was created, it became apparent quickly that the journey is not limited to technology. There are clear themes around people, process and policy because each plays a huge role in adopting cloud native technology.
People
Cloud native is a mindset and a different approach to technology. Your people are part of this journey. The team needs to agree how they will work, identify what skills are needed and how the organization will evolve through the stages of maturity. Security is ever present in the model and that includes how to balance security with people enablement.
Process
Your processes will change too. You need to understand the processes needed and the technology to support it. That includes mapping policy to workflows, CI/CD, infrastructure as code (Iac) and to shift the security process as far left as possible.
In addition, you’ll need to consider how your wider organization’s processes interact with cloud native. What workflows do you have today? How will they map to your new cloud native technologies? Your workflows and processes will also affect your cloud native processes.
Policy
Depending on your organization, you may have limited policies or be compliance-heavy and have tons! That policy needs to be translated into your cloud native environment. You need to know what internal and external policies are required to achieve security and compliance mandates and how these policies reflect your business’s operating environment.
Technology
Finally the technology you use may change several times during it’s life cycle. At the beginning of this journey, you need a baseline level of technology to be successful – adopting containers for example. You’ll need to spend time on the technology required for you to deliver on the benefits of cloud native and support people, processes and policy as well as the technology for CI/CD, adoption of GitOps, observability, security, storage, networking, etc.
Is the Maturity Model Right for Me?
The Maturity Model is set up to provide guidance in each stage and around people, process, policy and technology. The aim of this model is not to be overly prescriptive, but rather to be a tool to help guide you on your journey. Cloud native transformation is not an exact science, but rather lives within your project, your organization, and of course takes place in a specific time and place. No project, organization or person is expected to match all of the details contained within the model, perfectly. It’s deliberately designed to cover many different scenarios; everything from startups to Fortune 100 companies.
The 5 Stages of Cloud Native Maturity
There are five stages within the cloud native maturity model. While you may be in stage five for one application, at the same time, you may be at stage 2 for another. Keep that in mind as you identify your stage of maturity.
Level 1: Build: You have a baseline cloud native implementation in place and are in pre-production.
Level 2: Operate: The cloud native foundation is established and you are moving to production.
Level 3: Scale: Your competency is growing and you are defining processes for scale.
Level 4: Improve: You are improving security, policy and governance across your environment.
Level 5: Optimize: You are revisiting decisions made earlier and monitoring applications and infrastructure for optimization.
In each section, the Cloud Native Maturity Model discusses core concepts and what it means across people, process, policy and technology.
Contributions Welcome!
The maturity model is open source and we expect it to be a living document as the cloud native community and landscape evolves. The CNCF Cartografos Working Group welcomes participation from members of the cloud native community. You can learn more about the group and read the full maturity model at https://github.com/cncf/cartografos.
Am I ready to start?
Knowing when cloud native is right for you is the first step to starting this journey to maturity. However, this is a tool to use wherever you are in your journey. If you are at level 3 already, it can help you understand what you need to achieve in the next stages.
To be successful on the people side of cloud native, you’ll want to understand your relationships and potential separation between development and operations. You’ll need to understand how to stay compliant if mandated and the skills your people will need along this journey.
You are ready to start your process journey when your application deployments are being done manually or taking a long time to complete, often with multiple attempts. You may support multiple distributions of the same software and have trouble upgrading or evaluating without significant down-time. You may also find yourself needing to ‘take a step back’, look at some of your processes and carefully evaluate their overall effectiveness.
Your policy may be in the form of conventions and rules that are located external to the application and its platform, and are not enforced natively within your applications and runtime environment. Policies might be disparate and built in silos; defense in depth parity might be more of an accident than deliberate.
On the technology side of the house, you have some VM’s on demand, some scattered automation, and baseline security components such as SIEM, RBAC concepts, and a directory of some type. You’ll have perimeter security and perhaps some course network zoning at layers 1-4, but you may feel some anxiety and security practices. Your experience with encryption may vary – you might have some certificate authorities for example, but they may not be used extensively, with a high barrier to entry for many.
You have some software packaging, but this could be inconsistent. Your applications may rely on infrastructure solutions for high availability, which in turn may be more costly than you’d like.
Your server estate could range from single physical or virtual servers with low levels of availability, through to highly available clusters. Scaling could be a real challenge and may require considerable investment in money, time and planning. You may have started to dip your toe into a ‘Everything as Code’ model. i.e. started to script your infrastructure with Terraform.