This feels very FUDy. It gives a bunch of examples of ways in which microservices can go wrong, without empirically examining those claims. It also excludes the

This feels very FUDy. It gives a bunch of examples of ways in which microservices can go wrong, without empirically examining those claims. It also excludes the middle: you can have "milliservices" (really, just service-oriented architecture) which do more than route a single endpoint, but still give flexibility and scaling. We are a young startup in the ML-service space, with about a dozen engineers + data scientists. Our stack is based on all docker containerized python. We have 6 "micro"-services (not sure at which point they become micro) but each plays their own role, with ~4-30 REST endpoints each. It's been fantastic, and none of us are particularly experienced with microservices. We run on AWS east but you can spin most of the stack up locally with docker-compose. I don't even need k8s, if we wanted, we could probably deploy a local cluster with docker swarm. - Fault isolation I can't talk in depth but we were able to handle the recent east-1 outage with only parts of the stack degraded, others stayed functional. Also, rollout is most likely when something will fail. Rolling back a services is way easier than disrupting the whole stack. - Eliminating the technology lock The ML container is a massive beast with all the usual heavy ML dependencies. None of the other containers need any of that. - Easier understanding Yep, definitely true in my experience. The API surface area is much smaller than the code under the hood, so it's easier to reason about the data flow in/out. - Faster deployment We can easily patch one service and roll it out, rolling out hotfixes to prod with no disruption in the time to run through the CI pipeline, or roll back a task spec, which is near-instant. - Scalability Emphatically so. The difference in scale between our least and most used service is over 100x. We could probably get away with making the user-facing backend a monolith (and in fact it's the most monolithic, has the most endpoints) but for data pipelining, micro/"milliservices" has been a dream. I don't even know how it would work as a monolith. As with everything in this field, it all depends on use-case and tradeoffs. If your services each handle roughly the same load, the independent scaling argument weakens. If your business logic is complex, tightly coupled, and fits on a single box, you'll waste a ton of cycles just communicating.