top of page
Search

Beyond Operations: Scaling Platform Engineering in the CNCF Community

The platform engineering movement is coming of age, and Abby Bangser’s KubeCon NA 2025 keynote in Atlanta made the case that it needs to grow up fast.


Her framing was simple: every major shift in software delivery raises the bar. Cloud sped up provisioning. DevOps reshaped ways of working. Kubernetes changed architecture. Now, AI is changing what internal platforms must enable, and it is happening at a pace most organisations are not structurally ready for. 


The goal of the talk was to share the playbook for platform engineering that can support AI adoption without repeating the same painful cycles that have defined platforms for the last decade.


TL;DR

  • Abby argued that platforms exist to reduce scope and complexity for application teams, not to remove autonomy. They create focus by taking dependency management off developers’ plates.

  • She described three common “platform patterns” that organisations settle into (ticket queues, “infrastructure for everyone,” and templates), and why each eventually creates new pain.

  • Her proposed direction: start with an API for self-service, keep the platform continuously aligned to business rules, and run it as a managed service with fleet-style upgrades.

  • The scaling unlock comes from servicing a second persona: not just platform consumers, but platform producers, so specialists across the organisation can safely contribute capabilities without creating chaos.


Read on for a more in-depth look at these topics.


The opening premise: every wave of change asks more of platforms

Abby walked through the last two decades of software delivery as a series of step changes: Cloud, DevOps, Kubernetes, and now AI. Her point was not that AI is “another tool.” It is another shift in what the organisation expects to ship, how quickly it expects to ship it, and what internal platforms must make possible.


She kept coming back to first principles: we build platforms to reduce complexity and narrow the scope of what application teams need to hold in their heads. Done well, that does not remove ownership. It gives teams focus, just as the cloud removes concerns like physical security and cooling without shifting responsibility for outcomes.


The platform reality: speed, safety, efficiency, and a lot of whack-a-mole

Abby described platform evolution in most companies as a pendulum swing: fix safety, then speed suffers; fix speed, then cost or compliance suffers; then migrate again. Each iteration improves something, but it is also reactive, expensive, and disruptive.


From that cycle, she said, three patterns recur.


1) The ticket queue: Safe but slow

This is the familiar world where you request what you need via tickets. It buys safety through control, but trades away agility and creates friction that often pushes teams into workarounds anyway.


2) The “Oprah” approach: Infrastructure for everyone

You get a cluster, you get a namespace, everyone gets access to a wide-scoped playground. It feels fast at first, but the long-term tax is huge. With autonomy comes responsibility, and now every team is maintaining patching, upgrades, and security across the organisation.




3) Templates, and the “puppy for Christmas” problem

Templates seem to offer the best of both worlds: standardisation plus speed. But Abby argued that templates often become leaky interfaces. They expose platform tooling and platform languages (HCL, YAML templating, etc.) to people who just want to ship software.


A template that gets copied everywhere is like giving out puppies at Christmas. It feels great on day one, but soon you have an unsupervised litter across the business. Every CVE, every new feature, every change becomes a game of chasing instances and hoping nothing has been forked beyond recognition.


Abby’s warning was not “never use templates.” It was that templates alone do not give platform teams fleet-level control, and AI-era delivery will punish anything that cannot be managed as a fleet.


The playbook: three principles are non-negotiable



Abby proposed three principles that must shape how we build internal platforms now, especially as AI accelerates delivery expectations.


Start with an API for self-service

Her first principle was to begin with an API that codifies expectations and meets users where they are. That could surface through a Slack bot, an IDE workflow, or agentic AI, but first focus on the contract.


Keep the platform relevant to the business over the full lifecycle

She emphasised that platforms cannot be “set and forget.” Compliance, rules, and guardrails must remain relevant over time, not just on day one and the platform must enable this full lifecycle support.


Run it like a managed service

The people who understand a capability should own upgrades, patches, and maintenance. Abby positioned fleet management as the mechanism that turns platform expertise into organisational scale.


Note: Abby was explicit that this is not a call to rebuild what the market already provides. It is about filling the gap between what you can buy and what your teams need to be effective.


Scaling the model: the “app store” analogy and the missing persona

The second half of the keynote moved from principles to applying them into an operating model.


Abby argued that many organisations are still structurally centralised: a small group takes tickets and tries to keep up. That might work at a certain scale, but it does not create the “enterprise app store” dynamic that platform leaders have been pointing toward for years.


She compared today’s platform organisations to phones before the app store, when every manufacturer had to build everything themselves, which stifled innovation. App stores changed that by creating a marketplace with rules: consumers self-served what they needed, and producers owned upgrades across fleets of devices.


Her key move was introducing a second persona in internal platforms: not just consumers (developers requesting capabilities), but producers (specialists across the business who can create and evolve capabilities safely). Those producers might be security, data, or finance specialists, or infrastructure experts, and many will not be software engineers. Platforms need to support them, too.


Closing thoughts

Abby closed by pushing for experimentation over doctrine: define an experiment, run it, measure it, and treat “success” as a more effective organisation and a happier development team. 


She also pointed to the CNCF community as the place to keep learning year-round, not just during the KubeCon conference week.


→ Read more on platform as a product: https://www.syntasso.io/platform-as-a-product 

Comments

bottom of page