u/Complete_Sample_3149

Genuinely curious how much ABAC adoption is actually happening in practice versus how much airtime it gets in conference talks and vendor blogs.

RBAC is still what most access-control implementations I encounter actually run: roles mapped to permissions, reasonably well understood, tooling support everywhere. ABAC gets talked about as the more "correct" model for anything with real complexity (dynamic attributes, context-aware policy), but I don't see nearly as many real production write-ups of it compared to how often it comes up as a talking point.

A few things I'm trying to understand better from people who've actually shipped one or the other at scale:

●      For teams that moved to ABAC: was it a full replacement of RBAC, or a hybrid where roles handle the coarse filter and attributes refine within it? My hunch is hybrid is far more common than a clean full migration, but curious if that matches reality.

●      What was the actual trigger? Compliance requirement, a specific incident from stale role-based access, or just planned ahead of scale problems?

●      For anyone who evaluated ABAC and decided against it: what made RBAC the better call for your situation? Genuinely as interested in the "stayed with RBAC on purpose" stories as the migration stories.

Also curious about tooling maturity here specifically: my impression is RBAC has broad, boring, well-tested support pretty much everywhere, while ABAC policy engines (OPA and similar) still require meaningfully more implementation effort to get right. Is that gap closing, or still pretty real in 2026?

I've been in enough job specs, conference talks, and internal debates over the last year to notice a pattern: half the "Platform Engineer" postings I read are describing exactly what a senior DevOps Engineer already did five years ago. The other half are describing something genuinely different: a dedicated internal product team building paved roads and self-service tooling for other engineers, with its own roadmap and its own users (the org's own devs).

I don't think this is just semantics, but I also don't think the distinction is as clean as the conference talks make it sound. Genuine question for people who've actually sat in both seats, not just read the thinkpieces:

Where do you draw the line? A few candidate answers I keep going back and forth on:

●      DevOps is a set of practices/culture (CI/CD, IaC, shared ownership of ops); platform engineering is a specific team/role that productizes those practices for internal consumers. Under this framing, "platform engineer" isn't a rebrand. It's what you call the person once the team gets big enough to need a dedicated builder instead of everyone doing their own DevOps.

●      Platform engineering is what happens when "you build it, you run it" quietly failed at scale, and someone had to become the paved-road team so product engineers could stop reinventing Terraform modules badly.

●      It's mostly branding, and a lot of "Platform Engineer" postings are just "Senior DevOps Engineer, but the title tests better in this hiring market."

What's made me second-guess my own take: at companies under maybe 40-50 engineers, I've basically never seen a real separation. It's the same 2-3 people doing both, and "platform engineering" there is just a slide in a deck, not an org reality. It seems to only become a real, distinct discipline somewhere past that scale, and I'm not sure where.

Curious where people who've actually lived through the transition, either building a platform team from scratch or watching DevOps quietly get relabeled, land on this. Real difference, or mostly vibes and a better-selling job title?

Ours was a cron job.

Somebody set up auto-renewal years ago on a box that got decommissioned during a migration. Nobody moved the cron job, because nobody remembered it existed.

Cert expired on a random Friday. We found out from a customer support ticket instead of monitoring, which is its own kind of embarrassing. Ninety minutes of browser warnings before anyone connected the dots.

Fix took ten minutes. The actual problem was that no alert existed for "this cron job silently stopped running."

Curious whether other people hit the same orphaned-box thing or something dumber.

I did a dumb exercise last week: sat down and wrote out every tool that touches a single deploy on my team, start to finish. Not “tools we have licenses for”, just the ones actually in the critical path of getting one change into production.

Landed on 14.

Source control. The CI runner. A separate container registry. An image scanner that runs after the registry push. A secrets manager. The Kubernetes dashboard we check for rollout status. A log aggregator. A separate APM/tracing tool, because the logs don't show latency well on their own. An alerting tool that is, confusingly, different from the paging tool. A DNS/cert dashboard. A cost/billing dashboard nobody opens until the invoice is a surprise. The ticketing system for the actual incident. And a chatops bot that glues some of this together, badly.

None of these were wrong choices individually. Each one was probably the right call in isolation, at the time it got added. But nobody ever sat down and asked whether this thing talks to the other 13. It's less a stack and more a pile that happens to work most days.

What's bugging me isn't the number itself. It's that almost nobody on the team could tell you the number without doing this exercise. We just live inside it. New hires take weeks just to learn where to look when something breaks, and that's before they've learned what any individual tool actually does.

So, genuinely curious: if you did this exercise on your own team, what would your number be? And more interesting to me: which of your 10+ tools do you think is actually load-bearing, versus which one is just... there, inherited from a decision three engineers ago that nobody wants to be the one to rip out?

Not fishing for “just consolidate everything into one platform” as the answer. I don't think that's automatically true either. Sometimes the sprawl is a symptom of real, unavoidable complexity, not laziness. More curious whether other teams' numbers look like mine, and whether anyone's actually fixed this in a way that stuck.