Infosys client

Re-hosting a mainframe to Azure Cloud using Kubernetes and KEDA

Challenge

The Infosys client – a leading insurance company providing life insurance, investments and retirement services – faced heavy expenses due to mainframe licensing fees and rising storage costs. Legacy mainframe technologies like Assembler, REXX, QMF, FOCUS, Telon, and IMS database posed challenges not only in maintenance but also hampered cloud and DevSecOps adoption. Shared environments for development, testing, and production caused delays in implementing new enhancements and fixes, impacting time-to-market. The coexistence of multiple applications in a complex monolithic environment added to the burden of system management. Given these challenges, it was imperative for the client to embark on mainframe modernization.

Solution

Infosys compared various options of refactoring and re-hosting as part of mainframe
modernization considerations. After thorough analysis, re-hosting the mainframe to Azure Cloud using Raincode emulator was suggested as a best-fit approach. Based on the inventory stack & timelines consideration, the re-hosting option offered was comparatively less risky and faster for the migration over refactoring. With the migration, switching to a cloud environment was an obvious choice as it provides multiple benefits including cost savings, availability, scalability and many others.

Solution Approach

For hosting the mainframe workloads – both batch and online – Kubernetes-based containerization was implemented acting as backbone for the entire migration. Kubernetes is an open-source platform for managing containerized workloads and service. For autoscaling of the online containers, Kubernetes Event Driven Autoscaling (KEDA) was leveraged. KEDA supports multiple event sources from various cloud platforms, databases, messaging systems, telemetry and many more. Both Kubernetes & KEDA are accepted to CNCF and currently at the Graduated maturity level.

The diagram below depicts high level target state architecture comprising various technologies used:

As the mainframe rehosting was on Azure Cloud, the Infosys migration team (hereafter referred as ‘the team’) used Azure Kubernetes Service (AKS) for achieving the containerization. AKS is a managed Kubernetes service to deploy and manage containerized applications. Azure handles critical tasks like health monitoring, maintenance and other operational overhead thereby reducing complexity for AKS to manage Kubernetes efficiently. AKS Cluster with Linux-based computing nodes was used to host the containers. The nodes were hardened with strong security policies and a compliance checklist to provide a secure base for containers running on the host OS.

AKS containers were deployed with all application DLLs, dependent libraries, runtime and emulation system libraries. The team migrated application specific data into Azure SQL MI (Managed Instance) database and moved the datasets for batch jobs to VNAS storage (NetApp Cloud Volumes ONTAP for Azure). A single container for each application was created. Depending upon the criticality of application, memory and CPU limits were defined at the specification yaml file for each application. The container deployment followed enterprise-level hardening rules such as running containers with non-root privileges, restricting access for mount paths, and having configuration or log files within containers. An ingress URL was setup for each application providing unique way to access it from outside.

Batch Containers – CA Workload Automation (CAWLA) was used as a scheduler for triggering batch jobs. A custom created Https wrapper WebAPI handled the submission of batch jobs for respective applications. Upon receiving the Http request from CAWLA, the WebAPI in the container executed the programs by invoking all required files such as JCL and compiled .Net DLLs for respective application, emulation and runtime libraries. Batch jobs invoked data from SQL MI database or datasets from VNAS location on an as-needed basis. Output files were again created at VNAS and were accessible to users and application system IDs based on their security profiles. Depending on the WebAPI response returned, a scheduler updated the batch job status.

Online Containers – For online transactions, end users used the same Terminal 3270 screen as in the mainframe. A new Ingress URL along with a port number was configured for each online application separately. The team used the Raincode provided AD Security layer to authenticate users against enterprise LDAP data. For the authenticated users, online containers executed the transactions.

KEDA for Autoscaling of Online Containers

Online applications were accessible only during specific times of the day, e.g. 6 AM EST to 5 PM EST daily except Sunday. For rest of the time, those were inaccessible to avoid overlapping with application’s batch job schedule. KEDA was effectively used to achieve this orchestration.

To achieve container autoscaling, KEDA was installed in the AKS Cluster. The team updated the application container deployment specification yaml file to include the KEDA usage syntax that uses Cron type as event source and a schedule for the online container deployment. The specification file was updated with fields for max/min/desired Replicas to be created during deployment for autoscaling based on the trigger condition, i.e. the Cron job schedule.

The diagram below shows indicative sample code for the KEDA syntax and the container availability:

Impact

The mainframe re-hosting to Azure Cloud was successfully implemented as per business timelines. It provided following benefits:

• The entire source code, as well as build and deployment activities, were brought under enterprise DevSecOps standards resulting in a 25% reduction in development cycle time and thus improving the time-to-market.

• A 60% annual savings in annual total cost of ownership (TCO) with mainframe
  decommissioning.

• Moving away from some of the legacy technologies like Assembler, REXX, Telon, FOCUS and IMS database resulted into improved agility.

• Opportunity for replacing/rewriting legacy components with newer modernized capabilities.

• Legacy IMS database (hierarchical) migrated to SQL database (relational) enabling future modernization.

• 15 applications migrated from monolithic setup to individual containers on the cloud.