You run another instance of it.
I see how it works, and I completely agree that to start out, so going from PoC to first business implementation, a monolith is the way to go (unless the goal from the start is 100 million concurrent users I guess).
But after that initial phase, does it really matter if you use one or the other? You can overengineer both and make them a timesink, or you can keep both simple. I do agree on things like network latency adding up, but being able to completely isolate business logic seems like a nice gain. But Im also not talking about real micro level (i.e. auth login and registration being different services), but more macro (i.e. security is one, printing another(pdf,csv,word etc), BI another one
Not saying it can't handle everything as well. Just saying the modularity of microservices makes it, in my pov, easier to handle large complex real time systems.
Maybe that's also something that comes with experience - as a rather "newish" guy (professional SE, so one level above Jr), it makes it easier to work on our project.
The routing of just load balancing is much simpler than the routing of exectution jumping between many microservices.
>You can overengineer both and make them a timesink
I agree, but a microservice architecture starts you out at a higher complexity.
>but being able to completely isolate business logic seems like a nice gain
That can also be done by having that business logic live in its own library.
Not necessarily at all, i.e. using GRPC it's all self discovered.
> I agree, but a microservice architecture starts you out at a higher complexity.
Definitely
> That can also be done by having that business logic live in its own library.
That's true, having it in it's own library is certainly a possibility -> but then it's also not that far off micro/macro services anyway, except you deploy it as one piece. And basically this is my argument: If you're having it all as libraries, and you all work in a mono repo anyway, the only real difference between micro/mono is the deployment, and that with micro you _could_ independently scale up whatever the current bottleneck is, which we've used plenty of times