5 ms·
Nobody said anything about 1 VM per microservice. You're using the term "service" in a way I did not intend (and which is a carryover from other kinds of servic
by DanielBMarkham 11y ago
Nobody said anything about 1 VM per microservice. You're using the term "service" in a way I did not intend (and which is a carryover from other kinds of services)
This is illustrative of the point I was making.
One of the big benefits of microservices is the total decoupling of the code from the underlying hardware. Things are glued together by Ops, not by code. So you might have all the microservices in one VM -- or spread copies of one critical microservice across a thousand vms. It's all configurable.
- Thaxll 11y agoI don't understand properly the term micro service if services aren't separated in a "network" way.
- bobjob 11y agoYou have an entire A-Class network(127.0.0.0) within a single VM. That makes ~2^24 possible adresses and 2^16 ports. Isn't that enough of a network?
- Thaxll 11y agoit's more like "Why would you put multiple process on the same instance instead of just using a monolith app, the overhead for IPC / network isn't worth it if you put every process on the same machine"
- oldmanjay 11y agoThe abstract notion of a service has nothing to do with an execution model. It simply means a well defined interface to some meaningful unit of functionality. Properly designed, the execution model is orthogonal and the service itself doesn't care if it's invoked in-process or not. It delegates that to some other manager, which probably has a service interface of its own. It's about sane abstract system boundaries, not mapping to real world facilities.