All applications need to evolve and move forward. Many legacy applications can be containerized. The question is, should you containerize a legacy app? Where does it make sense and where doesn’t it provide the path forward for your old app? Remember, “just because you can, doesn’t always mean you should.”
There’s a lot of recent tech press coverage about containers. It’s almost “all containers, all the time.” The application container market is poised to grow to a $2.7 billion market in 2020. Although containers are a small portion of the overall cloud technologies market, containers are forecasted to see the highest growth, estimated at 40 percent through 2020.
When does it make sense to containerize?
It makes sense to containerize a legacy app in VM-based scenarios, where you can “lift and shift” workloads to containers on VMs in the cloud. Entire VMs are “lifted” from the existing environments and “shifted” as-is to a new hosting premises. The downsides are that it is costly and time consuming. Shifting entire VMs moves app clutter along with important business workloads. After the shift, taking advantage of the native cloud management requires significant refactoring. It can also be costly. The long-term remediation, improvement, and viability of the legacy app is still a challenge. The application still needs to be remediated, redesigned, recoded, and repurposed for the specific cloud use cases and platforms.
It also makes sense to containerize a legacy app in the case of Linux shops that are considering OpenShift. In Spring 2020, Red Hat released OpenShift 4.4., an evolution of the Kubernetes Enterprise 1.17 platform. OpenShift Container Platform is a cloud development Platform as a Service (PaaS) built around Docker containers. The platform is orchestrated and managed by Kubernetes on a foundation of Red Hat Enterprise Linux. It offers a cloud foundation for building, deploying, and scaling new containerized applications. It’s particularly attractive for IT shops interested in developing cloud-enabled micro services.
Microservices-based applications are well suited for container adoption. Microservices are an architectural approach to software development based on building an application as a collection of small, independent processes or services that communicate with each other using language-agnostic APIs. Container-based — and open source — systems can be an effective way to develop, deploy, and manage microservices at scale. With their promise of portability, scalability, openness, and consistency, containers can be beneficial to organizations building net-new in the cloud.
Should all apps be containerized?
Not all apps are right for the cloud and not all apps are perfect candidates for containerizing and service enabling. Examples of poor candidates are:
- Old apps built using proprietary languages or technologies. Think of apps with a dependency on a special hardware architecture, such as mainframes. It might be more economical to rebuild these in the cloud.
- Apps that will require a complete rework. Converting your legacy app to a microservices infrastructure requires a complete rethink of the infrastructure, and not every IT department will have the budget, resources, or time to do that.
Changes needed to leverage containerization – whether transforming an existing legacy app or building net-new container apps – are about 35 percent more than traditional app dev costs.
What about monolithic legacy apps?
What if you don’t have the luxury of starting a greenfield software project? What if your app is a legacy monolithic app? Containers work best when the application architecture is developed to be containerized from the outset.
Can you containerize a monolithic legacy app? The short answer is: Yes, but. As we’ve discussed in a previous blog, Docker Containers on Windows are experimental and only available on Windows Server 2019. They bring significant performance and app overheads. Plus, Dockerized Windows apps must be installed and executed unattended. You can’t install an application that requires a GUI at install time. If you’ve lost install scripts over the years, then Dockerizing is difficult. What if you don’t want to re-install your legacy app in a container? What you need is the current state of the legacy application, which includes all the configurations and patches you’ve applied over years of use.
An alternative strategy
You could consider an alternative strategy for legacy apps: an automated, stateful re-install on a modern server and host OS. VirtaMove decouples a legacy app from an outdated OS. The software captures app dependencies as well as its current state, and runs the app natively on a modern host Windows OS or in a Windows or Linux Container Core OS. There’s no need for install scripts or the original source code.
Benefits of an automated, stateful re-install include:
- Closing known malware and security exposures on old Windows or Linux OSs.
- Legacy apps run natively on a supported OS.
- New hardware improves performance. New servers are scalable and run faster. You’ll get more work done with your existing apps.
- Stateful re-installs allow apps to be split and installed on separate servers. Or, apps can be consolidated and installed on a single server. They can also be load balanced.
- The life cycle of legacy apps can be extended.
Extending the life of legacy apps
Using VirtaMove, a stateful re-install on a new server and a new host OS can extend the useful life of your legacy app by years. You can still make progress with your IT plans – reduce operational risk with a modest infrastructure investment, while enhancing performance and other efficiencies – and plan for big changes for the long-term benefit of your organization. It’s a net win, for a modest investment of money, time, and effort.
As a migration partner, VirtaMove has successfully extended the life cycle of thousands of legacy apps for hundreds of customers. If you need to move up with your legacy Microsoft Windows Server and Linux applications or would like to understand more about what VirtaMove does, don’t hesitate to give us a call. We’re pleased to share what we know.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries.