Kubernetes migration: 4 secrets to a smooth move
Blog: The Enterprise Project - Enterprise Technology
Migrating an existing application to a Kubernetes environment can deliver plenty of long-term benefits, but it’s not a decision to be made lightly. Like any significant technology investment, you should know what you’re getting into – and why – before diving in head-first.
“Don’t decide to migrate to Kubernetes and only then figure out why you want to do it and how you’re going to go about it,” says Gordon Haff, technology evangelist at Red Hat. Haff notes that not every organization or application will need the power and scale Kubernetes offers, for example, even if you are running containers. There might be simpler ways to automate your software delivery pipeline.
Moreover, remember that this is not merely a technical choice, especially if you’re migrating a monolithic application. It’s as much a people-related decision.
“Kubernetes migration is not just about technology, but people and culture also,” says Niraj Tolia, CEO at Kasten. “It’s critical to make sure there is buy-in, alignment, and excitement among the Dev and Ops teams responsible for the transition. Ensure that responsibilities are clear, and don’t forget training support.”
And that’s really the underlying “secret” of successful, efficient Kubernetes migration projects: They’re grounded in a clear strategy, a strong team and culture, and the proper resources to execute the plan. Trial and error? Sure, that’s par for the course with technology adoption. Trial by fire? That sounds painful, even if you make it to the other side.
[ Get the free eBook: O’Reilly: Kubernetes Operators: Automating the Container Orchestration Platform. ]
Kubernetes migration: 4 keys to success
Haff and other IT leaders shared with us four keys to an efficient Kubernetes migration so that you don’t get burned.
1. Take a “white glove” approach to start
Kubernetes affords greater speed and scale, but that doesn’t mean you need to go full-speed right from the start. Don’t fall for the “go big or go home” trap.
“Think twice about a big-bang migration,” Tolia says. “Start with the white-glove treatment, migrating low-risk projects carefully. Be sure to celebrate and evangelize the successes.”
Know your organization and team and pace yourself accordingly. If you’re in too much of a rush, you’ll likely be less efficient and add scope to the process.
“Like any migration, incremental wins and lowest-hanging-fruit approaches will build confidence in the migration,” says Ravi Lachhman, DevOps evangelist at Harness.
Taking a milestone-based approach – rather than setting a single “finish line” at some arbitrary point in the future – is also a good idea, according to Tom Manville, engineering lead at Kasten.
“Using frequent milestones is key to driving any migration and is especially important when moving applications into Kubernetes, since this often represents a fundamental shift in the way infrastructure is run,” Manville says. “Break down the migration into manageable parts and clearly communicate a timeline to all the stakeholders. Decide what components may be completely swapped for their cloud-native replacements and decide a day to cutover.”
[ Want to learn more? Get the free eBook: Getting Started with Kubernetes. ]
2. Pick the best candidates
Not every application is a great fit for Kubernetes, as Haff notes above. Make sure you prioritize those that will benefit most and start with the strongest candidates among your application portfolio.
Aside from greenfield development projects, this will likely mean some rework of the application. So one way to identify candidates is by looking for apps where modernization would make big-picture sense.
“Depending on the level of effort and the amount of technical debt to address, you may need to rework/rewrite the application,” Lachhman says. “Migrating to Kubernetes is a good time to re-architect applications to fit more modern architectures and infrastructure.”
“Lift-and-shift can be okay, but focus on net-new cloud-native applications or refactoring,” says Tolia, the Kasten CEO. “Otherwise, you will only see increased complexity in Kubernetes without benefiting from its deep functionality.”
Raghu Kishore Vempati, director of technology, research, and innovation at Altran, recommends applying the “measure twice, cut once” principle to your migration, especially when it comes to dependency mapping.
“If applications are already containerized, deploying them on Kubernetes and managing dependencies between the various components of the applications is relatively simpler,” Vempati says. “However, for applications getting containerized for the first time, it is important that the dependencies and access to them are clearly mapped and planned.”
Vempati shares a common example that needs to be properly evaluated: Containerized applications running on Kubernetes that depend on resources that are not containerized and are running on the same cluster. “Such dependencies must be very carefully considered, and their play within the overall application flow must be validated several times,” Vempati says.
Picking the right app is crucial to an efficient migration project; don’t try to unlock “hero” status on your first go-around, Lachhman advises. A first (or early) migration should help simplify tougher projects in the future; that doesn’t work if you start with the tougher project.
“Finding a good candidate for migration can build platform expertise so that when the time comes for more complex applications, that part of the equation is more solved,” Lachhman says. “Kubernetes works best with generics and stateless applications. Migrating containerized applications will build confidence in the target platform. More complex applications that require clustering, load-balancing, and replication will take more specific expertise to be created in Kubernetes via Operators. Those applications are most likely bad candidates for a lift-and-shift model or minor tweaking/re-packaging.”
Let’s explore two more best practices:
3. Make sure your software delivery pipeline is ready for prime time
Having a solid CI/CD pipeline already in place will help streamline your Kubernetes migration.
“With containerized applications, one of the advantages is the ability to have common, consistent deployment across multiple environments during the SDLC process,” Vempati says. “It will be extremely useful if continuous deployment is planned upfront and executed for migrating to Kubernetes.”
Kasten CEO Tolia concurs: “Make sure that the support technology stack is in place, particularly easy-to-use CI/CD pipelines, which will be critical to a successful transition.”
The core reason for this: A successful Kubernetes migration will mean that you’re now deploying and making changes faster and more frequently than you did in the past. A rigid delivery pipeline will probably start to crack. If you’re not already practicing CI/CD, this is an opportunity to start.
Kubernetes will stretch other parts of your SDLC process since you’ll now be able to deploy more quickly. With the iterations and velocity during an initial migration, embracing a more agile culture and investing in non-functional requirements like continuous delivery should happen organically, Vempati says.
Teams with a robust CI/CD pipeline already in place might be thinking: Well, duh. But that’s not every org or team. Vempati notes that some software groups eschew continuous delivery, for example, because they don’t see it as valuable to their application’s core capabilities.
“What must be understood is that it accelerates the migration process significantly,” Vempati says. “With a well-defined continuous deployment [pipeline] in place, the time taken for a complete migration can be significantly reduced.”
4. Consider a commercial or managed platform
Back to that fundamental question: Is Kubernetes right for your organization or application? The answer for many teams might well be “yes, but…”
“Maybe Kubernetes is right for you, but you don’t really have the skills to manage it all yourself,” Hass says. “Consider a Kubernetes managed service, ideally one that gives you portability among cloud providers. Finally, even if you do decide that operating on-prem Kubernetes is right for you, there’s no need to set the difficulty level to hardest. A commercial open source container platform integrates and tests both Kubernetes and other related tools – monitoring, CI/CD, security scanning, and so forth – so that you don’t have to.”
[ Read also: OpenShift and Kubernetes: What’s the difference? ]
This gets back to what Lachhman mentioned above about not trying to be a hero. Even superheroes have help sometimes.
“The goal of migrating to Kubernetes is most often to accelerate the development of applications and scale them and not necessarily to start setting up the cluster from scratch,” Vempati says. “The best approach to move faster to Kubernetes is to first pick a managed Kubernetes service on one of the public/private cloud platforms. This helps the developers and Ops teams to focus on the deployment of applications [while offloading a lot of the under-the-hood work].”
[ Kubernetes 101: An introduction to containers, Kubernetes, and OpenShift: Watch the on-demand Kubernetes 101 webinar.]