Or why it’s really okay to not know what this whole Container thing is about
We at MSB are huge Kubernetes fans. We believe it will continue to provide a strong foundation to modern software deployments and we’re excited to see what each new release brings.
The unprecedented pace of Kubernetes releases, each bringing new features and quality of life upgrades, means there’s a lot to keep pace with. Just having a look at the release notes of the latest version shows the scope of progress being made.
Kubernetes is already dead?
Even with the fast pace of evolution, and majority of companies still being somewhere on the long tail of adoption and struggling to keep up, there are predictions that building for Kubernetes is already building into a legacy system looking few years in the future.
Simon Wardley talks about serverless being the natural progression of the evolution of our software architecture, with projects like knative already building serverless abstractions on top of Kubernetes.
It’s not about the technology
Even though the tech may be on the way, or already here, utilising it and the benefits it brings requires first and foremost a change in the people building these systems.
A modern (micro-)service architecture requires properly managing:
distributed transaction management
distributed tracing and logging
clear API and interface agreements
DB schema versioning and migrations
software delivery pipelines
to name a few, and the most difficult thing of all - coordinating a large amount of people to agree on something and recognise the benefits of the increased workload (at least initially). Each one of these points is a whole field onto itself, with no “right” way to do it.
Our on the ground experience
Even though it’s exciting to talk about the tech and the possibilities it offers and read tech blogs, our on the ground experiences, and the many conversations we have, show a different reality.
Migrations start full of excitement, extracting from the “legacy” monolith several stateless services, and grinding to a halt when coming to the large “happy-path state machine” at the heart of every company - the code that checks ten different things, notifies several other components, ensures consistency, and provides a successful customer experience.
When working with companies, we often have to encourage people to not feel bad about not knowing what a container is or their purpose, how things are meant to communicate, and especially acknowledge when they rightfully recognise that this new system we’re proposing is much more complicated.
We’d like to provide some encouragement - in our experience, even the major tech companies, blogging about their shiny Scala microservices, usually have a large monolith at the heart of their tech stack, meetings trying to coordinate various components and developers struggling to understand how things work and how to get things done.
If you’d like to listen to some on the ground stories about Kubernetes adoption patterns, we’d recommend a listen of our podcast episode with Mr. Jamie Duncan from Google.