>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.
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.