The Path From Legacy Apps to Serverless Just Got Easier
Legacy Apps Are Still Mostly Off-Limits For Cloud Migration
Amid a never-ending flurry of acronyms, languages, tech stacks, frameworks, and platforms, the most important class of apps within many enterprises remain off-limits to cloud migration. These are normally considered legacy apps. They’re too valuable to risk touching. Rewriting is too expensive and would take years, considering the SME’s have often since retired. The cloud vendor that can move these class of apps will create an almost insurmountable advantage in the cloud war. When I say move I mean modernize. When I say modernize I mean rewrite and refactor. I’m not referring to virtualization. In laymen’s terms, virtualization places an app into a more cost-effective environment, but it doesn’t modify the app. The shortcomings that existed before virtualization—technical debt, outdated design, poor reuse, and so forth—will remain.
When you book a reservation, use your ATM card, or purchase gas with your credit card, a legacy app is likely involved. Legacy apps are a goldmine of tremendous value—a wealth of already paid for business thinking and domain-specific knowledge that adds critical differentiating value to an enterprise. Unfortunately, part of this value lies trapped. We can free some of it and refactor it to create even more value and competitive advantage.
Cloud Migration Is At A Tipping Point
Cloud providers have a bit of a conundrum. The low hanging fruit of “Lift and Shift” is running its course. Automation of moving workloads is, as well. Enticing developers to build cloud-natively is barely a differentiator. Tough work and decisions lie ahead, the toughest being whether to rewrite legacy apps or leave them as is. In many ways, this issue has been on the minds of many CIOs for decades. Newer and better technologies have come and gone, all making the same promises. Yet the apps remain mostly intact after weighing the pros and cons of a rewrite. Cloud and hybrid-cloud have changed the narrative by offering lower infrastructure costs, better reliability and scalability and more. But still, the legacy apps remain.
Cloud vendors with Cloud Migration Programs continue to attack the problem of legacy app migration with the usual tactics. They lead with professional services, cloud experts, processes, PowerPoints, and a dose of fear of the unknown. The enterprise has seen this before, when there was a shift from windows-based desktop apps to web-based apps. Yet, somehow, legacy apps have remained untouched through a few different waves of “paradigm shifting” technology.
Cloud migration of legacy apps via rewrite is not a new thing. It’s been around for more than 5 years and by any measure has been mostly unsuccessful. Having this same conversation within a new context does not seem to be working, so let’s change the conversation. Rather than focusing on manually tearing down a skyscraper before rebuilding it a few blocks away, let’s focus on how we can decompose—then repurpose—aspects of the skyscraper without disrupting its day-to-day operations.[RS1] Sure, that’s a typical rewrite initiative, but unlike times past, technology is at our disposal to help us infer capabilities of the legacy app in order to reuse them in a superior way. Think application generation.
This Math Makes Sense
Nobody has ever complained about simple arithmetic. Let’s say we work at an enterprise with 5000+ employees and we’re tasked with turning every minimal database capability into a Lambda function. All the reads, writes, updates, deletes, etc. This is definitely an odd request, but if we can fulfill it, the Lambda functions would be extremely valuable, as you could imagine. Let’s also suppose we were asked to create a Lambda function for each association (“Company has Address,” “Company has Departments,” etc.). How many functions would that be? What could the enterprise do with such an ecosystem of Lambda functions?
AWS Lambda Enterprise Cheat Sheet
Single Assoc. Functions
Multiple Assoc. Functions
CreateCompany GetCompany UpdateCompany DeleteCompany GetAllCompanies
CreateCompanyAddress GetCompanyAddress DeleteCompanyAddress
GetCompanyDepts AddDeptToCompany AssignDeptsToCompany DeleteCompanyDepts
Clearly, we’ve lost our minds thinking we can create 120,000 Lambda functions, let alone 1,000. Nice to have, but not worth the effort. Come to think of it, how can we create so many Lambda functions at once? “Hello, world!” examples are a good start, but we need a significant number of Lambda functions so our migration and net-new development efforts can be persuaded to choose serverless as a valid option. Again, think application generation.
Overcoming Through Sound Design
Lambda functions do not perform well when embedded with database transactional code. Lambda functions should be lightweight and singular in purpose. Database transactions, even traditional ORMs, impose a performance and memory cost that make Lambda functions rather unusable. If you have ever written such a function this way, you have experienced the disappointment of observing your function take many seconds to execute.
So here is an idea. Instead of creating the core functions solely as Lambda functions, create a RESTful API layer that contains the core functions. Then create Lambda functions as business delegates. A proxy layer, if you will. The Restful APIs would be the DAO layer capable of being stateful in order to persist database transaction sessions. The Lambda functions would understand how to make the right calls into the DAO layer, thereby cleanly separating the stateless layer from the stateful layer.
An ancillary benefit to creating a separate, loosely coupled RESTful DAO layer is that other applications can leverage these methods. Likewise, when fronted with an API Gateway, the Lambda functions can also be leveraged in much the same way as a RESTful API. Of equal importance is changes to this persistent layer are isolated with no impact to the Lambda serverless layer. This means changing from an RDBMS like MySQL to a No-SQL implementation like AWS Dynamo DB is seamless.
The big question is a rather simple one. Assuming you see the value in representing core legacy capabilities as AW Lambda functions, would you use technology to assist? It’s natural to resist for the first few dozen functions, but eventually you’ll want a button to press.
Using nothing more than database schema, not only are we beginning to migrate thousands of once-locked fundamental legacy business functions, it’s likewise available to innovation scenarios. Who knew this initial stage of legacy application migration would yield so much value? Few other opportunities in the history of an enterprise offer a zero-touch, low-risk means to improve reuse, standardization, competitive advantage, and short-time-to-market at such a large scale with minimal cost.