I’m not going to lie. As I was sitting on a plane taking off from Valencia, I admit that I was taken aback by the size of this year’s Kubecon Europe. In my defense, I’m not alone, the number of attendees seemed to surprise conference organizers and exhibitors alike, as evidenced by the apparent lack of water, (I was told) T-shirts and (in various places) taxis a little.
The keynote speech was packed, and the lively discussion of the attendees seemed to be divided into two camps: the young and cool, the mature, and the plainly dressed.
I spent most of my time at KubeCon Europe in one-on-one meetings, analyst/press conferences, and walking the stands, so I couldn’t Review Engineering Conference. However, throughout this article, Kubernetes is now really focused on the how, not the if. For some reason, companies decided they wanted the benefits of building and deploying distributed, container-based applications.
Oddly enough, instead of being seen as some magic sword that can kill the dragons of legacy systems and open the way for digital transformation, Kool Aid is like Water is absent. Ultimately, enterprises have accepted that the Kubernetes model is as good as anything currently available, from an architectural perspective and from an application perspective in general, as a non-proprietary, well-supported open standard they can support.
Virtualization-based options and platform stacks are too heavy; serverless architectures are better for specific use cases. So, if you want to build an application and you want it to be future-safe, the Kubernetes goals are your goal.
The adoption of Kubernetes may be a foregone conclusion, but how it is certainly not. The challenge is not Kubernetes itself, but the need to bypass it to make the resulting application enterprise-ready.
For example, they need a compliant operating environment; data needs to be managed, protected, and served in a less state-conscious environment; external and legacy systems need integration tools ; Development pipelines need to be in place, robust, and value-focused; IT operations need to have a clear understanding of what’s running, the bill of materials, and the health of individual clusters; and disaster recovery is a must.
Kubernetes does none of these things, opening the door for solution vendors and (often CNCF-backed) open source ecosystem projects. I can dig into service meshes, GitOps, orchestration, observability, and backup in these areas, but the broader point is that they are all evolving and merging around requirements. As capabilities increase, barriers to adoption decrease and the number of potential use cases increases.
All this puts the industry at an interesting time. Not that the tools aren’t ready: organizations have successfully deployed Kubernetes-based applications. However, in many cases they do more work than they need, developers need internal knowledge of the target environment, need to integrate interfaces instead of using third-party APIs, and must customize higher-order management tools (e.g. AIOps ) – a specification for deploying rather than acknowledging Kubernetes operations.
Solutions do exist, but they tend to come from relatively new vendors who are functional rather than platform players, meaning end-user organizations They must choose their partners wisely and then build and maintain the development and management platform themselves, rather than using pre-integrated tools from a single vendor.
None of this is a problem in itself, but it does impose an overhead on the adopter, even if they gain early 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 tool: As one travel company once told me, “We want to be the best travel site in the world, not the best platform in the world Engineer.”
So, Kubernetes may be inevitable, but again, it will be simpler, enabling organizations to apply the architecture to a wider and wider range of scene. For organizations that have not yet taken a step towards Kubernetes, now may still be a good time to run a proof of concept, although in some ways the sip has sailed that may focus the PoC on what it means to work practices and structure, while Not sure if these concepts are fully valid.
In the meantime, and perhaps most importantly, now is a good time for organizations to find the best scenarios for Kubernetes out-of-the-box”, working with vendors and Review architectural patterns to provide proven results for specific, high-value requirements, likely segmented by industry and domain (I could dig into this, but did I mention I’m sitting on a plane) ? 😉 ).
KubeCon Europe wrap-up – Kubernetes may be done, but that doesn’t mean it should be mass-adopted until some peripheral details are ironed out.
