TLDR: Micro services offer a REPL like experience for application architecture.
The way I see it, micro-services are the architectural analogues of functional programming. They let me build pieces of an application similar to a function, including tests and debugging in isolation without the fear of unintentionally messing up data somewhere.
This similarity to functions even extends to how micro services are used, calling their API's with keyword arguments e.g get post name id json etc
If you don’t mock out an RPC call in a microservice it has the same implications as not mocking out a database query in a monolith. I’d argue microservices actually encourage testing in isolation which can increase risks when you do ship (assuming you don’t have e2e or integration tests, which can also be more complicated with microservices).
I’m not arguing either way is right or wrong, but I disagree that microservices inherently makes things easier to test. Isolated tests actually implies you tested the lego bricks but not the overall assembly, which would potentially imply higher risk.
It’s also possible to write microservices that are architected in a way contrary to FP, such as having services that mutate their data stores, so I’m not sure id compare microservices to functional programming either.
You compare services to functions, which they are, only with the added complexity of dealing with distributed nature of it. I’m not obviating the benefits, but I disagree microservices are the automatic win you imply.
I would instead attribute the benefits you mention to having good abstraction, whether that’s functions or classes or services, abstractions allow you to isolate mock and reason in isolation.
For instance, the article mentions microservices are supposedly better so a change to your service doesn’t cause spooky action at a distance. I’m not buying this. In a poorly done microservices architecture emitting events can indeed cause spooky action at a distance, especially if you invested heavily into isolated testing only. It is easier for a monolithic architecture to shift boundaries, and in a microservices architecture it is possible (and in my experience common) that changes will need to be made across boundaries
You make fair points in that micro services are not a silver bullet, the functional wins I perceive aren't automatic and I intentionally build a service in that way to get the functional benefits.
So yes there is a caveat, if a service doesn't return the same output for the same input then some benefits of the approach are lost. I would like to add an additional benefit for teams of programmers, in that each team gets the ability to build out a service using whichever technology they find suitable i.e language, frameworks etc. Something I personally find difficult to do with a monolith.
