Exploring the Gentrification of Legacy Applications

Introduction

Legacy applications get no respect. The developers who wrote them have aged out, and none of the new developers want to work on career-killing software stacks. On the other hand, they are still churning away, faithfully doing the job that they were set in motion to do long ago with very little care and feeding. So what’s the problem?

Well, nothing as long as staff can still support them, and they don’t need to participate in an evolving enterprise architecture. The problem arises when the IT neighborhood around them changes, and they no longer fit within it. When that happens, the app is like an old house in a gentrified neighborhood—it just doesn’t fit in anymore. It wasn’t designed with the latest architecture patterns and computing infrastructure in mind. How could it have been?

Assessing the Situation

The last straw for the application usually occurs when it can no longer support the agility that business demands, or it becomes too brittle under the workload it is now subject to but was never designed for. It is usually at this point that Levvel is asked to give our assessment of the situation to see if anything is salvageable.

There is a spectrum of options to consider once a business decides it is time to do something about its aging applications. It is no surprise that the options range from tactical band-aids (e.g., lift and shift) to full-on re-architect and rewrite. Obviously, each option has its pros and cons, and a strategic approach very much depends upon the business problem(s) that must be solved.

Realistically, if an enterprise truly wants to give an application a brand new lease on life, there are two essential architectural features that could be considered must-haves since they will yield the most gain for the pain.

First, all the business logic bottled up in the legacy app needs to be exposed in a consumable way. This is what application programming interfaces (APIs) bring to the table. APIs are based upon the concept of Service Oriented Architecture (SOA), which was originally implemented using a complex SOAP protocol with XML service payloads.

APIs implement a form of SOA, but they have shed much of the weight and complexity that the SOAP-based services of yesteryear introduced. Consumers can now access the business logic easily using RESTful API services with JSON payloads, the simplest and most ubiquitous way for clients to consume services.

Second, containerization is arguably the most revolutionary development to date in software engineering. From an architecture perspective, containers can be thought of as specialized self-contained software building blocks.

Practically, application functionality can be divided into commodity components called services that are assembled into functioning applications and executed in a container management system like Kubernetes. Once containerized, it doesn’t matter where the application is hosted—bare metal servers, public cloud, private cloud, or a hybrid; it really doesn’t matter!

Closing

Obviously, the path your enterprise follows to modernize a legacy application depends upon what problem(s) you are trying to solve. Consider the introduction of APIs as table stakes regardless of which path you take. If you want to beat the competition, and we believe you do, containerized software components and container management runtimes will find their way into your enterprise, too.