Platform Engineering

When you need a platform

The platform a product runs on almost always comes together in a disorderly way, one piece at a time. As the product grows, it has to become robust, scalable and safe for the whole team to change. Until that step happens, code and infrastructure stay in a state where neither people nor agents can act on them effectively.

What platform engineering is

Platform engineering is the discipline that builds and maintains the internal platform on which teams develop, ship and run software. The CNCF platforms white paper defines it as "an integrated collection of capabilities defined and presented according to the needs of the platform's users".

The key concept is self-service: developers can create a new service, an environment or a release pipeline on their own, following a ready-made, supported path (the so-called golden path), without opening a ticket and without having to know every detail of the underlying infrastructure. The goal is to reduce the cognitive load on product teams.

Platform engineering and DevOps

Platform engineering grows out of DevOps practices and takes them one step further, shifting the emphasis to self-service: instead of expecting every developer to become an expert in Kubernetes, Terraform and pipelines, you provide tools and paths with that expertise already built in.

In practice the platform becomes an internal product: it has users (the development teams), documentation, consistent interfaces, and it improves based on how it is actually used.

What goes into a platform

Every platform is different, but some capabilities come up almost every time:

• Infrastructure as Code and GitOps. The whole environment is described declaratively, with Terraform and tools such as Argo CD, versioned and reproducible.
• A single release path. CI/CD pipelines that build, test and ship every service the same way.
• Templates and golden paths. A new service or a new environment is created from a template that already carries its pipeline, configuration and instrumentation.
• Environments. Development, test and production consistent with each other, created and torn down automatically.
• Observability. Metrics, logs and traces collected uniformly, for example with OpenTelemetry, from day one.
• Identity, secrets and security by default. Permissions, secrets management and controls are part of the platform, they don't get bolted on later.
• Ownership and runbooks. It is clear who is responsible for what, and how to intervene when something breaks.

Do you really need a developer portal?

A full internal developer platform, with a portal such as Backstage, is not right for every company. It makes sense when many teams run many services; in a startup or a scale-up it risks turning into a separate project, one you end up maintaining more than using.

In most cases it pays to start with something simpler: automated templates, a single way to ship, written conventions. This is what the Team Topologies approach calls the thinnest viable platform: the minimum set of capabilities that is enough to make product teams fast. The platform grows when the organization grows, not before.

An agent-ready platform

AI makes changing code and infrastructure faster. But if the platform is fragile, poorly documented, or full of exceptions, it accelerates risk too. I help the team build a declarative, observable, and understandable platform so that people and AI tools can act on it with confidence.

An agent-ready platform rests on the same principles as platform engineering and DevOps: declarative infrastructure, a single way of doing things, explicit conventions. To these it adds three elements:

• A harness: the agent's working environment, that is, the context it reads, the tools it can use and the way it proposes changes.
• Guardrails: the limits that stop an agent, or a person, from doing damage, such as least-privilege permissions, mandatory pull requests, automated tests and human approval before anything goes to production.
• Observability: to understand the effect of every change you need metrics, logs and traces that can be queried, by people as well as by agents.

I go into this in more depth on the DevOps consulting page.