Part 3 of 4: The Bad
As I’ve explained in Part 1 Basics and Part 2 Good, I did a proof of concept port of an Enterprise Application from Amazon Web Services on x86 to Linux on System z in 2017. The good news was I got to the point I needed to, the bad news was it was more than difficult to get there.
Linux is not Linux
Open Source is open source…available to anyone. The story goes that Linux is Linux. Close, but not quite. Unfortunately, architectural chip bits (Big Endian vs Little Endian) is one of many differences and there is code that needs to change to handle these differences. There are also supported platforms, “tolerated platforms” and unsupported platforms. This is the problem with Linux on System z. The marketing hype is that all of Linux is supported on z. The reality is somewhat different. Not necessarily insurmountable, but you better know what you are getting into.
Supported Platforms
When Linux on z is a supported platform, then the packages for System z are supported in binary format, such as an RPM file for Centos/RedHat or an APK file for Alpine. This is the best case and makes development of S390X on par with other platforms like x86 and ARM.
Tolerated Platform
In this case, the code may work on S390X, but it’s a source code build. You can find instructions on Github for S390X as to how to modify the code to get it to work on the platform. But if you want to use that code, it could take a long time to:
- Do all the things necessary to manually modify the code
- Execute the code to create a binary.
Let me use an example. Couchbase is the non-SQL database preferred by the vendor I worked with. Someone within IBM is maintaining a script on Github to help others leverage a particular release of Couchbase. Since Couchbase is constantly coming up with new versions, those edits need to be constantly updated. I would have preferred a binary version of the code, but IBM doesn’t do binaries…They only do source. And in order to make Couchbase work, there are pre-requisite source modifications necessary to Go, Python, cmake, Erlang, flatbuffers, ICU, jemalloc, and v8 javascript. Manually doing all that is necessary takes a few hours. I was fortunate to take all of these changes and build a docker script that was several hundred lines long to automate the build of Couchbase by doing all this work. When I ran this container build, it took over an hour to complete. I had to do this many times before I got the automation script to work properly. And that automation is only good until the next release comes out. In comparison, with an x86 rpm, this takes a couple of minutes and the Docker script is about 15 lines long. In the end, I got what I needed, but the level of effort to get there was tremendous. I also mentioned container memory size in Part 1. This Couchbase container on z was over 1 GB memory. This put a tremendous strain on Docker and we found a few bugs as a result. The size was a combination of Couchbase and all the prerequisite code to build Couchbase. So I had to modify the Docker build to delete all the prerequisite code which included source, binaries and documentation. This got the container down to a more reasonable execution size.
BTW, when I complained to IBM leadership about the lack of support for Couchbase, they suggested I use a different, easier product that was available on z. Since I was porting and not a true developer, this was not a possibility for me. I had begun negotiations with Couchbase toward this goal, but stopped working on it when the prototype ended.
Unsupported Platforms
There were two cases where neither the open source community nor the Linux on z community had guidance on how to get a particular open source program on the mainframe. In those two cases, I was able to get through the code, successfully and get a binary for System z. The good news was it was pretty simple to do. I was quite fortunate. If it hadn’t been easy, this could have ended the project earlier than I had hoped.
Docker containers are not portable across hardware architectures
I’ve seen some hype that once you get it in Docker, it’s portable to any Docker. I’ve heard a few mainframe customers believe any Docker container can run on System z. I’ve also seen articles in IBM sponsored magazines that purport this to be true. This is a combination of marketing hype and misunderstanding. It all depends on the container architecture/binary and source code. Typically, a container binary for a particular architecture, such as x86, should run in a Docker container on any x86 platform, even if it’s a different operating system running Docker. For example, Docker running on x86 version of RedHat 7.3 could be running containers with RedHat, SUSE, Alpine, Ubuntu, etc, as long as they were built for x86. Similarly, I ran Docker on a RedHat 7.3 image for Linux on System z, and had containers with Centos and Alpine running with binaries for S390X.
The only containers with source code that were portable were built exclusively with interpretive languages, such as Java or Python. Those could be portable across hardware architectures. Many of the test cases used by this vendor fit into that category. However, as soon as one of those interpretative languages makes a call to open source code middleware (e.g. Couchbase), then the container is no longer portable across architectures because the middleware is not supported across architectures.
Docker Stability
When I started this project, Docker on z was pretty new. Once in a while, it would have issues. Only a couple of times did it require Marist College to restart my z/VM guest. The other times, it would automatically recycle itself and get running again. I believe it’s improved since we began the port effort until now, but it’s been a few months since I tried it. I’ve heard from others, though, that the experience is better. During our Big Bang builds, we would peg each of our System z processors at 100% busy for a few hours. The fact that it would stay up and continue processing is a testament to the reliability of those large code tests.
Ultimately, I have a wishlist for the Open Source Community on z:
- Where source code changes are necessary, such as with Couchbase described earlier, supply a Docker build file to automate it for anyone that wants to do the build. It would be so much faster.
- Continue to lobby third-party open source middleware providers to support system z. In many cases, it takes a vendor, such as I was working with, to create that business case jointly to get it done, but doing that will lead to more usage on the platform. If you build it, they will come.
- Create more binary packages instead of source code update files. It greatly reduces the development time necessary for z unique porting. The more extra work necessary to support z, the less likely the x86 people will move there.
The net of all this bad is the initial effort to support the mainframe is longer than it would be on x86. However, if you have the patience to get to Part 4: The Future and Value, you’ll find that you should be rewarded for the effort.
Read Part 1 here.
Read Part 2 here.
Jim Porell is a Rocket Principal Software Architect, focusing on new functions for System, Storage and Security products from IBM. His primary focus is the architecture of the OMEGAMON family of monitoring agents. Prior to joining Rocket, he was an independent consultant and retired IBM Distinguished Engineer. He held various roles as Chief Architect of IBM's mainframe software and led zSystems Business Development, as well as marketing of Security and Application Development for the mainframe. His last IBM role was Chief Business Architect for Federal Sales. Jim held a TS/SCI clearance for the US Government, was a member of the US Secret Service Electronic Crimes Taskforce in Chicago and co-authored several security books. He has done cybersecurity forensic work at a number of Retail, Financial and Government agencies and created a methodology for interviewing customers to avoid security breaches for large enterprises. Jim has over 43 years working with Information Technology.