It occurred to me a couple years ago when designing my deployment architecture that the majority of the complexity was just this. Instead of letting linkers/module systems do the work, I was doing all that stuff first by hand and then basically writing my own form of linking logic to solve a problem we created ourselves. Reminded me of when I read about the old ways people used to link code by hand...

And yes we were definitely cargo-culting...microservices were totally unnecessary for us. The only positive result is that it forced clean boundaries, but those could just as well have been forced by thoughtful architectural design anyway.

If it only forces clean boundaries then I agree, you shouldn’t be using microservices. The main benefits of microservices are things like fault isolation and better security, since you can run different components with different privileges.

This can sometimes be worthwhile in a corporate environment even if technically it makes things harder, because it solves a major political / communication problem.

However, for the expense of dealing with the complications of an additional network boundary to worthwhile, some of the following must hold:

* You need architect who has an overview of the whole system creates abstractions that make sense and puts the API boundaries in the correct place, avoiding the "tightly coupled microservices" antipattern.

* You need good devops people who can track problems that span service boundaries. This is the one area where the company can't skimp (i.e. no outsourcing of this position). Without these people you get an epic political clusterfuck where everybody ends up blaming "the other" team for their problems.

* The two services need to be built by two teams which, for whatever reason, cannot be relied upon to communicate or work effectively with one another (different orgs, different country, different company maybe).

* The two teams possibly use different programming languages.

I believe these reasons are probably the reason why it worked wonders for Martin Fowler. Then startups read his blog and decided that every team needed to build 15 microservices and the whole world went crazy (thanks Martin).

"Although the evidence is sparse, I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team."

https://martinfowler.com/bliki/MonolithFirst.html

Yeah, he wrote that after he realized that the microservice movement he spawned had gone nuts.

This is exactly how I view microservies (assuming that you know how to build a monolith in a modular way).

At the end of the day its only going to increase complexity.

I think what you said is true even if you don't know hot build a monolith in a modular way.

And to add to that: Transaction handling will be vastly different in most cases between local calls and network calls.

Counterpoint: if network calls weren’t flaky and slow would it make a difference in deciding whether to separate modules via a physical machine boundary?

As people already said, there is little point on talking about hypotheticals, since those properties are inherent...

But there are tools that can distribute a program over a network, and let your functions run at any node with the right capabilities "just like" (the network allowing) if it was local.

This is another point that the microservices pushers miss. It's a solved problem, and can be done in a much better way than what they push around.

But network calls ARE inherently flakier and slower. What good does it to imagine they weren't?

It helps demonstrate where additional investment and development might be warranted. If we have hit a physical limit in networking, then that is one thing - but if we are only hitting an artificial limit because our technology and infrastructure is not sufficiently advanced - then this problem is actually showing an opportunity.

As an architect you have to sometimes ignore constraints to understand if the final picture you would assemble makes any sense. If the final picture you assemble makes sense, then working backwards through the limitations, to find out, are these really limitations or are these opportunities to innovate?

That's my thought as to why you would imagine they are not a limitation. To aid in brainstorming, innovation and identify opportunities for improvement, or alternative solutions you would not have seen if you simply accept the bottleneck as a given.

As GP said the network is inherently flakier and slower and yes, we are very close to the physical limit.