Kubernetes explained to Product Managers
If you're a Product Manager, a Product Owner or someone working in a tech company, you might have heard the words containers, Docker, Kubernetes or clusters from your colleagues. Maybe you've got no clue what they're refering to, maybe you have an intuition about it, or maybe you're already familiar with the topics and concepts behind these words.
As a Product Manager or a Product Owner, these concepts might be useful for you to understand. Obviously, you don't have to become a pro in Kubernetes, but some basic knowledge should allow you to collaborate more fluidly with your team, while being able to get an idea of the stakes, either because your company is considering migrating to Kubernetes, or because they already use this technology on a daily basis.
However, these concepts can easily get overly technical when you don't have a developer or devops background. When looking for clarifications online, you might end up with technical documentation mostly targeting developers, which already have some kind of understanding of the solutions, or super high-level articles describing the benefits of Kubernetes to guide decision-making.
But what if you're a Product Manager and you'd like some basic understanding of the technical aspects of Kubernetes and containerized applications, while at the same time getting a clear idea of what technical and business value Kubernetes can provide to your organization?
That's why we've built this extensive guide to help you get a grasp of these concepts and what they imply for your job.
Why is everyone talking about Kubernetes?
Kubernetes is an open-source project initiated by Google, and launched in 2014. Google being praised for its high performing infrastructure and applications, an open-source project originating from the company is kind of a guarantee that it might be helpful to other organizations. Google has a tradition of open-source, with more than 2,000 projects launched to date. Some of them are particularly famous, like the Go language or Spinnaker (although launched by Netflix, it's been considerably extended by Google).
Today, Kubernetes is no longer managed by Google, as the company passed the project to the Cloud Native Computing Foundation, or CNCF, a non-profit organization hosting critical infrastructure projects.
Although launched only 6 years ago, Kubernetes is becoming a standard used by an increasing number of companies. 78% of companies using container orchestration have chosen Kubernetes, from tech companies, to large enterprises or rising startups. Think Google, Slack, The New York Times, BlaBlaCar or Huawei.
There is therefore a chance that your company uses Kubernetes, considers moving to Kubernetes, or has deliberately chosen not to. In any case, this is a choice that widely impacts the tech teams, as it touches the workflow of ops and to a lesser extent, of developers. A Kubernetes migration usually takes time, from a few months to years, depending of the complexity and size of the project.
This probably explains why you might have heard of the word ;)
So what exactly is Kubernetes?
The name Kubernetes originates from Greek, meaning helmsman or pilot.
Kubernetes defines itself as "an open-source system for automating deployment, scaling, and management of containerized applications."
Let's break this down to understand what this means.
Containerized applications
Since Kubernetes orchestrates containers, let's start by examining what containers actually are.
Containers have been made popular by an open-source project called Docker, created in 2013.
Think of the container as a standardized unit of software. It is a way to package software into standardized units for Development, Shipment and Deployment.
You can imagine containers as same-sized boxes built around your code, which allow you to manipulate them much more easily than if the code was on its own, without any standard.
Thanks to this standardization, containers allow complex architecture to be managed much more easily. These days, companies and sometimes even applications rely on multiple languages, frameworks or architectures, which creates a significant complexity. By providing a standardized package, containers simplify and accelerate the workflows and give teams freedom to use their own choice of tools, application stacks and deployment environment. In practice, this means that different containers of a same app can have different languages or architectures. If one team prefers Ruby and another Python, no problem, the application will still work.
Containers have been particularly successful since they've been created and their standard is now widely used. In 2019, a CNCF survey found that 84% of respondents were running containers in production, up 15% from the previous year. To measure the speed at which containers are adopted, it is remarkable to notice that containers were only used by 23% of respondents in 2016.
So how do containers work?
A container is composed of several elements. To be precise, each container has its own filesystem, CPU, memory or process space. They are fully decoupled from the architecture, which allows them to be portable.
Containers don't happen by magic, they have to be built.
You might hear your team mention Docker images. A Docker container image is a set of instructions made for building the container. The image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.
Why is Kubernetes needed on top of containers?
So now that you get a view of containers, you might wonder why they're not sufficient.
Containers are great but they must be managed and orchestrated. For example, if a container goes down, another container needs to start instead to avoid downtime on the app.
Instead of moving containers one by one, that's where orchestration tools such as Kubernetes comes in. Kubernetes is an orchestration tool, that takes care of the orchestration and scaling of containers. Without Kubernetes, containers would be handled by hand. As you can imagine, the more the containers the more the hand work, which is not compatible with the growth of an application.
Kubernetes runs these containers for you and therefore is your best ally when your application is scaling.
For this reason, a lot of teams choose to complement their use of containers with Kubernetes. As long as the project remain simple (a simple website for instance), Kubernetes might be unnecessary, but it's a great addition to containers when you need more automation.
What makes K8S special?
Kubernetes runs containers at scale and have the following features:
- Declarative: Declarative refers to a model where you don't have to specify and plan exactly how things will happen. Instead, you just state what your desired outcome is, without thinking at the way it is achieved. This allows Kubernetes users to forget about the complex details, to focus only on the outcome.
- Automation: Thanks to this declarative mode, Kubernetes achieves automation. Rather than spending countless hours working on the details of containers orchestration, Kubernetes abstracts it for you.
- Portable: Kubernetes can be used whatever the cloud provider or the kind of infrastructure used, which means it is portable.
What are the benefits of using K8S?
- Kubernetes can run anywhere. It is cloud agnostic and can run on virtual machines, which means there is no vendor lock-in.
Being completely agnostic, Kubernetes can be installed on a variety of public and private clouds (think AWS, GCP, OVH), as well as on bare metal servers. This is great, since it means that you are not tied to a provider, can easily switch from one to another or even support hybrid cloud or multi cloud strategies.
- Kubernetes accompanies the scaling of applications and helps manage complex architectures and infrastructures
Kubernetes allows companies to manage large applications without significant overhead. This is particularly important in a world where ops resources are scarce and difficult to find.
- Kubernetes allows developers to be more productive
Thanks to its declarative model and its ops friendly approach, Kubernetes has changed a lot how code is being deployed, allowing teams to scale and deploy faster than before.
Kubernetes vocabulary
Kubernetes comes with a variety of concepts that can seem initially obscure. Without entering the details, we'll explain them to you in order to understand what Kubernetes is made of and how it's structured.
Basically, Kubernetes is made of clusters, nodes and pods.
When you deploy Kubernetes, you get a cluster.
Inside this cluster, you can find nodes.
You deploy pods on these nodes.
For those willing to go further, here are some more explanations on each of these components:
Cluster: It is a collection of hosts (servers) that helps you to aggregate their available resources. That includes ram, CPU, ram, disk, and their devices into a usable pool.
Nodes: Nodes are controlled by the control plane. Nodes are a virtual or physical machine. Nodes are the machinery needed to deploy pods.
Pods: Pods are the smallest units in Kubernetes. A pod is a group of one or more containers, with shared storage/network resources, and a specification for how to run the containers.
Well done! If you've read this guide, you are now equipped to understand the basics of containers, orchestration, Kubernetes and what it can bring to your organization. This will allow you to be on the same page than your colleagues and hopefully, will be useful in your day to day job!
Want to go further? Here is a set of beginners resources about Kubernetes.
Oldest comments (0)