Kubernetes Maturity Phase 2: Transformation
We previously introduced the Kubernetes Maturity Model and discussed how to prepare for Kubernetes. The next phase in your journey to achieving Kubernetes maturity is transformation.
Thus far, you should have prepared for adoption by getting buy-in from the organization to invest in Kubernetes. You have prioritized your workloads by putting a plan in place to migrate an existing application – or to build your new application or service – with containers and Kubernetes. If you haven’t received the buy-in from your business, take a step back. You must ensure the business is aligned with your goals, as you won’t necessarily achieve those on day one with Kubernetes.
Covering the Basics: Language and Architecture
Phase two takes time. This phase covers your initial implementation, during which you verify your foundational knowledge, including learning terminology and nomenclature (understanding nodes, pods, namespaces, controllers, etc). Start with the basics; even so, you should expect a big learning curve as you undertake some key activities.
As you adopt Kubernetes, don’t be fooled by “up and running” articles. There is a functionality gap that occurs between when you first set up your clusters and when you are production-ready. You may find it helpful to undertake a Kubernetes proof-of-concept in this phase, or work with Kubernetes experts to ensure you are setting up your first clusters correctly to meet the demands of your workloads.
You’ll want to map your application architecture to the new, cloud-native context. Doing so will help you discover requirements and uncover dependencies for your application, so you can successfully embrace containers. Examples include dedicated workloads versus self-healing and ephemeral workloads, or configuration management for deployment versus containerization deployment.
Technical Transformation
Technical transformation could be an in-depth article on its own. This is the stage where you start running workloads in Kubernetes. Here, you will containerize your application, if you haven’t already done so. You’ll want to break down your application based on the twelve-factor app methodology. You’ll build your cloud and Kubernetes infrastructure, start writing YAML or Helm charts, plumb in external cloud dependencies, define your Git workflow, build the CI/CD pipeline, test in non-production and promote to production. If that sounds like a lot, it’s because it is! Your team will want plenty of time to experiment in this stage, and they may require some Kubernetes expertise to help establish the architecture correctly.
In this phase, you’ll also want to decide how you make decisions about tooling, including how to decide what problems need a tool solution, who is responsible for making that decision and how tools are vetted. For open source tools, you’ll want to ensure that each tool is updated regularly and that there is enough community support to avoid tools becoming outdated. Spend time during this stage answering these questions in collaboration with the developers using Kubernetes. You can read a more detailed analysis of steps here.
Balance Ultimate Flexibility With Control
A key benefit of Kubernetes is developers’ ability to commit code without involving the ops team. What’s required is good policies to ensure security, reliability and efficiency gains. The challenge is, as you set up your first clusters, you need to strike a balance between giving developers ultimate flexibility or controlling the infrastructure. Will you open Kubernetes to your developers in the beginning to enable productivity; or will you lock down the system? What configurations will you use to restrict changes? You must consider how you will balance developer needs with corporate policy.
Challenges and Outcomes
This stage can be challenging. You may become overwhelmed by complexity, decision paralysis due to the vast Kubernetes ecosystem, a lack of in-house expertise or loss of talent or uncertainty around Kubernetes best practices/execution.
These challenges are common in any IT environment, and Kubernetes is no exception. What adds difficulty here is the extremely limited talent and/or expertise in this space. If these challenges do arise, you can seek help from Kubernetes managed services.
After investing this time, energy and thought in phase two, you will next move on to phase three of the maturity model. Phase two will have helped you identify what applications are best for Kubernetes, and also understand fundamentals, strengths and weaknesses. You’ll have undertaken a successful Kubernetes proof-of-concept, so you will be able to make the decision to proceed or not.