Hacker News Reader

Comment by BurningFrog | Hacker News Reader

The only good argument I know for microservices is organizational:

When each team is responsible for one microservice, they can manage that with much less painful coordination with other teams.

View on HN

My experience has been the total opposite. When each team is responsible for a service then to build anything complex you need to have meetings with stakeholders from a bunch of teams. So much time wasted on coordination compared to when working on a monolith. There you usually just need to get buyin from the platform team plus at most one other team. And that assuming you can't just build it and open s pull request which is often the case.

I also definitely prefer a monolith, if possible!

Yes, they can do their own thing without having to worry about their pesky users. In reality, this means that when you consume somebody else’s service and you need something changed, you have the choice to either hack up your own thing or somehow convince the service team to put your needed changes on the backlog. From my experience you often end up with everybody implementing some version of what the official service is supposed to do because the service can’t be bothered to make the changes within a reasonable time frame.

I would do micro services only once the requirements are very stable and there is a clear need for scalability. Microservice first architecture is a recipe for complexity.

I think the cross team dynamics you describe works the same way in a monolith architecture.

One difference/advantage in a monolith is that you don't have to worry which version the other microservices are on.

And TBF this is a great reason for why microservices.

That's the why, but the implication is that it's possibly not the most efficient way to build the system, and that we can't do better because we're no good at communication.

Conway's law

That's a big part of it!

Reply on news.ycombinator.com