ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

The Path From Legacy Apps to Serverless Just Got Easier

Updated on August 30, 2018
tylertravismya profile image

Steven is focused on paradigm shifting thinking around application transformation and the process of app migration.

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

CRUD Functions
Single Assoc. Functions
Multiple Assoc. Functions
CreateCompany GetCompany UpdateCompany DeleteCompany GetAllCompanies
CreateCompanyAddress GetCompanyAddress DeleteCompanyAddress
GetCompanyDepts AddDeptToCompany AssignDeptsToCompany DeleteCompanyDepts
It is straight forward from here : 500 Apps x 1 Database per App x 20 Tables per Database x 12 Functions per Table = 120,000 Lambda Functions!

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.

In Conclusion

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.


    0 of 8192 characters used
    Post Comment

    No comments yet.


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
    ClickscoThis is a data management platform studying reader behavior (Privacy Policy)