Containers, Microservices and Open Source: IBM i From Another Perspective
If you’ve worked with enterprise software development, I assume you’ve come across concepts like microservices and containers. Perhaps you’ve worked with Kubernetes or OpenShift. And maybe you already develop microservices in Java with the open-source framework Spring Boot and are over the moon about how great GraalVM is. Personally, I use all the above with Git, DevOps and CI/CD pipelines day in and day out. However, all of these tools and products aim to solve problems that have been around in the IT industry for ages. It’s about separation of concerns. It’s about isolation, security and faster time to market. Basically, it’s about best practices.
I’d like to compare how we use these technologies today, how the approaches have been in the past, why IBM i played a primary role, and why IBM i has a great future ahead for robust solutions.
Containers and the IBM i Architecture
Let’s first look at containers. Why all the fuss about containers? First, a container is a common image format you can spin up on your PC that’s isolated from other workloads and can be moved between a company server and multiple instances in the cloud easily. I think this says it all! With such a building block, life is so much easier. But does IBM i support containers? Not in the shape and size you’d expect. Don’t expect Docker to run natively on IBM i (at least not at the time of this article). And yes, you can do some magic with chroot, but that’s not my point. I would rather challenge the common expectation of the IBM i architecture.
The team in Rochester was way ahead when they made the first blueprints of IBM i back in the 1980s. That team came up with an approach to create a container for objects—being programs, databases, security objects, etc. This container can be converted to an image that can be transported from a development environment to a test environment, to another system or in the cloud. One big difference between this and the containers we know today is the name; on IBM i they’re called libraries, and a container image is called a save file.
IBM i comes with a rock-solid implementation of Db2. When you create a database schema in Db2 it will become a container (also known as a library). Deployment and security follow the same rules as for other libraries, making it easy for anyone working with the IBM i library paradigm. Create an image, move it to the cloud, and you’re done. No need for offloading data and reloading.
But what about orchestrating the containers? The OS itself is built around the same concept of containers (libraries), so it ships in a container called QSYS. When you look for Kubernetes or OpenShift, instead you’ll have IBM i and a concept of subsystems that spin up processes from your library (your container), and you can even combine functionality by these containers (libraries) with a concept of library lists nicely defined in job descriptions. The job description even gives you the ability to control system resources like processor workloads, user access and other important tuning items. The concepts are the same as writing Docker files with Compose for example, but different.
Java Community Improvements
The most important improvement for the Java community over the last couple years in my opinion is GraalVM. It’s such an obvious solution for integrating other languages, giving them a common VM that supports not only Java, but also Python, Node.js, R and more.
In the past, I’ve used Nashorn, Rhino and Jython that allowed the JVM to run JavaScript and Python within the JVM, but that was Java-centric, so it didn’t gather much attention in the industry and is now all more or less sunset. Now with GraalVM, all languages are integrated and can use components from each other, so the barriers are melting down and you can use whatever languages are best for developing your specific solution. It might come as a big surprise that even this feature was covered for IBM i many years ago.
The Integrated Language Environment (ILE) as the name implies, gives you the possibility to choose the language that fits your needs the best. Even the scripting language CL is an ILE language, so you can interact with programs and pass parameters between your application, script (CL) and the OS commands seamlessly. I would love to see GraalVM on IBM i since Java, Node.js and Python are different animals compared to ILE and do not run from within a library- only ILE does.
Microservices and Open Source
Microservices are on everyone’s mind these days. Microservices are all about separation of concerns typically driven by serverless architectures. When I build Java applications, I prefer to use Spring Boot. For Python, I use Flask or FastAPI. For Node.js, I prefer Seneca.
But what about the ILE environment? Well, that’s where open source comes in. I invest a lot of time and work into a serverless architecture open-source project called ILElastic where you glue a simple HTTP server technology into your application. Also, for ILE microservices using the JSON I/O concept, you’ll be helped a lot with the noxDB project—yet another open-source project just waiting for you to use and even contribute to. These projects reduce development time and let IBM i work seamlessly, even in a huge microservice architecture governed by an API gateway like OpenShift or Kong. These are proven solutions that let even the oldest COBOL and RPG programs play a vital role in a heterogeneous service landscape.
Evolving Systems and Best Practices
The core strategy—separation of concerns—in the microservice architecture isn’t what you’ll first think of when you open a traditional IBM i legacy application. When these legacy systems were designed, it was all about integration. Architects used (whether knowing it or not) functional dependencies when normalizing the database. Basically, everything that had a common key should be normalized into the same table.
But with domain-driven design, this changed dramatically, and best practices became worst practices. The reasons are obvious when you think about humans’ cognitive limitations. In smaller systems, it’s easy to overview the impact and consequences of certain changes in code and databases. However, when systems grow over time, the difficulty increases almost exponentially and even the smallest change requires intense testing. To make things worse, regression tests and unit tests are not on everyone’s mind these days. Does that mean you should decommission legacy systems and replace them with microservices? Absolutely not! The value of legacy systems is enormous. Thousands of hours are put into these legacy systems over decades and are driving businesses around the world today. Legacy systems are real treasures if you move them forward correctly.
Modernization Versus Transformation
You will hear from multiple individuals that you should modernize. I totally disagree. Your weapon is transformation. Perhaps modernization is your first step, but the journey doesn’t stop there. Breaking down a monolith with microservices with shared databases is an antipattern, and with that in mind you can embark on the train for the future to come.
In the process, it’s also worth the time spent to also segregate your database into domains. Domain segregation is separation of concerns. You split your legacy database into separate containers (libraries) where no (or as few as possible) dependencies exist to other domains. This is the way to go and before you know it you will have implemented real microservices in your applications where human cognitive limitations are no longer an issue. Microservices are not a silver bullet and come with a price. All of your containers (libraries) together become a heterogeneous services landscape and orchestration of these is a challenge of its own.
With this article, I hope you now have another impression of IBM i. The platform isn’t dated, as some individuals in the IT industry might want you to think. I am not an IBMer. I dare to say there’s technology beyond what IBM can provide, especially in the open-source arena, that will make your life easier. However, I’m also a huge fan of IBM i and what it can do for your business. I think it’s amazing that IBM made a blueprint that can drive the development of the most advanced architecture you will find on the planet today.