What We Got Right with Cloud Foundry

Cloud Foundry is sometimes spoken about as if it belongs to a different era of technology. Kubernetes, internal developer platforms, and platform engineering have all moved the conversation on, and it can be tempting to treat Cloud Foundry as a stepping stone we’ve since outgrown.

That would be a mistake.

Cloud Foundry wasn’t a theory, a proof of concept, or a fashionable idea that briefly caught on. It was a production platform used by hundreds of large enterprises to run real workloads, often in highly-regulated environments, at a global scale. More importantly, it proved something that many organisations still struggle to accept today: platforms, when built and operated well, can dramatically improve speed and safety at the same time.

Before we talk about what didn’t scale and why we eventually built something new at Syntasso, it’s important to be honest about what Cloud Foundry got right.

The Real Problem We Were Solving

When I started building platforms in the late 1990s, most organisations were cleanly split into development and operations teams. Developers wrote code. Operations teams ran it. To get value into production, work had to cross that boundary, and this often occurred multiple times.

Developers would finish a feature and declare that it “worked on their machine.” Operations teams would quite reasonably worry about reliability, security, and stability, and slow things down to protect the wider estate. The result wasn’t bad behaviour on either side; it was a broken system.

No single team owned the flow of value from idea to production. Velocity and safety were treated as opposing forces, and organisations oscillated between moving too fast and breaking things, or moving too slowly and missing opportunities. The tension wasn’t cultural; it was structural.

Cloud Foundry set out to fix that structure.

Flow of Value: Why “You Write It, You Run It” Worked

One of the most important ideas that emerged alongside Cloud Foundry and later became central to DevOps was “you write it, you run it” (popularised in 2006 by Amazon CTO Werner Vogels as “you build it, you run it”). The insight was simple but powerful: if the same team is responsible for building and operating an application, hand-offs disappear, and feedback loops tighten.

Cloud Foundry made this practical at scale. Teams could deploy their own applications to production without waiting for tickets, approvals, or manual intervention. They could quickly see the impact of their changes, learn from failures, and improve continuously.

This wasn’t just about tooling. It was about aligning responsibility with outcomes. The flow of value improved because the system finally allowed teams to own it end-to-end.

One of the most important lessons we learned here is that flow is an organisational property, not a feature you can bolt onto a tool. Cloud Foundry succeeded because it reshaped how work moved through the organisation.

Opinionated Abstractions Reduced Cognitive Load

Another thing Cloud Foundry got decisively right was abstraction.

Developers didn’t need to understand load balancers, networking rules, VM lifecycles, or operating system patching. The platform absorbed that complexity and exposed a simple, consistent interface. You pushed code. The platform handled the rest.

This was intentional. Cloud Foundry was opinionated by design, and that opinionation was often misunderstood. It wasn’t about constraining teams or enforcing a single way of working for ideological reasons. It was about reducing cognitive load.

Every abstraction is a trade-off, but having no abstraction is worse. By standardising the common, non-differentiating parts of application delivery, Cloud Foundry freed teams to focus on what actually mattered: delivering value to users.

Consistency wasn’t a side effect. It was the point.

Platforms as Products Actually Worked

Cloud Foundry also demonstrated that platforms could, and should, be treated as products.

That meant having clear APIs and contracts. It meant prioritising usability, documentation, and feedback loops. And it meant recognising that internal teams were customers, not just recipients of infrastructure.

This shift changed behaviour in profound ways. Backlogs moved away from “infra tasks” and toward user-facing improvements. Platform teams began measuring success by adoption and satisfaction, not just uptime.

Much of what later became known as “platform as a product” was forged in this period. Cloud Foundry showed that treating a platform like a product wasn’t a nice-to-have; it was essential for success at scale.

Reliability and Safety Were Built In, Not Bolted On

A common misconception is that platforms trade flexibility for safety. Cloud Foundry showed the opposite.

Security, compliance, and reliability weren’t external processes layered on top of the platform. They were encoded into it. Guardrails were built into defaults. Workflows made the safe path the easy path.

This mattered enormously in regulated environments. Instead of relying on documentation, training, or manual review boards, organisations could rely on the platform itself to enforce policy consistently.

One of the most important lessons here was that governance must be largely invisible to be effective. When safety is built into the platform, teams move faster because they don’t have to think about it constantly.

Proof at Enterprise Scale

Perhaps the strongest validation of Cloud Foundry was that it worked at scale.

Not in greenfield startups, but in large, complex, regulated enterprises. These were organisations with legacy estates, strict compliance requirements, and thousands of developers. Cloud Foundry ran real production workloads, generated real revenue, and carried real risk.

This matters because scepticism about platforms often stems from the belief that they can’t withstand contact with the realities of the enterprise. Cloud Foundry demonstrated that they can.

Platforms were not the problem.

Success Created New Problems

But success has consequences.

As Cloud Foundry proved its value, organisations wanted more from it. Building “12-factor” applications was only part of the story. Teams needed CI/CD, data services, identity, integration, and more. The scope of “the platform” kept expanding.

At the same time, the platform team became an increasingly significant bottleneck. A single team couldn’t possibly be experts in every domain the organisation depended on. And while Cloud Foundry made day-zero provisioning dramatically easier, managing thousands of long-lived resources over time remained hard.

None of this means Cloud Foundry failed. Quite the opposite. It solved a critical set of problems so effectively that it exposed the next layer of challenges underneath.

Cloud Foundry didn’t show us the limits of platforms. It showed us where the next evolution had to begin.

Why This Story Still Matters

Many organisations today are on the same platform journey, even if the technologies have changed. They’re rediscovering the importance of flow, abstraction, and developer experience. They’re learning, sometimes painfully, that platforms must be on-demand, safe by default, and easy to consume and contribute to.

The danger is forgetting the lessons we already learned.

Cloud Foundry proved that platforms can work at enterprise scale when built around people, not just infrastructure. In the next part of this series, we’ll look at where Cloud Foundry began to strain and why those lessons led us to rethink what a platform needs to be in the modern enterprise.