Hey there! Welcome to Platform Weekly issue 100.

It’s been 100 weeks of platform weekly. I can’t believe it. It’s time for our 100th weekly dive into the Olympic-sized platform engineering pool. Every week we explore another area of the platform engineering universe, talking about best practices, lessons, news, ideas, and all-around platformy goodness.

BTW - You’ve still got 12 hours to use the code PW30 and get a 30% discount on the first-ever official Platform Engineering Fundamentals course. Seats are filling up very fast - so don’t miss it.

Build your platform right

‍

To celebrate 100 weeks of Platform Weekly, I want to talk about my favorite topic. Platform backends.

We’ve been talking a lot in the community lately about the need to focus on the backend of your platform first to get the true value of platform engineering. You probably know by now that slapping a developer portal on top of your existing setup and just focusing on the frontend of your platform won’t get you far.

You need to get to the guts of your Internal Developer Platform, design clear golden paths for developers to consume application configurations, and interact with the underlying infrastructure the right way.

Just because platform engineering is still a young discipline, it doesn’t mean that established architectural and design principles don’t apply. Building your IDP is like building a regular application and you should start from the backend. That’s where the core logic is implemented and the golden paths for your developers are designed.

But are all backends the same? Of course not. There are two dominant ways to approach platform backends

Pipeline-based 👉🏻this is what most teams are familiar with, a CI/CD pipeline plus some Terraform or other IaC tooling. These systems are designed to handle environment progression logic: IF this THEN move to the next step. They are not great at handling more complex logic, however.

Platform teams that misuse pipelines to handle more complex logic end up with pipelines nested into one another. And you are back at square 1 with a setup that’s very hard to maintain and scale and delivers none of the results that you had hoped for when starting your platform initiative. Not to mention your devs are still overwhelmed by the amount of scripts and config files they need to touch to deploy.

‍

‍

Graph-based 👉🏻a.k.a. Platform Orchestrators on the other hand are designed to handle any level of complexity (e.g recursive intra-resource dependencies), while shielding developers from the underlying complexity.

Devs don’t need to worry about any implementation details, they simply request the infra they need and the orchestrator supplies it following the golden paths designed by the platform team. Though a Graph-based backend might not make sense for a team with less than 100 devs, the power of platform engineering comes from its ability to deliver insane value at scale. And that is where a graph-based backend becomes mandatory.

‍

If you’re a small organization, a pipeline approach might work great for you. But if you really want to get the benefits of platform engineering and deliver the business results you’re hoping for (and have probably promised you’d deliver) then you need a graph-based backend.

P.S. Haven’t answered the State of Platform Engineering 2024 surveys yet?

Build your platform right

Past issues