1. Yes, if you have an application that works this way you will have to manage your deployment to compensate. But you can use configuration as feature flags to keep a monolith but when you deploy it to X servers you enable one feature set and to Y servers you enable another. So you get the benefits of developing in a monolith but the isolation of microservices.
2. See #1, but also use proper error handling. It's been a while since I've seen a single request take down the whole app.
I wonder if this is why my issue is with the terminology, what you have described in 1 to me is a microservice architecture. I currently have a monorepo deploying microservices in order to get the benefits of developing in a monolith but with the isolation of microservices, but I do consider it a microservice architecture on the whole.
There are definitely ways each approach can approximate the benefits of the other:
- Microservices can be deployed as processes on the same machine and communicate over the loopback interface or domain sockets without much network-related risk. This is still more complicated than function calls, and I wouldn't quite call it a monolith.
- Monoliths can have traffic for different endpoints partitioned over different deployment groups. So the behavior of one endpoint can be changed independent of the others. But a module deep in the stack, potentially consumed by many endpoints, cannot be deployed on its own in a way that affects all its consumers. So I wouldn't quite call this microservices.
Nah, it can be one service just deployed with different configuration. Or as another commenter said, a different binary based on compilation flags/config.
1. Yes, if you have an application that works this way you will have to manage your deployment to compensate. But you can use configuration as feature flags to keep a monolith but when you deploy it to X servers you enable one feature set and to Y servers you enable another. So you get the benefits of developing in a monolith but the isolation of microservices.
2. See #1, but also use proper error handling. It's been a while since I've seen a single request take down the whole app.