DEV Community: Lise Pleyber

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!

An Overview of Environments in Software Development

Lise Pleyber — Thu, 30 Apr 2020 10:32:46 +0000

If you work in software development or are planning to, you've probably encountered environments at some point such as local, dev, test or staging. Yet, the difference between them might be unclear and you could wonder what their purpose is. Additionally your company may refer to them with different names, making the whole thing even more blurry.

Because each environment has its own properties, you need to use them accordingly. To help you do that, we will give you an overview of the different environments that are commonly used and a few best practices.

As microservices are becoming the state of the art, we will mainly illustrate their use with the case of a web app with a microservice architecture (by the way if you don't know what microservices are, have a look at this article!).

What is an environment?

Now, let's begin to dig into the subject! First, let's define what an environment is. An environment is a set of computer resources, real or virtual, that runs your code.

In the cloud era, and in our example, an environment is usually a system of virtual machines that runs your containers and carries the infrastructure needed. Under this paradigm, an environment is mainly defined by:

The stored data it uses (storage)
The processing power of the virtual machines (computing)
The communication between the pieces (network)

Except for the final environment - Production, the goal of an environment is to allow the development teams to test their code and make sure it behaves as expected.

But why are there so many different environments? Because you will test your code step-by-step, each time getting closer to Production. The main idea is to find, at each stage of the development process, the right balance between having an environment that is easy to set up, not too heavy (which would be really expensive), and the ability to perform efficient and realistic tests on it. Of course, this balance will vary greatly from one application to an other.

The local environment

The local environment, sometimes called 'development environment', is where development happens. Each developer has its own. It serves as a sandbox to work and iterate on the copy of the code base that they imported from the source code repository. Most of the times, the local environment consists of the developper's computer. It might also be a virtual one.

This environment doesn't need to be close to the production environment. If you are working on a software for an embedded system with low processing power for example, your local environment could totally be a powerful desktop computer - it's even better. The goal of this environment is to allow developers to develop and test their code through unit tests quickly.

The most challenging task regarding this environment is to design unit tests, especially for microservices. It might seem straightforward as microservices are supposed to perform a single business or infrastructure functionality. Yet, as they mainly rely on interactions with databases or services, the term 'unit test' might seem counterintuitive, as Cindy Sridharan pointed out in this great article. Therefore, a unit test at this stage can consist in testing the interface of the microservice (i.e. how it interacts with others).

Best practices

The local environment has to be light but with a good processing power Well designed unit tests / interface tests need to be performed, automated whenever possible
Developers should design the tests themselves and keep them updated Developers should commit frequently - but only once the code succeeded the tests!

The test environment

Test environments, sometimes called 'QA environments' or 'integration environments' are where most of the tests are performed - including integration tests, hence its secondary name.

These environments and tests are usually designed by a dedicated team - the QA engineers. Deployment on this environment and the tests that are associated are usually part of the CI process, and as such, should be automated. The tests performed are either functional or non-functional.

Functional tests in this environment are usually integration testing, i.e. how the microservices perform as a group. In a complex architecture, performing large integration tests (in terms of numbers of microservices included) can prove to be really costly and time-consuming.

Non-functional tests are more about testing the resilience of the system against traffic and charge: load testing, stress testing, endurance testing, etc...
Overall, there is an arbitrage to make on the similarity of the environment with Production, and on the number of tests and speed of integration.

Best practices

It is of utmost importance for the team responsible for those environments and tests to document all actions. This is key for other users to be able to replicate the environment.
Automate test and deployment on the test environment with CI.
To keep your velocity, be realistic on the amount of integration testing you can do.

The staging environment

The last environment before the release to production is usually the staging environment but it can also have different names like 'pre-production' or 'acceptance'.

It is the final step before Production and, as such, is used to test in conditions as close as possible to Production. It can also be used to perform a demo in front of prospects, or to show a prototype to a product manager or a designer.

Usually, end-to-end tests, which are tests of the whole system, are performed in the staging environment. Teams also use the staging environment to test all the installation and configuration scripts before they're applied to a production environment. As it is closer to production than test environnements, some performance testing, particularly load testing, are tested in Staging.

Because staging environments are a wide subject, we wrote a whole article about best practices regarding these environments, but here are a few of them:

Use anonymized data from production.
Fake trafic.
Limit the access to each staging environment. For instance, implements slots per team, to make sure that only one team at a time uses the environment. This prevents people from accidentally screwing with each others' tests.

The production environment

For a long time, the production environment was used only as the user-facing environment.

However, it is now trendy to perform more and more tests in production. It began with tests such as A/B Testing. A/B Testing is not about testing if the code is bug-free, but making design and UX experiments.

These days, companies begin to test the resilience of an application in production. The idea behind it is that there is nothing as close to production than production. It makes sense because in Staging, the size of your cluster will be different, configuration options will be different, there is no monitoring, etc. Also, maintaining a staging environment costs a huge amount of money and energy...

Moreover, if you have the ability to roll-back quickly, is there any risk in testing gradually in production? That's why some companies begin to neglect heavy staging environment and prefer practice such as Canary testing.

Wrap-Up

As said at the beginning, there is no single testing process that fits all. Each project must find its balance.

However, with the rise of distributed systems, the increased complexity of applications and the increased velocity of deployments, some practices seem impossible. You can't expect to test a system as a whole for each change of tens of microservices, you can't expect to fake a huge production environment on staging, and you can't expect several teams to test on the same environment without some interferences.

Therefore, it might make sense to test in pre-prod only specific elements and focus on keeping your developers as agile as possible, and lean back on a strong ability to roll-back and to deploy step by step. At Strio, we try to help companies doing that by allowing developers to spin up environment when needed, giving them agility and independance.

I hope this article made things clearer for you and that you began to grasp the difficulty of pre-prod testing for microservices!

Best Practices for Staging Environments

Lise Pleyber — Mon, 27 Apr 2020 14:54:25 +0000

Let's talk about staging environments.

Staging is the last step before production. It simulates the production environment as closely as possible. Staging is crucial for bug detection, as it's the last line of defense against bugs. Staging can also be leveraged for other objectives: it can be a great way to demo new features, or even show to a customer what changes on your app could look like.

But as applications are getting complex and tech teams scale, staging environments can become somewhat difficult to manage.

In this article, we want to give you a few insights to help you manage your staging environments and to encourage you, when relevant, to set up on-demand environments. Sounds exciting?

Why is my staging environment difficult to maintain and use?

In the best scenario, the staging environment works perfectly, responsibilities are clearly defined and it allows engineers to test in conditions that are very close to production.

But in some cases, working with a single staging environment can be slightly more difficult. In particular, as scaling occurs, it becomes much harder to work on a single environment.

When your architecture becomes distributed, with dependencies and connections between services (micro ones or applications), spinning up a production-like environment on your laptop to test a new feature is not an option. Engineers have to stub and mock the other services in order to test quickly, but that's often too hard to put in place and very time consuming when the stack has some legacy.

The staging environment is often used to test the integration of new features in a production-like environment. If this feature breaks something, a new patch has to be shipped through the long CI process. During this time, no one can call this bugged service, no one can test the features he wants to ship to production, creating a development and deployment bottleneck for everyone.

Data is also a huge issue in this situation. Maintaining a good dataset in Staging, with the right information and set of edge-cases, is time-consuming and becomes harder and harder when the deployment rate gets higher.

All this results in inefficiencies and a lot of frustration. Release a single feature might take a long time, and the process might not sufficiently prevent bugs from happening in production.

So what should we do then?

Tips for managing staging environments

Avoiding difficulties with staging environments requires to act at different levels: technical of course, but also organisational or cultural.

Taking good care of staging environment

A first step is to facilitate the maintenance of your Staging. The good news is that it doesn't require complex or technical new processes! Most of it can be solved through improved communication and responsibilities.

Make sure that you test efficiently your code before going into Staging. This will reduce the risk that the tests fail in Staging.
Clearly define infrastructure ownership.
Limit the access to each staging environment. For instance, implements slots per team, to make sure that only one team at a time uses the environment. This prevents people from accidentally screwing with each others' tests.
Involve developers in the process of maintaining the environment: giving responsibilities to developers incentivizes them to take care of their playground.

Consider having multiple staging environments

With only one environment, each team has to block Staging for its own testing. This quickly becomes difficult to manage.

A solution is to create multiple staging environments, so that each team can use its own environment.

This seems like a great solution, but can lead to various issues:

Time and energy to set up new environments might be very significant. Some manual coding has to be written for each new Staging, even with some levels of automation.
Data sharing might still be a problem as it might be difficult to completely isolate environments from one another. This means that they might share the same data which can result in side-effects when it is modified.
Cost! Just adding up environments will necessary lead to much higher cloud costs.

Create on-demand environments

Another solution is to create on-demand, disposable test environments that will be used to test every code change.

This way, it will become easier to test isolated features with confidence. This is definitely great for developers, and can also be powerful for product owners or even salespeople, who will be able to create personnalized demos for their leads!

This configuration should allow you to set up a new environment in only a few minutes. In terms of costs, rather than having 24/7 environments consuming cloud credits, the environments have a specific lifetime that limits the costs.

There are multiple ways to set up this kind of disposable test environments, but we advise you to go with the tool we built, Strio.

Strio creates on-demand test environments, based on technologies you already use, such as Kubernetes and Terraform. It asks for your dependencies and deploys them with the new version of your service to enable full integration testing. To rely on production-like data, our solution contains an anonymization function, so that you can comply easily with GDPR and other privacy regulations.

Ready to try Strio?