[duaneb]

> technical justification for this new architectural mold

The technical justification is easier than the cultural or managerial justification: you can make more granular technical decisions by splitting and merging code across services and servers. This is very powerful.

Microservices aren't going away—they are the core of a successful, scalable distributed system. The hype surrounding the term is definitely loaded with cultural and managerial implications that are rarely addressed, however, and I hope that changes soon.

[crdoconnor]

>you can make more granular technical decisions by splitting and merging code across services

"granular technical decisions" -- can you please give an example of a 'granular' technical decision?

>Microservices aren't going away—they are the core of a successful, scalable distributed system.

It would be more accurate to say that microservices is what you call a system that you made distributed even though you didn't actually have to make it distributed.

[duaneb]

> can you please give an example of a 'granular' technical decision?

Whether or not to upgrade an underlying library for a service. How many nodes to give a cluster, what features to prioritize on that node. You can do this with a monolithic codebase but you move slowwww if upgrading one unit implies upgrading others. With microservices, you could even write every service in an entirely different language.

> It would be more accurate to say that microservices is what you call a system that you made distributed even though you didn't actually have to make it distributed.

You don't have to make anything distributed. I think it's more apt to draw an analogy to the Actor paradigm—microserves are discrete actors in a distributed system and can be analyzed independently from the other actors.

All the microservices movement has really brought to the table is "no, you don't need to distribute your work to benefit from the looser coupling". If you're seeing anything more, I suspect there would be significant disagreement in the movement about it.

[crdoconnor]

>Whether or not to upgrade an underlying library for a service. How many nodes to give a cluster, what features to prioritize on that node. You can do this with a monolithic codebase

Right. And it's no harder, either.

>you move slowwww if upgrading one unit implies upgrading others.

Absolutely not. You don't have to have microservices to have a set of loosely coupled libraries.

A reliable automated test suite is what is going to make library upgrades less painful for you, not 1,000 new, brittle serialization/deserialization layers.

>With microservices, you could even write every service in an entirely different language.

Really, really bad idea. Debugging a call stack is an order of magnitude easier than tracing a failure across a set of multiple services which is an order of magnitude easier than tracing a failure across a set of services written in different languages.

>You don't have to make anything distributed.

Some systems do have to be distributed for the ability to call on more resources than one machine can realistically provide, to deal with the inherent unreliability of individual servers, or (sometimes) for legal reasons. There are a great number of problems that you create for yourself if you do this, though, which is why avoiding it where possible and minimizing the pain of doing it is the architecturally sane thing to do.

"Microservices" is the 'paradigm' that you should create this headaches for yourself because Martin Fowler Told You To and because the idea that separation of concerns and loosely coupled libraries won't happen unless you do the technical equivalent of self-flagellation. The unfortunate reality is that it is just as easy to write tightly coupled code with microservices, it just creates a bigger headache for you when you do.

>All the microservices movement has really brought to the table is "no, you don't need to distribute your work to benefit from the looser coupling".

It seems to me that the microservices movement implies the direct opposite of this.