Skip to main content

The Joining of Mainframe, Distributed and Cloud-Native Continuous Delivery

Tracy Ragan, the CEO of DeployHub, is a DevOps ambassador, a microservices evangelist and a Continuous Delivery Foundation Board Member. She’s deeply passionate about cloud-native platforms and configuration management. She cut her teeth on configuration management and lifetime management practices while working on the mainframe. Because of that, Tracy urges professionals and organizations to bridge the gap between the worlds of the mainframe and distributed systems.

Read more in the blog or watch Tracy’s keynote from Open Mainframe Summit 2021 below.

The Traditional World and the Brave New World: It’s Time to Bridge the Gap

We can say there are two separate “worlds” in the software industry today: the mainframe side and the distributed systems side. On the one hand, you have the world of Java, jar files, and the mainframe. On the other hand, you have the cloud-native way and its components.

It’s time we bridge the gap between these two worlds. Why is that?

In many large enterprises, the “old” and “new” sides coexist, and such hybrid environments have become critical. While the use of the mainframe has always been pretty standard for large organizations, we haven’t been very good at automating the process of moving the mainframe to the distributed world. These two worlds have become siloed, and we manage them using different strategies and tools. As an industry, we need to figure out how to join these two silos.

A Cooperative Continuous Delivery

How do we bridge the gap we just talked about? First, we need to understand that the software life cycle consists of many moving parts. Instead of segregating those parts, we should create a cooperative continuous delivery process that coordinates all of these parts together.

In other words: we need a shift in the way we think. Let’s accept that, at the end of the day, software is always made of parts, and we can manage those parts in the same way.

It doesn’t matter that those parts are executed in different scenarios—e.g., a Kubernetes cluster vs. a more traditional, monolithic application. They are still components of a whole and shouldn’t be treated differently.

Parts Are Just Parts: The 3 Shifts In Thought

As we’ve mentioned, we need to shift our mindset to acknowledge the simple concept of “parts are just parts.” Actually, there are three important shifts we need, and we’ll walk you through all of them now.

Shift 1

The first shift refers to the fact that systems are always made up of similar parts despite coming in different shapes and sizes. These parts have unique attributes you need to manage. Attributes can look different, but they’re essentially the same:

  • For instance, endeavor repositories vs. git repositories.
  • Every software system has its build process
  • release logic. Every part has its release logic
  • Parameters can be key-value pairs or environment variables.

Shift 2

The second shift is acknowledging the fact that the mainframe, in a way, created DevOps. By acknowledging that the mainframe life cycle management process embraced DevOps practices with great success, we take the first step into coordinating that in a way that leverages the same tooling used by the distributed side of things.

Shift 3

When it comes to the mainframe side, continuous delivery tooling has achieved a great deal of maturity. We needn’t replace those tools. At the same time, we could use some improvement on the distributed systems side, regarding getting code all the way to production.

We must create a CD practice with all parts in mind. Such an approach needs to have a focus on coordination and tracking. The goal is to have a central repository of data, aggregating data from all CI/CD pipelines—regardless of the actual tools you use. That way, this repository of knowledge can act as a single source of truth, so the organization can use its data to develop actionable insights.

It’s All Parts and Attributes: Marry the Mainframe and the Distributed/Cloud-Native World!

When all is said and done, software is just parts, and the parts have similar attributes and parameters. We should collect data about these parts and aggregate the data into a central place to foster collaboration and smarter decision making.

This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.