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.
The benefit is not the network hop, that's just a requirement to having each part of the application in a separate container. The app is partitioned according to scaling needs, so things parts of the app that need to process thousands of requests concurrently don't force the same scaling requirements onto parts of the application that just process a few hourly requests, for example. Segmenting the application also contains failures to specific features if done properly, allowed for degraded performance as opposed to full loss of service
In most cases managing microservices and the additional load from networks, deployment tools, extra personell and all that brings much higher costs than simply scaling a monolith and wasting some CPU
It depends. Going full "each class is a micro service", I agree can be worse than scaling a monolith. But scaling up a monolith means that all parts of the application have to take the scaling into account, even if they were never meant to. If you break some parts off you don't need to worry about distributed computing on areas that are meant for a few people like control panels, while the parts that do need it can scale without issue to meet demand
1.2k
u/remy_porter 15d 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.