Mainframes, containers, and Linux

We all know why mainframes are good – all that reliability, availability, and security stuff that we’ve been hearing about for many years. The question then becomes: how can we make mainframes better? IBM’s new Z15 mainframe announcement shows how security can be enhanced with the introduction of Data Privacy Passports technology with any data created on the Z15 being encrypted and protected as it moves to the public cloud or a third party, eg an x86 server, phone, or Internet of Things (IoT) device. The Z15 compresses secure Web transaction data before encryption using a unique technique rather than using software compression. But what else can be done?

One answer is to use containers on a mainframe. So, what is a container? A container is a standard unit of software that packages up code and all of its dependencies, so the application runs quickly and reliably in different computing environments. An example you might be familiar with is Docker. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings.

Container images become containers at runtime, and in the case of Docker containers, images become containers when they run on a Docker engine. The advantage is that containerized software will always run the same, regardless of the infrastructure. Containers isolate software from the surrounding environment and ensure that it works uniformly. Docker packaging reduces the complexity and installation of software.

You may also have heard of Kubernetes. Kubernetes (often referred to as k8s) is an open-source container-orchestration system for automating application deployment, scaling, and management. It was originally designed by Google, and is now maintained by the Cloud Native Computing Foundation. It aims to provide a “platform for automating deployment, scaling, and operations of application containers across clusters of hosts”. It works with a range of container tools, including Docker. Many cloud services offer a Kubernetes-based platform or infrastructure as a service (PaaS or IaaS) on which Kubernetes can be deployed as a platform-providing service.

IBM has picked up on the idea and produced z/OS Container Extensions (zCX). This provides a way to run Linux capabilities on z/OS. You might raise your eyebrows at the idea and ask whether we need another way to run Linux on mainframes. You’re right that we already have UNIX System Services, or we could have a LinuxONE mainframe. Both good ways of running Linux on Z. What zCX offers is a complete Linux on Z operating system as part of z/OS. zCX runs in a started task and contains both a full Linux system and Docker. zCX is a virtual appliance that requires minimal involvement after set-up. z/OS V2.4 provides this virtual Linux appliance as part of the OS. It’s set up to expose Docker-based functionality. And the benefit is that z/OS can run Linux code that has an affinity for z/OS data or applications. The thinking is that once it’s been set up, an appliance won’t require the system programmer to spend very much time managing it. And any management the zCX server does need can be simplified by using z/OSMF workflows.

IBM’s z/OS Management Facility (z/OSMF) provides system management functions in a task-oriented, Web browser-based user interface with integrated user assistance, so that users can more easily manage the day-to-day operations and administration of their mainframe z/OS systems. By streamlining some traditional tasks and automating others, z/OSMF can help to simplify some areas of z/OS system management.

The installation of zCX is straightforward because it’s included as part of the z/OS 2.4 licence and it uses z/OSMF workflows for configuration and starting. It only runs on z14 (and, I’m sure Z15) hardware. And zCX runs on general purpose engines, while the workloads that run on zCX are zIIP eligible.

Application developers don’t need to know much about z/OS to create and deploy Linux on Z applications to run in zCX because applications will look like Docker applications to the developer, rather than z/OS applications. So, if an application comes from Linux on Z, no z/OS skills are required, just a knowledge of Docker and Linux. Not surprisingly, zCX runs in ASCII (rather than EBCDIC) like any typical Linux distribution.

The initial release of IBM zCX for IBM z/OS V2.4 is intended to provide Docker Swarm as support for Docker cluster management. Swarm is an open-source container orchestration platform and is the native clustering engine for and by Docker. Any software, services, or tools that run with Docker containers run equally well in Swarm. Swarm turns a pool of Docker hosts into a virtual, single host. zCX doesn’t currently use Kubernetes, however, IBM apparently plans to leverage Kubernetes clustering for the orchestration, scalability and management of zCX with compatible cloud platforms.

So, if you can now run Linux inside z/OS, what’s the future for USS or Linux on Z? At the moment, IBM is saying that UNIX System Services is still an integral and strategic component of z/OS that continues to be supported with the rest of the operating system. It also says that zCX isn’t a replacement for traditional Linux on Z environments. If you’re a client with Linux on Z installations, you will continue to run those installations. But for z/OS clients that used to, but no longer have a Linux on Z installation, zCX could be of real interest. Similarly, z/OS clients that have never had a Linux on Z installation may find that zCX is a low effort way to try Linux on Z.

The version of Linux that comes with zCX is Ubuntu, which is the same Linux distribution used in Secure Services Containers (SSCs), and is provided and maintained through IBM. In addition to open-source packages, IBM plans to have IBM and third-party software available at the GA of z/OS V2.4. Clients will be able to participate with their own Linux applications, which can easily be packaged in Docker format and deployed in the same way as open-source, IBM, and vendor packages.

It strikes me as a very good idea from IBM. A lot of mainframe sites also use Linux, so it’s an easy way to get people to experience the power of the mainframe with their Linux applications. Once they’ve done that, they won’t want to go back. It’s good for the systems programmers because they now have an excuse to “play with” containers, which they may not have had a chance to do before. Because it becomes available with the next release of z/OS, it could be a driver, convincing sites to upgrade to the new version sooner than they might otherwise have done. And because it only runs on the latest processors, it might well act as a spur for sites to upgrade to the latest hardware, when they may well have been putting off the cost involved for, perhaps, another year. And looking to the future, what other operating systems could IBM wrap up in a container and run under z/OS?