February 6, 2020
TABLE OF CONTENTS
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?
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!
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.
Architecture Senior Manager
Jim Boone is an Architecture Senior Manager at Levvel and has over 25 years of experience in systems engineering, systems management, software design/development, and payment software systems across the power generation, health care, and banking industries. He has helped both large and small clients integrate payment systems into their enterprise architecture, and he has designed and implemented custom payment software solutions.
At the end of lunch with a mentee, I used the items on our table to express the fundamental concepts of Kubernetes. Sometime after explaining the purpose of the Kubernetes scheduler, she asked a question I spent the next several weeks thinking about.
API design is crucial, giving structure to application interaction. Given cross-functional teams and applications, development time is reduced with a clear, intuitive way to access data. API development often follows two approaches: REST and GraphQL.
As of June 2018, the state of California passed a new privacy law that could lead to more consequences for US-based companies than the European Union’s General Data Protection Regulation (GDPR). Here's what you need to know and how to be compliant.
Before your data scientists wring value out of your reams of data, it has to be accessible and, on some basic level, coherently arranged. To harness all that brainpower, you need to keep the data wrangling to a minimum. Enter the data lake.