Search
Close this search box.

A guide to running mainframe applications in containers & as microservices

Google has been one of the leading pioneers of software containers. In 2006, two of its engineers, Paul Manage and Rohit Seith, defined and implemented an essential component of this new container technology(1). In 2015, Google released Kubernetes, the open-source version of it’s decade old internal version of orchestration(2) . Known as Borg, this architecture explored and defined the correct mechanisms to orchestrate container-based workloads at web scale. Google claims to start two billion containers/week at a rate of 3,300/sec!(3). Use of containers by Google for all workloads is in itself a validation of this swarm-based architecture. But Google is not alone! Containers represent the core architecture for Amazon(4), FaceBook(5), Twitter(6), Netflix(7) and many more web scale companies. If these massively web scale companies have shown such a dramatic commitment to containers, why wouldn’t you?

Containers and Modernization

So what exactly is the power of this technological innovation? Containers drastically reduce time-to-market. They make the race to continuous innovation sustainable, even at the scale of these internet giants! This innovation is the fuel for the digital evolution of entire business sectors for both new and old companies. In the digital business era, innovation happens through highly recurring deployments of both new and improved software. That’s what Amazon does 50 million times a year(8), to make them the retail juggernaut that they have become. Every second new retail services are deployed, and existing ones incrementally improved at a rate of change that boggles the mind.

Let’s compare this rate of evolution with that of a corporation still depending on legacy applications. Even when its mainframe infrastructure provides a back-end function for digital internet services, how many times per year are its legacy systems upgraded? Best-in-class organizations do this once a quarter. Clearly these companies are playing in a completely different game than the web scale companies. They can never catch up. It’s like trying to race a rocket with a truck – not really a fair race!

LzLabs is currently developing a container solution for its Software Defined Mainframe (SDM). This approach is designed to enable companies with legacy mainframe applications to take advantage of the scale and agility of containers, exposing existing business logic as services or microservices. The web scale giants of today are so fast in rolling out new or updated services because they are designed to be small to very small. “Go big or go home” does not always apply! Microservices are small pieces of software, designed to specialize on a small number or even a single business function. The boundaries and dependencies of these microservices are extremely explicit and clear; they are defined by their communications with OTHER microservices, over the network. Amazon has recently disclosed that several hundred microservices are used during even the simplest purchase on their web site4 .

Containers – One Path to Agility?

These explicit and clear boundaries dramatically reduce the scale of testing – it becomes much easier. A minimal to single function enable automated testing to yield dramatic improvements in productivity. How else could anyone achieve the scale the web giants are getting? The usual fear to go to production associated with legacy systems is a result of the queasiness over testing. Many mainframe shops are never quite sure if they’ve tested the whole thing because these systems are so monolithic and complex. With a simpler and limited function piece of software, supported completely by automated testing solutions, companies are able to role out changes in a continuous delivery mode, incurring limited risk due to the smaller footprint of these microservices. Legacy mainframe applications are quite different. These large, complex monolithic systems, with lots of programs, each highly dependent on each other must be tested in their entirety over many weeks in order to find the “bug in the haystack”!

Microservices – The Path to Modern

LzLabs solution is to enable these legacy systems to participate in a more modern and agile world by transforming these monoliths into a myriad of independent microservices, without ANY changes to the source code. This approach allows existing COBOL Commarea programs (to use a legacy term) to become a microservice that is hyper-connected with new applications written for mobile and social networks. It means that innovation can occur on top of the cornerstones of the current business. To put this in terms of the Gartner Bimodal IT vision, it means that Mode 2 applications can more easily leverage Mode 1 services. Exposing these legacy “crown jewels” as microservices enables them to be reused for modern digital business solutions. For example, a banks with tens of thousands or millions of lines of COBOL that are used to determine the value of their banking customers, can reuse these functions, “as-is” and not have to spend the time and money to rewrite them in Java or some other modern computing language. The LzLabs solution enables organizations to isolate the legacy programs providing this “customer valuation” function as a separate microservice, that can be readily reused by the evolving application portfolio. In essence, our solution is being designed to:

1)   Leverage automatic application analysis techniques to be able to unambiguously understand all programs required to provide the business function, and expose them as a microservice.

2)   Package these required components, still in their mainframe binary form, with an optimized version of the LzLabs SDM.

When combined with necessary Linux packages and Docker technology, these components are bundled as an independent microservice, ready to be deployed in our new “Legacy Container-as-a-Service”.(LCaaS) The number of microservices extracted from legacy applications using this new approach can yield hundreds of controlled functions, requiring modern processes to build and maintain them. The LzLabs solution is being designed to automate the build, delivery and update engine to support these legacy-based microservices by:

1.    Application analysis is run automatically each time application program changes are committed to source code repository. This recurring analysis detects if dependencies changed (new copybook, different call tree, etc.) and redefines, if needed, the set of components to be packaged together for the next version of the microservice.

2.    The construction of Docker image is also fully done automatically to populate the container image registry with the latest version following the update of the Cobol application program. The LCaaS platform will then transparently take care of the automated deployment of this new version.

Software upgrades are the fuel of innovation in the era of digital business: the LzLabs LCaaS solution is the way to leverage the vast amount of “business energy” laying in legacy software assets into very dynamic and fast evolving services, aimed at playing on par, with the web giants

References:

1.     https://en.wikipedia.org/wiki/Cgroups

2.    https://research.google.com/pubs/pub43438.html

3.     https://www.theregister.co.uk/2014/05/23/google_containerization_two_billion/

4.     https://odetodata.com/2016/04/amazon-microservices-and-the-birth-of-aws-cloud-computing/

5.     https://fr.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997

6.    https://www.linux.com/news/how-twitter-avoids-microservice-version-works-my-machine

7.    https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/

8.    https://www.zdnet.com/article/how-amazon-handles-a-new-software-deployment-every-second

Related articles.