Microservices are a tax your startup probably can't afford

1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either.

That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case.

You can have a distributed system of multiple services of a decent size.

I know "services of a decent size" isn't as catchy as "go for one huge monolith!" or "microservices!" but that's the sensible way to approach things.

One place I worked at got sold on microservices by Thoughtworks, along with a change to Java as the main language to be used.

As one would expect, they made bank from their consulting endeavor and rode off into the sunset while the rest of us wasted several years of our careers rewriting ugly but functional monolithic code into distributed Java based microservices. We could have been working on features and product but essentially were justifying a grift, adding new and novel bugs as we rebuilt stable APIs from scratch.

The company went under not long after the project was abandoned. Nobody, of course, would be held to account for it. I will no longer touch a tech consultancy like TW with a 10 foot barge pole.

Microservices are a fad.

Every service boundary you have to cross is a point of friction and a potential source of bugs and issues so by having more microservices you just have more than go wrong, by definition.

A service needs to maintain an interface for compatibility reasons. Each microservice needs to do that and do integration testing with every service they interact with. If you can't deploy a microservice without also updating all its dependencies then you don't have an independent service at all. You just have a more complicated deployment with more bugs.

The real problem you're trying to solve is deployment. If a given service takes 10 minutes to restart, then you have a problem. Ideally that should be seconds. But more ideally, you should be able to drain traffic from it then replace it however long it takes and then slowly roll it out checking for canary changes. Even more ideally, this should be largely automated.

Another factor: build times. If a service takes an hour to compile, that's going to be a huge impediment to development speed. What you need is a build system that caches hermetic artifacts so this rarely happens.

With all that above, you end up with what Google has: distributed builds, automated deployment and large, monolithic services.

In 2016-17, I was involved with a rather large mictoservice-heavy rewrite project tha didn't go particularly well. The main reason was that microservices were actually a good fit for the _planned_ organisational structure, but not for the one that was eventually put in place. When you go from 4 vertically integrated independent teams to 2 backend devs, 2 frontend devs, and 1 "devops" without stopping 5 minutes to rethink the architecture, of course shit will happen.

Years ago I attended a local meetup where the CTO of a local startup gave a presentation on their, mostly successful, microservice rollout.

In the Q&A after ward, another local startup CTO asked about problems their company was having with their microservices.

The successful CTO asked two questions: "How big is your microservices tooling team?" and "How big is your Dev Ops Team?"

His point was, if you're development team is not big enough to afford dedicated teams to tooling and dev ops, it's not big enough to afford microservices.