Take the Kolkata metro at rush hour and you are touching a platform in every sense — a shared piece of infrastructure, run by specialists, used by everyone, with a map that tells you exactly what you can rely on. That is genuinely the best mental model I know for the software idea this post explains. When a company’s engineers all need the same plumbing — pipelines, servers, logins, deployments — somebody has to run that plumbing like the metro runs: reliably, on published schedules, with nobody’s commute depending on a favour. The discipline of doing that well is PlatformOps, and this is a friendly walk through it for people meeting the subject on a Monday morning, glossary included, jargon kept on a leash.
PlatformOps, Before the Jargon Piles Up
Here is the whole idea in a paragraph. Inside companies with more than a couple of software teams, the same needs keep recurring: everyone needs to ship code, everyone needs somewhere to run it, everyone needs logs and logins and the hundred small services that make a product possible. Teams can each build their own versions, and for a while they do — and then the company wakes up owning four half-finished copies of everything. The alternative is to build those shared things once, properly, and run them as a service that any team can use without asking permission at every step. PlatformOps is the running part: the schedules, the upkeep, the person to call, and the promise that the last train of the night will actually show up.
What makes it interesting — and occasionally awkward — is that none of the users were assigned. Teams choose the shared route because it is genuinely the easier one, the same way most of us choose the metro over arguing about parking. The moment a shared platform has to force people aboard, something has gone wrong upstream, and the operators usually know exactly what.
The PlatformOps Glossary You Will Actually Use
Seven terms cover most conversations. Friendly definitions, no exam at the end.
- The portal. The front entrance — the website where you can see what the platform offers, ask for what you need, and find out who to talk to. A good portal is a station map, not a locked turnstile.
- The service catalog. The honest list of everything the platform provides, with the owner’s name beside each entry. Its only job is to be true; the day an entry is wrong is the day users stop trusting the rest.
- The golden path. The route the platform team maintains and vouches for — from code on your laptop to the thing running for users. Like a metro line, it is not the only way across the city; it is the way that comes with a driver, a schedule and someone to complain to.
- An SLO. A service level objective — a written promise about how well something will behave, plain enough that you can tell whether it was kept. “The login service responds within a second, 99 times out of 100” is the shape of one.
- The error budget. The polite amount of failure a promise allows. If you have committed to 99%, one call in a hundred is budgeted, not a scandal. The budget turns arguments about reliability into arithmetic, which is why everyone calm likes it.
- Deprecation. The managed goodbye — announcing that something will be switched off, helping everyone move to its replacement, and then actually switching it off. Doing this well is the single most trust-building move a platform team can make.
- Cognitive load. The amount of stuff a team must hold in their heads to do their work. The platform exists to take some of that weight off product teams — and if it adds more weight than it removes, users will vote with their feet, quietly and correctly.
Watch the words cooperate in one ordinary afternoon and they stop being vocabulary. A developer opens the portal and finds the catalog entry for “preview environments”, owned by Ritika, marked generally available. That is her SLO attached — ready in ten minutes, nine times out of ten. The developer clicks, gets an environment at minute seven, and never learns which cluster it landed on, because that detail is not hers to carry. A month later the entry says “deprecating in March — migrate to the v2 template”, with a migration note that takes four minutes to follow. She follows it, mildly pleased. Nothing in that afternoon required a meeting, a ticket, or a favour — which is the entire test of whether a platform is being operated or merely possessed.
Who Does What on the Platform
Three groups orbit any internal platform, and knowing which you are saves everyone confusion. The operators run it — upgrading, measuring, answering pages, and doing the quiet writing that keeps the catalog honest. The users are the product teams, who treat the platform the way commuters treat the metro: they want it boring, punctual and always there. And in the middle sit the co-designers — squads building something new alongside the operators, because sometimes a team needs a custom line rather than the scheduled route. The on-call rule is worth memorising because it prevents so many 3 a.m. injustices: if your application breaks, your team carries it; if a shared component breaks, the operators carry that. Everyone carries their own layer.
Notice what the operators do not do. They are not the company’s mechanics for everything with a plug. Their job is the interfaces and the experience — the maps, the counters, the schedules — not every track and wire in the earth. Companies that forget this turn their platform team into a bottleneck with a helpdesk accent, and then wonder why nobody rides anymore.
A day in the operator’s chair, for contrast, because beginners usually imagine it is either heroic firefighting or endless meetings. Mostly it is neither. The morning is a round of checks: did the promises hold overnight, is anything trending towards its budget, are the upgrade schedules on time. Midday is improvement work — shaving a minute off the golden path, updating a catalog entry that drifted, pairing with a squad that wants something new. The pager interrupts occasionally, and when it does, the runbook answers before the adrenaline does. The best days are quiet ones, which took me a while to appreciate: in this line of work, boredom is the product shipped to users, and it is delivered on purpose.
Three Things to Explore This Week
Reading is lovely; poking is better. Three small expeditions, none needing permission.
- Find your golden paths and count them. Ask around: when a new project starts here, what does it copy? One maintained route beats five folk traditions, and simply drawing the current map tells you how much folklore you are running on.
- Look for an ownerless thing. Somewhere near you is a script, a server or a library that everybody uses and nobody owns. Find one. The mild dread you feel is the entire business case for PlatformOps, compressed into a single artifact.
- Read one real promise. Find any internal tool’s documentation and look for a commitment about how well it works. If you cannot find one, you have learned something about that tool; if you find one, check whether anyone could tell if it were kept. Either way, you now understand SLOs better than most slide decks teach.
Where to Go From the Station
If the commuting metaphor landed, treat yourself to the real thing with a ride through Kolkata’s metro corridors under the river — shared infrastructure as public art, and a reminder that platforms are oldest idea in cities. On the software side, two pieces from this site make good next stops: the full stack DevOps engineer roadmap from containers to orchestration, which covers the ground a platform operator is expected to know, and the core fundamentals of site reliability engineering for high-uptime services, where the promises and budgets above come from. When you want the source of it all, this Ops Atlas page on PlatformOps is the reference the whole subject defers to — slow read, hot chai, and the jargon never bothers you again.