BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Options to update COBOL have existed for years -- consider mainframe rehosting scenarios and compilers that convert code to more modern languages. Serverless deployment models now join that mix.
AWS has joined with Blu Age, a vendor that offers tools to modernize applications, to support COBOL on Lambda, the cloud provider's serverless computing platform. Blu Age's software provides a COBOL runtime and takes advantage of AWS' new Lambda Layers feature.
Developers can run COBOL-based functions on AWS' native Java 8 runtime and use Blu Age's compiler to build Lambda deployment packages from COBOL source code, Blu Age said. Support for COBOL applications is part of a wave of improvements to AWS Lambda revealed last week at its re:Invent conference.
There are massive amounts of COBOL code still operational today -- some 220 billion lines of it, as Reuters reported last year. The venerable language is a linchpin of the financial industry's transaction processing systems. For example, about 95% of ATM card swipes rely on COBOL code, Reuters said.
Blu Age's COBOL runtime for Lambda means that users don't have to manage servers or containers, and AWS handles scaling. Costs incur for every 100 ms of code execution time, with no fees when code is idle.
The other advantage of Lambda is that it helps developers decompose COBOL applications into microservices to provide more agility and flexibility, Blu Age said.
Many current COBOL applications are already well-suited for serverless, said Ryan Marsh, a DevOps and serverless trainer and consultant based in Houston.
"Your typical COBOL application that you most run into in the wild is an application that runs from time to time," Marsh said. "It's batch-oriented. It takes data from place to place, does things with it and puts it somewhere else or calls other COBOL applications."
Ryan MarshDevops/serverless trainer and consultant
Marsh likened COBOL applications to Rube Goldberg machines; both are composed of a series of things deliberately chained together to perform complex tasks. Serverless applications follow this same model.
Few COBOL apps are monolithic, where all the functionality is in one executable or invocation that continuously runs, he said. That's why a move to a serverless model makes sense for COBOL apps.
Some IT shops might be hesitant to move COBOL applications from on premises to the cloud, because those apps often run on hardware paid for long ago.
"Moving into something where I'm renting [compute resources] and paying for it again just doesn't make sense," Marsh said. However, there are bigger considerations for COBOL shops to mull.
"When I completely remove the ops headaches and I no longer have to think about virtual machines and instances and worry about disk space and things like that and I'm just thinking about my business logic and data, that makes perfect sense," he said.
Meanwhile, some companies spend vast sums of money to rewrite their COBOL applications in languages such as Java, but that idea is wrongheaded, Marsh said. For one, documentation on these old applications is frequently poor, making a rewrite project much more fraught with pitfalls.
"What if you could skip all that and lift and shift it into the cloud?" Marsh said. "Moving to Lambda, versus a wholesale rewrite to technology and patterns that were cutting-edge 10 years ago, is much more advisable. You can skip two-plus generations of application development patterns. How often do you have that kind of opportunity in enterprise application development?"