Falling Into the Pit of Success: What Cloud Foundry’s Achilles Heel Teaches Us About Platform Design

Jeff Atwood wrote something on his blog Coding Horror that has stuck with me for years:

Make it easy to do the right thing and hard, but not impossible, to do the wrong thing.

• Jeff Atwood

This comes from his post Falling Into the Pit of Success, and the central thesis is simple: if you make it easy to do the right thing, people will naturally do it. Most people aren’t trying to do the wrong thing. They’re short on time, heading in a general direction, and will happily take the path of least resistance - if it’s also the right path.

But the second half of that quote is where it gets really interesting: hard, but not impossible, to do the wrong thing.

If you make it impossible to do the wrong thing, you remove the flexibility that people need to solve legitimate problems. And that’s where platforms go to die.

Two Ways Inflexibility Kills Your Platform

When a platform makes it impossible to color outside the lines, the damage shows up in two ways.

1. The Uncontemplated Requirement

Someone has a legitimate business need that you didn’t anticipate when you designed your opinionated platform. Your system could do it in theory, but you haven’t provided a way. You’ve essentially locked them out.

What happens next? They leave. They go to something more raw - like pure Kubernetes - and build their own platform with their own abstractions. Word spreads: “Yeah, that platform doesn’t work for this kind of use case.” You’ve lost a user, missed critical feedback, and potentially seeded a competitor.

It’s fine to decide you don’t want to support a particular workload. But that has to be intentional, not accidental.

And the cost to that team is brutal. They came in expecting maybe four hours of infrastructure thinking. Instead, they hit a brick wall and suddenly face tens, hundreds, or thousands of hours building a platform from scratch. Completely unplanned.

2. The Blocked Power User

Someone loves your platform. They’ve mastered your abstractions and they’re trying to take it further - essentially building the next feature you should have, for free. But there’s no power user mode. No way to extend the platform beyond its built-in boundaries.

When you shut down your power users, you slow your own rate of innovation. You’re saying only the anointed few can evolve the platform, throwing away the leverage of your entire organization.

The irony is devastating. Most platforms are created because the old way was too slow, too bureaucratic, too disconnected from what teams actually need. When you block power users from extending and experimenting, you become the very thing you set out to replace. You become the impediment instead of the enabler.

The Cloud Foundry Lesson

Cloud Foundry - and particularly Pivotal Cloud Foundry - is the perfect case study.

The benefit was extraordinary. Thousands of application developers could use a platform operated by a handful of platform engineers. The operator-to-developer ratio was insane. If you were building a Java, .NET, Python, Node, or Go application, and you needed a URL, deployments, scaling, and access to a database, cache, or message broker - it was phenomenal. For 80% of the applications in a typical enterprise portfolio, it was a no-brainer.

But as soon as you hit the limits of what it would let you do? You were stuck. There was no power user mode. No way to lift the hatch, go into the subfloor, and change the way things worked.

So people went to Kubernetes. It gave them all the configurability they were missing.

Fast forward to today: many of those organizations struggle because they didn’t build opinions and abstractions on top of Kubernetes. They got the flexibility they needed, but not the leverage. The operator-to-developer ratio in Kubernetes land is not great - you end up with tens or hundreds of people thinking deeply about Kubernetes, with a wide diversity of approaches to solving the same problem in the same organization. Consistency evaporates. Maintenance becomes a nightmare.

And yet - flexibility won. Kubernetes is ascendant. Cloud Foundry has declining market share.

Why? Because at the end of the day, you have to solve business problems. It doesn’t matter what the underlying platform is - the business problem still has to get solved. Teams will take the inefficiency hit if it means they can actually deliver. And once you must have Kubernetes for some workloads, the economic argument for paying extra for a rigid abstraction layer falls apart.

Cloud Foundry’s Achilles heel: it made it easy to do the right thing, but it made it impossible to do the wrong thing. That lack of flexibility drove people to Kubernetes and stalled its market growth.

So What Does a Well-Designed Platform Look Like?

The answer is a Kubernetes-based platform that makes it easy to do the right thing on Kubernetes - using custom resources and operators to lower the cognitive burden for developers, while creating a clear contract between the platform team and their customers (application teams, data teams, etc.).

That contract serves as a point of mediation. Without it, you can find yourself held hostage by a single team that refuses to let you maintain the underlying system because it might impact their use case.

We know what the 80% solution looks like. Cloud Foundry already proved it out:

• Ingress - a URL for my app, subdomain or context path, custom domains, SSL termination
• Application runtime - run, auto-scale, and do zero-downtime upgrades
• Network dependencies - connect to other services, external databases, etc.
• Data services - app-specific databases, Redis, RabbitMQ, and the like
• Environment-specific configuration - managed across the environments an app traverses from dev to production

The question is: why hasn’t anyone built consensus around this for Kubernetes? Lots of people have talked about it, but there’s no standard answer.

An Invitation

I suspect there’s prior art out there that I haven’t read - in fact, I’d say it’s almost certain. If there’s existing literature that addresses this, I’d love to see it.

If the consensus answer already exists and it’s good, then the question becomes: why isn’t everyone doing it this way? What’s standing in the way? And that thread is worth pulling.

If there isn’t one - then it’s time to build it.

What am I missing? Where should I be looking? I’d love to hear from you.

I recently had the pleasure of joining Nicky Pike on the [Dev]olution podcast to talk about something that’s been on my mind for a while: are teams actually using the right tools, or just chasing the latest trends?

We covered a lot of ground in this conversation, from the realities of Kubernetes in the enterprise to why so many companies are getting burned by their cloud strategies. Here are some of the key topics we dug into:

Kubernetes Is Not Always the Answer

Kubernetes has become the default choice for container orchestration, but it’s not the right fit for every organization. We talked about the real limitations enterprises face when adopting Kubernetes and why it’s critical to evaluate whether the complexity is justified for your use case.

Cloud Costs Are Out of Control

Many organizations moved to the cloud expecting to save money, only to find their bills spiraling. We discussed common cloud strategy pitfalls, why overspending is so prevalent, and the growing trend of cloud repatriation as companies look for better ways to manage infrastructure costs.

AI Needs a Reality Check

AI is everywhere right now, and so is the hype. We talked honestly about what AI can and can’t do today, and why responsible scaling matters more than rushing to adopt every new tool that comes along. The key is aligning your AI investments with actual business problems, not just adopting technology because everyone else is.

Choose Technology That Solves Real Problems

The thread running through our whole conversation was this: technology decisions should be driven by the problems you’re solving, not by what’s trending on Hacker News. Whether it’s your infrastructure stack, your cloud strategy, or your AI tooling, the right choice is the one that aligns with your business objectives.

You can listen to the full episode on Apple Podcasts, YouTube, or wherever you get your podcasts. I’d love to hear what you think, feel free to reach out if any of these topics resonate with your team.

Platform engineering teams today face immense pressure to deliver faster, reduce risk, and increase efficiency at scale. These challenges can be daunting, but there is a solution. At MomentumAI, we understand these needs and are excited to announce our partnership with Syntasso, the innovative team behind Kratix, a cutting-edge platform engineering framework.

Many platform engineering teams struggle with bottlenecks, inconsistent processes, and the complexity of managing resources at scale. These issues slow down development, increase risk, and create inefficiencies that hinder growth.

MomentumAI and Syntasso have joined forces to guide platform engineering teams through these challenges. With our deep expertise and Syntasso’s revolutionary Kratix framework, we offer a clear plan to build best-in-class platforms. Kratix focuses on empowering platform engineers to build better platforms, and its unique features include:

• Go Faster: By providing everything-as-a-service and self-service access to the resources your teams need, Kratix helps eliminate bottlenecks and accelerates development.
• Reduce Risk: Incorporate key business processes consistently by codifying them across your organization, ensuring critical processes are applied uniformly.
• Increase Efficiency: Manage resources as a fleet and automate the full lifecycle of your platform resources to reduce technical debt and operational overhead.

By adopting Kratix, your team can overcome the challenges that hinder growth and efficiency. Without a robust platform, your team will continue to face delays, increased risks, and inefficiencies that can jeopardize your business growth.

Our collaboration with Syntasso is built on trust, technical expertise, and a shared vision. Together, we offer enhanced platform engineering, tailored solutions, and long-term support, ensuring your platform’s success from day one to day two thousand and beyond.

Industry analysts and thought leaders such as Gartner, Thoughtworks, and the Team Topologies authors have recently advocated that the only way to build a successful platform is to treat it as an internal product. Joe Fitzgerald, CEO of MomentumAI, and Colin Humphreys, CEO of Syntasso, coauthored the original 2017 whitepaper that introduced and argued for the value of implementing Platform as a Product: Why You Should Treat Platform as a Product.

Kratix was designed from the ground up to enable teams to embrace a product mindset, and MomentumAI has a proven track record of building developer-focused platform products.

Our clients will have access to the most advanced platform engineering tools and expertise. Whether you are modernizing an existing platform, building a new one, or enhancing your platform management capabilities, our combined team is here to help you succeed.

Join us as we work to solve the Day 2000 Platform Problem, manage platforms at scale, and embrace the power of everything as a service (XaaS), including Database as a Service (DBaaS). Together, we will enable your teams to go faster, reduce risk, and scale efficiently. Schedule time with us to learn how MomentumAI and Syntasso can help you build a high-performance platform.

While digging in on the first week of the new job here at MomentumAI I came across the cloud-provider-kind utility that allows you to add services of type LoadBalancer to a local kind cluster! Sounds great, right? 🎉

After I got it working Joe said:

Wouldn’t it be nice to have a tray application that would allow me to see the LoadBalancers that are created and then click on them to open a browser window to the port?

So, I created this tray app to do just that. Love to hear your thoughts on it and if you have any ideas for improvements. PRs welcome! 🙏

Good riddence to NodePort and port forwarding. Next Up… packaging this up into a MacOS app 🍎. Stay tuned! 📺

I am thrilled to announce that Caleb Washburn is joining MomentumAI as our Chief Technology Officer. With over 25 years of experience in software architecture and platform engineering, Caleb brings a wealth of knowledge and expertise to our team. His extensive background includes deep expertise in Cloud Foundry, Kubernetes, and Open Source technologies.

Caleb has demonstrated a remarkable passion for building internal developer platforms within enterprises throughout his career. His innovative approach and profound understanding of platform engineering have consistently driven success and transformation in every project he has led. At Tanzu Labs, he worked with 100s of Pivotal and VMware customers, helping them adopt a Platform-as-a-Product approach to build their next-generation platforms.

At MomentumAI, Caleb will spearhead our technology strategy, focusing on empowering enterprises with cutting-edge internal developer platforms. His vision aligns perfectly with our mission to enable platform teams to build amazingly productive app platforms by adopting a product mindset.

Please join me in welcoming Caleb to MomentumAI. Stay tuned for more exciting developments as we push the boundaries of what’s possible in platform engineering and delivering Platform-as-a-Product.

Above all, Caleb is an incredible friend and mentor. Welcome aboard, Caleb!