Introduction

If you have worked with enterprise software development, I assume you have come across concepts like microservices and containers. Perhaps you have 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 these tools and products aim to solve problems that have been around in the IT industry for ages. It is about separation of concerns. It is about isolation, security and faster time to market. Basically, it is about best practices.

In this article, I will compare how we use the technology 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.

Why containers matter

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 is 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 is not my point in this article. I would rather challenge the common expectation of the IBM i architecture.

IBM i as a pioneer of container concepts

The team in Rochester was way ahead when they made the first blueprints of IBM i back in the 1980s. What that team came up with was 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 are 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, AKA 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 are done. No need for offloading data and reloading.

Orchestration the IBM i Way

But what about orchestrating the containers? The operating system itself is built around the same concept of containers (AKA libraries), so it ships in a container called QSYS. When you look for Kubernetes or OpenShift, instead you will 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.

GraalVM and Integrated Languages

The most important improvement for the Java community over the last couple years in my opinion is GraalVM. It is 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 have used Nashorn, Rhino and Jython that allowed the JVM to run JavaScript and Python within the JVM, but that was on-premises, so it did not 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 ILE, Integrated Language Environment 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 IBM i

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, here is open source my friend. 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 will 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.

The Legacy System Dilemma

The core strategy - separation of concerns - in the microservice architecture is not what you will 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) 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 human’s cognitive limitations.

"Legacy systems are real treasures if you move them forward correctly."

In smaller systems, it is 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 that 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.

Transformation, Not Just Modernization

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 does not 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 is 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 your containers (libraries) together in fact become a heterogeneous services landscape and orchestration of these is a challenge of its own.

"The platform is not as dusty as some individuals in the IT industry might want you to think."

Conclusion: IBM i’s Future Potential

With this article, I hope you now have another impression of IBM i. The platform is not as dusty as some individuals in the IT industry might want you to think. I am not an IBMer. I dare to say there is technology beyond what IBM can provide, especially in the open source arena, that will make your life easier. However, I am also a huge fan of IBM i and what it can do for your business. I think it is amazing that IBM made a blueprint that can drive the development of the most advanced architecture you will find on the planet today.

References

Microservices 
OpenShift 
Kubernetes 
Spring-Boot 
Git 
CI/CD 
DevOps 
Separation of concerns 
Best practices 
Chroot 
IBM i 
Db2 
IBM i subsystems 
Nashorn 
Java Rhino 
Jython 
ILE 
Serverless architectures 
Python 
Flask 
FastAPI 
Node.js 
Seneca 
R 
ILEastic 
noxDb 
Kong 
Functional dependencies 
Domain driven design 
Monolith 
Microservices with shared databases 
Antipattern 
Domain segregation 

Frequently Asked Questions & Takeaways

• Why are containers such a big deal in modern IT?
  • Containers make workloads portable, isolated, and easy to run across environments. They simplify deployment by packaging everything an application needs into a single image. This means faster delivery, easier scaling, and less friction between development and production.
• Does IBM i really have something like containers?
  • Yes - IBM i introduced the concept decades ago through libraries and save files. These act as containers for programs, data, and security objects that can be moved across environments. It shows IBM i anticipated today’s container practices long before Docker and Kubernetes.
• How does IBM i handle orchestration compared to Kubernetes?
  • IBM i uses subsystems and library lists instead of Kubernetes pods and manifests. These allow processes to be spun up, resources tuned, and functions combined within the operating system itself. It’s a different implementation of the same orchestration principles developers use today.
• What makes GraalVM important, and how does IBM i compare?
  • GraalVM enables multiple languages like Java, Python, and Node.js to run together on a shared VM. IBM i’s ILE environment already provided a similar approach, letting developers mix and match languages seamlessly. Both highlight the power of polyglot development for flexibility and efficiency.
• Should legacy IBM i applications be replaced with microservices?
  • No - legacy systems hold enormous value and should be transformed, not discarded. Breaking them into microservices without strategy can create new problems. The smarter path is domain segregation and gradual transformation, preserving past investments while gaining modern agility.
• Is IBM i still relevant in the age of cloud and open source?
  • Absolutely - its core architecture solves many of the same challenges cloud-native tools are designed for. Combined with modern open source projects, IBM i can integrate into microservice landscapes and API-driven systems. The platform remains a future-ready foundation for enterprise IT.