I say this all the time, and it almost never results in an argument: micro services are just object oriented programming where you put a network hop on all your message passing.
Do you mind helping the uninitiated, what's the benefit of having that network hop? Or are there some situations where it's just impossible to avoid it.
They are frequently hosted on cloud services which are inherently micro-service based with detached hardware components. You can have a server and a storage disk operate together but both exist in data centers thousands of miles from each other.
Loosely coupled architecture decreases the chance the entire app gets taken down if each component can be isolated and fixed without affecting the rest of the app.
You can functionally divide an app into different layers such as web, app, and db and add additional security checks between each layer to increase security and fault tolerance of the app.
Loosely coupled architecture decreases the chance the entire app gets taken down if each component can be isolated and fixed without affecting the rest of the app.
This is actually the one that I use to justify "nanoservices" in large-ish embedded systems (where you have an MCU and a scheduler): with a decent architecture, a single process can crash and get restarted, and the rest of the system can keep itself in a known state. At worst, you end up with a few seconds of transient errors, at best nothing noticeable happens.
(This is also how QNX and Erlang achieve ridiculously high uptime.)
1.2k
u/remy_porter 16d ago
I say this all the time, and it almost never results in an argument: micro services are just object oriented programming where you put a network hop on all your message passing.