Don't Call It A Platform
Down with The Platform, up with Developer Enablement
Posted on Feb 8 2023
This year (2023) is the year of platform engineering. Don’t believe me? Here is the esteemed (and it has to be said lovely) Charles Humble totally accurately quoting the ravings of some madman on twitter:
“This is going to be year of platform engineering.” @samnewman, #WTFIsCloudNative
— Charles Humble (@charleshumble@mastodon.social) (@charleshumble) February 2, 2023
See? The industry is all ablaze about the idea. I mean, even Gartner has come to the party, so it must be a thing, right? If Gartner says something, it must be true. I fully expect we'll see the announcement of PlatformCon 2023 to be held at the Moscone Center, with "Con" taking on many, many, meanings.
But, let’s pump the brakes for a bit. I fear that we’ve come too far from the original intention of a developer platform. We’re in danger of being drowned under an orgy of vendor-driven mis-direction, which will allow existing IT structures to carry on as if nothing ever happened as they can slap a new label on old practices.
A cynic might argue that the (as of time of writing) $66.8 BILLION raised to fund the Cambrian explosion of products around Kubernetes means that a lot of VCs are looking for their payday. And I suspect that much like the early days of attempts to monetise Agile, DevOps and the API Economy, the pickings have been slim. But a new term they can get behind, leaving aside the confusing term “Cloud Native”? Count them in! Marketing suddenly got a whole lot simpler.
The Kubernetes Awakens
The reality is, Kubernetes is everywhere, and just like every successful fungus continues to spread (I kid, I kid!).
Let’s get some things out of the way. Kubernetes, vanilla Kubernetes, not whatever horrific private cloud your company has cobbled together, is not in any way shape or form developer friendly. To be fair, that’s not what it was created to be. But fundamentally, the out of the box experience is fine for infrastructure automation nerds like me, but friendly for the bulk of developers? Hell no.
Kubernetes, again vanilla Kubernetes, not that complex expensive disappointment your CIO purchased, also doesn’t do much. At its heart, its main job is to help schedule containers. It was successful for a number of reasons. Firstly, because it has a pretty good API allowing for extensibility. Secondly, because it was competing against solutions that were by turns too expensive (PCF), confusingly complex (Mesos), or suffering an identity crisis (like Docker Swarm - I can only assume the marketing geniuses at Docker ended up in charge of naming stuff at Google). Thirdly, and most importantly, because a bunch of people got scared by AWS and thought backing the project might stop Amazon becoming the dominant cloud platform for deploying software. On that front, it's been a huge success, right? Right?
Kubernetes was extensible, and allowed an ecosystem to grow around it. It’s easy to use the CNCF landscape as a source of snark (and as you can see, I do) - but it’s a sign of success. It’s also a sign of a bewildering array of options available to anyone considering building a solution on top.
I think I finally started to understand how crazy everything had got after watching this great talk from V Körbes. After watching this engaging talk, I needed a lie down. The bewildering array of options to solve the same problems can take an expert like V to navigate, was a concern to me back in 2019 when this talk was from. Since then, can anyone say it's got better?
So, now we have a towering edifice, created out of software which is well meaning and apparently simple in isolation, that ends up as a rube Goldberg machine of operational overhead, latency blackholes, and ever increasing budgets. The VCs are rubbing their hands, the rest of us are staring into the abyss - but this time, it's got an API.
The past experience
I was far from the only person worried about the complexity of the Kubernetes ecosystem in the pre-pandemic times, in fact rather than just bitching about it down at the pub, a number of folks actually started talking about it more to try and share better ways of thinking about this space. Developer experience, typically shortened to DevEx or DX, became a hot topic for a while.
Although I do a lot of general vendor bashing (hey, my company has two people - I consider vendor bashing to be very much punching up!), a lot of the talk about DevEx was coming from the vendor space. People building technical developer-focused products, wanting to understand how to make their tooling easy to use and sharing tips with the wider industry.
Daniel Bryant from DataWire in particular was talking about these ideas back then, his talk in 2019 giving a great overview of the challenges we have to deal with.
Remember 2019? Simpler times. Very much pre-pandemic, and back when we thought “jeez, the whole Kubernetes ecosystem is a bit much, isn’t it?”. Here we are in 2023, and how is that going for us?
Enter The Platform
2023 is here. Developer Experience is dead, long live The Platform.
So now, we’ve arrived at The Platform. Note the capital ’T’ and ‘P’. This is it. The time has come. We brought all this stuff, now we have to make it work together.
The reality is, much of the effort around platform engineering is NOT about empowering developers, it’s about hiding the towering pile of crap we’ve assembled and now have to hide from the people we apparently got it for in the first place. It’s like buying a bunch of presents for a child, then having to hide them because they’re too dangerous for them to use, and in reality you really got them for yourself. Did your kid really need that compound hunting bow?
It’s not about the experience. It’s not about enablement. It’s about serving the idol of technology, doubling down on our sunk cost. The Platform Above All Others. It should be here to serve, but instead it ends up bending those who use it to their will.
Topologically Topical
Into this morass, wades Manuel Pais and Matthew Skelton, who outline a vision for modern software delivery organisations in their book Team Topologies. In it, they describe long-lived stream aligned (outcome-oriented) teams who work with high degrees of autonomy. Empowered to get things done, and get software out of the door and into the hands of their customers as quickly as possible.
To support this mission, these poly-skilled teams need help. Other types of teams - enablement teams in Team Topologies speak - exist to help these teams get things done. Functions like security, architecture, design, go from being gatekeepers to enablers - their job is to provide support to get things done.
In the book, the authors also make it clear that these teams need enablement in terms of the developer tooling they need too, hence the need for some sort of platform. The book positions a Platform Team as being somehow different to an enablement team, but personally I see the platform team as just another type of enablement team. The mission of the platform team, should you choose to accept it, is about enabling these stream aligned teams to get things done.
Above all though, as great as the content is in the book (and I highly recommend it to anyone in a leadership role in software development), I do wish they hadn’t codified the concept of the platform team. Naming is important - it pushes a direction - "we exist to build a platform". But read the words of the book, and that’s not really the role they should play.
The book goes on to outline a vision for the ideal platform. It should be developed like a consumer-facing product. Think about customer needs. Most controversially of all, they make an argument that the platform should be optional..
Making the platform optional is very challenging for some people. It cost so much, we need to justify the cost. So people have to use it! Otherwise we wasted time and money. And as Matthew and Manuel point out, when something becomes mandatory, interesting thing happens, When you make people use the platform, you stop caring about making it easy to use, because they don’t have a choice. You aren't incentivised to improve the user experience to attract people to the platform, as they have to be there anyway.
Matthew, Manuel, and myself are far from the only people banging the drum for developing an internal developer platform like a consumer-driven product. Another ex-colleague of mine, Evan Bottcher, put forward a compelling vision for what a developer platform should be back in 2018 What I Talk About When I Talk About Platforms:
“A *digital platform* is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.”
But those of us with no products to sell don’t have the marketing budgets of those who do. Remember that $66.8 billion raised by companies on the CNCF landscape? That money doesn’t just go into building the stuff. Pushing back against the weight of money in this space with this blog post is a bit like trying to stop a tornado with a kazoo. It’s not very effective, but at least I enjoy the funny sounds it makes.
The vision for The Platform has gone from being a vision for a better experience for developers, where the platform exists to serve developers, and has instead come to serve the Kult Of Kubernetes, and it's worshipers.
What's In A Name?
Whenever you come across a team which is named after a specific tool or technology, you have a potential problem. The API Gateway Team. The Enterprise Service Bus Team. And yes, The Platform Team.
The problems occur on two fronts. Firstly, for "technical" single-issue teams like this, they become the bottleneck, the silo. They end up owning key technical infrastructure, in much the same way as a dragon hordes its gold. Making changes to these pieces of key infrastructure to suit the needs of the developers that use them can often be like getting Gollum to share the ring, if Gollum used Jira.
There is a more subtle concern with single-issue teams like this though. It speaks to confused motivations, a lack of focus. Their job becomes about managing the tool. Are they ever going to be in a position to think about alternatives? To realise a better way to solve the problems at hand? These are teams where they have only one tool, one hammer - and all problems better be a nail. Or else.
An old colleague of mine succinctly differentiated the two world views at play. Sriram Narayan described ActivityOriented teams as those driven to carry out a certain activity:
“... activity-oriented teams are prone to optimize for their own activity and not for the bigger picture of delivering useful software. This is a consequence of what they are held responsible for and how they are measured. It is common for a team of only developers to only be measured by their velocity. If they are only tasked with delivering scope, they will not think about whether it is going to solve the problems it was meant to.“ - Sriram Narayan
Sriram suggests instead that the solution to this is to instead think in terms of OutcomeOriented teams, where teams are focused on delivering an outcome, rather than slavishly locked into a certain implementation detail.
We want our Platform Team to be about outcomes - but we are hamstringing them from the beginning by calling the Platform Team in the first place, and worse could follow by codifying "Platform Engineering" as a thing.
Naming things is important. For a team inside an organisation, it can change how you are viewed, and what people expect you to be able to offer. For people in the team itself, it's one of the simpler ways you can help set direction - rightly or wrong.
It's for these reasons that I argue we should name the team after the outcomes we wanted them to achieve, rather than in terms of a technical solution they might want to use. Quite aside from the fact that you might need more than one platform (so Platform Team has to become Platforms Team?), often the best way to improve the experience of developers may have nothing to do with a platform in the first place. Better names might be “Delivery Support” or even better “Delivery Enablement”.
A platform might be the best way to reduce the cognitive burden on developers and allow them to get more done, but at best it is a means to an end. But we need to encourage people in charge of this function to be able to think more broadly. Matthew Skelton:
What if the most important part of "platform engineering" is maintaining a high quality wiki with proven, empathic patterns for Stream-aligned teams to follow? 📄 #platformengineering #DevOps
— Matthew Skelton #BLM 💙🌻 (@matthewpskelton) October 15, 2022
If you're a team who cares about empowering developers, you'll think about offering training, doing outreach, embedding yourself in delivery teams to help them use the tools and also get feedback on if the solutions you are offering are appropriate. All of those things seem like they'd be the responsibility of the Delivery Enablement team, don't they? The Platform Team though? Sorry, I've got a Kubernetes cluster to polish.
Just as with DevOps (It's The Culture, Stupid!) we're in danger of missing the point all over again.
So What?
When writing the 2nd edition of Building Microservices, I revisited the concept of habitability - a concept which I visit in the context of developer platforms in a talk last year.
Habitability, in the broadest sense, describes how nice (or not) the experience is for the people who have to live in a system. From a building, to a codebase, to the ecosystem of developer tools we deliver for our workforce. In the talk, and in my most recent book, I make the argument that we ignore habitability at our peril. Those of us in a place to shape the lived experiences of our colleagues have a duty of care to ensure that we take their needs to heart.
Delivering a habitable experience requires empathy for the people that will live and work there. Having a clear focus, and vision, for the people who are responsible for this is much more important than any particular technology.
And so, I come back once again, to the name. If we want to have a hope of coming out the other side with a better lived experience for our delivery teams, I urge you to consider making at least one small change inside your own organisation.
No more platform team. Kubernetes, containers, the cloud, the platform - it’s all means to an end. Down with The Platform, up with Developer Enablement.
Back to Blog.