Take the Kolkata metro at rush hour and you are touching a platform in every sense \u2014 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 \u2014 pipelines, servers, logins, deployments \u2014 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.<\/p>\n
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 \u2014 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.<\/p>\n
What makes it interesting \u2014 and occasionally awkward \u2014 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.<\/p>\n
Seven terms cover most conversations. Friendly definitions, no exam at the end.<\/p>\n
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 \u2014 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 \u2014 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 \u2014 which is the entire test of whether a platform is being operated or merely possessed.<\/p>\n
Three groups orbit any internal platform, and knowing which you are saves everyone confusion. The operators<\/strong> run it \u2014 upgrading, measuring, answering pages, and doing the quiet writing that keeps the catalog honest. The users<\/strong> 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<\/strong> \u2014 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.<\/p>\n Notice what the operators do not<\/em> do. They are not the company’s mechanics for everything with a plug. Their job is the interfaces and the experience \u2014 the maps, the counters, the schedules \u2014 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.<\/p>\n 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 \u2014 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.<\/p>\n Reading is lovely; poking is better. Three small expeditions, none needing permission.<\/p>\n If the commuting metaphor landed, treat yourself to the real thing with a ride through Kolkata’s metro corridors under the river<\/a> \u2014 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<\/a>, which covers the ground a platform operator is expected to know, and the core fundamentals of site reliability engineering for high-uptime services<\/a>, where the promises and budgets above come from. When you want the source of it all, this Ops Atlas page on PlatformOps<\/a> is the reference the whole subject defers to \u2014 slow read, hot chai, and the jargon never bothers you again.<\/p>\n","protected":false},"excerpt":{"rendered":" A friendly beginner’s tour of PlatformOps using the metro as the guide: seven usable glossary terms, who does what, and three things to poke at.<\/p>\n","protected":false},"author":6,"featured_media":627,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[496],"tags":[],"class_list":["post-626","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts\/626","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/comments?post=626"}],"version-history":[{"count":1,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts\/626\/revisions"}],"predecessor-version":[{"id":679,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts\/626\/revisions\/679"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/media\/627"}],"wp:attachment":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/media?parent=626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/categories?post=626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/tags?post=626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Three Things to Explore This Week<\/h2>\n
\n
Where to Go From the Station<\/h2>\n