Hacker News new | ask | show | jobs
by shaneprrlt 2434 days ago
Interesting. One of the heavily marketed advantages of using micro-services is the ability for individual sub-systems to scale independently of one another, which is obviously a cost optimization that matters once you reach a certain scale, but is isolating components to dedicated teams the larger advantage?

The comment you replied to mentioned "startups that matter" that have significant scale and have 100+ engineers. I think if you're at that point it makes sense, but when you're finding product/market-fit and have 1-2 founding engineers working on a codebase, is it safe to assume micro-services are a premature optimization that unnecessarily add to a founding team's already heavy workload?

3 comments

Conway's law.

The only real reason for microservices is a big team.

Microservices should reflect your organisation.

A monolith is a small team.

Microservices and their infrastructure are shit to maintain on a small team. There is more overhead in that than monolithically designed software. The best use of microservices on a small team is for appropriate reusable services with low maintenance or almost no maintenance at all.
> One of the heavily marketed advantages of using micro-services is the ability for individual sub-systems to scale independently of one another, which is obviously a cost optimization that matters once you reach a certain scale, but is isolating components to dedicated teams the larger advantage?

It's not like this is a new and unknown opinion... It's been repeatedly pointed out for years now.

Conway's law just names the reasoning behind it ;)

https://en.m.wikipedia.org/wiki/Conway%27s_law

For sure, I was just hoping to get some clarification. I'm by no means a micro-service expert.
You can have diferent components scale differently in a monolith.