Serverless COBOL in Knative

Matt Ray
Matt Ray
Aug 31, 2021
Serverless COBOL in Knative
Serverless COBOL in Knative

Originally released in the late 1950s, COBOL became one of the most popular languages for business, finance, and other enterprise systems for decades. While COBOL didn’t crack Redmonk’s Programming Language Rankings this year, there is still a tremendous amount of it running in production, an estimated 220 billion lines of COBOL in 2017. Some of these COBOL applications are batch processing, fitting a scale-to-zero serverless approach quite well. As some of the platforms these workloads are running on approach their end of life (and ever-increasing support contracts), moving to newer platforms such as Kubernetes makes a lot of sense.

Kubernetes provides a standardized cloud native control plane for applications and services to run across public clouds and private data centers. Knative provides automatic application scaling up and down as workloads expand and contract in response to demand. Whether they are batch processing or continuously running, COBOL applications migrated to Kubernetes could continue to provide production value running free from the shackles of legacy systems and execute wherever the applications are needed.

GnuCOBOL is a modern, open source COBOL compiler that implements the COBOL 85, COBOL 2002, and COBOL 2014 standards and many of the extensions provided by other COBOL compilers (IBM COBOL, MicroFocus COBOL, and others). GnuCOBOL translates your COBOL code into C and compiles with your native C compiler (ie. GCC or Clang). Many existing legacy COBOL applications can safely be migrated to GnuCOBOL without being rewritten.

Inspired by the AWS Open Source Blog article on Serverless COBOL, our engineers put together a proof of concept for wrapping a COBOL application and running it on Knative. The source code is at and this video walks through how it works.

COBOLformation is a Golang wrapper for COBOL applications, allowing them to run within Knative as a serverless application. The handler.go is a wrapper that takes a CloudEvent data payload the processEvent function and uses it as the arguments for the wrapped COBOL application. The data is passed to the COBOL application through C bindings as the C.datatyp defined through cgo definitions.

arg1 := C.CString(r.Arg1)
arg2 := C.CString(r.Arg2)
arg3 := C.float(r.Arg3)
arg4 := C.double(r.Arg4)
arg5 :=
C.datatyp(arg1, arg2, &arg3, &arg4, &arg5)

The example datatype.cob COBOL program takes the passed arguments as variables.

01 ARG1 PIC X(24).
01 ARG2 PIC X(24).

The Go float maps to COBOL’s COMP-1, double to COMP-2 and int to BINARY-SHORT SIGNED respectively. PIC X(24)is a 24 character string in COBOL. We do a few trivial operations to the data and return it to the Go wrapper.

The included ksvc.yaml is used to deploy the application to our Kubernetes cluster already running Knative Serving. You can use the Docker image referred to in the document or build it from the Dockerfile and push to your own registry if you prefer. 

To deploy the application create a demo namespace.

kubectl create namespace demo

Apply the ksvc.yaml to your Kubernetes deployment and create the cobolformation service.

kubectl -n demo apply -f ksvc.yaml

Give it a few seconds to come up, then check that the cobolformation service is available and is serving on an external IP address.

kubectl -n demo get svc cobolformation

You can use that address to post to the API with curl. You can copy and paste the example from the README, just make sure to update for your cobolformation endpoint.

curl -D- \
  -H 'Content-Type: application/json' \
  -H 'Ce-Specversion: 1.0' \
  -H 'Ce-Type: greeting' \
  -H 'Ce-Source: my-workstation' \
  -H 'Ce-Id: 0000' \
  -d '{ "arg1": "hello,", "arg2": "replace me", "arg3":123.45, "arg4":234.5678,"arg5":3 }'

HTTP/2 200
ce-id: 4500e4e9-a911-40f8-b27e-dc0ed9cc8631
ce-processedid: 0000
ce-processedsource: my-workstation
ce-processedtype: greeting
ce-source: io.triggermesh.targets.cobol-sample
ce-specversion: 1.0
ce-time: 2021-08-26T08:13:37.283368232Z
content-length: 179
content-type: application/json
date: Thu, 26 Aug 2021 08:13:37 GMT
x-envoy-upstream-service-time: 2405
server: istio-envoy

{"code":0,"detail":{"message":"event processed successfully:hello, Replaced in COBOL","arg3":223.4499969482422,"arg4":134.56779999999998,

The CloudEvent data payload is sent to the COBOL application and the returned results show the passed arguments were modified accordingly. 

This is a relatively simple example, but it should be straightforward to upgrade the wrapper and the COBOL application for your own usage as necessary. 

Related Posts

Join our newsletter

Sign up for our newsletter for the latest news, training, and offers to help you build event-driven systems with TriggerMesh.