Hacker News Reader

Comment by maxxxxx | Hacker News Reader

A lot of people say that microservices are often a way to deal with lack of communication between teams. It's probably better to improve communication than creating microservices which later on create another set of communication problems.

View on HN

As organizations scale they find that teams just can't communicate enough (while also programming) to solve these problems through human interaction. That's kind of OK when it is just one or two teams that have the problem and rotate through devs for the communication responsibilities. But when most teams starts doing it, feature work will slow down too much.

Contracts (api, documentation for those apis, documented processes, etc.) are important to scale and greatly reduce communication load. Microservices aren't required to make that happen, but they sure help.

Communication is expensive and improving it generally leads to increased engineer unhappiness. Engineers don't want to be in endless meetings, have to follow endless email threads, have endless planning meetings for any change, etc. If they wanted those thing they'd have moved into management of some kind.

Refactoring a microservices architecture seems to lead to even more frustrating meetings.

Wide scale refactoring is a rare occurrence and a somewhat constrained problem. The whole point of micro services is most changes are limited and constrained. In monoliths you have none of that so everything require mass communication and not just wide scale refactoring.

Indeed, instead projects just fall rather than get refactored.

Reply on news.ycombinator.com