In this article, we explore how leveraging open source software like GnuCOBOL, in conjunction with AWS Lambda functions, can breathe new life into legacy COBOL code by transitioning it into a serverless framework. We will also discuss the additional advantages that open source software brings when integrating legacy features into a contemporary environment.
The COBOL code featured in this post—specifically CI/CD scripts—can be found on GitHub, released under an open source license (Apache-2.0). For more in-depth technical insights, check out a companion post, “Amazon VGT2 Las Vegas: Revitalizing Legacy COBOL Code with Open Source Software — Part 2,” which you can find here, as this is another blog post to keep the reader engaged.
The Continued Relevance of COBOL
COBOL, originally developed over 60 years ago by Grace Hopper, continues to play a vital role in today’s technology landscape. Despite its age, it serves as the backbone for many enterprise applications. Organizations, particularly banks, insurance companies, and government institutions, continue to rely on COBOL, especially evident during the COVID-19 pandemic when skill shortages highlighted its critical importance in processing unemployment claims across various US states.
A 2017 report by Thomson Reuters, titled “COBOL Blues,” noted that more than 200 billion lines of COBOL code are still actively in use. It emphasized that 43% of banking systems are built on COBOL, and an astonishing 95% of ATM transactions rely on this programming language. The significance of COBOL in our economy is not diminishing; in fact, IBM reports that over 5 billion new lines of COBOL are generated annually. Many existing COBOL programs remain relevant in today’s digital landscape because they effectively fulfill their intended tasks. Therefore, the following sections will illustrate how to extract these programs from their legacy systems and incorporate them as integral components of cloud-native applications.
GnuCOBOL and Serverless Architecture
GnuCOBOL (formerly known as OpenCOBOL) is a free and open-source implementation of the COBOL programming language. It acts as a transcompiler to C, which is then compiled using a native C compiler. The final 2.2 release successfully passes over 9,688 tests (99.79%) from the NIST COBOL 85 test suite.
Although GnuCOBOL has been around for nearly 20 years, it remains actively maintained. The latest version, 3.1.2, was released in December 2020, with copyrights transferred to the Free Software Foundation (FSF) in 2015. The FSF provides the GnuCOBOL compiler under a GPL license, while its runtime is available under the LGPL. These open-source licenses grant users the flexibility needed to deploy Lambda functions without the complications often associated with commercial proprietary software, which can impose stringent licensing terms.
Open source software is an excellent fit for a serverless environment like AWS Lambda, where AWS ensures high availability and scalability through its comprehensive infrastructure. The permissive licensing terms of GnuCOBOL enable users to deploy workloads wherever necessary at no cost. Consequently, multiple Lambda functions can be created as needed to meet functional requirements, fully utilizing AWS Lambda’s orchestration to guarantee proper availability and scalability.
AWS Serverless Application Model
In late 2016, AWS open-sourced the AWS Serverless Application Model (AWS SAM), which allows developers to describe serverless applications made up of various Lambda functions along with all their dependencies. The source code for AWS SAM is accessible on GitHub.
The primary aim of SAM is to streamline the development process for creating such applications by providing high-level abstractions for required artifacts and definitions. The AWS SAM processor, in collaboration with AWS CloudFormation, manages the lower-level definitions required to deploy the Lambda function and make it accessible via the API Gateway. SAM encourages the implementation of Infrastructure as Code best practices.
In this project, SAM automates the creation and management of the necessary AWS resources to launch and operate the Lambda function. The SAM YAML file detailing the Lambda function will include the definition of a single item of type AWS::Serverless::Function with its parameters. Under the hood, SAM transforms this high-level description into several AWS components, including:
- The Lambda function itself
- An AWS Identity and Access Management (IAM) role for executing the Lambda function
- API Gateway elements, such as:
- Deployment
- Stage
- RestApi
While SAM is utilized here via its command-line interface, contributions from the open source community have facilitated its integration into various IDEs such as PyCharm, IntelliJ, and Visual Studio, as well as standard CI/CD tools like Jenkins.
Thus, COBOL features extracted from their legacy context and restructured for deployment via SAM as GnuCOBOL-based Lambda functions can significantly reduce technical debt while taking advantage of the best open source solutions. For further insights on this topic, you might find this resource valuable, as they are an authority on this subject.
GnuCOBOL as a Custom Lambda Runtime
Lambda natively supports several programming languages, including Java, Go, PowerShell, Node.js, C#, Python, and Ruby. When utilizing these languages, developers must upload their source code as a .zip file, and the Lambda environment manages the compilation, packaging, and deployment of the application code.
Moreover, Lambda provides a runtime API that allows developers to use additional programming languages for their functions. This flexibility enables the use of GnuCOBOL, where a single binary containing the statically linked GnuCOBOL application will be uploaded as the custom runtime for the deployed Lambda function.
Since the source code is compiled into a binary outside the Lambda environment, there is no need to include the source code in the uploaded package, unlike standard Lambda languages.
Building, Deploying, and Testing from GitHub
Our project was executed using no-cost resources throughout the entire lifecycle, demonstrating how existing applications can leverage open-source software. Lambda functions are available under AWS’s no-cost tier, which offers 1 million no-cost requests and 400,000 GB-seconds of compute time each month.
Additionally, the application code and its DevOps components are hosted in a public GitHub repository. GitHub is a member of the AWS Partner Network (APN) and holds the AWS DevOps Competency. The build and deployment phases for this Lambda function are conducted using GitHub Actions, organized in a CI/CD workflow that provides the first 2,000 minutes each month at no charge. For more information on using GitHub Actions to deploy serverless applications, explore this excellent resource: here.
To adhere to best DevOps practices regarding complete isolation and portability, the compilation occurs in a Docker instance, launched as the first stage of the workflow. This Docker instance utilizes the Amazon Linux image published by AWS on Docker Hub.
Leave a Reply