undefined | Better HN

0 pointssimplotek3y ago0 comments

> I think the general consensus is that the most-root cause for why cloud infrastructure and microservice architectures matter is more People, less Technology.

Indeed the main selling point of microservices is People, more specifically how to set hard boundaries on responsibilities and accountability while ensuring independent decision-making.

Another important selling point of microservices is flexibility. It's trivial to put together an entirely new service from scratch, written in whatever technology crosses your mind. With microservices you don't even need access to a repo.

0 comments

4 comments · 1 top-level

margorczynski3y ago· 3 in thread

> set hard boundaries on responsibilities and accountability while ensuring independent decision-making

This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly.

And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. And microservices if you want them can be run on a single machine, you don't need "the cloud" or multiple computers in general to run a bunch of REST apps if your single instance is powerful enough.

And for most web apps it is with the currently available hardware.

simplotekOP3y ago

> This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly.

I'm not sure you got the point. The need to provide interfaces and establish contracts and pledge SLAs is irrelevant and a non-issue. Naturally, your goal is to have a perfect uptime and never break interfaces, just like your goal when working on a monolith is to not add broken code that crashes the service.

The whole point of microservices is that you are entirely free to make any decision regarding the things you own, and your only constraint is the interfaces you provide and consume, and SLAs. From those interfaces inward, you are totally free to make any decision you think is best without having to bother about anyone else's opinions and technical choices and tastes and permissions. You can run one service behind your interface or hundreds. As long as your interfaces are up, you can do whatever you like. That greatly simplifies your problem domain.

> And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application.

No, no you can't. Think about it for a second: can you pick your software stack? Can you pick what dependencies you adopt? Can you rewrite your code in any other language? Etc etc etc. Your hands are tied left and right.

time0ut3y ago

An even more important consideration is being able to release features (and even more importantly roll back) in isolation when the team is ready. The more teams contributing to a monolith, the harder this becomes. I am sure someone here has seen it done with a 10 million line monolith built by 100 geographically distributed teams, but I suspect that is exceedingly rare.

Microservices aren’t a silver bullet for this, of course. They can be part of a winning recipe though.

danjac3y ago

While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole that has to maintain different languages and frameworks, when that developer moves on and now they have to find or hire someone else to keep that service running.

2 more replies

j / k navigate · click thread line to collapse