> Network failure (or configuration error) is a reality. The probability of having one part of your software unreachable is infinitely bigger now. Network part

> Network failure (or configuration error) is a reality. The probability of having one part of your software unreachable is infinitely bigger now. Network partitions are indeed a problem for distributed software in general. By the time microservices are worthwhile, however, the application likely already necessitates a distributed design. > Remember your nice local debugger with breakpoints and variables? Forget it, you are back to printf-style debugging. ...why? What's stopping you from using a debugger? A microservice v. a monolith should make zero difference here. At worst, you might have to open up multiple debuggers if you're debugging multiple services. Big whoop. > SQL transaction ? You have to reimplement it yourself. ...why? What's stopping you from pulling it from a library of such transactions? I don't even really think this is a "problem" per se. Yeah, might be inconvenient for some long and complicated query, but that's usually a good sign that you should turn that into a stored procedure, or a view, or a service layer (so that other services ain't pinging the database directly), or something else, since it simply means bad "API" design (SQL being the "API" in this context). > Communication between your services is not handled by the programming language anymore, you have to define and implement your own calling convention Which is arguably a good thing, since you're able to more readily control that calling convention and tailor it to your specific needs. It also gives ample opportunities for logging that communication, which is a boon for troubleshooting/diagnostics and for intrusion detection. > Security (which service can call which service) is checked by the programming language (with the private keyword if you use classes as your encapsulation technique for example). This is way harder with microservices: the original Monzo article shows that pretty clearly. The programming language can do little to nothing about security if all the services are in the same process' memory / address space; nothing stopping a malicious piece of code from completely ignoring language-enforced encapsulation. Microservices, if anything, help considerably here, since they force at least process-level (if not machine-level) isolation that can't so easily be bypassed. They're obviously not a silver bullet, and there are other measures that should absolutely be taken, but separation of concerns - and enforcing that separation as strictly as possible - is indeed among the most critical of those measures, and microservices happen to more or less bake that separation of concerns into the design.