Bridging the chasm between Cloud-Native and the Mainframe
Part 1: Introduction
The Cloud Journey Optimization Team spent much of 2023, and the first quarter of 2024, increasing our hands-on work with and deepening our focus on mainframe modernization. To expand upon our inaugural post, sometimes that means “modernize on” (remaining on the mainframe, but using modern devOps, recompiling to get various optimizations, and cost savings such as leveraging ZIIP processors where possible, among other things), sometimes it is an “integrate with” play (doing some work in the cloud, but calling back to the mainframe for the “crown jewels” routines), and sometimes a full “move off” (evacuating the mainframe, including migrating COBOL and other legacy languages to Java or other modern languages). In this series of articles, we’ll focus on the “integrate with” approach, using our Stock Trader application in Azure with some business logic that lives on the mainframe.
As some background, we had previously (in 2022) done some simple work with Kyndryl’s Core Enterprise and zCloud Services team to test out having Stock Trader running in Azure, but delegating to their mainframe in zCloud as its System of Record (SOR). Specifically, that meant getting a VPN setup so that our Portfolio microservice could make JDBC calls to IBM Db2 for z/OS as its relational database. We’ll talk more about that networking setup in a future article in this series. This figure shows the basics of what we’d gotten working in 2022:
Another thing we did in 2023 was creating a new Spring-based microservice for Stock Trader called Cash Account (at https://github.com/IBMStockTrader/cash-account). Our intern Celina Chen wrote it, and I wired up my Broker microservice to debit it for the total cost of any stock bought, and to credit it for the total cost of any stock sold. It uses JDBC to store the cash account balance (like to PostgreSQL), and keeps track of your local currency type, and does conversions to and from US Dollars (and keeps the exchange rate cached in Azure Cache). Celina wrote an article about it before her internship ended.
Moving forward to more recent work, we worked with the Core Enterprise and zCloud Services team to create a CICS/COBOL implementation of Cash Account (at https://github.com/IBMStockTrader/cash-account-cobol), that uses DB2 for z/OS and VSAM. It exposes a REST interface (the exact same interface as Celina’s Java Spring implementation) via z/OS Connect that is made available to the Azure Kubernetes Service (AKS)-based Stock Trader application via Azure API Management. We also set up security, which we’ll discuss in detail in a future article in this series, so that login would occur against the IBM Resource Access Control Facility (RACF) user registry on the mainframe. The following figure shows Stock Trader in Azure integrating with this COBOL-based business logic and the user registry on the mainframe:
Of course, having the application on the cloud, but its system of record on the mainframe can have performance implications. Therefore, our next intern, Jaylon McShan, did considerable work doing Gatling-based stress testing of Stock Trader in various configurations. Each test simulated 100 concurrent users for 1 hour. The tests included having our Portfolio microservice use various databases, including PostgreSQL or Microsoft SQL Server in Azure, as well as IBM Db2 for z/OS on the mainframe, and with the mainframe-based CICS/COBOL/DB2/VSAM flavor of Cash Account added in. Of course, we saw longer response times once we included trips from Azure us-east to the mainframe in zCloud (the physical location is in Brazil — round trip ping time averages about 125 ms):
We were pleased that, even the most sophisticated “integrate with” scenario, including IBM z/OS Connect and CICS/COBOL, resulted in sub-second response times. That said, it is still significant that mean response times roughly tripled, so in a future article in this series we will explore the idea of keeping a replica of the data in the cloud, kept current with the “source of truth” on the mainframe via change-data-capture.
Another reason we did this work to make a CICS/COBOL version of Cash Account was so that we could run it through the various COBOL to Java mainframe modernization tools and compare the results across tools, and to our hand-written Spring version of Cash Account. Our team has invested considerable time becoming skilled in, and in some cases certified for, tools like AWS’s BluAge, Google’s G4, Astadia, Heirloom Computing, and Base100’s Caravel. We will explore this in further details in a future article in this series.
Note that while we did most of our work in Azure, we did also set this up in AWS as well, using its Elastic Kubernetes Service (EKS), Relational Database Service (RDS), ElastiCache, Lambda, and a VPN connection to the same mainframe in zCloud, with the appropriate firewall setup, etc. All worked well running the same tests, including use of IBM DB2 for z/OS and IBM z/OS Connect to talk to the CICS/COBOL version of Cash Account, from AWS.
To summarize, we spent much of 2023, in between customer engagements, teaching ourselves about mainframe modernization. While much of this involved learning about tools from our various partners, it also meant expanding our cloud-native application to integrate with resources on a mainframe maintained by our Core Enterprise and zCloud Services colleagues. We’ve gained considerable experience “integrating with” an SOR on the mainframe, have learned about exposing COBOL-based business logic to be called from a microservices-based application on the cloud, and have done security integration. We will discuss these topics further in future articles in this series.
As always, we stand ready to work with anyone interested in embarking on such a mainframe modernization journey, informed by what we have learned over the past year. Thanks for your time, and feel free to leave comments on what you’d like to see next in future articles in this series!
Thanks to Eric Herness for his review of this article.
