When running applications on large scale, you’ll not only be pushed to scale-up, but also consider scale-down. Containers are tuned for performance than any other existing technologies that fit the purpose to scale up/down. A lot of initiatives are taken around container platforms that enables migrating legacy applications to container platforms that can run alongside cloud native, microservices and serverless functions.
- Can I containerize my legacy applications running on physical and virtual machines?
- Is it effective and been done before?
HCL's answer to both these questions is ‘yes’. An application that has really not been designed to run in a container, can be deployed utilizing Docker platform. And the effort required to modernize the environment is often worth doing it.
The article takes you through the basic ideas that we formed to move legacy applications to containers. It also discusses what type of container management method is best for legacy applications and explains the suitability and unsuitable criteria in relation to containerization.
Why Should We Run Legacy Apps in a Container?
Business applications were previously run directly on a physical server, then came virtual machines (VM). Now we can containerize them, migrating them from virtual machines in containers. The legacy apps that ran on physical servers still remain useful for many enterprises. These apps have been growing their user base organically and have well established their presence. Enterprises use infrastructure hardware to run software that enables businesses to interact with customers via applications. They shift from physical to virtual machines to containers, but the lifetime of an application still exists.
Enterprises with such legacy applications reach out to HCL to help adapt them to container infrastructure platforms (ContainerizIT) when possible. It is more efficient than developing an entire application every time a new infrastructure is available.
Containerization has two approaches that can be adopted while dealing with legacy applications:
- Lift & Shift
Containers are meant for microservice architecture. Still, legacy applications can make use of the container management procedure to avail the benefits that the platform offers.
At the first level, to have a legacy application containerized, we must consider refactoring so that it is modular enough to fit in a microservice architecture. Remember that these applications were developed using monolithic designs in mind.
Refactoring is where you had to customize the application and run insider containers. The customization can modify some parts of the application, whereas a complete refactoring might also be required to change most of the application.
Lift & Shift Applications
Once we identify that refactoring is not going to work or will cost too much, we can consider the Lift and Shift model. This approach takes the entire legacy application and pushes it into a container which makes the necessary adjustments required to operate in a container platform. The on-boarded application will leverage several container features like consistent environments, simple deployment in a consistent environment, networking, better infrastructure resource consumption, etc. However, without redesigning the application, it won’t be able to leverage all the benefits of containerization like a microservice architecture.
There exist legacy apps such as RPG, FORTRAN, etc. which are not suitable for containerization in either way explained above.
Applications that have a proper design where the data is tightly coupled to the application logic or difficult to separate becomes an ideal case for Lift and Shift. The best example would be CMS applications.
Applications that are poorly designed without standards will carry a significant risk of performing Lift and Shift. The question is whether we should containerize legacy applications or not? Unless we understand what is being done in the process of containerization and why is being done, it is not a good option to bring old applications into new platforms.