Hacker News Reader

Comment by sz4kerto | Hacker News Reader

One thing that is usually overlooked: do microservices fit your team structure? A team who spends all day together can manage a monolith very well, synchronous releases (everything-at-once) are not a problem. If you don't need 24/7, then it's even better.

However, if you're a distributed team (maybe across timezones), quick discussions are difficult and 'costly', then microservices might worth the effort. Managing the deployment and operations is more difficult but sometimes much less coordination is needed when people communicate through APIs and not Skype and Slack.

View on HN

This. This is so often overlooked. Getting your architecture to roughly align with your team structure can do wonders, even if there's only a hallway dividing people. When a small team can iterate and evolve a chunk of code independent of anyone outside the team, it really unshackles them.

There are obviously patterns for doing this in monoliths (or, say, mobile clients - another type of monolith), but at some point you are bound by the dependencies inherent in a single runtime.

As others have already pointed out, you don't need microservices to achieve a good modularization of your code. Then have each team work on a different module, with clearly defined APIs between them. No need to separate them with HTTP calls.

The main benefit of microservices is that each team can deploy their service independently.

This is really useful to reduce the level of required of interaction (and pressure) between teams.

It may reduce development interaction, but it'll certainly turn testing into a nightmare.

If you have teams that communicate badly, you'll need people specialized in deployment and assigning issues to them. That's not a good situation anyway, but it's the less worse of them.

Again, this is something that is independent of microservices. If you have a modular mono codebase then one team can easily deploy commits that only touch their module.

I always though that microservices would be helpful if you had frequent transient programmers like contractors. Where you can onboard a new person faster by having them focus an a much smaller view of the system.

Reply on news.ycombinator.com