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:
