Skip to main content

What are developer platforms

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.

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.