The first day of KubeCon + CloudNativeCon Europe 2025 at ExCeL London, Tuesday 1 April, was the co-located day. In my KubeCon Europe 2025 hub post I only had video blurbs from that week. Going back through the photos I took from the audience, the Platform Engineering Day sessions turned out to be the most useful thing I had not written up. This post covers the morning quiz and one talk in detail: the abstraction debt trap.
The room and the quiz
Platform Engineering Day Europe had its own hall at the venue, with its logo on the screen between sessions.
The Platform Engineering Day Europe screen at ExCeL London, 1 April 2025.
One session was staged as a quiz in the style of a parody news site called FuzzBeed. The slides were mock web pages, and the audience was asked to pick an answer. My photos show two of the questions. The first one reads: a developer comes to you in a panic because your infrastructure-as-code automation broke production. The options were to stay calm and go into incident response mode “like the platform hero you are”, to say “Huh. Weird. Worked on my machine.” and slowly back away, or to insist the outage is a feature that enforces resilience (“Chaos engineering, baby!”). The second question was about a junior engineer who suggests an idea that could improve your platform. One answer was to encourage them and give them space to experiment. Another was to pull up a deck titled “Why You’re Wrong: A Deep Dive”.
A quiz slide: three ways to react when your infrastructure-as-code automation breaks production.
It was a light break, but the questions were about the real job: incident behaviour and how a platform team treats ideas from outside the team.
Platform abstractions: asset or liability?
The talk I photographed in most detail was “Platform Abstractions an Asset or Liability? Let’s Understand the Abstraction Debt Trap” by Atulpriya Sharma of InfraCloud Technologies, listed on the co-located events schedule for 13:30 to 13:55 BST. The speaker slide describes him as a Senior Developer Advocate at InfraCloud Technologies, a CNCF Ambassador and Co-Chair of the Platforms Working Group.
The opening slide: “Platform Abstractions: Asset or Liability?”
The speaker slide.
The schedule abstract frames the problem well. Platform teams give developers abstractions to hide the complexity of Kubernetes manifests and CI/CD pipelines. The more a team abstracts, the more rigid the platform can become. When a team needs something the abstraction does not offer, it works around the platform, and yesterday’s simplification becomes today’s bottleneck. The abstract calls this the “Abstraction Debt Trap” and introduces “Abstraction Elasticity” as the way out.
The dilemma
The talk made this concrete with a database example. The slide called “The Abstraction Dilemma” walks through four steps: the platform team builds a database provisioning abstraction for standard use, the abstraction works for ten application teams, a mobile payments team asks for specific PostgreSQL extensions, and the platform team has to decide how to handle the request.
The Abstraction Dilemma: one new request tests the abstraction that worked for ten teams.
The next slide shows the two responses side by side. The one marked wrong adds more configuration parameters to the core abstraction for each new extension request, which creates an increasingly complex interface that everyone has to understand. The one marked right creates multiple interface options: a simple one for basic needs and more advanced interfaces for specialised requirements.
Two answers to the PostgreSQL extension request.
Tiers with escape hatches
The follow-up slide shows what the second answer looks like as an API. The “Level 3: Advanced Database Abstraction” example includes all the Level 1 and Level 2 options plus escape hatches. It lists the extensions pg_stat_statements, pg_repack and pgcrypto, a backup schedule with a retention period, and, highlighted in yellow, direct PostgreSQL parameter settings such as shared buffers and maximum connections.
Level 3: everything from the simpler levels plus direct parameters as an escape hatch.
My reading of the slide: most teams stay on the simple level, and the few that need more can drop down a level without leaving the platform. That is better than a single interface that grows a new field for every special case.
Policy-based guardrails
Flexibility needs limits, and the closing slide is about those. “Policy-based Guardrails” lists five ideas around a padlock: exception mechanisms, context-aware policies, contextual validation, flexible enforcement and environmental awareness.
Policy-based guardrails: the counterpart to escape hatches.
In Kubernetes terms this is the job of an admission policy engine such as Kyverno, with exceptions that are explicit and reviewable instead of silent workarounds.
What I took from the day
My take, not the speaker’s: platform teams should expect the first awkward request after the abstraction works. Plan for it up front with tiers, escape hatches and policies, and the platform stays a product teams want to use. Two days later I heard the same idea from the other direction. A talk on how LinkedIn runs Kubernetes at scale said to build abstractions instead of handing out raw Kubernetes (that talk is covered here), and a keynote slide said abstractions cannot hide physical limits (covered here).
