[joshdick]

You need a certain level of maturity in devops practices before microservices are worth it.

Deploying an extra service to a kubernetes cluster, for example, is neither costly nor prone to breaking nor harder to monitor, etc.

I think the best practice nowadays is for a small startup to first write a monolith and then later split it out into microservices when they're ready.

[mattmanser]

To me it seems guaranteed that it is more expensive, regardless of if you use [insert trendy tool here].

There's always something that can break. More parts, more breakdowns. The services have to communicate, those communication channels are extra points of failure. What happens when one service inadvertently passes along something another one can't decode properly?

Ooops, wasn't expecting unicode! Ooops, wasn't expecting a long int! Oops, the JSON encoder we used in this service spits out stuff the JSON decoder in this one hates! Ooops, we upgraded a package in this service, but not that one! And on, and on.

And when something does inevitably break in the chain, there's the extra cost in debugging of figuring out which bit actually broke.

[eropple]

Agreed on all counts. The only time I recommend multiple services, rather than just load-balancing across monolithic applications, is when part of it's written on a different stack. As an example: I'm writing a gizmo with a Ruby core and a NodeJS ingest endpoint, and yeah, I'll probably run them on separate machines.

But here's the dirty secret: if you have a load balancer in front of your application, you already have a way to send requests for feature X to a separate pool of machines if that feature is a hot spot for you currently--and unless your application hits some really degenerate cases your base RAM load Simply Should Not be that high for your application in the first place, making the marginal cost and machine sizing floor less of an issue.

There are benefits to microservices in some environments, chiefly to reflect your org chart when your human protocols are breaking down. They tend to be marginal, and whether they outstrip the increased overhead of dealing with more moving parts (whether in your code or not; I quite like k8s but I still wouldn't want somebody less comfortable with it than I am running it in production, and plenty of those folks do!) is in many ways up in the air.