Four Best Practices to Migrate to Kubernetes (Part 1)

Kubernetes has evolved into the leading platform to build your microservices systems. Given its increased maturity over the past few years as well as the robust ecosystem which has been built around its technology, Kubernetes has become more production-ready than ever.

Nevertheless, it still has its own unique set of challenges. In particular, it brings a lot of complexity into play with its adoption. For those who do not have much expertise working with Kubernetes, migrating to its systems may introduce new challenges.

This post will outline the best practices for migrating to Kubernetes, from my personal experience of working with it daily for the last four years, aiming to help make what is sometimes a tough migration significantly less painful.

Taking the Kubernetes Plunge – Tips for a Smoother Migration Process

Below we’ve rounded up some tips, from firsthand experience, that we’ve found to be the optimal way to bring your applications into the Kubernetes ecosystem.

1. Evaluation of Development Processes

If your company is not on Kubernetes today, there is a very high likelihood that your development and engineering processes are significantly different than working with this complex system. It is most likely that your engineering teams are working with different technologies, and the end-to-end development and deployment process usually takes longer. This is because with non-Kubernetes based environments, changes, even small ones, are harder to implement and integrate into applications and production.

Working with Kubernetes, on the other hand, is meant to be extremely agile and more elastic. Changing a version is as simple as changing a single line of code with a fast to deploy to production, making it a significant enabler of more agile development processes.

So the first step to ensure a smooth migration to Kubernetes is to understand the fundamental differences between your current engineering processes, and build a plan for evolving these processes to be more suited to highly distributed, high-scale microservices systems. Give this time, and prep the team well before you get started, not after the fact, so that they can understand what they’re getting into.

2. Evaluate Your CI/CD Pipelines

CI/CD sits right in the heart of the entire engineering operation, and therefore deserves a specific focus. The difference between running Kubernetes and any other platform for your applications impacts all of the major parts of your code deployment processes, from the packaging (if you weren’t using Docker before, now you’ll need to Dockerize all of your applications), versioning, and ultimately deployment to production.

When you are not running your applications on Kubernetes, this can be a much more cumbersome and even error-prone process. In other environments, you often need to write extensive scripts.

Let’s take the example of a version upgrade – many times, for even such a simple task, you’d need to copy the new files to the server you’d like to upgrade to, and restart manually. This requires the expertise of many people in the process – not to mention the required permissions to access said server, just to deploy a new version.

In Kubernetes, a similar change would solely require a change to the specification of what you would like to deploy. A brief aside, Kubernetes is the extreme of infrastructure as code – in that you define everything in a YAML file, describing your entire app and its configurations, therefore, deploying it is merely changing a line in this specification.

The bottom line here is – be ready for the changes that will affect your CI/CD operations. These often may be significant changes to accommodate a Kubernetes operation.

In addition, even though K8s enables you to make changes and updates much more rapidly, this can also be a double-edged sword. You’ll need to ensure you have the proper safety measures and processes in place, all while not slowing down the system that is intended to move fast and provide a greater level of autonomy for your developers.

A good read would be this piece by Itiel Shwartz: How Culture Impacts Technology Choice: A Review of Netflix’s Use of Microservices).

3. Deciding On a Commercial Offering or a Self-Maintained Open Source Operation

Kubernetes is indeed an open source project that you can self-manage on bare metal or virtual machines. This will require you to manage the Kubernetes control plane, although a certain level of expertise in Kubernetes is necessary that comes with time and experience using the platform, which isn’t always the case for those who are new to managing operations on K8s.

Another popular option is using a commercial offering from one of the large cloud providers, whereby each has their own service – Google Cloud, AWS, and Azure. These offer a very easy and straightforward way to get a cluster up and running in a matter of minutes.

This enables teams to put aside all of the expertise required with managing the infrastructure and low-level primitives of managing a Kubernetes cluster, and frees you up to focus on deploying your applications, their business logic, and eventually what’s important for your company.

4. Take a Step-by-Step Approach

Since Kubernetes comes with a high learning curve, a good practice is to begin your foray into Kubernetes by migrating low-risk projects, with an emphasis to certainly not begin with production critical projects (despite these many times being often the projects that will reap the most value from moving to a more agile operation).

Internal projects are ideal for your first projects to move into Kubernetes. These low-risk projects can help you to learn the complexities of Kubernetes through real-world experience, and ensure that you have the right tools and processes in play, as part of your engineering team.

TL;DR

Migrating to Kubernetes can introduce many benefits for engineering organizations looking to build their applications in a microservices architecture. That said, making the move is not an easy undertaking and should not be taken on lightly.

With the proper preparation, both from a process and culture perspective, as well as identifying the right projects to get started with, you can decrease the risk to your organization’s core business, and get around what sometimes can be a steep learning curve.

Once you have mastered Kubernetes, after learning its internals from non-business critical applications, you will be ready to migrate your mission critical applications and reap the real benefits of increased developer velocity and agility.

In this post we’ve covered the high-level considerations of the planning, as well as why, when, and how-to aspects of migrating to Kubernetes.

Curious to learn more about our technical best practices for managing applications on K8s in the long run?

Check out Part II of our Kubernetes Best Practices series.