High-Performance Mainframe Workloads on AWS with Cloud-Native Heirloom

By Gary Crook, CEO at Heirloom Computing

It is common to meet enterprises still using mainframes because that is historically where their core business applications have been. With Heirloom on AWS, we can decouple the application from the physical mainframe hardware, allowing us to run applications in the cloud and take advantage of the benefits of Amazon Web Services (AWS).

Heirloom automatically refactors mainframe applications’ code, data, job control definitions, user interfaces, and security rules to a cloud-native platform on AWS. Using an industry-standard TPC-C benchmark, we demonstrated the elasticity of Heirloom on AWS, delivering 1,018 transactions per second—equivalent to the processing capacity of a large 15,200 MIPS Mainframe.

Heirloom is deployed on AWS Elastic Beanstalk, which facilitates elasticity (the ability to automatically scale-out and scale-back), high availability (always accessible from anywhere at any time), and pay-as-you-go (right-sized capacity for efficient resource utilization). With Heirloom on AWS, mainframe applications that were rigid and scaled vertically can be quickly and easily transformed (recompiled) so they are now agile and scaled horizontally.

Heirloom Computing is an AWS Partner Network (APN) Standard Technology Partner. In this post, we use a real-world example to outline how monolithic mainframe applications can automatically be refactored to agile cloud-native applications on AWS.

Heirloom Overview

At the core of Heirloom is a unique compiler that quickly and accurately recompiles online and Batch mainframe applications (COBOL, PL/I, JCL, etc.) into Java so they can be deployed to any industry standard Java application server, such as Apache Tomcat, Eclipse Jetty, or IBM WebSphere Liberty.

With Heirloom, once the application is deployed it retains both the original application source code and resulting refactored Java source code. Heirloom includes Eclipse IDE plugins for COBOL, PL/I, and Java, as well as a fully functional integrated JES console and subsystem for running JCL jobs. This enables a blended model for ongoing development and management of the application so you can bridge the skills gap at a pace that is optimal for you, and switch code maintenance from COBOL to Java at your convenience.

Figure 1 – Heirloom refactoring reference architecture for mainframes.

Elastic Architecture

Heirloom deploys applications to industry standard Java application servers, which means your application can instantly leverage the full capabilities of AWS. Applications can dynamically scale-out and scale-back for optimal use of compute resources, and seamlessly integrate with additional AWS managed services like AWS Lambda and Java application frameworks like Angular2.

Here’s an example that uses Amazon Alexa to interact with unmodified CICS transactions deployed as microservices, and here’s another example that utilizes Docker containers.

Figure 2 – Heirloom elastic architecture for high performance.

The Heirloom elastic architecture relies on stateless share-nothing application servers that scale horizontally across Availability Zones (AZs). Any shared or persistent data structure is stored in an elastic managed data store. On AWS, this horizontal architecture across several AZs and many instances is key for elasticity, scalability, availability, and cost optimization. AWS Elastic Beanstalk automatically handles the application deployment, from capacity provisioning, load balancing, and auto-scaling to application health monitoring.

Application artifacts that are not inherently scalable are refactored to a target that automatically removes that constraint. For example, file-based data stores such as VSAM files are migrated to a relational data store using Heirloom built-in data abstraction layers. This is achieved without requiring any changes to the application code.

Performance Results

Using a COBOL/CICS implementation of the industry standard TPC-C benchmark, we measured transaction throughput per MIPS by running the application on a mainframe with a known MIPS specification. We then ran the same application on AWS infrastructure to measure transaction throughput and derive a MIPS rating using the ratio from running the application on the mainframe. Consequently, we determined the AWS environment was able to consistently deliver an equivalent MIPS rating of 15,200 at a sustained transaction throughput of 1,018 transactions per second.

For the performance test on AWS, we took more than 50,000 lines of the TPC-C application code and screens and compiled them (without any modifications) into 100 percent Java using the Heirloom Software Developer Kit (SDK) Eclipse plugin. The Java code was then packaged as a standard .war file, ready for deployment to any industry standard Java application server (such as Apache Tomcat).

The TPC-C environment on AWS is composed of:

• 22,500 simulated end-user terminals hosted by 10 m3.2xlarge Amazon Elastic Compute Cloud (Amazon EC2) instances.
• All concurrent transactions are distributed to application instances by a single AWS Application Load Balancer which automatically scales on-demand.
• The Heirloom TPC-C application layer is hosted in an AWS Elastic Beanstalk environment consisting of a minimum of 16 m4.xlarge Amazon EC2 instances (a Linux environment running Apache Tomcat). With the AWS Auto Scaling Group, this environment automatically scales-out (by increments of 8), up to a maximum of 64 instances (depending on a metric of the average CPU utilization of the currently active instances). It also automatically scales-back when the load on the system decreases.
• For enhanced reliability and availability, the instances are seamlessly distributed across three different AZs (i.e. at least three different physical data centers).
• The database (consisting of around five millions of rows of data in tables for districts, warehouses, items, stock-levels, new-orders, etc.) is hosted in an Amazon Aurora database (which is either MySQL or PostgreSQL compatible).
• The application monitoring layer is provided by Amazon CloudWatch, which provides a centralized constant examination of the application instances and the AWS resources being utilized.

The application workload at peak was distributed over a total of 144 CPU cores (each CPU is equivalent to 2 vCPUs), consisting of 128 CPU cores for the application layer and 16 CPU cores for the Aurora database layer. For a 15,200 MIPS capacity, this yields approximately 105 MIPS per CPU core (or 52 MIPS per vCPU). This is consistent with our client engagements, and a useful rule of thumb when looking at initial capacity planning.

Cost Analysis

For a large mainframe of more than 11,000 MIPS, the average annual cost per installed MIPS is about $1,600. Hardware and software accounts for 65 percent of this, or approximately $1,040. Consequently, we determined the annual infrastructure cost for a 15,200 MIPS mainframe is approximately $16 million.

On the AWS side, using the AWS Simple Monthly Calculator to configure a similar infrastructure to the performance test, we estimated the annual cost to be around $350,000 ($29,000 monthly). This AWS cost could be further optimized with Amazon EC2 Reserved Instances.

The annual cost for Heirloom varies depending on the size of the application being refactored (it consists of a cost per CPU core with larger discounts for larger application workloads). With all costs accounted for, our clients typically see a cost reduction in excess of 90 percent, and positive ROI within a year.

Code Quality

With any solution that takes you from one ecosystem to another, not only is it essential the application behaves and functions as it did before, it’s vital that any application code produced is of the highest quality.

Using SonarQube with the default configuration, we can examine the quality of the Java application produced by Heirloom when it compiled the 50,000+ LOC in the TPC-C application (which was originally a COBOL/CICS application written for the mainframe). SonarQube rated all the major aspects (reliability, security, and maintainability) of the Java application source-code with the highest rating of “A.”

Figure 3 – SonarQube analysis for the TPC-C benchmark application refactored with Heirloom.

Refactoring Tools and Application Development

The Heirloom SDK is a plugin for the Eclipse IDE framework and provides tooling that covers all aspects of a refactoring project, as outlined in Figure 1.

The same tooling is then used for ongoing application development and maintenance. This can be done in COBOL, PL/I, Java or any mix. Each language is fully supported with a feature-rich project workspace, editor, compiler, and debugger.

Regardless of which language you choose, Heirloom applications always execute on the Java platform.

Figure 4 – Eclipse IDE with Heirloom SDK showing a COBOL debugging and editing session.

Not Just Cloud, But Cloud-Native

You can move an application to the cloud by re-hosting it (also called “lift and shift”) on an Amazon EC2 instance, retaining the existing constraints of the legacy workload such as stateful applications, monolithic application structure, file-based data stores, and vertical scaling. It works with limitations, but it is not cloud-native.

In simple terms, cloud-native is an approach to the development and deployment of applications that fully exploits the benefits of the cloud-computing platform. There are best practices for cloud-native applications, such as:

• Adherence to the Twelve-Factor App methodology, including stateless share-nothing processes and persistent or shared data stored in backend databases.
• Dynamic, horizontal scale-out and scale-back.
• Available to be consumed as a service.
• Enables portability between execution environments in order to select fit-for-purpose compute or data store services.
• Leverage cloud-provided system management such as central monitoring, central logging, central alerting, central automation, central billing.

Cloud-native applications are elastic, highly-scalable, and embrace the elasticity of underlying AWS services. With horizontal scalability, cloud-native applications are also more cost optimized because you don’t need to size a fixed number of instances for peak traffic. Instead, you can use smaller instances which are instantiated or terminated automatically based on the exact workload demand.

The major benefit of Heirloom on AWS is that it can automatically refactor mainframe applications to Java application servers so they are cloud-native, while preserving critical business logic, user-interfaces, data integrity, and systems security.

Learn More About Heirloom on AWS

See Heirloom in action with our 60-second demo. You can also try it by downloading Heirloom SDK for free—available on Windows, Linux, and macOS.
You can read an in-depth look at how the performance benchmark on AWS was performed in my LinkedIn article.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

Heirloom Computing – APN Partner Spotlight

Heirloom Computing is an APN Standard Technology Partner. Heirloom automatically transforms mainframe applications so they execute on Java Application Servers, while preserving critical business logic, user-interfaces, data integrity, and systems security. With Heirloom , mainframe applications can quickly and easily be transformed to be agile, open, and scaled horizontally.

Contact Heirloom Computing | Solution Brief | Solution Demo | Free Trial

*Already worked with Heirloom Computing? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.