So you are convinced, and your boss is also on board. You both read the latest DevOps and State of Platform Engineering reports; you visited KubeCon and spoke about it with half the vendors there. You even attended an exec roundtable on the topic with other practitioners in your industry. The decision is finally official: You are getting started on your platform engineering journey. Congrats! The promised land of improved DORA metrics, developer self-service and faster time to market is around the corner. Right?
It can be, but you’ll need to dodge some crucial mistakes and antipatterns that too many platform teams have fallen for. The first and most common one: to start by building the frontend of your internal developer platform (IDP) first, rather than focusing on the backend. So many teams just take their current CI/CD pipeline and slap a developer portal on top of it. Bam, done! Your platform engineering is off to a fantastic start. Right?
Not so fast. There are a number of issues with this portal-first approach and Aaron Erickson, who built the IDP at Salesforce highlights the most obvious one: “Building an IDP is like building a house. You would never start from the front door or the windows, but rather from the foundation. Then you add the walls and only in the end the door and windows. Building an IDP by starting with a portal is like building a house by starting with your front door and windows.”
The other big challenge this approach leads to is that, as your platform engineering initiative matures and grows in scope, you’ll need more and more logic to be built into your IDP. If you haven’t done things properly from the get-go, such as starting from your platform’s backend, you will find yourself trying to shoehorn logic into your frontend. If there is anything we’ve learned from building microservice architectures over the last 10-plus years, it is that building business logic into your frontend is a big problem and violates the single-responsibility principle, where a module “should be responsible to one, and only one, actor.” This exposes your business logic, creating application vulnerabilities while making your frontend heavy and slow.
That’s why every internal developer platform needs a proper backend, and why as a platform team you want to make sure you start by designing and building that before you worry about anything else.
So how do you design a backend? You essentially have two options.
Option 1: Pipeline-based backend (CI/CD+IaC)
This is what many teams starting with platform engineering often default to. It’s usually a legacy of former DevOps and infrastructure teams, combining CI/CD pipelines with Infrastructure as Code (IaC) setups.
In its basic form, the user (the application developer) works on an environment-by-environment basis, defining application and infrastructure configurations with individual config files for each environment. CI/CD pipelines then execute the changes to these files with every git-push. In more advanced setups, developers can describe changes in a more abstract way, and these requests are then transformed through nested pipelines into individual pipeline runs.
Pros and cons
The advantage here is very clear: most teams are still used to this type of toolchain and process. That also means the talent pool in the industry to build and maintain pipeline-based systems is relatively large.
The disadvantage is that pipelines are a start-stop system that is not designed to have advanced logic built into it. So a similar argument applies regarding the frontend-first approach we discussed earlier. While simple logic such as environment progression and sign-offs are well suited for pipeline systems, anything that goes beyond that — for instance, developers interacting with your infrastructure — won’t scale well.
Say for example that a developer requests an AWS S3 bucket for their workload. You’d naturally want your IDP to create individually configured buckets for each environment, run policy checks and inject secrets at runtime into the container before deploying. To do that, a pipeline-based backend will exponentially grow more complex and will quickly become hard to maintain.
The result is that pipeline backends are often kept to a minimum of business logic as anything more advanced would become too sprawling and complicated. This leads to poor platform setups that do not manage the full life cycle of an app and don’t drive standardization across your org. They are also hard to audit and difficult to consume (no API first, no multiple interfaces, etc.)
Option 2: Graph-based backend (Platform Orchestrators)
A platform orchestrator is a platform backend that sits post-CI system. It reads in a declarative, abstract request (for instance, a developer wants a Postgres database for their workload, to be deployed to staging). It interprets the context of the request (environment=staging in this case) and matches it to the rules set by the platform team. It then outputs an executable resource graph that can be deployed directly by the orchestrator or by an existing CD solution (synced to the cluster by ArgoCD).
Graph-based approaches are very versatile and allow for advanced logic. If the developer requests a new dependency (like adding a Redis cache to the workload), the graph will automatically be extended. If the platform team updates Redis from Vx to Vx+1, the graph gets automatically rebuilt and the newer version is used at the next deployment.
This architectural approach lets platform teams use the same definition of a resource type for each environment. Sticking to the example, all resources of type “Postgres” in the context “staging” are configured exactly the same way, are life cycle managed and any config deviations are automatically reverted back to the standard. Platform orchestrators should also have deployment pipeline functionality to manage environment progression and other automation.
Pros and cons
Graph-based backends tick all the boxes of good architectural design. They convert abstract developer requests into executable configuration files that follow clear golden paths and rules. This automatically drives standardization by design, across all workflows and teams. They are API-first and have multiple interfaces (CLI, UI, code-based such as Score). They come with role-based access control and single sign-on, and they allow for automatic sign-offs, secret injections, policy checks, etc., making an IDP truly enterprise-ready.
On the flip side, they are new and require a mindset shift, especially from existing infrastructure teams that are used to thinking in pipelines. Also, graph-based backends only make sense at scale. If you are a smaller team ( fewer than 50 developers), you might be better off with a simpler pipeline-first approach to your backend.
Conclusion
Gartner expects 80% of all enterprises to have a platform engineering initiative by 2026. It’s great to see so many teams understanding the potential of internal developer platforms. But you need to do it right, or your platform initiative might end up creating more problems than it solves.
