My opinion here is highly biased, since I developed it while working at Netflix, but I think you're dismissing a lot of non-technical benefits of microservices.

I'll start off by saying that I agree with you in that when it comes to small teams, microservices is probably not the best option, as it adds additional unnecessary complexity.

But one of the best benefits I saw of microservices was that it allows small teams to work together mostly independently. It meant that each group could run in whatever way was best for the four of five folks in the group.

If the auth group really thought Go was the best solution for their problem, then they could do that. If the API team wanted to do a deployment every two weeks on Wednesday, they could do that. If the tools team wanted to deploy on every checkin, they could do that.

It meant that the 1000 engineers didn't have to all agree on a particular language, development method, or development cadence. Each team could do whatever worked best for that team, and was most in control of their own success or failure.

wasn't that what the reply said, unless you have 1000 engineers, you don't need it?

The debate is where that threshold is. 5 engineers, no. 1000 engineers, yes. But most engineering orgs are in between. I suspect microservices start to make a lot of sense at around 50 individual contributors. At that point you've got 10 pizza sized teams and making decisions that affect all of those teams is taking more time than building out the infrastructure needed for them to work independently.

You may have 5 engineers today, but what if you have 1000 engineers tomorrow? Do you start from scratch, or do you use microservices now in case you do grow in size?

some of the worse evils I've seen in software development is a team of 5 trying to act as if they were a team of 1000. There are inherent costs in microservices, they don't come without tradeoffs. Those tradeoffs seem uncessary for a 5 engineer team (sometimes it makes sense). Not only that, it's very unlikely you are going to predict correctly how your product will evolve by the time you get to 1000 so even if you did microservices, they probablly won't be right for the future evolved product which will likely include new innovations you can't yet design for.

All you do, as a team of 5, is write nice modular composable well tested code. That way your code base will adapt as you grow. It's quite likely going from 5 to 1000 people is going to involve a number of large architectural shifts during the life of the product.

I think this largely describes the considerations of "enterprise architecture" (versus dude-builds-an-app-with-Rails).

Different communication coordination patterns and levels of complexity.

Look at specifics to determine appropriate solutions (which will still have particular benefits and drawbacks).

> Most services complain of complexity from "the monolith" but upon further inspection, what we're usually see is poor architectural layout. These teams feel that microservices solve this, but really just make the entire backend more complicated.

I agree with this, but there's another very important driver for microservices - the presence of multiple customers, each with different ideas as to what makes up the right stack - i.e. SaaS.

In our domain (HR software) microservices make good sense because they allow each customer to compose their own stack, with individual bits coming from us or from third party vendors.

Without this need, I don't think I'd recommend most normal scale companies (Netflix et al excluded obviously) go microservices.