Migration to Kubernetes – the process, pitfalls, and success

Just ask George R.R. Martin: the hardest thing when starting to write a book is the inertia of the beginning – what are the first words of the first page? The same roadblock applies when you decide to migrate your IT infrastructure to Kubernetes: the most challenging part is getting started.

In this article, we make it a little easier for you by explaining how to start this ambitious project, what steps you should not miss, and what are the key elements to succeed in migrating to Kubernetes.

In this blog post, we want to talk about the pitfalls of migrating to Kubernetes, what to watch out for, the quick wins, and the best practices in general.

Planning the Migration – Where are you coming from?

We are assuming you have already decided to migrate to Kubernetes. The first question then is: what are you migrating from? Are you moving from physical servers in an on-premise data center? Or perhaps standalone servers in a public or private cloud? Or even an already-containerized set up in the cloud? Each option will need a slightly different approach. And if you have not already containerized your apps and infrastructure, step zero really should be to do this first, so you can take advantage of Kubernetes symbiotic relationship with containerization, especially Docker.

Another issue to watch out for: If you are migrating monolithic applications that were designed on the old client-server architecture, one important consideration is how to refactor your applications – breaking them down into microservices to enable them to work optimally on containers. Rani Osnat, VP of strategy at consulting firm Aqua Security says: “Start with simpler, smaller applications. Taking a 2GB monolithic application and containerizing it as is will create issues in deployment and runtime since the container stack wasn’t made for this use case. Try breaking up your application into smaller logical services, so that you’ll benefit from better speed of deployment, resilience, and updatability.” You can read more details about microservice architecture here, and more about application refactoring in this great article.

Your Kubernetes needs: During and After Deployment

1: The people and skills needed to support your Kubernetes setup

In the last decade or so, there has been a huge increase in the number of tools used to embed and enable the use of cloud-native architecture and technologies: new cloud platforms, orchestration tools, containerization tools, and monitoring apps. All this new stuff means that today’s developers (and the closely related DevOps role) need to learn and be proficient in many more tech tools.

You will definitely need to keep in mind that you may possibly require your IT engineers and developers to improve their skills in Kubernetes and other cloud-native architecture tools. This is especially true if you go all-in and decide to host and manage your Kubernetes clusters yourself, but much less true if you decide to utilize a hosted-Kubernetes setup. In fact, with CloudPlex your developers do not even need any technical Kubernetes know-how.

2: Whether to use in-house clusters or managed services

This is also tied to the previous point but merits further discussion on its own. Your decision to either host your own Kubernetes cluster or use a managed Kubernetes service will depend on how you answer these questions:

Do you have enough Kubernetes know-how internally? Kubernetes is often reputed to be ‘simple to grasp, difficult to master’. That means it is easy to understand the basics of Kubernetes, but actually making it work in a complex environment is no job for a newbie. This is especially true when you have to use advanced Kubernetes features such as dynamic parameterization, proper use of RBAC (role-based access control), and autoscaling.
Do you appreciate the pain points that come with a standalone Kubernetes, and how can a top-tier managed Kubernetes service provider help resolve these? As an example, read through this explanation of typical Kubernetes blockers that the average migration has to endure, and how Cloudplex can help resolve each of them.
And of course, if you manage your own Kubernetes cluster, you will need to buy your own infrastructure. Even if you set it up in your cloud infrastructure, you are still missing out on the efficiencies that a tool like Cloudplex can offer, thus reducing your footprint in terms of deployed servers.

3: The cost of migration and continuing support

And lastly, we, of course, cannot forget the cost. “What cost, isn’t this supposed to be a non-factor when I implemented an open-source platform?”, you may ask. Well, yes and no. Yes, there are no software-licensing fees. But there are additional hidden costs.

The first of these is the aforementioned cost of upskilling your developers and DevOps teams to gain the new skills needed to support your shiny new Kubernetes clusters. In fact, if you are going to fully host it yourself, you may need to hire a DevOps guru with this skill set. Budget at least an extra $100k a year for this.

Another rarely-appreciated factor is the opportunity cost of learning on the job, where your dev team members trade away productivity for learning time. As explained in this article: “When developers learn best practices on the job, this takes productive time away from other key activities as there are limited hours in a day. This means developers are spending less time writing application code and more time working on the cloud-native infrastructure (think crafting YAML files for Kubernetes, tweaking and building Docker files, and reading up on Istio best practices). The time and mindshare spent eats away at what businesses want their developers to be doing: writing core business code.”

I’m having second thoughts on Kubernetes

Fear not! You should absolutely implement Kubernetes and reap the rewards of rapidly orchestrating and managing your containers. All the headaches mentioned above are those you will face in case you go it alone when implementing Kubernetes.

However, if you instead use a managed Kubernetes service, then you are firstly using experts who you don’t have to hire full-time. Next, you are saving your dev team the added hassle and lost productivity of having to learn a set of new tools and platforms. And lastly, you don’t have to hire a new DevOps resource.

Actually, with a developer-friendly Kubernetes platform like Cloudplex, you don’t even need to learn Kubernetes at all! Check out Cloudplex’s comprehensive feature list to learn how to massively simplify your Kubernetes rollout, and sign up for a free trial here.