In this article, we explore how leveraging open source software, specifically GnuCOBOL, in conjunction with AWS Lambda functions, can breathe new life into legacy code within a serverless framework. Additionally, we highlight the extra advantages that open source software brings when integrating legacy features into a contemporary environment.
The COBOL code discussed herein—specifically CI/CD scripts—can be found on GitHub and is released under the Apache-2.0 open source license. For more technical insights into the implementation, check out another blog post here.
The Continued Relevance of COBOL
Designed by Grace Hopper over 60 years ago, COBOL remains a crucial programming language today. It serves as the backbone for many enterprise applications, particularly in mainframe environments such as banks, insurance companies, and government entities. The skills shortages observed during the early days of the Covid-19 pandemic underscored COBOL’s ongoing importance for daily operations in US administrations. For instance, several states relied heavily on outdated COBOL applications to handle unemployment claims.
According to a 2017 Thomson Reuters report titled COBOL Blues, there are over 200 billion lines of COBOL still in use, with 43% of banking systems relying on it and 95% of ATM transactions executed via this language. The significance of COBOL is far from diminishing; IBM estimates that over 5 billion new lines are written annually.
Many existing COBOL programs remain valuable in today’s digital landscape because they effectively fulfill their intended purposes. 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 Integration
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 with a native C compiler. The latest release, version 2.2, successfully passes over 9,688 (99.79%) tests from the NIST COBOL 85 test suite.
Despite being nearly two decades old, GnuCOBOL remains active, with version 3.1.2 launched in December 2020. The copyrights were transferred to the Free Software Foundation (FSF) in 2015, with the GnuCOBOL compiler released under GPL and its runtime under LGPL. These permissive licenses empower users to utilize Lambda functions without the entanglements of commercial proprietary software, which often impose restrictive licensing terms.
In serverless contexts like AWS Lambda, open source software offers a compelling alternative. AWS manages high availability and scalability through its robust infrastructure, which dynamically adjusts to service demands. GnuCOBOL’s licensing allows for unlimited Lambda functions, enabling scalable deployments as necessary.
Introduction to AWS Serverless Application Model
In late 2016, AWS open-sourced the AWS Serverless Application Model (AWS SAM) framework to facilitate the creation of serverless applications composed of multiple Lambda functions along with their dependencies. The source code for AWS SAM is accessible on GitHub.
SAM’s primary function is to simplify the development of serverless applications by providing a high-level abstraction for required artifacts and definitions. Working in conjunction with AWS CloudFormation, SAM translates these high-level specifications into the necessary AWS resources for deploying and making Lambda functions publicly accessible via the API Gateway. SAM embodies best practices for Infrastructure as Code.
In our project, SAM automates the creation and management of the AWS resources essential for launching and operating the Lambda function. A SAM YAML file will define an AWS::Serverless::Function item with its parameters. The SAM framework will ultimately convert this abstraction into various AWS components, including the Lambda function itself, an AWS Identity and Access Management (IAM) role for function execution, and API Gateway elements such as Deployment, Stage, and RestApi.
While SAM is utilized through its command-line interface, the contributions of the open source community have enabled its integration into various Integrated Development Environments (IDEs) like PyCharm, IntelliJ, and Visual Studio, as well as CI/CD tools such as Jenkins.
Thus, COBOL features extracted from legacy settings can be restructured and deployed via SAM as GnuCOBOL-based Lambda functions, significantly reducing technical debt and harnessing the power of open source solutions.
GnuCOBOL as a Custom Runtime for Lambda
AWS Lambda natively supports languages such as Java, Go, and Python, requiring developers to upload their source code as a .zip file. Lambda manages the compilation, packaging, and deployment processes for these applications.
Lambda also offers a runtime API that allows developers to implement any programming language for function creation. This capability enables the use of GnuCOBOL, where a single binary containing statically linked application instructions is uploaded as the custom runtime for the deployed Lambda function. Since the source code is compiled externally, there’s no need to include it in the uploaded package as is typical with standard Lambda languages.
Building, Deploying, and Testing from GitHub
Our project demonstrates the end-to-end implementation of existing applications using open source software at no cost. AWS Lambda functions fall under a no-cost tier, which offers 1 million free requests and 400,000 GB-seconds of compute time monthly.
The application code and its DevOps components are housed in a public GitHub repository. GitHub is a partner within the AWS Partner Network (APN) and holds the AWS DevOps Competency. The build and deployment phases for the Lambda function are executed as GitHub Actions within a CI/CD workflow, benefitting from the first 2,000 minutes monthly at no charge. For more information on utilizing GitHub Actions for serverless application deployment, refer to this excellent resource.
To adhere to best DevOps practices emphasizing isolation and portability, the compilation process occurs within a Docker instance initiated at the beginning of the workflow. This Docker instance utilizes the Amazon Linux image provided by AWS on Docker Hub. The image will subsequently pull the compiler source.
For further authoritative insights on this subject, check out this site.
Leave a Reply