Docker on the mainframe: yeah, that’ll be a thing

New release of #Docker EE extends #IBM mainframe support: New Z managers and Power hosts. Read more: https://t.co/PVacybCsIr pic.twitter.com/QUWGH9shUF

— Docker Build Cloud is here! 🐳🧱☁️ (@Docker) November 2, 2017

I haven’t written up the Docker Modernize Traditional Apps (MTA) thing I promised you from Dockercon Europe yet, but bear with me. I think we can basically make this a standalone post in the meantime.

My primary argument for why we can expect Docker on the mainframe to become a relatively significant phenomenon, at least for the top 100 or so IT spenders on the planet, is essentially an argument from history. The fact every significant technology that promises platform portability, and modernity, makes its way into the mainframe installed base. The idea of writing an app on a Mac and running it on a mainframe is the latest version of the portability story.

Back in the olden days when IBM first announced Java support on the mainframe the fit wasn’t quite right. Mainframes were for DB2. Cobol, CICS and IMS. Why run Java workloads there? But over time it made more and more sense. The reasons are fairly prosaic – data management, I/O and cost. Without going into the mainframe pricing priesthood lingo of books, Workload Licensing Charge (WLC) and so on, it turned it was just a lot more expensive, both in terms cost based on I/O but also administrative overheads, to run the mainframe as a back end server, and then WebSphere on a separate Unix or Linux machine. If you’re going to run anything on the mainframe, it makes most sense to run other workloads touching those transactions as close to the mainframe as possible – which usually means on the mainframe. Java on the mainframe became part of the IBM modernising the mainframe shtick, and now it’s normal for those huge customers running transaction workloads – folks that run banks and airlines and massive retailers and so on – to do so.

Linux on the mainframe followed a somewhat similar pattern. At first glance – why would you do that? If you want to run Linux then do it on commodity hardware, right? It turned out again that the economics aren’t quite so straightforward, and many organisations started running Linux on the mainframe, so IBM offered them specialist processors to do so. Enterprise customers were keen enough on Linux for mainframes IBM also made a “mainframe without all the mainframe stuff” called LinuxOne – as a consolidation server for Linux instance sprawl. IBM also introduced pay per use pricing. Bottom line – customers felt they were getting Linux servers with mainframe “-ilities” without paying normal mainframe MIPS for the privilege. IBM also pushed the open platform case forward by supporting Apache Spark, Node.js, MongoDB, MariaDB, PostgreSQL and Chef on LinuxOne.

For mainframe shops running Linux Docker is an obvious tuck in. Docker EE 17.06.1 supports Ubuntu, SLES, RHEL for IBM Z using the s390x architecture. So now it’s Docker’s turn. We’ll likely see the Docker Pattern assert itself at companies like ADP (big Docker shop, big mainframe shop) and Walmart (mainframes, anti-Amazon Web Services mandates). So while, as I say, this is not my MTA post, it’s significant that Docker is working with partners on a legacy modernisation factory approach.

There will be some internal competition and bet hedging at IBM – this week it announced its own IBM Cloud Private offering, designed with Kubernetes as the portability layer. Architecturally it’s not a stretch for IBM to support both Docker Swarm and Kubernetes (Docker itself has embraced K8s). IBM customers can support customers whether they take the blue pill or the red pill, and the mainframe business could care less frankly. They just want apps that run close to the data.

IBM and Docker are both RedMonk subscribers, but this analysis is independent of these relationships.