Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: