Object-Oriented Primitives (in-process primitives)
As a Java developer, I'm well familiar with object-oriented concepts such as class, object, inheritance, encapsulation, polymorphism, etc. In addition to the object-oriented concepts, I'm also well familiar with the Java runtime, what features it provides, how it manages my applications, what would be the life cycle of my object and the application as a whole, etc.
And for over a decade, I've used all the primary tools, primitives, and building blocks as a developer to create applications. In my mental model, I would use classes as components, which would give birth to objects that are managed by the JVM. But that model has started to change recently.
Kubernetes Primitives (distributed primitives)
In the last year, I began to run my Java applications on Kubernetes, and that introduced new concepts and tools for me to use. With Kubernetes, I don't rely only on the object-oriented concepts and the JVM primitives to implement the whole application behavior. I still need to use the object-oriented building blocks to create the components of the application, but I can also use Kubernetes primitives for some of the application behavior.
For example, now I strive to organize the units of application behavior into independent container images, which become the main building blocks. That allows me to use a new richer set of constructs provided by Kubernetes to implement the application behavior. For example, now I don't rely on only an implementation of ExecutorService to run a service periodically, but I can also use Kubernetes CronJob primitive to run my container periodically.
The Kubernetes CronJob will provide similar temporal behavior, but use higher-level constructs, and rely on the scheduler to do dynamic placement, performing health checks, and shutting down the container when the Job is done. All that ends up in a more resilient execution with better resource utilization as a bonus. If I want to perform some application initialization logic, I could use the object constructor, but I could also use init-container in Kubernetes to carry out the initialization at a higher level.
The Distributed Mental Model
Having local in-process primitives in the form of object-oriented concepts and the JVM features, combined with distributed out-of-process primitives provided by Kubernetes give developers a richer set of tools to create better applications. When building a distributed application, my mental model is not any longer limited to a JVM but spreads across a couple of hosts with multiple JVMs running in coordination.
The in-process primitives and the distributed primitives have commonalities, but they are not directly comparable and replaceable. They operate at different abstraction levels; have different preconditions, and guarantees. Some primitives are supposed to be used together, for example, we still have to use classes, to create objects and put them into container images. But some other primitives such as CronJob in Kubernetes can replace the ExecutorService behavior in Java completely. Here are few concepts, which I find commonalities in the JVM and Kubernetes, but don't take that any further.
With time, new primitives give birth to new ways of solving problems, and some of these repetitive solutions become patterns. Check out my in-progress Kubernetes Patterns book for this line of thinking.
About the author: Bilgin Ibryam is a member of Apache Software Foundation, integration architect at Red Hat, a software craftsman and blogger. He is an open source fanatic, passionate about distributed systems, messaging and application integration. He is the author of Camel Design Patterns and Kubernetes Patterns books.
Whether you are new to Kubernetes or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.
Last updated: September 3, 2019