This is absolutely right in my experience.

Microservices are all about scaling development agility in exchange for increased technical overhead.

In many cases this tradeoff is atrocious. If you can say "we can easily take on (large feature XXX) and deliver that", microservices are all pain and no gain.

Where they really start feeling good is when your "two week sprints" turn into about two days of available dev work because the remaining time is spent regression testing your changes and trying to keep the build from breaking because of tests you didn't touch failing (spooky action at a distance is real and it hurts). A clear API contract that both sides of the fence can develop against means that you can keep making progress.

At least until it's time to integrate against the real world, not your mock ;-)

I think there are plenty of examples of monolithic architectures that also have huge technical overhead, builds breaking for unrelated changes, huge amounts of regression testing, not to mention the build times...

Microservices can be a great pattern to deliver quickly _and_ maintain high availability/low technical overhead, that's their point. I think the problem arises when developers try to over-optimize or over-engineer a system, or they want to get promoted so they write a new service, ending up with huge entangled webs like in the sketch.

Individuals and interactions over processes and tools, every time

> I think there are plenty of examples of monolithic architectures that also have huge technical overhead, builds breaking for unrelated changes, huge amounts of regression testing, not to mention the build times...

Yes – I was talking about those same monolithic architectures in that comment ;-)

Conway's Law applies here [1]. Poor architectural design can be rooted to how managers organize the team. If you want to see the architecture designed a certain way, organize the team structure along that line and the architecture desired will naturally emerge from the teams. If you have a misalignment of teams and architecture, you're always bound to hit friction along the way.

As you move up in leadership, the tool that you have is organizational design. Doing it right and you have a highly efficient org. Do it wrong, and you'll constantly hit roadblocks.

[1] https://en.wikipedia.org/wiki/Conway%27s_law

I think it often can, but I've seen plenty of teams where things were split into microservices despite only having 4-5 developers in relatively close collaboration, mostly due to trend-following and it being the "right" way to architect software.

...ease of dividing people into smaller teams where a team could focus on a single objective without worrying about rest of the company.

How's that working out for you?

In most cases, and I'm talking right up to the scale of very large enterprises[1] you don't need that much complexity to scale technically and, if you avoid the complexity, you don't need that many people either.

And I don't think you can ever afford to be myopic if you want to effectively deliver solutions to real business problems.

[1] 90k employees, specifically, but also, specifically, not a tech company. A traditional company with a tech function.

This is absolutely correct. The best teams I've worked on understand both the business and the technical domain, and are able to leverage synergies to keep things simple.

I think most slow downs are due to single teams owning many (20+) services. Usually it's their own choice too.