IT modernisation series – LzLabs: Making mainframe apps 'cloud-native'

Cresswell writes as follows…

A general misconception is that the cloud is a home purely for new applications. In fact, many initiatives are underway to transform legacy applications such that they can take advantage of the cloud. Major players in the cloud world are contributing software infrastructure along with an open source model, to support this exponentially growing enthusiasm for cloud deployment.

From increased development agility, to horizontal scalability, service-meshes, micro-services and security; if you are looking to take advantage of the cloud, you’ll need to become cloud-native.

However, even with all this innovation, the cloud still seems stubbornly out of reach for those legacy applications that run on mainframes.

Defining cloud native

Cloud-native is a separate and distinct notion to that of simply running in the cloud. Crucially, “cloud” in cloud-native has nothing to do with where the application runs. The term concerns itself with development and deployment technology that has its origins among the public-cloud vendors, but has now gone mainstream; regardless of the final deployment destination of the application. For an application to be cloud-native, it will exploit technologies, development patterns and methodologies rarely found in traditional, monolithic applications.

It is conventional wisdom that mainframe legacy applications cannot participate in the new world of cloud-native computing; so much so that it is rare for commentators to question why this is.

There are a few reasons:

1. Mainframe applications will not run on the underlying cloud hardware, without significant refactoring and recompilation. They are typically compiled into mainframe-specific machine-code and the mainframe instruction-set architecture is substantially different from the x86 platforms that underpin almost all cloud services.
2. Legacy mainframe applications rely on infrastructure software to manage batch and online activity, data access and many other legacy mainframe features. Like the applications themselves, this infrastructure software is also tied to the physical mainframe hardware; it will not run in a conventional x86 cloud environment.
3. A mainframe development pipeline cannot support many of the rapid deployment features upon which cloud-native applications rely. For example, it’s virtually impossible to spin up testing environments on mainframes without extensive planning. There is just no support for large-scale, container-driven integration testing of traditional legacy applications after each merge of a code branch.
4. Much of the technology that has emerged in recent years to support cloud-native applications is simply not available within the legacy environment of mainframes. Without the ability to run application components using a containerised deployment model, many of the other cloud-native requirements are unachievable.

It sounds like quite the headache doesn’t it? Is it ever possible to work magic and make these mainframe applications cloud-native?

Absolutely it is!

Unfolding the implementation

A vital first step is to move these applications out of their mainframe environment. Recent innovations have allowed for migration of applications, unchanged, to containerised open source systems where the fundamental mainframe infrastructure is faithfully reproduced in a software-defined manner in the cloud. The application can then function exactly as it would in-situ and the rest of the journey toward a cloud-native implementation unfolds.

Of course, simply moving a monolithic legacy mainframe application to a cloud environment does not make it cloud-native.

A key part of the rehosting process involves the replacement of legacy API implementations (which will not run on x86 or the cloud) with API implementations based on standard Linux facilities and cloud-native components.

What this implementation model allows for is the exploitation of cloud-native components; such as etcd to assist with serialisation, Inter-process Communication services such as gRPC, and many cloud-native instrumentation services, that provide immediate benefit as the application is migrated to the cloud.

Mainframe applications can then run in horizontally-scaled, serverless containers, benefit from the inherent capabilities of load-balancing, tracing and granular authentication and take full advantage of relational database services provided by cloud-service providers.

Progressive refactoring

Sometimes called incremental modernisation, progressive refactoring is the most effective method of reaching the promised land of a fully cloud-native implementation. While you can leave these migrated applications as they were, software-defined platforms allow for refactoring of individual ‘programs’ within the application, which can continue to depend on the remaining unchanged mainframe programs in a perfectly natural way. Once replatformed, these applications can fit perfectly into a modern development pipeline – working on them is identical to working on any other modern application, with programming language being the only difference. This consistency means the entire scope of cloud-native services becomes available and these applications are enhanced with exactly the same development methodology as more conventionally modern applications.

System-of-record data residing on mainframes is some of the most intrinsically valuable data to the enterprise.

What many don’t realise is that it is not only possible to rehost mainframe legacy applications on cloud infrastructure, but it can be done in ways that instantly increase the application’s opportunities to take advantage of cloud-native features, without requiring any changes to application source-code.

Furthermore, the applications are now positioned perfectly for progressive refactoring towards a more complete cloud-native implementation.

LzLabs CEO Cresswell: Exploiting the full scope cloud-native for all the right reasons.