Only Oteemo transforms business through acceleration, enablement, and adoption
Oteemo uniquely transforms teams and processes too
Why we’re different
Get to know us
Work with us
by Jamil Jadallah | Apr 01, 2019
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:
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.
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.
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.
Figure 1.2: Simple architecture consisting of a Node, Pods, and Containers
Figure 1.3: Relationship between Nodes and Pods
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.
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.
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.
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.
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.
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.
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.
In the next Blog Post we will go over how to model your microservice for the current state and future state.
Kubernetes Tooling For TechOps And Support (Local Kubernetes Clusters)
Kubernetes tooling for TechOps and Support
Ingress 102: Kubernetes Ingress Implementation Options
As passionate technologists, we love to push the envelope. We act as strategists, practitioners and coaches to enable enterprises to adopt modern technology and accelerate innovation.
We help customers win by meeting their business objectives efficiently and effectively.
Join tens of thousands of your peers and sign-up for our best technology content curated by our experts. We never share or sell your email address!
© 2021 Oteemo Inc. All rights reserved