IBM Shows Instances of COBOL Running Natively on Kubernetes
IBM has launched a research and development project through which applications developed in COBOL are able to run natively on Kubernetes clusters.
JJ Ashgar, developer advocate for IBM, says at the moment the initiative is little more than a science project that it is sharing with other researchers via GitHub. However, IBM researchers have been demonstrating, by invitation, instances of COBOL applications running on Kubernetes clusters based on both x86 and graphical processor units (GPUs).
IBM also previously committed to making Kubernetes available on the z/OS operating system on which IBM COBOL applications are deployed.
The demonstrations make use of the Red Hat OpenShift platform to both spin up Kubernetes clusters and deploy Kubernetes applications on then. The Red Hat OpenShift platform provides a level of abstraction that makes Kubernetes accessible to IT teams building and deploying COBOL applications on Kubernetes. Otherwise, all the options Kubernetes makes available via settings quickly become overwhelming to the average enterprise IT team, he notes.
The goal of the project is to enable IT teams to transform COBOL code into a microservice that runs natively on Kubernetes, says Asghar. While IBM has a clear preference for the Red Hat development platform it owns, there’s no reason why other development platforms deployed on Kubernetes couldn’t leverage the same research.
It’s too early to say whether COBOL applications would be deployable on Kubernetes clusters in production environments. However, at the very least, organizations that are building COBOL applications should be able to leverage Kubernetes to build COBOL applications wherever they like that could be deployed on a mainframe. Because those COBOL applications are deployed using containers, it should also become easier to update COBOL applications by ripping and replacing containers, in keeping with best DevOps practices.
IBM already has a major DevOps initiative underway that leverages containers to make IBM mainframe middleware accessible to developers working on platforms other than the mainframe. That approach is intended to make building and deploying applications for mainframes a natural extension of existing DevOps processes by, among other things, making it possible to deploy an instance of CICS transaction processing software on Kubernetes.
Since the economic downturn brought on by the COVID-19 pandemic, the need to integrate legacy mainframe applications with emerging cloud-native applications deployed on Kubernetes clusters is becoming more pressing. Rather than rewriting millions of lines of COBOL code, IT teams would in theory be able to lift and shift COBOL code on to a Kubernetes cluster as part of an effort to integrate application code more closely.
Many IT teams today assume that investments made in COBOL applications were never destined to reach beyond the mainframe itself. However, as more abstractions are added to IT environments it’s becoming apparent that many things once deemed impossible may prove to be entirely feasible. In fact, the biggest challenge now may not be the underlying code itself as much as it is opening the minds of IT teams to consider the possibilities.
