Migrating (and Modernizing) Applications for Open Source Private Cloud

Migrating away from VMware? Planning ahead to move legacy (VM-hosted) and modern (containerized, modular) applications is key to fast (and increasing) ROI

So, you have a new, post-VMware, based-in-opensource cloud platform. Congratulations! Now the bad news: you should have started planning to move applications some time ago.

So take a step back. There are two main points to VMware out-migration. In fact, these are – or should be considered as – the mission statement for almost any modern cloud initiative:

• Making sure your critical contemporary and legacy applications and data move-over seamlessly, and can thrive in your new environment (because they’re paying the bills)

• Making sure new (and probably more cloud native) applications can be built and delivered quickly and surely on the new platform, and can thrive as well (because they’re expected to be paying the bills before long)

• … All on the shortest practical timetable, and with the goal of maximizing:

  • Software quality and reusability, by refactoring where practical to incorporate standardized services, modern design patterns, and components

  • Development toolchain and DevOps optimization, by using application migration and modernization to evolve mature workflows and processes for new application creation

  • Reduced “application operations” overheads. By not just migrating (or building) and deploying apps, but operationalizing them as well for resilience, self-scaling, easy updating, and other tasks

Ensuring these goals are met means planning and executing a set of projects, beginning at the same moment you start shopping for a new cloud solution.

As prior blogs in this series have suggested, there are now viable, open-source-based alternatives to VMware vSphere/vCenter for infrastructure-as-a-service and for Kubernetes (and other forms of container orchestration). And the best of these are engineered and wrapped in services that create a “developer-first as-a-service” experience for cloud users.

In other words, these are cloud platforms and associated services and support commitments aimed at letting developers focus on building and maintaining great applications, and operators focus on strategically enhancing a powerful platform suite to better meet developer needs. Obviously, selecting a platform engineered this way is a good start if you want current and future applications to thrive and keep cloud total cost of ownership low. Lack of such a platform can make the job of application migration more difficult and time consuming, since part of operationalization potentially involves being able to automate platforms and their underlying infrastructure (for example, to scale up a Kubernetes cluster if a critical application is pressed for resources under a traffic surge).

So the platform is not a commodity. But for purposes of argument – the procedures you should follow to enable application migration and modernization remain largely the same for any enterprise-qualified alternative IaaS and/or container platform, or can be adapted. Here’s how AMM works from 10,000 feet:

1. On your existing cloud, use tools to discover all your applications and map their configurations, characteristics, interconnections, and dependencies. The tools are typically complex and use a wide range of techniques, from interactive network traffic analysis to source code and configuration manifest parsing, to create application dossiers that are as complete as possible. Given complete dossiers, the migration/modernization team will search for opportunities to update, consolidate, and shore up security during migration/transformation, and understand and account for business and technical requirements like recovery point and recovery time objectives, essential for bringing things up in the right order and recreating operations playbooks and disaster recovery plans for apps in the target environment. Applications discovered will be grouped by commonalities of architecture, criticality, and other criteria for moving in as “industrialized” and efficient a way as possible. Weak points of application layout (e.g., single points of failure) will be identified for mitigation in the target environment. 

2. Migration and transformation strategies are developed, tested, approved, and toolchains engineered to automate them efficiently. In many cases, organizations are best served by migrating stable, serviceable, VM-based applications and their dependencies, databases, etc., directly from VMware to the new cloud (e.g., OpenStack) -- while potentially taking advantage of the opportunity to leverage available economies where practical: for example, by deploying applications on a more economical Linux variant than previously used. It may also be sensible to consider modernizing select classes of application -- for example, simple websites and other application types may be relatively easy to containerize, perhaps with an eye to running them on a Kubernetes PaaS or serverless framework. Modernization efforts, though, require careful planning and involve much more work. Apps flagged for serious refactoring (e.g., of VM monolithic apps into containerized microservices) will require additional up-front architectural effort, plus coding, automated test, and other technically challenging labor. Each migration/transformation process must be expressed as a workflow/toolchain for speed. Aspects of these toolchains can potentially be reused as the foundation for new software development on the target platform – so a lot of value inheres to this activity.

3. The migration/transformation plan is actioned in phases. For full-on transformation, a three-phase model is often used, with an initial assessment phase of about two months, overlapping with a ‘containerization’ phase, the latter overlapping with a deployment phase on the target system.   

Implementing a mature AMM playbook pays off hugely. Here are some throughput averages for typical enterprise AMM efforts by Mirantis, on behalf of customers:

• An average of 700 applications can be assessed and mapped over three initial months.

• Containerization begins early in month three, beginning with toolchain implementation.

• First candidate apps are deployed on the (in this case, Kubernetes) target environment early in month five. Short-listed applications are all deployed to production by month 10. All apps deployed in month 12.

This, versus the average 30-month+ timetable for modernizing the same applications with manual methods – saving an equivalent of over 20,000 person-hours.

The catch is that most organizations aren’t equipped to do this by themselves. Developing a really reliable migration+modernization playbook means doing this a lot, in the process, training a lot of people, over a span of years. It demands deep familiarity with software architectures of all kinds, system administration on source and target systems, configuration management, development workflow automation, DevOps, disaster recovery, observability, and other skills. So organizations that need ROI from cloud initiatives are well advised to work with partners who have this complex practice dialed-in.

Mirantis’ Daniel Virassamy recently discussed why application modernization and migration are essential to cloud ROI in a talk called "Migrating applications to open source private cloud." You can watch the recording to learn how organizations can move to efficiently assess current application requirements, then modernize and migrate apps at industrial scales, with predictable timelines. And you’ll see concrete examples of why a well-conducted modernization/migration effort can be an essential foundation for future modern application development by your organization.