[bhuber]

Most of the conversation so far has focused on the development benefits of microservices (decoupling deployments, less coordination between teams, etc). Small teams don't really have this problem, but there are other benefits to microservices. One of the biggest is scaling heterogeneous compute resources.

Suppose, for example, your webapp backend has to do some very expensive ML GPU processing for 1% of your incoming traffic. If you deploy your backend as a monolith, every single one of your backend nodes has to be an expensive GPU node, and as your normal traffic increases, you have to scale using GPU nodes regardless of whether you actually need more GPU compute power for your ML traffic.

If you instead deploy the ML logic as a separate service, it can be hosted on GPU nodes, while the rest of your logic is hosted on much cheaper regular compute nodes, and both can be scaled separately.

Availability is another good example. Suppose you have some API endpoints that are both far more compute intensive than the rest of your app, but also less essential. If you deploy these as a separate service, a traffic surge to the expensive endpoints will slow them down due to resource starvation (at least until autoscaling catches up), but the rest of your app will be unaffected.

[jeremyjh]

So sure, maybe make the ML model a separate service, but you don't really have the same driver for other services; state-less server processes tend to need the same type of resources only in different amounts, and you don't really gain anything by splitting your work load based on the words used in your domain description.

Real-world monoliths often do have some supporting services or partner services that they interact with. That doesn't mean you need a "micro-service architecture" in order to scale your workload.

[midrus]

Well, no. You can deploy the same monolith to two different clusters with different resource configurations.

In fact, this is what you usually do with "worker" nodes that do background jobs.

And you can always have feature flags/environment variables to disable everything you don't need in a given cluster.

[bhuber]

I'm not saying you have to use microservices to solve these problems, just that they are potential reasons why you might want to, even with a small team of developers. I would also argue that if you're deploying the same codebase in two different places and having it execute completely different code paths, you're effectively running two separate services. Whether or not you decide to deploy a bunch of dead code (i.e. the parts of your monolith that belong to the "service" running on the other cluster) along with them doesn't change how they logically interact.