Things in monospace

KubeCon 2025: Recap

Authored on 2025-04-22

A couple of weeks ago I got a very unexpected chance to attend KubeCon EU in London. But first! Let me point out the irony of hosting KubeCon EU in London. Now that we got that out of the way we can proceed.

tl;dr YouTube playlist

KubeCon? More like kubAIcon!

Gosh am I funny or what? No? Well Deepseek thinks otherwise and I'm sure that's what matters in the long run. I suppose the rest of the community shares my sense of humour or rather, lack of it seeing as almost half (1/2, 50%, 0.5) of all presentations were in one way or another about AI.

Whether it's running AI workloads or training models it didn't matter. I have successfully avoided all but the keynote presentations on AI and if those are any indicator of the quality then oooooh boy.

One would think that I'm an AI sceptic which fair. I honestly think that the uses of AI are limited by lack of integration with any of the existing tools. Yes, I'm aware of MCP, but the integrations are lacking and the results are so far... not impressive.

Developers, developers, developers, developers!

Cognitive dissonance that I felt during KubeCon was strong. On one hand I saw people trying to abstract away the software engineers from the platform their applications are running on and concurrently I've observed a distinct and equally sized group of people arguing that we should bring developers closer to the platform and remove unnecessary abstractions.

Just to illustrate, there's a lot of buzz around projects like Dapr, CNOE and the likes. For someone like me who occasionally writes SQL window queries the idea of abstracting it away access to your database is at best questionable and at worst an absolute maintainability nightmare. I guess we as an industry are doomed to learn every 10 years that building an enterprise bus over HTTP/gRPC is a terrible idea and abstracting inevitably leads to unplanned plumbing work.

If it's not clear to the reader what stance I take on trying to "abstract away the nitty-gritty details" -- it is not a positive one.

At the same time I feel the approach taken by Spotify (explained in a series of articles) is much closer to what we (the developers-turn-platform-engineers) should offer. The focus on developer's perception of their happiness pays off. Offering abstractions not authored by developers does not.

In my view, adding abstractions does not solve the underlying issue of cognitive overload for developers, it just shifts the focus towards different and not necessarily better abstractions. Eliminating obstacles should be the standard mode of operation for platform teams.

Policy as Code

On the topic of eliminating obstacles -- I believe that having strong policies around workloads on Kubernetes is one way to ensure developers don't waste time. Setting and enforcing clear rules around what your applications can help with getting application into production state faster.

We've been using Kyverno at $WORK since before I joined hence I was curious if there are any new developments. As it turns out, there are! It kinda flew under my radar, but Kubernetes now ships with policy support for both validating as well as modifying workload definitions. Looking at the way we (ab)use Kyverno, a vast majority of our policies can be updated to use the built-in ones.

Another thing that I would describe as a positive development is the agreement between large policy engines (Kyverno, Gatekeeper.sh) have agreed on the common query language, the aptly named Common Expression Language.

Buildpacks

One of the few projects that really caught my interest was buildpacks. In my experience having to support a zoo of Dockerfiles across hundreds of repositories is... not fun. Having centralized buildpack definitions would lower the cognitive load for developers who simply don't have the time or desire to maintain their Dockerfiles.

The rebase is the absolute killer feature though. No more busted cache across thousands of builds because the base image had a patch for a CVE that has zero practical exploitation path. Add better caching on top and I'm in love.

Of course, I would not want to take away Dockerfile from developers who want to use them. Fortunately it seems I would not have to! Sweet all around.

Notable mentions

Instead of conclusion

I don't think you should go to KubeCon. Too many shovel peddlers, too little gold.