Kubecon, held at Amsterdam’s RAI conference centre this year, was bigger than in 2022. Nothing untoward there you might say, but I mean Bigger. Double the attendees. By my visual estimates, the expo area was three times the size. It felt like the conference was growing up, a point I will come back to. But meanwhile, I thank organisers for maintaining a smaller-stand format, which kept the step count under control.
Over the three days I met dozens of companies, large and small, and most had a similar icebreaker — “What are you seeing this year?” Questions like this are the mainstay of being an analyst, like you’re able to maintain a complete and comprehensive overview of everything that’s going on in a complex and dynamic field, then map it onto a randomly placed set of brightly coloured stands and people movements, and pop out some pithy conclusion.
Spoiler alert: I can’t, because nobody could, and besides, the artist currently known as cloud native is still on a journey. Nonetheless I used the frequent positing of the same question to test some ideas and build a picture. Call it crowdsourcing if you like, though I am more minded to quote Arthur Conan Doyle, “When you have eliminated the impossible, whatever remains, however improbable, must be the truth.”
So, what did I see this year? I would use the following keywords: touchpoints, coalescence, platforms. Two are vague, yet specific; and one is specific, yet (it turns out) vague. I will start with touchpoints as this was the first, shimmering image that reflected the themes of the conference. But first, some more about the nature of the conference itself.
Imagine large halls full of (often younger, generally male) attendees, watching one or two people standing on a stage in front of multiple, superbright, wall to wall screens. In and out of the halls move these folks, shuffling between the keynote rooms and smaller sessions. At one end of the RAI, the curved, glass-ceilinged greenhouse of its expo hall was the closest thing to natural light anybody will experience for four days.
Within the hall, stands stretch. At one end, booked-out massage chairs and a rather forlorn creative corner. To the side, dining spaces mapped out by round tables and longer benches, any risk of the austere broken up by clusters of beanbags, green plastic plants and a large tree-like structure topped with a pink lampshade. Everywhere, people are walking, talking, clustered around screens, eating, drinking coffee, taking the occasional nap.
And what about said stands? Apart from a few, likely expensive exceptions these were mostly square, each no more than a blank wall and a standing desk for a sponsoring company to customise. Nonetheless each was different if familiar, not least as cloud native has its own colour palette, purple and dark green, black and red, ironically clashing against the more pastel-like themes of the conference itself.
Backdrops boldly state purpose — solving challenges of container security, or automated deployment, or visibility on performance. Together, these make a picture, of solutions to an emerging set of problems, caused by an agreed alignment towards massively distributed, cloud-based, microservices architectures with Kubernetes as the common orchestration tool and control plane.
There’s the rub. Whilst some very large applications have been built, deployed, used in this way, for many, the main challenge is one of solving for what is still a work in progress. Single solution providers offer multiple, overlapping approaches to solve the similar problem — API management versus service mesh, for example. Should you build an application using an all-encompassing environment, or piece together multiple tools to deliver something more custom?
As per one discussion, which happened to take place over a table covered in lego bricks, this is less about that old decision point between all-in-one solutions vs best of breed; rather, this is more like the legos, where all options are possible . We’re working at the component level rather than the application level, with all potential configurations catered for: customisation is no longer a differentiator, and more a cause of potential discomfort.
But, touchpoints. Just as each vendor (and, to one side, each CNCF project) does its own thing, so it develops, matures. Individual solutions are growing, covering more space, solving the higher-order challenges that come with scale. Just as a city might form around a river, with shops appearing at corners of roads, with common paths being discovered, so are providers part of a bigger, growing system that is maturing as a whole.
This was reflected in the interfaces between deployment and management tools, or the extensions to OpenTelemetry to cover logs (it won’t stop there) as part of its broader adoption, or the integration of data management within monitoring solutions. Increasingly, such extensions have come from customer demand as vendors find how their unique solution needs to respond to scenarios outside the lab, or as they hit their own glass ceilings of adoption.
Just as touchpoints stem from multiple ways to achieve the same goal, so there was a palpable feeling of coalescence, of the coming together of solution sets, or packages that built on top of others. Don’t want to have to configure everything on AWS yourself, all those namespaces and security policies? How about you use our management overlay, it’ll take care of all of that. Looking for a way to replicate cloud functionality on-prem? We have you covered.
By building in, building on top of, replicating functionality for different deployment types, we’re seeing the formation of what could (loosely, at this stage) be called a common architecture. Some pieces were already in place, like the aforementioned service mesh, or the newly CNCF-graduated capabilities for GitOps. The bigger theme, however, is that both organisations and vendors have something to build to, which will inevitably result in an acceleration of progress.
An inevitable, yet flawed conclusion is that everything else ends up as one platform. Platform engineering was the topic of several conversations but, don’t be fooled into thinking this means all the stands are going to pack up and we’ll be left with a handful of big providers. Some companies may choose to back a single horse — indeed, smaller companies may have no choice. But we’ve already seen the cost management issues caused by putting all eggs into a single hypervisor’s basket.
Meanwhile, the very nature of technological change means that a single, simple, all-things-for-all-people platform will always be challenging. Such things exist, and serve a clear purpose, but there’s a trade-off between using a standardised software infrastructure that does most things pretty well, or making use of more innovative features from smaller providers. Indeed, this dilemma is directly reflected as one axis of our radar reports.
Another counterpoint is the association between Kubernetes-plus-containers and the emerging popularity of WebAssembly, that re-imagining of Java virtual machines and byte code approaches for the microservices world. Both will exist, and both have their strengths; and, frankly, both are on a journey towards maturity. Who knows what is round the corner, but the chances are it will build in some core ML capability, across build, deploy and operate.
Rather, the skill will lies in what we might call multi-platform engineering (can I say MPE?). Platform engineering already exists in many organisations, as the group putting together frameworks upon which others can build their applications. I would extend the role of this group to cover understanding all options, past, present, and future, to deliver a coherent set of managed services so others could benefit.
That is, the job isn’t just to understand and deliver a platform, but to enable applications to work across multiple clouds, multiple stacks, multiple CI/CD toolchains, operations and security capabilities. Whether or not that sounds like a big ask, that’s still the job. And yes, it can encompass decisions across on-premise systems and legacy applications, all of which make up the overall estate.
The MPE group may find that a single provider, or a small number of them, can meet the majority of needs. In which case, hurrah for that — but don’t get complacent. A strong risk stems from the old adage, “When all you have is a hammer…” — whilst the primary goal is to deliver stability within a world of constant change, the group needs to ensure its recommendations remain fresh and appropriate.
Equally, whilst the resulting end-to-end environment may be well-defined, the MPE group needs to acknowledge its role as empowering and enabling first. Based on experience, the danger of such a group is that, over time, it might become inwardly facing, focused on its own goals rather than those of the people it serves. As one panel speaker said, it is up to the MPE group to act as a product group, at the behest of its users— not just developers, but the business as a whole. I’m not particularly proud to have coined the term silo-isation, but the point stands.
As a final point, a challenge for analysts is the self-fulfilling prophecy of having conversations about your own opinions — I could easily have responded to “What are you seeing this year?” by rambling on (heaven forbid) about the need for better-governed applications, policy-based design, shift-left, business value and so on.
Nonetheless I will proffer that these are all aspects of a more mature approach, one which the cloud-native world is moving towards (see also: SBOMs, FinOps et al). A multi-platform architecture will by consequence build in better manageability, and indeed, many of the touchpoints between tools and platforms talk to this need.
So, to a pithy conclusion, written even as an aeroplane carried me, and my fried brain, away from Amsterdam. Even as one person said, as we stood on the balcony looking over the expo hall, “it’s the Wild West down there,” another looked across the stands, the people, the flyers, socks and other paraphernalia, and remarked on the clear signs of ‘adulting’ across the piece.
The cloud-native world is growing up and filling out, breaking through its youthful vim even as it delivers on its promise. There’s lots of work still to do, and potholes on the road ahead. But by taking a multi-platform engineering perspective, organisations will be putting the building blocks in place for the future.
The post Touchpoints, coalescence and multi-platform engineering — thoughts from Kubecon 2023 appeared first on GigaOm.
Source : Touchpoints, coalescence and multi-platform engineering — thoughts from Kubecon 2023
