This blog was written by a team of technical consultants from IBM Montpellier.

Using a microservices architecture is the popular way to create new applications, and this can bring many advantages, including greater agility, scalability and resilience. But what if the application is a hybrid application that relies on core applications and data residing on the mainframe. Does it matter where you deploy the new microservices?

Figure 1 shows different topologies that can be used when microservice applications access core systems running on IBM Z.

Figure 1    IBM Z microservices deployment options

Figure 1 illustrates the following deployment options:

• Host microservices in a public cloud

Increasingly, an organization's applications reside in public cloud environments and are often deployed as a set of microservices. When these microservices have a dependency on core systems (for example, CICS, IMS or Db2) the core systems are accessed as attached resources (or backing services) which are normally exposed as REST APIs.

• Host microservices in a private cloud on IBM Z
  When a microservice application has a close dependency on core systems, resulting in many interactions to systems running on IBM Z, it can be advantageous to deploy these microservices on IBM Z.

Our tests showed an end user response time improvement of nearly a third[i] when re-deploying a microservice application from a public cloud to a private cloud on Linux on IBM Z.

• Co-locate microservices with core applications
  When a specific microservice requires the fastest possible response time from a backing service, or requires transactional integration with the core data, the microservice can be co-located within the same system as the core application.
  

In this blog we focus on the latency considerations, by comparing different deployment options for microservices that require connectivity to CICS and Db2 core systems.

We also consider some of the other advantages of deploying microservices to IBM Z, including security, data integrity, high availability and scalability.

Introduction

Hybrid architectures, that integrate public and private cloud as well as traditional on-premises infrastructure, are enabling clients to extend beyond their data centers into cloud services.

This shift from traditional enterprise IT, to hybrid, multi cloud environments brings with it very real architectural considerations, and particularly the need to improve the integration of services across the mix of environments.

Containers provide the runtime environments for new microservices applications. These containers require an orchestration technology such as Kubernetes or Red Hat OpenShift to enable managed production-grade deployments. IBM Z now supports a range of container solutions including Docker, Kubernetes and OpenShift, allowing you to deploy microservices on the same platform as the core systems on which they depend. Platform co-location can improve network latency and provide a more secure integration between microservices and core applications.

In some cases, closer integration may be required, for example, where updates in a microservice and in a CICS application must be made within the same logical transaction to ensure data integrity. To meet these more ‘tightly-coupled’ requirements it is also possible to deploy microservices within the same runtime as the core system, for example, within CICS using a Liberty JVM server.

In our tests for this blog, we deployed a sample account management microservices application to different topologies and then compared the user response times for each topology. The microservices have close affinities to an Account management system running in CICS, and a Master data management (MDM) system running in Linux on IBM Z.

We’ll see from the results of these tests that careful consideration should be given to microservice deployment.

Account management application

Let’s start with a quick overview of the sample application.

The account management application is part of the IBM MPLbank showcase created by the IBM Garage for Systems team in Montpellier. The demo banking system used in the showcase runs a mixed workload of real-world financial transactions, including cash withdrawals, deposits, and real-time payments. The CICS/COBOL core banking application stores customer and account records in Db2 for z/OS. The end user interacts with a front end microservices application which enables the user to access account data and to perform payments (see Figure 2).


Figure 2    Account management application - user interface

The user (a bank employee) connects to the application and uses a client’s email address to retrieve personal information such as name, marital status, number of children, annual income and a list of accounts. A balance and list of recent account operations is shown for each account.

Figure 3 shows the component model of the account management application.



Figure 3    Account management application – component model

The main components of the application are described in the table below.

Component	Language	Platform	Role	Interacts with
User interface microservice	Node.js	Cloud platform	Retrieves client information and list of accounts. Generates html file to be sent to the user	MDM Account management microservice
Account management microservice	Java	Cloud platform	Retrieves detailed account information	Account Management System
Master Data Management System	Java	Linux on IBM Z	Stores client information in Db2 for z/OS	User interface microservice
Account Management System	COBOL	CICS TS running on z/OS	Core banking application (Sopra Banking)	Account management microservice

When considering where to deploy the user interface and account management microservices it is useful to consider the different interactions between the components (see Figure 4).





Figure 4    Account management application – interaction model

In Figure 4 we see the following interactions:

For our tests, we measured response times for the account management application in three different cloud deployment topologies.

Topology test results

A workload from a small number of clients was simulated using JMeter. The tested topologies, and the results of each test, are described in more detail below.

Topology 1 – Public cloud (IBM Cloud)

In the initial topology, the user interface and account management microservices are deployed to IBM Cloud (Figure 5) and they access IBM Z through the IBM Secure Gateway. The user interface microservice calls the MDM using SOAP over HTTPS. The account management microservice calls the Account Management System using REST over HTTPS. The REST APIs have been enabled using z/OS Connect EE.

Figure 5    Public cloud (IBM Cloud)

Figure 5 shows the average end user response time (1580ms) and the response times of the calls to the core systems. The end user response time includes the network connection to IBM Cloud, the processing of the microservices application, 2 calls to the MDM, and 10 calls to the Account Management System (5 balance requests and 5 requests to retrieve the latest account operations). Note that retrieval of the list of user accounts from the MDM (839ms) makes up the most significant part of the end user response time.

Topology 2 - Private cloud (OpenShift on Linux Z)

In the second topology, the user interface and account management microservices are deployed to a private cloud using an OpenShift Container Platform on Linux on IBM Z (Figure 6). The user accesses IBM Z through the IBM Secure Gateway. The microservices deployed to containers running on Linux on IBM Z interact with the core systems using the same protocols as in topology 1.

Figure 6    Private cloud (OpenShift on Linux Z)

Enabling cloud capabilities like OpenShift on IBM Z enables containers to exist in the same environment as a company's core systems and data. The microservices application is developed and deployed using the same cloud-native processes as other cloud environments, whilst benefitting from the advanced security, vertical and horizontal scalability, and 99.999% availability capabilities of IBM Z.

This topology enables cloud native applications to easily integrate with existing data and applications running on IBM Z, enabling latency to be reduced by avoiding network delays. Figure 6 shows that the average end user response time improved by 29% in our tests (from 1580ms to 1128ms) compared to topology 1.

For more information on the benefits of deploying OpenShift on IBM Z see Application modernization with Red Hat OpenShift on IBM LinuxONE.

Topology 3 - Private cloud (OpenShift on Linux Z and CICS Liberty)

In the final topology, the account management service is deployed to a Liberty JVM server in CICS (figure 7).

Figure 7    Private cloud (OpenShift on Linux Z and CICS Liberty)

When a specific microservice requires the fastest possible response time from a backing service, or when a microservice updates transactional data that needs to be updated within the same unit-of-work as updates to core data, the microservice can be co-located within the same system as the core application.

For topology 3 the account management microservice was enhanced to use JCICS (the Java equivalent of the EXEC CICS API) to call the Account Management COBOL program. The microservice was then deployed to a Liberty server running in the same CICS region as the Account Management COBOL application. This significantly improves the response time for retrieving account balances and account operations as it eliminates the network connection.

Whereas the end user response time for this topology did not differ significantly from topology 2, deploying the account management microservice to CICS Liberty gave the best response time for accessing the Account Management System (3-5ms).

Comparing the results

Deploying cloud services to a public cloud is appealing for clients because there is a large choice of Cloud Service Providers (CSPs), and the initial deployment can be fast because there is no on premise infrastructure to setup. Cost is often the most important factor in choosing a CSP, and services can be re-deployed to a different public cloud offering if one CSP undercuts another.

CSPs offer choices about where to deploy cloud applications and data, and it is important to consider connectivity to backing services when deciding where to deploy cloud services. For example, in our public cloud test (topology 1), we measured end user response times with the user interface and account management microservices deployed either to the IBM Cloud Dallas data center or to the IBM Frankfurt data center. Deploying the microservices to the Frankfurt data center improved the network latency between the microservices and core applications running in the IBM data center in Montpellier France by 37%.

For topology 2, the microservices were deployed to a private cloud using an OpenShift Container Platform on Linux on IBM Z. Although this requires an investment in the private cloud infrastructure and skills, this solution benefits from the highest levels of data security and protection, resilience and scalability offered by the IBM Z platform. With this topology we were able to reduce the end user response time by 29%, from 1580ms to 1128ms (see Figure 8).

Figure 8    End user response time comparison  

In topology 3, the account management microservice was co-located within the same CICS region as the Account Management COBOL application. Note that the end user response time for this topology did not differ significantly from topology 2. This is because the calls to the MDM make up 75% of the end user response time. However, the tests for topology 3 gave the best response time for accessing the Account Management System (see Figure 9).


Figure 9    Account Management System response time comparison

Deploying the account management microservice to CICS Liberty improves the response time from the Account Management System by 90% (from 30ms to 3ms) compared to deploying the microservice in the IBM Cloud. This would have an impact on the end user response time if the number of calls to the Account Management System increases significantly. It is important to note, however, that deploying the account management microservice to CICS Liberty requires a change to the way that the microservice calls the Account Management COBOL application and to the way that the microservice is deployed.

Summary

In this blog we explored some deployment options for a microservices application that has a close dependency on core systems running on IBM Z. We have seen that deploying cloud native applications to IBM Z can simplify integration with existing mainframe data and applications, improve end user response times by reducing network latency and benefit from the well-established mainframe qualities of service.

This blog was written by the following team of technical consultants from IBM Montpellier who help clients to leverage the unique capabilities of IBM Z and LinuxONE.   

Yann Kindelberger and Stephane Faure (IBM Garage for Systems)
Aymeric Affouard, Eric Phan and Nigel Williams (IBM Z Systems Lab Services)

[i] The performance data discussed herein is presented as derived under specific operating conditions. Actual results may vary.