3/8/2026 at 8:40:29 AM
> In that decade, this company was behind the curveI like to think there is no curve only fashion. I've seen company's that were so behind that they managed to avoid adopting disasters like microservices etc. I've seen companies ahead of the curve go from monolith to microservices back to monolith.
Also funny that the ops team is now back just rebranded as the platform team.
Plus ça change.
by andersmurphy
3/8/2026 at 3:19:48 PM
Pretty much. Using "old" tech (assuming its maintained) is not "being behind" or "having technical debt". If stuff works and there is no meaningful gains from switching, you're doing engineering correctly.It might be seen boring. Brakes in my bike are boring. I like them that way
by PunchyHamster
3/8/2026 at 12:49:54 PM
> I like to think there is no curve only fashion.Exactly! For instance, we had pull-based monitoring 20 years ago (Zabbix et al), but we abandoned it because it scaled poorly, favoring push-based agents (for InfluxDB, KairosDB etc). Now Prometheus is all the rage, yet we’re hitting the exact same scaling walls these systems had before. In a few years, we’ll rediscover push agents and call them the best thing since sliced bread.
by dig1
3/8/2026 at 1:25:30 PM
Yup, same way people are starting to realise/remember having your compute next to your data is a good idea (maybe lambdas/serverless are not so hot because they get in the way of this).Spacetimedb, convex, etc are basically the revenge of stored procedure.
by andersmurphy
3/8/2026 at 5:30:53 PM
If we’re trading war stories, one of my first software jobs was developing an electronic medical records system. We didn’t use VCS. At the end of the day/task, you send the director the file you’ve changed with a txt file of which lines were changed.The director made sure things compiled, then we would drive down to the hospitals and copy the dlls into each PC one by one. And because hospitals can’t shut down their computers willy nilly, we could only deploy on weekends or public holidays. Not weekday nights because the directors have to be home for the kids.
That was in 2014. They’ve worked that way since the late 90s and ‘no point changing what works’.
by SenHeng
3/9/2026 at 1:29:34 AM
You are absolutely right. It’s frustrating to see otherwise smart people acting like lemmings, blindly walking off the cliff.by deterministic
3/8/2026 at 12:22:13 PM
If you read the article - or know anything about platform engineering - it should be clear that a platform team is certainly not just a rebranded ops team. The success criteria are entirely different, just for a start. Most ops teams don’t have the skillset to be a credible platform team.by antonvs
3/8/2026 at 1:20:41 PM
Yeah that's a good point ops teams don't over engineer or do CV driven development like platform teams.by andersmurphy
3/8/2026 at 10:38:41 PM
That's a cute hot take, but it most likely comes from not having come across an environment where this is needed, so instead you may have seen people cosplaying as much bigger companies.A true platform team is responsible for implementing and maintaining an internal platform for automated deployment and operation of a company's software. The platform is essentially a product, where the customers are developers and anyone else who has a stake in the deployment, maintenance, and operation of the company's software - including the ops team! I.e. strictly speaking, an ops team is a customer of the platform built by the platform team.
Done properly, this automates away a lot of what ops teams and "devops teams" do, because it allows fully automated self-service by developers. Developers should be able to create new environments and deploy new and existing services without opening tickets to some other team. Those environments and services are fully compliant out of the box with company policies and architectural decisions.
People sometimes think that this means that if you let devs submit PRs for terraform files and, say, k8s configs, that that's a "platform". But no, that's just shifting that kind of work to developers, it's not automating it. Under the hood, a platform might use those tools, but if deployment of environments and services requires interacting directly with generic tools that can be configured however a developer wants, that's not an internal platform.
by antonvs