A legacy application can be loosely defined as a software program or system that is more than 10 years-old, outdated and/or obsolete, that comes without warranty or documentation, and whose developer is most likely “retired in the Bahamas.” Most people in the industry do not want to own legacy apps, and IT departments try to avoid owning these systems at ALL cost.
When faced with this conundrum, is it worth it to containerize your legacy applications (apps)? Can this be done in a cost-effective manner? The answers to both questions, most of the time, is “yes.”
So, why should we run legacy apps in containers? First, many legacy apps still have an important role to play in most corporations and Federal agencies. Second, the majority of legacy apps were once installed on physical machines (servers) that currently run operating systems that are “end-of-life” (EOL). Running applications on physical servers doesn’t scale, and there is the possibility that the physical server will experience a catastrophic failure at some point in the future. Despite “legacy” having a slight negative connotation attached to it, legacy apps can still serve a purpose for many years or even decades after their initial go-live date. These older systems may still be considered mission critical or have well-established user communities willing to pay for ongoing support or updates rather than buying new software. In other scenarios, the department owning the legacy apps may not have the funds to procure a new system and “maintaining” the existing system is all they can afford. The third reason for containerizing legacy apps is because these systems have outlived the platform on which they were originally designed and developed for. For example, many large institutions or Federal agencies may still run applications on the legacy Solaris Unix platform. Various versions of Solaris are already end-of-life and patches are no longer available for them, resulting in potential security and compliance issues. If you currently own legacy apps, rehosting these systems on more current infrastructure and within containers would make a lot of sense from a business risk and security compliance perspective.
There are currently two popular approaches to containerizing your legacy apps―refactoring and re-writing the legacy app or “lifting and shifting” the app into containers. The first approach is considered a cleaner approach and is often preferred by external vendors. However, refactoring your legacy app requires that it is modular enough to be broken up into a microservice ecosystem. This will often require serious development cycles and project management resources. On the other spectrum, the lift and shift approach basically takes the legacy app and drops it into a container, only requiring limited code changes to have the system running in a container. The lift and shift approach clearly results in a less optimized containerized app.