A few years ago, lift and shift to the cloud was all the rage––with the companies building those solutions being snatched up at exorbitant selling prices to the biggest cloud vendors. Nearly a decade, and multiple failed lift and shift migration stories later, we have now learned the hard way that slow and steady wins the race.
Therefore, it’s important to start by saying that there is no magic pill for migrating to the cloud or cloud-native infrastructure like Kubernetes. In a recent conversation I’ve had with engineers from one of the world’s largest banks I learned about their failed attempts––many resources and much time were spent on their cloud strategy with the most expensive lift and shift platforms and promises. A year later, and millions of dollars in the hole, the project was an utter bust.
On the Kubernetes for Humans Podcast, I heard similar tales from guests like Pavel Brodsky, Developer Platform Group Manager, who shared with us the challenges Forter faced during their migration.
Why is this still happening?
The honest and real answer is that applications that were not born cloud-ready, will simply not port well, and there is just too much proprietary and custom business logic to create a universal way for achieving this. Lift and shift solutions obfuscate that never-truer fact.
And honestly, this isn’t anything new. When I was an engineer at eBay Israel, which builds the core of the eBay platform, I arrived after the process had begun to migrate their legacy monolith to a microservices architecture, and the project continued well after I had already left. In all honesty, some parts of the monolith are still in use today – years later, in the parts of the system where it was too difficult to transition.
That’s why I realized that a real and honest guide on how to migrate to cloud-native technology is still more relevant than ever. One without hyperbole or fake promises, the best-proven method for migrating to the cloud or cloud-native technology, that will enable long-term maintenance and scale. Over the years I have put together a tried and tested primer for migrating to the cloud, but this is also applicable to Kubernetes.
Below we’ll walk through the steps organizations need to take to migrate to Kubernetes and cloud-native stacks. This is the first post in a series that will start with providing an overview of the considerations involved when evaluating a migration to Kubernetes, and in consequent posts will dig deeper, and provide practical, tried and true methods to get there.
Migrating to Kubernetes: The Definitive Failproof Guide
While this doesn’t promise a migration that isn’t rife with some pain, it is the most reliable and proven way to truly migrate to cloud-native systems effectively, that will be sustainable in the long term. Another important aspect to keep in mind is that much of this also begins with education and culture inside your organization. Fostering an engineering culture of extensibility, elasticity, and scale, is the beginning of democratizing your underlying architecture choice.
Below we’ll walk through the step-by-step process of migrating to Kubernetes successfully.
STEP 1: Choose Your Cloud Provider and Kubernetes Distribution
Like with all migration processes, we cannot emphasize enough the importance of putting in the time to do the proper research and make the right selection of a suitable cloud provider and Kubernetes distribution. This needs to be an educated decision that will map directly to your organization’s needs & cultural dynamics.
This choice will depend on your specific requirements, such as scalability, ease of use, support options, and integration capabilities with existing tools and systems. When choosing your Kubernetes distribution, these functions will serve to support the applications you migrate to this environment in the long term, and should also focus on future development and services your applications and teams will require.
STEP 2: Assess and Plan the Migration
This involves a thorough assessment of your current infrastructure, applications, and workflows––this is both a technical and cultural assessment of your stacks, team topologies, and practices. Identifying dependencies, bottlenecks, and potential challenges is crucial to a successful migration, and understanding how to mitigate issues as they arise.
You should also establish clear migration goals and timelines, and decide on the migration strategy (e.g., lift-and-shift, refactor, or re-architect).
Lift and Shift
The “lift and shift” approach is suitable for applications that are written and architected in a way that supports cloud-native operations, albeit, they are not currently running in Kubernetes. Lift and shift is suitable for containerized applications, or those that had the cloud in mind when written and deployed, even if they are currently running on alternative platforms.
Refactor
Refactoring of your applications is needed when certain code changes are required to enable your application to properly run in a cloud-native environment. However, the application architecture is largely suitable for the target cloud-native environment to which it is planned to be migrated.
Re-Architect
Re-architecture involves the whole enchilada. This includes rewriting parts of the application to be suited for cloud-native runtime, and the architecture so it can properly scale and operate in its new and highly elastic environment.
Like with everything in engineering, it’s important to reserve time in the process for testing each component thoroughly to ensure they work as expected in the new environment, and not assume all your work is complete once the application has been deployed to the new system.
STEP 3: Set Up the Kubernetes Environment
Once you have chosen a provider and planned your migration, the next step is setting up the Kubernetes environment. Although summarized in a single sentence, this of course entails quite a bit of work for the environment to reflect the architecture, scale, security, management, and operations capabilities your applications and organization require.
This includes configuring the cluster, setting up storage and network resources, and ensuring security and compliance measures are in place. If you do not currently have this expertise in-house, it is worthwhile to work on acquiring it through different accreditations like Certified Kubernetes Administrator (CKA) courses, or work with external service providers who can augment your in-house knowledge.
STEP 4: Migrate Applications and Data
I’m not going to lie, while this step receives the exact same weight as the other steps in the process, this is likely the most time-consuming and hard part of the actual migration. It involves the actual execution of the migration of applications and data to the Kubernetes environment.
This is the point at which you take your applications and re-architecture to suit the cloud-native environment. Migrating databases or other data stores and the applications themselves through lift and shift can take a few days to a few weeks. Rewriting or rearchitecting applications can take up to a few months for a single application.
One good practice is to start with applications that are cloud-ready, and not business-critical to see that you can successfully migrate them to Kubernetes. This will enable teams to familiarize themselves with the specifics of the new systems, environments, and applications running in production, without fear of customer impact.
It’s essential to do this in phases and not migrate too many applications all at once––as then it will be very difficult to isolate issues as they arise. Build up your team’s confidence step-by-step.
Once an application has been deployed to the new system, this is the time to thoroughly test it, and ensure it is running as expected without any degradation in performance or service.
STEP 5: Optimization and Continuous Improvement
Congratulations you have applications running in Kubernetes! But hold on celebrating just yet. Our work doesn’t end here.
After successfully migrating to Kubernetes, the focus shifts to optimization and continuous improvement. This includes monitoring performance, scaling resources as needed, and continuously updating and improving the infrastructure and applications based on feedback and evolving requirements. This is true for any system, but particularly true when migrating to new systems that perform differently than previous systems. This work will be based on the outcomes of the thorough testing and monitoring of your applications running.
This is not a one-time step, this is essentially the rinse-and-repeat step of Kubernetes migration, which will ultimately be the lion’s share of your operations in the long-term. Oftentimes the perception is that the hard work lies in getting your workloads onto Kubernetes, but it cannot be emphasized enough, that this is just the very first step (a big one – so congrats!). Maintaining your systems in the long term, particularly as they grow and evolve should be something you will need to dedicate engineering resources to, and this is a journey, not a sprint.
Where Things Break Down – And How to Overcome These Challenges
When you have led and supported many such migrations over many years, even decades now, there are often recurring patterns and pains that are expressed as blockers to successfully completing the migration. The most commonly voiced concerns are around the lack of internal knowledge before and after the migration, to ensure that it can be completed successfully and managed and maintained properly in the long-term.
When looking at the technology stacks the teams are working with, how well the existing tooling will support such a transition, and again back to the lack of knowledge––how great of a learning curve will there be with adopting new tooling? The rest is largely process-oriented, what needs to be done, by whom, and the project management around it – how long will it take, who makes the decisions, and will hard deadlines be attainable or are they wishful thinking?
At Komodor we helped support many such processes for some of the largest legacy systems out there, and we often encountered a dissonance between the perception and the full reality of the gaps and work involved with achieving a successful migration.
With the step-by-step guide above I tried to translate this chasm into explicit tasks that help overcome the challenges of Kubernetes migration. Much of this requires bridging the knowledge gap before setting out on such a journey, which could potentially not be the right fit for your organization at all.
Once you have a well-defined plan, the right tooling and knowledge, and understanding of realistic deadlines, the task of migrating to Kubernetes becomes a lot less daunting. It provides predictability from a time, resource, and cost perspective, making it easier to translate to relevant stakeholders, and ultimately ensuring it will have a successful outcome.
In our next posts in the series, I will dispel the fear, uncertainty, and doubt around migrating to Kubernetes, and provide more practical tips, tricks, and procedures to help you plan and execute the migration successfully.
