The current trend in application development is Microservices. There are a number of reasons why Microservices are so compelling. Some of the key benefits are centered around improved agility, scalability, availability and the general complement with cloud services. In this blog post we will look at how Mainframe architectures map to microservices and how can they be applied to application modernization projects.
So, what is CICS?
Unless you have had the experience of being an architect or programmer on an IBM Mainframe, you might not be familiar with CICS. CICS stands for (Customer Information Control System). To understand what it is and what it does require a bit of a history lesson.
In the early days of computing, there is no question that IBM pioneered many of the technologies that we take for granted in today's modern technology environment. One of the technologies that is the underpinning of what makes Cloud Platforms possible is virtualization. IBM created this as a need to provide more capacity for a given finite set of hardware resources. Another need was that of providing an environment for applications where the applications could rely on well defined interfaces for transaction management and interfacing with the user. Does this sound like a container? In many ways, CICS was one of the first containerized application environments.
CICS enabled high-volume online transaction processing for Mainframe applications. By leveraging it, developers could write their code in a variety of programming languages. They interacted with CICS via CICS supplied language extensions that enabled database access via transactions and online interaction with the user via BMS (Basic Mapping Support). This was the backbone for many of the "green screen" applications that dominated mission critical workloads throughout the 70's 80's and 90's. With the advent of distributed computing, interfaces were created to allow web services to interact with CICS.
Because of the abstraction layer CICS provided for application developers, they were free to focus on the application logic rather than the complicated process of communicating with the user and the database. As a result of the benefits provided, many applications were created that leveraged CICS (especially in the Financial Services, Government and Healthcare industries). Many of these CICS applications are still in service today.
Now let's fast forward to today and see how CICS maps to microservices. Microservices were born out of SOA (Services Oriented Architecture). The premise of this application design pattern was that if an application was designed of a collection of loosely coupled services, this would allow for more agility, flexibility and resiliency for an application. Essentially, the cloud has made the promise of SOA a reality, by allowing developers and architects to deliver resilient services in a scalable and agile way. Without a doubt, the most popular technology for this is Containers and the most popular way top orchestrate these containers is Kubernetes.
CICS Meets Microservices
In the image below, you can see how an application (or applications) created in CICS can map to a modern microserviecs environment. In the Mainframe world, compute resources are divided into LPAR's (Logical Partitions). In today's vernacular, this equates to a VM. Within LPAR's are CICS Regions which are very similar to the functionality provided by a Node in Kubernetes. Within a CICS Region are applications. Typically denoted by a 4 letter transaction code (i.e. TX04). The benefit of the approach with this mapping is that you can dial in your level of granularity when it comes to the deployment. In Kubernetes there are Pods which can contain one of more CICS transactions. Do you want multiple CICS transaction per Pod, or just one? The choice is yours.
Also, notice how CICS was the abstraction layer for the database which on a Mainframe was typically DB2, VSAM or IMS. In our modern world we have many more choices for the database tier.
So why would developers want to move from CICS to Kubernetes? Actually there are a number of benefits for moving to this architecture:
Hopefully, this post was helpful to make you think about how you can map legacy Mainframe workloads into today's modern microservices architectures. As you can see they are really not that different and depending on the applications and workloads you are thinking about migrating, you can find a starting point for moving forward.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.