On: Microservices: Why Are We Doing This?

[jjnoakes]

I'm not for or against microservices, but that seems like quite the cherry-picked list. There are arguments on the other side too, such as...

If we think about the easiest way to swap out pieces of functionality, that is by using well-defined interfaces, low coupling, and separation of concerns.

If we think about the easiest way to scale parts of the whole independently, that is by similar mechanisms.

If we think about the easiest way to build in fault-tolerance, that is by distributing work across failure points.

And so on...

[hackerfromthefu → jjnoakes]

But well-defined interfaces are not specific to microservices (ms). Low coupling, high cohesion, separation of concerns and well defined interfaces are simply system architecture. Which is easier to work with without the infrastructure overhead of loads of semi-independent ms. Ms is a net loss here because your complexity budget is consumed by the infrastructure instead of the system architecture.

Fault tolerance again is largely orthagonal to ms. It's a matter or system architecture, see the point above. e.g. A common situation where service one depends on availability from service two, having them as seperate ms doesn't help, what helps is architectural design to keep service two useful somehow regardless, and this is orthagonal to if the services are in process or done as ms.

Scaling is a whole other discussion, and microservices can have good impact here, but so can other techniques.

[hu3 → jjnoakes]

> If we think about the easiest way to swap out pieces of functionality, that is by using well-defined interfaces, low coupling, and separation of concerns.

Microservices don't enforce good practices and monoliths don't prevent them either.

[jjnoakes → hu3]

Right, but some of those desirable system properties are much easier and lower friction in microservices.

And others in monoliths.

Each has its pros and cons.