IDP: Make the Right Path the Easy One

Mikhail asks to rework the question: not why such a platform is needed, but where it came from. Infrastructure, cloud especially, kept growing more complex, and large companies built their own small platforms long before the term IDP existed: at Google that was Borg, before Docker. Borg was later rewritten into Omega, and when Docker appeared and needed orchestrating, the early platform's principles moved to containers — which is how Kubernetes grew. Alexander reads it as second-system syndrome: Omega never flew, yet it got a white paper, then Borg, and only afterwards Kubernetes. Part of Borg's internal capabilities were deliberately kept out of open Kubernetes: with them it would have been too complex for other companies. Both agree that before the term went public such platforms belonged to big tech, where without that abstraction layer you could not ship features.

What turned platforms into a mainstream topic was microservices: the backend long ago, the frontend more recently. Alexander brings in Sam Newman with Building Microservices and Monolith to Microservices, where the author already qualified that not everything needs splitting — but the genie was out of the bottle. Complexity moved out of modules inside an application up to the operations level: the network, latency, error handling, consistency, shared nothing — and observability grew from the same shift. Mikhail adds: on the surface it is one product, while under the bonnet sit a hundred, two hundred, three hundred services, each with its own freedom, and at scale that fires back as an inconsistent experience the platform has to pull together. The participants single out Kubernetes' declarative application descriptions and control loops — you cannot hold that state by hand. Mikhail cannot recall the name of one of the first open-source systems of this class, and Alexander supplies it: Backstage from Spotify, a service catalogue and developer portal. One more pillar is Accelerate: the false dichotomy of fast versus reliable disappeared, but engineering practices need tooling, and that tooling ended up inside platforms.

At its base, Mikhail says, a platform is a one-button click: a single click stands up a service with all its infrastructure, and the standard patterns come with it. The tool then grows, and companies that build an IDP purely for development problems, without the business, in his view lose out: to the business "engineering culture" sounds like money going nowhere, while a platform converts the investment into engineer-hours and metrics. Alexander tells his own story: their platform began in early 2020, when Igor Maslov arrived to head the base services unit and pulled scattered pieces and people into one concept — code storage and delivery, the target runtime, databases, queues, reliability; the team has just marked five years. Until a platform exists, every product team pays a tax on its own mini-platform: its own GitLab or Bitbucket, monitoring, databases and queues — 20 to 25 per cent of engineering time poured into a pile of so-so solutions.

Consolidation buys the effect of scale: instead of a scattering of teams each keeping their own databases, three well-built options handed out through a button rather than a ticket. First a dip, then a sharp boost, because a framework improvement immediately reaches every team. Mikhail adds that with a proper product cycle the platform starts to instil culture — the right thing becomes easy and the wrong thing hard; getting there took them 18 months to two years, and it is no small investment. The talk turns to measurement: DORA — deployment frequency and lead time, the share of failures, the speed of rollbacks — and, by Alexander's reckoning, some eight years have passed since Accelerate, and DevEx and SPACE have appeared in that time. They walk the SPACE letters with examples: commits and merge requests are meaningless at the individual level, yet cutting a test run from 20 to 18 minutes turns into saved hours company-wide; communication covers code review and onboarding, which at Google dropped dramatically during covid; efficiency and flow covers context switching, noisy logs, and management meetings every two hours.

The dashboards do not drill down to individual engineers, but they let you compare teams: mobile developers came out ahead on the sense that they work on important things — probably because they sit on the last mile and see the result. What the business really buys, they argue, are maturity boards: at a glance you see what each team has plugged in, and metrics are best chosen by whatever hurts — for the mobile rollout they wrote a script checking which teams have an adapted interface. Among the basics Mikhail names finding the owner: a platform at least shows services with nobody responsible, and their services are registered so that the team on duty, the guarantees, and the escalation path are visible. Traces reach down to infrastructure, but their adoption lags behind logs and metrics — some people still chase a correlation ID through logs, where cause and effect are invisible. Alexander has a similar service with SLAs by criticality level and reports: nobody wants to top the anti-leaderboard, so tasks prioritise themselves.

A platform team fails when it closes in on its tool: Alexander recalls a team that declared itself a Kubernetes guru on bare metal and waited for people to come; it was folded under common leadership, the approach rebuilt, everything migrated to the target runtime. Mikhail's recipe is straightforward — product approaches: regular syncs with demos and feedback; the developer is the customer, and the platform is not the boss. Alexander adds that the platform must also evangelise what it can do — not just feature demos but workshops on assembling a typical solution from its building blocks. Their platform team counts as a product team and defends its features like any other, while its product managers grew out of team and tech leads: technical product managers are almost impossible to hire. Beyond DORA the participants suggest developer jobs and comparing the real path with the golden path: a code review where, instead of open it, read it, comment, two hours go on deploying it, reading documentation, and hunting down an expert. Among the newest tools are assistants: test cases generated from screenshots, cutting manual testing time several times over. The closing advice: the later you start, the more expensive the platform gets.