Forem: Strio

Kubernetes Explained To Product Managers

Lise Pleyber — Thu, 22 Oct 2020 15:56:03 +0000

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.

A New DevOps Workflow: On-Demand Environments

Lise Pleyber — Thu, 20 Aug 2020 08:25:29 +0000

One of the unavoidable question when designing a development workflow in a company is the management of cloud environments. Environments are mostly needed in the development process to perform tests that are either too heavy to be run locally, or that use managed cloud services. Yet, they can also be required to perform demos to customers, for example.

Regarding cloud environments, most of the teams still work under the same paradigm as before the cloud era. They have static environments - a set of dedicated resources running continuously. However, thanks to the elasticity offered by the cloud, a new paradigm is getting adopted by top performers: on-demand cloud environments. It is time-consuming to set up the automation needed to reach that goal, but it allows teams to reduce significantly their cycle time (the time from the moment a new development branch is created, until it is released in production) and deploy safer code.

In this post, I will present and analyze these two different configurations adopted regarding cloud environments in companies, the usual static environments and the deployment of dynamic ones.

Static cloud environments

In companies that have static cloud environments, developers usually work on their machine — i.e. the local environment, and then make a pull / merge request when they feel ready to push it to the staging environment. The code must usually go through the CI and be reviewed before being deployed to staging, either automatically through a CD pipeline or manually by the DevOps team. The number of staging environments varies from one company to another, there can be from one staging for the whole tech team up to one per feature team. In this second case there is usually in addition a pre-prod environment which is the last step before the release to production.

In a classic organization, cloud environments are shared.

Because staging environments are shared, issues arise quickly:

Every deployment on staging needs to be as foolproof as possible, because if the staging breaks it would slow down the whole team. Thus, it takes time for the code to go through the different stages and arrive to Production. It needs first to pass the CI and to be reviewed. Even for a functional preview with the product manager, one's code needs to pass those steps — slowing down the development process.
Staging environments are rarely available. As you can't perform two tests simultaneously, there is usually a "waiting list" to test, slowing down the development process.

Since every developer is only given a specific slot on Staging, they only have time to perform a limited number of test, in order not to block the others. This in turn increases the risk of error in Production.

Thus, a bottleneck emerges. It's especially true if the number of developers per environment is important. But having multiple environments is a costly solution as more static environments means a bigger cloud bill.

Moreover, teams in this configuration usually have a low level of automation. Therefore, significant time — usually from the DevOps team, is dedicated to maintain those environments: clean the environments after the tests, provision them with recent data, and update features from every teams on each environment.

To sum up, having static environments is the easiest system to set up and works well for small teams that have a low level of automation. However, it can quickly create a bottleneck in the development process and be time-consuming for the DevOps team at scale.

Dynamic cloud environments

The best performers in deployment automation set up internal tools to allow developers to spin-up isolated cloud environments from scratch in just a few minutes. Team members can usually deploy a whole environment (containers and dependencies — databases, cache, etc.) on a Kubernetes namespace. This approach is becoming increasingly popular. See for example this article about how Dollar Shave Club implemented it in 2017.

Dynamic environments have a lot of benefits:

The deployed environments are completely isolated — they are not linked to external components, making it risk-free to use them.
Environments can be launched by anyone, and can be shared or personal — solving the issues cited above.
Environments are deployed for a specific task and destroyed once achieved. They don't need to be cleaned and maintained.

How does it work? Usually, you deploy one environment per branch, on which you test before deploying to a shared staging environment. It's useful for functional previews with product managers, code reviews or complex automated testing (integration/load testing). There are a lot of possibilities, on-demand environments can even be use to set up demos.

In the most agile organizations, each developer deploys his own isolated environment.

On-demand environments encourage the autonomy of developers. They're the owner of the code at any time, from its writing, to its testing and finally its push to Production. This reduces the cycle time and helps ensure that the code deployed to Staging is bug-free. Finally, at some point it decreases the cloud bill compared to having one staging environment per team.

However, it's complex for companies to adopt on-demand environments. Indeed, implementing this kind of solution internally is time-consuming for the DevOps team — usually it's a several months project to set up this workflow. Moreover, it's not enough to be technically able to spin up environments in minutes, some other questions need to be answered to make the solution useful:

How to test a feature which spans multiple repositories — i.e. how to deploy the right version of each service on your environment?
How to provision these environments with data while ensuring that they are still isolated?
How to ensure that the organization's members — developers but also product managers and sales — are autonomous on the deployment of environments?
How to manage the cost of this approach? If environments aren't well sized, if some environments are "forgotten", or if the whole application is deployed each time, this approach becomes pretty expensive.

Answering all these questions through on-demand environments makes it a significant project for the DevOps to develop and maintain.

At Strio, we firmly believe in the benefits of on-demand environments for teams constantly wishing to improve their product at fast pace. However, we think it shouldn't be limited to the teams who have the resources to dedicate a whole team to set it up. That's why we decided to develop a turn-key solution that DevOps can configure and provide to the development team. Try it now!

What is GitOps and why it could be great for your team

Alexis Tacnet — Wed, 15 Apr 2020 18:11:56 +0000

Have you heard of GitOps? This newly coined term describes an innovative pattern in configuration management, used to scale deployment on Kubernetes, especially in a microservices environment.

GitOps refers to something that you might already have implemented in your company. "Everyone who successfully did infrastructure-as-code… is the true creator of the concept of GitOps" says Priyanka Sharma, evangelist at Gitlab. GitOps allows developers to perform more tasks related to infrastructure, by relying on familiar git-based workflows and pull requests.

Currently used by companies such as Weaveworks or the Financial Times, the GitOps pattern can bring some great benefits to your organization. Let's dig into this!

What is GitOps?

GitOps is "pushing code, not containers", says Alexis Richardson, CEO of WeaveWorks. The underlying idea behind GitOps is that changes to a cloud-native system can be implemented through Git. It implies that a version control system - such as Git - hosts all configuration and code to deploy on Kubernetes. It is used for automatically creating, updating and deleting system resources such as containers, infrastructure, proxies, ...

With GitOps, developers can manage their operational workflow and deploy on Kubernetes in the same way they perform merge requests or pull requests. While changes to Kubernetes were done previously through manual actions, the GitOps pattern brings automation to the deployment process.

How GitOps works and what it implies for your organization

GitOps ensures that the state of an application or service is reproducible based on the state of a Git repository. Once a pull request is approved and merged, it modifies the state of the repository that will be the trigger to automatically reconfigure and synchronize the live application and its infrastructure.

Let's imagine you want to create a deployment on Kubernetes. You can for example implement a GitOps pattern with Helm charts: you put your charts in a subfolder of your service Git repository, and every time it changes, you can ask for a deployment of the new Helm chart. Basically, you trigger deployments with pull requests and merges.

In order to listen to the changes and trigger a deployment, you need what it is called a controller. This controller will hook to your Git repository and synchronize the deployments every time it is needed. For instance, a controller such as FluxCD is the operator responsible for listening to changes and deploying them to your Kubernetes clusters.

GitOps is not limited to Helm charts only. It can also be a useful pattern for plain Kubernetes manifests, Ksonnet applications, Jsonnet files or even Terraform files and more globally, Infrastructure-as-Code. Having an agent (your controller) fetching your changes where they are defined allows you to set up Continuous Deployment processes easily and quickly.

Benefits of GitOps

GitOps provides significant benefits to your team.

Improved productivity and speed

GitOps allows developers to work with tools they already use and methods they already rely on. Because developers are already familiar with Git, they are able to participate more efficiently to the DevOps process. This common language increases their productivity and avoids useless back and forth with the Ops team.

Better visibility and auditability

GitOps allows for more visibility, transparency and clarity by relying on a central repository. GitOps provides a single source of truth through the version control system, allowing to track changes and issues easily. Teams can easily review the history of changes and identify where an unexpected behavior occurred, which can be of great help in the case of an audit for instance.

More security and reliability

GitOps brings more security to your infrastructure. Git has strong correctness and security guarantees and it allows an easy identification of authorship and origin. This creates a secure and correct definition of what the desired state of the cluster is.

In case a security breach occurs, GitOps enables the recreation of a new system that is independent from the compromised one.

Reduced time to recovery

Since you have a single source of truth in Git, it is much easier to identify and troubleshoot cluster failures. Furthermore, GitOps allows automatic rollbacks, which means you can simply revert any change that caused a failure.

Cost effective

Less downtime and a much better productivity means that IT spendings are used more wisely and with more efficiency. Your team is able to ship features faster and more safely, while dowtime is significantly reduced.

As you can see, GitOps is a very powerful way of creating and managing your modern cloud infrastructure. GitOps can generate many benefits to your team including improved productivity, visibility and system reliability.

Strio, the current tool I'm working on, is based on this pattern, making it even more efficient. Strio allows you to set up more easily your GitOps process: our tool generates, manages and monitors all your pipeline configuration files in your Git repositories, making it a breeze to manage for SRE teams and easy to configure for everyone in the engineering team.