Introduction

As a Scrum Master, Product Manager, or Project Manager new to the technology, it can be challenging to wrap your head around Kubernetes, Cloud-Native application development, Microservices, and Containers. You need to learn new terminology and rethink how applications are built, deployed, and managed.

The purpose of this blog post is to help provide you with the following:

  • A high level overview of Containers and Kubernetes.
  • A new build, deployment, and management model with these technologies.
  • Mental models of Containers, Kubernetes and Microservices to help you start rethinking and relearning how this change will work as you and your teams move to Kubernetes and a Cloud-Native application world.

Note: there is plenty of literature that lays out what and how Kubernetes works. This is the Oteemo approach and our target audience is for Project Managers, Product Managers, and Scrum Masters.

Containers

There is a universe of good literature on Containers. What makes them important for you is how they make it easier for your team (Operations team, Developers, Data scientists, or yourself) to repeatedly run and deploy software with confidence – no matter what environment. You can deploy your app in containers on a server in a data center, on your laptop, in an autonomous car, or on the public cloud from providers such as Microsoft, AWS, or Google. This is helpful because what normally would take a lot of back and forth, and/or trial and error, can be done in a matter of minutes. Think about how many times you’ve heard “it worked on my laptop.” Containers solve this problem.

Kubernetes Pods and Nodes

After Containers, Pods and Nodes are the next logical thing to learn about with Kubernetes. Google defines Pods as “collections of containers that are co-scheduled.” Pods have to run somewhere (cloud, bare-metal, your laptop) and this is where the concept of Nodes comes in. The Kubernetes documentation defines a Node as “a worker machine in Kubernetes…A node may be a VM or physical machine.”

Here are some models for you to consider about Nodes, Pods, and Containers. In the second diagram, it’s important to note the one-to-many relationships between Nodes, Pods, and Containers.

Nodes, pods and containers

Figure 1.2: Simple architecture consisting of a Node, Pods, and Containers

k8s-Fig1.3

Figure 1.3: Relationship between Nodes and Pods

Masters

As you can imagine, this is a lot of complexity to manage. For example, how do I keep all the pods healthy and running? How do I know when they are not healthy? Kubernetes has a tool that takes care of these questions, they are called Master(s). Imagine the Kubernetes Masters as the command center of the Kubernetes system. There are many resources available about what makes up the Kubernetes Master but for the purpose of establishing a mental model of how things work, think of the Kubernetes Master as the orchestrator of all this complexity.

Although there is a lot more to Kubernetes, understanding these core concepts will help you get a sense of some of the foundational elements of Kubernetes and the value it brings. Below, we’ll go about doing some of the activities we recommend for alignment purposes as you begin your journey to adopting Kubernetes.

12 Factor and Mental Models

At Oteemo, we are big believers in Kubernetes for container orchestration and we are also big believers in Cloud-Native application development to create applications that run effectively and efficiently on Kubernetes. One approach to take advantage of the Cloud is to follow the 12-Factor (https://12factor.net/) methodology. It is our opinion that following this methodology is ideal for building Cloud-Native applications which allows you to take advantage of the benefits Kubernetes provides. Just as the way your infrastructure is managed is different with Kubernetes, the way you build and design applications should change.

As a Scrum Master or Product manager, this change requires you to reconsider or re-think what the DNA of your application will look like and what will change. In my experience as an Agile coach supporting a project that did exactly this for a large bank, I not only had to learn a whole new vocabulary and mental models of how things fit together, I also had to reconsider and adjust how to follow along and support the teams as they refactored their applications to migrate to Kubernetes. Breaking down work into small iterative pieces changes when the traditional blocks are different.

We won’t go into the background of the 12-Factor Methodology but below are the agreed upon characteristics of a 12-Factor application.

The 12-Factor Methodology

  1. Codebase: One codebase tracked in revision control, many deploys
  2. Dependencies: Explicitly declare and isolate dependencies
  3. Config: Store config in the environment
  4. Backing services: Treat backing services as attached resources
  5. Build, release, run: Strictly separate build and run stages
  6. Processes: Execute the app as one or more stateless processes
  7. Port binding: Export services via port binding
  8. Concurrency: Scale out via the process model
  9. Disposability: Maximize robustness with fast startup and graceful shutdown
  10. Dev/prod parity: Keep development, staging, and production as similar as possible
  11. Logs: Treat logs as event streams
  12. Admin processes: Run admin/management tasks as one-off processes

We recommend you to incorporate these into the DNA and characteristics of your project and backlog. As you start to do this, you can start to consider what part of the application goes into each Container and what that will look like. One approach (and the one we’ll use for this blog post) to achieve this is to break your application into Microservices (although this is not synonymous with Cloud Native application development). Ismail, one of our consultants, has a great saying that you as a Product Owner and Agile coach should write down if you use this approach “Microservices are like puzzle pieces that you have to put together and in order for those pieces to fit they must have Contracts.”

Contracts are a good forcing mechanism for communication not only between team members but teams (things that are important in your role as Product Manager or Scrum Master). There is a lot of literature out there about Contracts, but the idea is: you want to ensure that when you put the pieces together-they fit. This is not a novel idea, yet something that can be lost as you are managing and breaking everything down into smaller and smaller pieces and the complexity increases.

We recommend the following activities to adhere to the 12-Factor Methodology.

  • Alignment on language to identify what each factor in the 12 factor methodology implies and means. This will ensure everyone is on the same page on the characteristics of the application.
  • Good teams have common agreements and understandings of Definitions of Done. Incorporating the 12 factor characteristics into your Definitions of Done will ensure you and your team are adhering to the methods and guidelines.
    • What are Definitions of Done? This is a term commonly used in the Agile framework and is an agreed upon list of criteria for when a work increment is completed.
    • For example, the Feature isn’t complete unless the Logs have been treated as event streams, or Contracts between Services are explicit and have been exposed or agreed upon.
    • Define Contracts and gain agreement on what they are and mean for your team and the groups you will be working with.
  • Build a timeboxed “Walking Skeleton” of what the application looks like with these characteristics (i.e., codebase tracked in version control, configurations for each environment stored, build, release, run stages for your application, etc) so your team can learn, iterate, and start building the patterns to follow.

Keep in mind that adopting a new way of building applications can be like working out: it is tough at first and while over time it will not necessarily be easier, you’ll be able to handle it better and reach new heights.

Now that you have the what defined, you’ll have to start defining the components of a Microservice that can go into a Container. One pattern you can adopt is for the Microservice to have a Database and a Rest API associated with it as seen in figure 1.4.

k8s4rest-fig3

Figure 1.4: Example Microservice Architecture inside a Container

This is different from the monolithic architectures of the past and it is important to keep this mental model in the back of your mind as you build your new application.  As you start breaking down your application into Microservices, you will start to mentally visualize the Contracts that need to be there and better understand what the microservice, as a whole, will look like. The nice thing about this conceptual model is that it allows you to consider an end-to-end scenario that you can demonstrate to your stakeholders at your Demo ceremony. For example, you can have a process that performs an action called  ‘x’ and writes to a database. That process can be running within a Container, and this container can be running within a Pod on a Node, within Kubernetes.

Summary and takeaways

The journey to Kubernetes and Cloud-Native application development can be a challenging one not only from a technical perspective but also from an alignment and how the pieces fit together perspective. In our role as as Product Manager or Scrum Master, focusing on understanding how things will be different in this new world will help you as you interact with your Agile team and with your stakeholders. Misunderstandings, confusion, and misalignment can be detrimental to the project.  Our hope is by following these guidelines and examples, you will be set up for success with your teams and on their journey to modernizing their applications.

Takeaways

As a Scrum Master, Product Manager, or Project Manager it is important for you to have a sense of how things are different in the Cloud Native/Kubernetes world.

  • Having consensus and understanding of the characteristics of a 12-factor application and Microservices will help you build alignment both internally and externally within your teams.
  • Understanding the vocabulary will help you understand the mental models of your Scrum Team, what they are talking about, and how they think about things as you perform Agile ceremonies.
  • Rome wasn’t built in a day and being able to articulate to your stakeholders the why and how of these concepts will help you explain to your stakeholders and others of the progress you are making and what they are seeing.

In the next Blog Post we will go over how to model your microservice for the current state and future state.