Cloud technologies provide a rich set of primitives. Primitives that can be used as building blocks to build your dream product.
Each primitive serves a specific purpose while taking care of nonfunctional characteristics as well: you can run them fast, secure, and at scale. Your credit card balance is the limit.
The open source world, the ecosystem shepherded by the Cloud Native Computing Foundation, also gives you building blocks to build and run your product on top.
The era of cloud and cloud native has been about optionality. You have a rich set of tools available to you to build your engineering practices around, reaching levels that were not possible for most companies before this era.
But a rich set of tools doesn't make a developer platform.
A rich set of tools doesn't make a developer platform
When you pick tools from cloud providers, or the cloud native ecosystem, you often don’t just have a single tool in mind. You are optimizing your team's developer experience across the whole flow.
You begin to prioritize features that are touch points along the larger system. But those features span across multiple tools and they typically have gaps between them, so you have to put deliberate effort into making things feel seamless.
You know you're building a PaaS when you start stitching together 1,000,000,000 other tools in order to get one click deployments.— Kelsey Hightower (@kelseyhightower) April 11, 2017
When we think about Developer Experience, we have think beyond a single product.— Sarah Drasner (@sarah_edo) January 31, 2022
In a Developer's journey, we begin to prioritize the features that are touch points along the larger system. pic.twitter.com/3d1vikuTyJ
Developer platforms start organically
When you pick a primitive, and integrate it in your product, you make certain decisions. These decisions - without you knowing it - result in your developer platform.
When you are a small team, engineers are on double duty. They mostly build product features for customers, but every once in a while, they make a decision that contributes to the developer platform. The way you use DynamoDB, the CI plugins you pick, the way you run containers in production is your developer platform.
Platforms are not explicit in the beginning. Engineers make decisions on their own constantly.
As companies grow, however, different teams may make different decisions affecting the same area. Performance or knowledge sharing issues may become apparent.
Platforms become explicit when growing pains start surfacing. When engineers start talking about standardization across teams. Or simply when productivity halts.
At this point, organic efforts get structured. Responsibilities are decided, teams may be restructured.
But developer platforms are born earlier. They start out as little as a custom CI plugin, a Docker base image, a CLI to do everyday tasks, or a shared deploy script.
This can include a core business feature: a payment component that is integrated different ways in your product, or a web scraping component. Things that were previously addressed in multiple teams, often differently, now get dedicated attention.
Developer platforms are about technical goals
As you have probably guessed by now, developer platforms are about technical goals, not product features.
Developer platforms may take care of
- scaling a key area
- performance and availability goals
- easier maintenance
- compliance questions
- encapsulating core business features
Bluntly put: a developer platform is whatever you come up with that allows developers to focus on business-logic, by letting them rely on the platform taking care of the above listed characteristics.
Developer platforms are about developer experience
Besides technical goals, there is one more key characteristic of developer platforms. Platforms enable engineers, they shouldn’t make their lives harder.
A clear sign of a platform feature not working is engineers going to any length trying to circumvent it.