Welcome to our blog! Welcome to our blog!
Enabling Continuous Delivery for Mainframes: Yes, It's Possible (and Essential)

Continuous Delivery for Your Mainframe

When you hear the word “DevOps,” you probably first think of flashy new infrastructure technologies like Docker containers. But that doesn’t mean DevOps practices are incompatible with older types of infrastructure. As this article explains, there’s no reason you can’t do continuous delivery – one of the hall marks of DevOps – on mainframe systems.

Below, we take a look at what continuous delivery means, and how you can enable it on mainframes.

Defining Continuous Delivery

What is continuous delivery? As the term implies, it means that software is delivered to users on a continuous, or nearly continuous, basis. Updates to applications are released to users every day, or sometimes even every hour.

Continuous delivery is different from “waterfall” delivery, which predominated before the DevOps age. Under the waterfall model, developers released software according to slow, irregular, staccato rhythms. Instead of pushing out updates to applications daily, they’d release them every few months – or sometimes even years.

DevOps -- Continuous Delivery versus Waterfall Delivery

Why do Continuous Delivery?

The waterfall approach worked well enough in an age when users were not constantly connected to their apps, and when adding new features and security updates was not essential for businesses to stay competitive.

Today, however, user expectations have changed. If you go months or years without updating the software you host, your apps will feel stale and outdated. Users will go elsewhere.

Or, if you use the apps in-house, they’ll become inefficient because they will lack the latest innovations and integrations to speed operations. They may also become insecure because they are missing the latest privacy and vulnerability-mitigation patches.

Continuous delivery helps you avoid these pitfalls. By letting you integrate updates into your software on a continuous basis, it assures that you’re always up-to-date.

From a developer’s perspective, too, continuous delivery offers key benefits because it breaks work down into small chunks. As a result, it becomes possible for members of the development team to work in parallel rather than sequentially.

With continuous delivery, there is no need to wait on software architects to design a large new feature before programmers can start work coding it. Quality assurance teams do not have to wait for a big piece of code to be written before they can begin testing. Admins who deploy software in production can release small updates on an ongoing basis, rather than trying to implement major changes all at once.

Enabling Continuous Delivery

Achieving continuous delivery is not as simple as adopting a few specific tools or implementing a new technology. It’s more about cultural and organizational change.

In order to enable continuous delivery, organizations need to make a few essential changes to the way they develop software. They include:

  • Everyone who plays a role in software development needs to be in constant communication with one another. This is important for assuring that all teams can work in parallel.
  • Software development and deployment should be automated as much as possible. Otherwise, your ability to work continuously will be limited by the number of staff members you have on hand to perform manual tasks.
  • Hardware and software should be integrated as much as possible so that systems can be swapped in and out as necessary. In other words, you don’t want your development process to be dependent on a certain type of hardware or software environment. If it does, you will lack agility and flexibility.

In short, achieving continuous delivery means eliminating all roadblocks that can cause delays in the way you write code.

Continuous Delivery on the Mainframe

You may think that getting the level of flexibility and automation described above is possible only if you overhaul your existing infrastructure completely and replace it with next-generation technology like containers.

But that’s not realistic for most organizations – and even if you did have the budget to rebuild your entire infrastructure, containers and other new technologies probably would not be able to replace all of your legacy systems anyway. Docker is just not designed to handle the massive amounts of information and processing that mainframes have been doing for decades.

This may leave you wondering how you can possibly take mainframes – a type of system architecture that was designed decades ago – and make it jive with continuous delivery. If you take advantage of some of the latest innovations in the mainframe ecosystem, however, enabling continuous delivery on mainframes is much easier than you might think.

What the process essentially boils down to is optimizing the integration of your mainframes with the rest of your infrastructure. As long as you can exchange information between mainframes and other environments seamlessly, and update your mainframe software continuously, there is no reason why your mainframe apps can’t be continuously delivered along with all of the other software you run.

Remember, continuous delivery is not about switching to a specific type of tool. It’s about the approach you take to integrating the systems and technologies you have in place, however “old” or “new” they happen to be.

Using Syncsort to Achieve Continuous Delivery

Syncsort’s suite of mainframe, “Big Iron to Big Data” solutions can help you make the jump to continuous delivery by making your mainframes work seamlessly with the rest of your hardware and software resources. In addition their “Big Iron to Big Data” solutions for easily accessing and integrating mainframe data into Hadoop and Spark Data Lakes, or sorting large amounts of information quickly, deliver exactly the type of automation and integration that you need to deliver mainframe apps continuously and bring your mainframes into the DevOps age.

Christopher Tozzi

Authored by Christopher Tozzi

Christopher Tozzi has written about emerging technologies for a decade. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, is forthcoming with MIT Press in July 2017.
1 comment
  1. The reason the mainframe has been different adapting to the continuous delivery era is because of the environment that mainframe systems were used in. They were designed and intended to serve as many clients as possible, rather than devoting all their services to one. Sometimes quite complex update procedures built up in the organizations that used mainframe services. In DevOps all updates to a running mainframe system occur asynchronously, with multiple systems and operational applications services. We used to schedule big updates so that we could minimize service disruption. Turning the whole thing off was to be minimized. Downtime was expensive. On your device you can start and halt a service at will. The way in which sequencing and management software interacts with the tasks that perform the work of installing new software, is different in the mainframe environment and the device world. So there are challenges to eventual full automation as it is displayed on my laptop or phone device.

Leave a Comment