I am not going to lie. As I sit on a plane leaving Valencia, I must confess that I have been impressed by the scale of Kubecon Europe this year. In my defense, I was not alone, the volume of attendees seemed to take conference organizers and exhibitors by surprise, illustrated by the conspicuous lack of water, (I was told) T-shirts, and (at several points) taxis.
The keynotes were packed to capacity and there was genuine enthusiasm from the participants who seemed to be divided into two camps: the young and cool, and the more mature and soberly dressed.
I spent much of my time at KubeCon Europe in one-on-one meetings, press/analyst conferences, and hanging out in the stands, so I can’t comment on the engineering sessions. However, throughout the piece, there was a genuine sense that Kubernetes is now about the how, rather than the if. For one reason or another, companies have decided that they want to reap the benefits of building and deploying distributed, container-based applications.
Oddly enough, this didn’t look like a magic sword that can slay the dragons of legacy systems and pave the way for digital transformation: kool-aid was as absent as water. Ultimately, enterprises have accepted that, architecturally and for applications in general, the Kubernetes model is as good as any available right now, as a well-supported, non-proprietary open standard that they can support.
Virtualization-based options and platform stacks are too heavy; Serverless architectures are more applicable to specific use cases. So if you want to build an application and you want to make it future-proof, the goal of Kubernetes is the goal.
Whether adopting Kubernetes may be a done deal, but how to adopt it certainly isn’t. The challenge is not with Kubernetes itself, but with everything that must surround it to make the resulting applications enterprise-ready.
For example, they need to operate in compliance environments; data needs to be managed, protected, and served in an environment that doesn’t care too much about state; integration tools with legacy and external systems are required; lines of development must be in place, robust, and value-focused; IT operations need a clear view of what is running, while a bill of materials and the status of individual clusters; and disaster recovery is a must.
Kubernetes doesn’t do these things, opening the door to an ecosystem of solution providers and open source projects (often backed by CNCF). I could go deeper into these areas Service Mesh, GitOps, orchestration, observability, and backup, but the broader point is that they’re all evolving and merging around necessity. As they increase in capacity, they reduce the barriers to adoption and the number of possible use cases grows.
All of which puts the industry at an interesting juncture. It’s not that the tools aren’t ready—organizations are already successfully deploying Kubernetes-based applications. In many cases, however, they are doing more work than they need to. Developers need insider knowledge of target environments, interfaces need to be built in rather than using third-party APIs, higher-order management tools (such as AIOps) need to be customized. implemented instead of recognizing the rules of Kubernetes operations.
The solutions do exist, but they tend to come from relatively new vendors who are feature players rather than platform players, meaning end-user organizations have to choose their partners wisely, then build and maintain development and management platforms instead. to use pre-integrated solutions. tools from a single supplier.
None of this is a problem in and of itself, but it does create overhead for adopters, even if they gain earlier benefits from adopting the Kubernetes model. The value of first mover advantage must be weighed against the value of investing time and effort in the current state of the tools: as a travel company once told me, “we want to be the best travel site in the world, not the best platform engineers in the world. .”
So Kubernetes may be unavoidable, but it will still get simpler, allowing organizations to apply the architecture to an ever-expanding set of scenarios. For organizations that have not yet made the move to Kubernetes, now may be a good time to run a proof of concept, although in some ways, that sip has navigated and perhaps focused the PoC on what it means for practices and structures. rather than determining whether the concepts work at all.
In the meantime, and perhaps most importantly, now is a great time for organizations to look at which Kubernetes scenarios work best “out of the box,” working with vendors and reviewing architectural patterns to deliver proven results against specific high-value needs. be by industry and by domain (I could dig into this, but did I mention I’m sitting on a plane? 😉).
KubeCon Europe Recap: Kubernetes may be a done deal, but that doesn’t mean it should be adopted in bulk before some of the peripheral details are ironed out.