Building Composable Platforms That Actually Scale

KubeCon North America 2025 gave me the opportunity to revisit a question I've been thinking about for many years: why do some internal platforms become strategic assets while others slowly become collections of tools that nobody really wants to use?

The answer, in my experience, has very little to do with selecting the "right" technology. Instead, it comes down to how platform teams think about ownership, APIs and product design. Technology certainly matters, but successful platforms tend to emerge from good architecture and good organisational boundaries rather than from any particular tool. That was the central theme of my talk on composable platform architectures.

https://www.youtube.com/watch?v=05AxSXIQz6w

Platform engineering is more than a portal

Platform engineering continues to gather momentum, but I still see many organisations equating it with deploying a developer portal. Backstage and similar tools are incredibly valuable, but a portal is only one part of the overall platform. It provides an interface into platform capabilities, not the capabilities themselves.

The mental model I've found most useful breaks a platform into three distinct layers: the application and developer experience layer, the platform orchestration layer, and the infrastructure layer. Each exists to solve different problems for different users, and each should be owned by the team responsible for delivering value at that level. When those boundaries begin to blur, developers end up learning infrastructure tooling they shouldn't need to know, while infrastructure teams find themselves solving application-level problems they were never intended to own.

That idea of every team owning its own flow of value became one of the recurring themes throughout the talk. Looking back at both successful platform initiatives and those that struggled, I realised that many of the problems weren't technical at all. They appeared because responsibility leaked across those architectural layers.

Every team should own its flow of value

Developers should consume platform capabilities rather than assemble infrastructure. Platform teams should compose infrastructure services rather than recreate them, while infrastructure teams should focus on exposing reliable building blocks that others can consume. When each layer can evolve independently, the entire platform becomes easier to understand, maintain, and scale.

This is also where I think the platform engineering conversation has matured. A few years ago, we spent a lot of time discussing tools. Today, the more interesting discussions are about interfaces, ownership and developer experience. Those are the things that determine whether a platform continues to evolve or slowly becomes another operational bottleneck.

Composition is about APIs, not tools

When people hear the word composable, they often think about technologies or frameworks. I think about APIs instead.

A composable platform is built from capabilities that expose clear interfaces, have predictable behaviour, and can evolve independently over time. Whether that capability provisions a PostgreSQL database, creates a Kafka topic or delivers an entire development environment is almost secondary. What matters is that consumers don't need to understand how it works internally, only how to consume it safely and consistently.

Once platform capabilities become reusable building blocks instead of one-off implementations, developers stop reinventing infrastructure while platform teams stop rebuilding the same solutions for every project. The result isn't simply better reuse. It also creates far clearer ownership and makes upgrades significantly easier because every capability has an explicit lifecycle rather than existing as another copied template.

The DevOps tool dump is not a platform

One anti-pattern I highlighted was what I jokingly called the "DevOps Tool Dump". This is where organisations provide developers with Terraform, Helm, Argo CD, Vault, Kubernetes and a wiki full of documentation, then declare that the platform is finished.

That approach often works surprisingly well at first, particularly in small teams full of experienced engineers. As organisations grow, however, every team gradually creates its own flavour of the platform. Standards drift, upgrades become increasingly painful, and operational consistency slowly disappears until maintaining the platform becomes more expensive than building it in the first place.

A better approach is to expose a smaller number of well-designed organisational building blocks that are versioned, discoverable and designed to work together. Developers shouldn't need to understand every implementation detail. They should simply be able to assemble capabilities that solve business problems, leaving the platform team to manage the complexity underneath.

One of my favourite examples of this comes from LEGO. Their engineering teams invested heavily in exposing reusable platform capabilities through APIs and making those capabilities discoverable. Rather than forcing developers to understand every implementation detail, they built an experience where teams could find and consume the services they needed while the platform team retained ownership of how those services were implemented.

Governance belongs in the platform

Another anti-pattern I discussed was relying on documentation and manual review processes to enforce governance. Most organisations start here because it feels safe, particularly in highly regulated industries. The problem is that documentation doesn't scale, and neither do people.

As platforms grow, manual approvals inevitably become bottlenecks. Policies become inconsistent, exceptions accumulate, and platform teams spend more time reviewing requests than improving the platform itself.

A much more sustainable model is to encode governance directly into the platform using technologies such as Open Policy Agent, Kyverno and automated security scanning. Compliance then becomes part of the delivery workflow rather than something layered on afterwards. Developers move faster because the platform guides them towards compliant behaviour by default, while security teams gain stronger guarantees without becoming gatekeepers.

The biggest lesson I learned here wasn't technical. It was organisational. Bring security teams into the conversation early. When platform engineers and security engineers build these capabilities together, everyone benefits.

Platform as a Product remains the biggest mindset shift

If there was one idea I wanted people to leave with, it was this: treat your platform like a product.

Products have customers, owners, roadmaps and lifecycle management. They evolve continuously rather than being delivered once and forgotten. Internal platforms deserve exactly the same treatment.

I've seen too many organisations distribute Terraform modules or Helm charts and assume the job is finished. In reality, that's only day one. Day two introduces upgrades, security fixes, operational drift and changing customer requirements. Without clear ownership and lifecycle management, those templates quickly become liabilities.

Thinking about platforms as products naturally leads teams towards better APIs, better documentation, clearer ownership and far healthier operational practices. It also encourages platform teams to spend more time talking to their customers instead of simply shipping more tooling.

Measuring platform success

It's easy to become obsessed with technical metrics, but I suggested evaluating platforms across four broader outcomes instead: speed, safety, efficiency and scalability.

Those dimensions help frame much more meaningful conversations. Speed isn't just deployment time. It's how quickly developers can safely deliver value. Safety isn't about restricting change but enabling change with confidence. Efficiency measures how easily capabilities can be upgraded and operated over time, while scalability applies just as much to the organisation as it does to the technology.

I've found that those four themes provide a useful way to evaluate whether a platform is genuinely improving the developer experience or simply becoming more sophisticated from an engineering perspective.

Final thoughts

Looking back, I don't think composability is really the destination. It's a design principle that enables better platforms.

The organisations succeeding with platform engineering aren't necessarily using radically different technologies. They're exposing capabilities rather than tools, encoding governance into the platform rather than in documents, and creating APIs that allow different teams to own their own flow of value without stepping on each other's toes.

Perhaps the biggest takeaway, though, is that platform engineering is still fundamentally about people. Building composable systems is important, but building platforms that developers genuinely want to use is what ultimately determines whether an internal platform succeeds. Treating the platform as a product remains one of the most effective ways I've seen organisations make that transition.