Hacker News Reader

Comment by dajonker | Hacker News Reader

The article does not address any of the technical complexities of microservices. If you use microservices you are developing a distributed computing system with a lot of technical challenges: additional network delay for each rpc, error propagation, consistency, etc. Addressing such technical challenges will often consume lots of time and requires a lot of knowledge that most developers do not have. It's a huge investment with a very high risk.

Furthermore this article fails to list any sensible alternatives. For example, if you have different rates of change you simply need a good separation of concerns with clearly defined boundaries and interfaces. You can do this equally well in a monolithic application, with none of the distributed computing issues.

View on HN

Agreed, microservices is literally a last resort in my book.

It's the thing you reach for when you're hiring a new team worth of developers every other week and can't avoid developer blockage any other way.

It's not even a good architecture for most of the things it ends up being used on.

There are very few problem sets that a microservices arch actually excells at.

Almost always a monolithic with some SOA and clear domain boundaries is going to work better for static/slow growth teams.

It might be exciting for some but I wouldn't wish it on anyone.

> Almost always a monolithic with some SOA and clear domain boundaries is going to work better for static/slow growth teams.

If it has “some SOA and clear domain boundaries” its not a monolith, even if it isn't decomposed so far as to be microservices.

“Right-sized services” isn't a catchy meme-spreading label, but it's probably the synthesis pointed to by microservices as the antithesis to monoliths.

Monolithic just means it can carry out all it's required functionality alone, i.e. it's [major] dependencies are internalized.

It doesn't say anything about not being able to be broken into modularized sections, services, or domain boundaries.

Neither does it reject any setups where satellite systems, micro or otherwise make use of the monolith programmatically or otherwise, hell it's kond of part of the definition of a monolith that it has multiple access points (i.e. cli, sdk, rest, rpc, events.)

> if you have different rates of change you simply need a good separation of concerns with clearly defined boundaries and interfaces. You can do this equally well in a monolithic application, with none of the distributed computing issues.

Exactly my thoughts - all of the benefits discussed are centred around source code management, specifically, things tied into the source code management which have poor separation of concerns: ungranular tests, ungranular CI...

This doesn't have anything to do with it being loosely coupled code that aught to have an API and then _maybe_, _potentially_ is amenable to being run as a separate service and is worth the cost of that complexity.

> requires a lot of knowledge that most developers do not have

Any resource you would recommend?

Reply on news.ycombinator.com