I’m going to let you in on the secret to platform design. There is no platform.
As Theodore Levitt once said, “people don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
In other words, a platform only exists to solve specific problems, for specific people.
Therein lies the challenge of platform engineering. If you want to offer meaningful platform discounts, you need to walk the gemba. You have to physically go to where the work takes place, observe reality, identify inefficiencies, and gather insights from the team members who are closest to the work.
When you walk the gemba, you will see there is no platform. There are only tasks.
For platform engineers, there are four task anti-patterns you want to look out for.
Undifferentiated programming tasks. Any code that can be templatized represents an undifferentiated programming task. Boilerplate API code would be the most common example of undifferentiated programming.
Tasks where variation is not acceptable. Infrastructure provisioning is an example where variation is not acceptable. Infrastructure snowflakes are face-rakes waiting to be stepped on.
High task cost. Tasks that are tedious and expensive tend to be neglected, irrespective of their importance. That’s why dependency upgrades are routinely neglected.
High cognitive load. Tasks that require specialized or obscure knowledge can easily bottleneck your production line. WCAG (accessibility) testing is a good example of a task with high cognitive load.
Most software delivery organizations display all four anti-patterns in some measure. How do you choose which one to solve?
In my opinion, it’s not possible to solve all of these problems well. Successful developer platforms tend to solve in one area and then design key platform discounts around the solution. Here are some examples.
Firebase
When I started in tech, the old saw was that a startup had to spend its first $1M just to build login. There was more than a grain of truth to that. Between 2000 and 2010, I built three separate, but functionally identical, auth systems. You could have literally copied and pasted the same code from one context to another, and it would have worked just fine. This is the definition of undifferentiated programming. The Firebase platform solves this by providing login as a service. Firebase users can build a very robust login experience, compatible with any authentication provider, in less than an hour. This is a huge platform discount that also makes the Firebase platform extremely sticky.
Supabase
Supabase is a newer player on the platform scene. Supabase is marketed to teams that rely on relational data generally and the Postgres database specifically. Supabase acknowledges that Postgres administration is a key task for which there should be no variation. The more trivial the task, the less variation there should be. If you want to add a column for example, you should do it the same way every time. Supabase’s extremely opinionated administrative tooling is a forcing function that allows customers to scale out Postgres implementations with very low variation.
Netlify
One of the most expensive tasks in any delivery organization is the pull request review. Any discount against that task is probably worth millions to any sizable team. The Netlify platform seeks to reduce the task cost of pull request review by automatically deploying every pull request into an isolated and ephemeral testing environment. At Thrivent we don’t use Netlify, but we are building an internal developer platform that provides the same platform discount. To understand the scale of the cost savings here, consider that between May 1 and May 19 (today), just one of our repo’s has emitted over four thousand pull requests. The reason this output is possible is because we have driven the task cost of pull request deployment nearly to zero.
Backstage
The team that built Backstage doesn’t make a big deal of it, but under the covers, Backstage is really a framework for Domain Driven Design. The beating heart of Backstage is a system catalog that allows you to define your inventory using DDD constructs like domain, system, component, resource, etc. Backstage solves a problem that is very common with microservice architectures. Namely, if you have more than a handful of microservices, just keeping track of your inventory can become overwhelming. Backstage lowers the cognitive load of your inventory by shelving components against a simple DDD taxonomy.
Platform Discounts and the Cloud
You may have noticed a common theme in the examples above. Firebase, Supabase, and Netlify are all cloud-native platforms. Their platform discounts only make sense within the economics of the cloud.
What about Backstage? Backstage ships as a self-hosted app. However, many Backstage customers use a SaaS version, hosted in the cloud by a company called Roadie. Without the cloud, Roadie’s value proposition would fall apart and a substantial chunk of Backstage’s user base would disappear.
Cloud economics are a multiplier that can scale a simple engineering solve into a valuable platform discount.
Conclusion
Great platform discounts solve one of the following task anti-patterns:
undifferentiated programming
variation
high task cost
high cognitive load
To know which problem is most pressing, you have to walk the gemba. And remember, there is no platform.