From Abby Bangser’s KubeCon US 2025 keynote:
Now, I’m sure that at least some of you are shaking your heads and thinking, I’m saying we have to all build our own PaaS. Haven’t we been there before with platforms as a service? But I am absolutely not suggesting that we walk up to Sisyphus, give a big high five and go, “Let’s grab that boulder and push it up the hill of our internal platform as a service.” It’s not about rebuilding what we can purchase that is available on the market. It’s about making sure we spend our time building the things that are bespoke and important for our organization. It’s so we can depend on platforms like these products and more to build on top of because an internal platform is bespoke to your business. It is always striving to fill the space between what you can buy from the market and what your teams demand to be effective. Said another way, an internal platform is your specialized internal economy of scale. It’s what’s unique to your business but common to your teams and it will be changing over time to address that. This is when we bring in the strategies that allow us to apply the platform principles to our organizations.
Buy everything you can. When it’s not differentiating, use it from the market. But when you can build something to support multiple teams and create that economy of scale, do it. And realize that what becomes available for purchase and what your teams demand is continuously evolving. So is your platform to keep up.
And, platform sprawl as a Christmas puppy:
You’re not just the owner of a single puppy on Christmas morning. You have a mega litter. These puppies are running rampant around your entire organization and they’re completely unsupervised. You need to track them down each time you want to introduce a new feature, each time you need to patch a CVE. So, as a platform engineer, you don’t get to be high leverage as an engineer. You’re a full-time puppy parent, but you don’t even get the Insta photos. You don’t get the snuggles.
Check out the full talk, lots of good stuff crammed into a 15 minutes.
Related and also from Syntasso land, advice from Sarah Wells, who worked at the Financial Times for some time:
Sam [Newman] had a blog post last year, I think, about “don’t call it a platform team.” Yeah, because if you call something a platform team they think their job is to build a platform, and their job isn’t to build a platform—it’s to speed up all the other teams. And Team Topologies talks about the thinnest viable platform. So what’s the minimum? What can you get away with? Is it just a list that says “here are the AWS tools that we use and here’s how to use them”?
I don’t think tooling is the core thing to be considering. I think the important thing is don’t build something if you can buy it. And generally I like to choose tools that people are already using, and when you need them. So I think any platform team that says “right, the first thing we’re going to do is set up a Kubernetes cluster”—like, you have to work out if that’s actually what is needed. So the FT made a lot of progress—and this is a long time ago—deploying services for the website to Heroku. So if you can lean on something that isn’t as complicated, then that’s great. We also had Kubernetes for more backend stuff, so we had a variety of things. And it’s just basically you don’t have to cram everybody into one approach or build a really complicated thing. I think the problem is it’s fun, it’s interesting, you’re really into that area, you want to go off and build a thing. But it’s realizing sometimes that it’s not what you want to do—it’s what your customers actually need. And there’s a great quote, I think it’s from Kathy Korevec, who says “you’re a chef cooking for other chefs, but that doesn’t mean they want to eat steak.” Basically, they may have different tastes.