Most large enterprises run some form of a legacy application, for which updates and replacements can be costly and time-consuming, not to mention potentially risky. But failing to modernize out-of-date systems can ultimately damage app performance via slow runtime speeds and poor load balancing.
One of the primary challenges to modernization is to get the entire IT team on board, said Chris Gardner, senior analyst at Forrester. Developers typically are ahead of the curve, while operations teams drag their feet to maintain a currently functional -- and secure -- architecture.
Enterprises' reliance on time-consuming manual processes and tools that were de rigueur with legacy applications also hinders modernization efforts. If a batch process is how you've always done things, and the application is stable because of this, sys admins will be loath to change it -- especially in a risk-averse industry such as finance or healthcare. But manual processes take up valuable time and leave room for error, a bottleneck that opens the door to automation.
Developers won't naturally become ops people; it's not in their nature, Gardner said. They need to continue to focus on delivering apps and user experiences as quickly as possible. Instead, systems administrators must become developers to revitalize production support for applications. They also must emphasize proven ops processes while adopting new methods, such as infrastructure as code.
In traditional, inefficient setups, infrastructure and operations people end up being policy enablers instead of policy executors. "They're the ones that are manning the tollbooths, checking that everything is good with some very manual processes," Gardner said. "You want them building the highways and stepping away, and making sure they efficiently run."
Modernization process methods
Two important factors drive organizations to modernize legacy applications: Either the application or its supporting infrastructure is too expensive to maintain, or it doesn't reach current business channels, said Mark Sperber, legacy modernization expert at Spring Beach Associates in Bedminster, N.J. Organizations that face one or both of these scenarios have three options to conduct the modernization project: lift and shift, refactor or completely rewrite the application.
Lift and shift projects simply rehost applications as a whole unit onto a cloud service. The organization must have a fluid, functional application stack with distinct components that act independently once shifted into the cloud. Lifting and shifting an application avoids redesigns and can temporarily decrease costs -- but if the app isn't optimized for cloud or is resource-intensive, cloud cost will quickly outweigh its benefits.
Refactoring projects are most suitable with legacy applications that are difficult to deconstruct into microservices. These apps require changes that are interdependent and, therefore, complex to work through. Refactoring requires time, patience and a good testing environment.
Complete rewrite projects -- also called rip and replace -- are for end-of-life legacy applications that are built on hardware or code languages that will lose vendor support or are difficult to match to operator skill sets. Despite the complexity, time requirements and total costs of this type of project, replacement proves worthwhile for applications when refactoring and lift and shift are not feasible.
These questions help IT teams determine the best approach to a given modernization project:
- Can operations split the application into distinct pieces and redeploy the app code into containers without instigating a massive rewrite?
- How quickly can the IT team get to disposable testing environments, automated processes and integrated continuous integration and delivery?
- Can the modernization project be done using open source technology, avoiding vendor lock-in and high project cost?
Multiple factors play into why an organization might choose to replatform an application instead of adopting a new one, Sperber said. Some applications or systems have the user interface, database and services portions of their logic intertwined, or embedded in one large module, or a series of large modules, making it exceptionally difficult to parse out the individual logic of service, user interface or database.
To modernize legacy applications into containers, businesses must consider performance tradeoffs, said Brian Aznar, director of engineering at a North American professional sports organization. Containerizing applications that weren't designed for such portability yields bottlenecks and inefficiencies that operations must address. "If the application has heavy reliance on a file system, that's probably the first and foremost [performance] hit they will take." Applications that are "chatty" or have high networking needs face the same hurdle.
Drupal, meet containers and the cloud
Aznar's organization recently completed a three-step legacy system modernization from a traditional, monolithic application in a private data center to Amazon Web Services (AWS) with Docker containers and Kubernetes. The organization ran a traditional setup when this process began: PHP and NGINX on dedicated bare-metal servers. They wanted to start small in AWS and Docker containers to see how the services would work with their applications, Aznar said.
Aznar took a "two buckets" approach to modernizing the legacy systems: The first is to containerize previously existing applications; the second is to develop net-new applications or features in containers from the start.
The organization developed all of its new services, functions and products using node.js directly on AWS, not touching its Drupal app's core functionalities. At that point, 30% to 40% of the organization's applications ran in Docker containers on AWS, with the other 60% run in a colocation facility.
Next, the organization migrated more of its Drupal instances onto virtual server instances on AWS using preconfigured Amazon Machine Images (AMIs). The development team wrapped Drupal instances in AMIs during the build process to facilitate scaling in the cloud. At this stage in the modernization process, the organization had migrated 100% of its infrastructure onto AWS, but still had just 40% in containers. Aznar tested the waters in AWS, and finally added Docker into the precarious balance of old and new to ensure that the cloud service would play nice with the Drupal application.
Aznar's group expected a performance hit by moving Drupal applications onto AWS, but they knew that the payoff of shifting into containers would outweigh that -- he needed to normalize the company's application stack, deployment and infrastructure, and make management consistent across everything. His group tracked lagging response time and monitored granular container performance with Sysdig to offset the minor performance dip.
To containerize an existing application, be clear on the rationale and the value thereof, as there will be pain points, Aznar advises. "Some people want to just because it's the new thing -- and there I'd be wary," he said. Still, organizations that agree upon a rationale to modernize legacy systems should forge ahead, starting with an assessment of the app's cloud-readiness.
Emily Mell is an assistant editor for TechTarget's SearchITOperations. Write to her at email@example.com or follow @EmilyRMell on Twitter.
Start here before putting containers in production
Determine a container networking strategy
How to cluster containers for production scaling
Value stream mapping software redirects DevOps to business goals.