It’s been a long gap, since I blogged. Packt reached out to me, after reading my blog, and offered to convert the content into a more details hands on book.

It's been a super exciting, learning experience writing the book.

Before I explain what is gone into this book, let me introduce GraalVM. Here are some blogs on GraalVM, I had published before.

Episode 1: “The Evolution” — Java JIT Hotspot & C2 compilers (the current episode…scroll down)

Episode 2: “The Holy Grail” — GraalVM

In this blog, I will talk about how GraalVM embraces polyglot, providing interoperability between various…

Function-as-a-Service or Serverless is the most economical way to run code and use the cloud resources to the minimum. Serverless approach, runs the code, when a request is received. The code boots up, executes, handles the requests, and shuts down. Thus, utilizing the cloud resources to the optimum. This provides a highly, available, scalable architecture, at most optimum costs. However, Serverless architecture demands a faster boot, quicker execution and shutdown.

GraalVM native images (ahead of time) is the best runtime. …

CRI-O and podman have been widely adopted by most of the modern container platforms. In this blog, I will explore, why everybody is gaga about this new ecosystem of tools/utilities, and share some of my experience, in this series.

I got a lot of feedback, after I published my blog on Containers & evolution of Containers (you can read it here “Evolution of k8s worker nodes — CRI-O”). One of the common questions asked, is how podman is different from docker & how the new ecosystem of podman+buildah+cri-o+skopio different from what we do with docker…so I wanted to do a…

Thanks a lot @Carlos for a very detailed review. I am really glad to see you go through the book in detail, and hitting on the right points, which even I felt as "AHA" while writing the book. Your blog is a very good summary of my book, and great notes. Thanks once again for spending time, going through the book and also writing this in detail.

In the last Episode (Episode 1: Podman Hands on), we got Podman working on CentOS/VirtualBox. We also pulled tomcat image and got it running. In this episode we will explore the advantages of Buildah and Skopeo and build a complete custom image with our sample web application.

Why Buildah?

Docker provided a very sophisticated configuration file based provisioning with Dockerfile & Docker compose. It provided a simple configuration file, that docker daemon would use to build custom images, configure and provision the container. Docker Daemon has the functionality to build, pull, push, run and manage containers.

So why do we need Buildah…

In Episode 1, we looked at how JVM evolved into an optimum VM, with JIT C1, C2, and HotSpot. In this blog, we will see how Graal replaces the C2 compiler and brings in a larger ecosystem of frameworks to support multiple non-JVM languages…


With large enterprises embracing the CloudFirst approach, more and more we are building/moving critical enterprise applications onto Cloud. To truly realize the value of the cloud, and derive the most optimum TCO, it's important that these applications are built on optimized runtimes.

I had listed a few critical non-functional requirements in Episode 1 (smaller footprint, faster…

In my search for the most optimum container tech, I have been playing around with various combinations of OpenSource and frameworks.

In this blog, I will walk you through what, I think, is one of the most optimum container stack.

Before I dig into the stack, let me spend some time, walking through what are some of the non-functional requirements of a Container & Serverless/FaaS based MicroServices Architecture

IMHO, the following are some of the key requirements

Smaller Footprint: Eventually all of these MicroServices are going to run on the cloud, where we “pay for what we use”…What we need…

I have been playing around with Red Hat OpenShift 4.x for the past few months now… It has been a super exciting learning journey…In this blog, I will attempt to capture the key architectural components of OpenShift 4.x and how they come together, to provide the most comprehensive container platform.

… let's open the hood…

Nuts and Bolts

Built on CoreOS: According to me, this is one of the major architectural changes in OpenShift 4.x. and I think it really changed the way platform works…here is how!!!

CoreOS provides “immutability”!!!…what does that even mean…let me explain…while Red Hat CoreOS is built on RHEL…

Kubernetes Operators has the power to realize the dream of Zero-touch Ops, bringing in AIOps to life…and this is how I believe it will.


As we step into MicroServices architectures, and ways to deploy these on cloud with containers, and all the goodness of DevOps …the application functionality grows..the clusters and the number of resources in the cluster also grows…if the application is not “built-for-manage”, its going to be a nightmare to manage these applications, and we might end up spending more effort in managing these applications, than building them…ironically!!! …

Just a few months back, I never used to call containers as containers…I used to call them docker containers…when I heard that OpenShift is moving to CRI-O, I thought what's the big deal…to understand the “big deal”…I had to understand the evolution of the k8s worker node


If you look at the evolution of the k8s architecture, there has been a significant change and optimization in the way the worker nodes have been running the containers…here are significant stages of the evolution, that I attempted to capture…

Stage 0 : docker is the captain

A B Vijay Kumar

IBM Distinguished Engineer, Master Inventor, Mobile, RPi & Cloud Architect & Programmer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store