Hacker News new | ask | show | jobs
by giaour 1607 days ago
> Microservices allow your team to have control over the full stack they require to deliver a feature.

This is honestly pretty rare, at least in my experience. What I have seen is that organizations will buy in to the microservices hype, then dictate to their teams what stacks, deployment paradigms, etc. (sometimes even down to the sprint cadence) are acceptable.

3 comments

My experience is the opposite of yours. Teams I've worked with get massive freedom to implement their services with any (reasonable) language + framework: Rust, Python, Java, Go, C++, C#, and so on.

Seems like an organizational decision

My experience was mostly at small companies with dedicated ops personnel and in government. I worked with a large number of teams that had been chartered with implementing microservices within government agencies, and every single one of them was told what stack they were going to use, either by agency leadership or by infosec personnel.

There was slightly more freedom of choice when I was at AWS, but compliance requirements and tooling support basically strongly encouraged everyone to adopt a standardized stack.

All of which is to say, I get that what you're describing is in theory what microservices are supposed to allow, but I have yet to see it actually work that way in practice.

Honestly, "every team in the same company having full control over what kind of stack they want to use" sounds like a nightmare. Soon you have services running in Python, C++, Java, Go, and node.js, with five different internal libraries talking to MySQL, all slightly incompatible with each other. (Let's hope someone doesn't start up a PostgreSQL server.)
or even worse: the teams DO have full control over their stack and now you have dozens or more different technology stacks at the company and expertise isn't shared between them
Extra fun when you're on-call for one of those stacks that only 2 people in the company have experience with, and you can't get hold of either of them.