> Microservices are, in that essence, a religious belief that we should approach with skepticism - as is true with many things in software.

This is a ridiculous strawman. The point of microservices is higher-level architecture and design: to have discrete components in your system that fulfill a single responsibility — do one thing, and do it well—, so that reasoning about the entire system as a whole becomes simpler. It allows the microservice to expose its implementation behind a well-defined API, and thus keep its privates private. Additionally, microservices permit those (sub-)systems to scale independently.

Monoliths can do some of that, but often the "keeping the implementation private" is the hard part. When every part of the system has access to a database, people will reach behind the API & just get the data they need. It's not impossible to prevent, per se, but having the service entirely separate makes for a much better, stronger separation that forces the API design & planning that would not otherwise occur, as it would otherwise require a level of discipline that I don't think today's PMs and "agile"/scrum permit to exist.

Now, the article tries to address one of my points,

> In the usual web application, this is not a problem, because load and tested ensures each VM will be tested to it’s autoscaling parameters, and then it will grow.

No, it most certainly does not… I've seen plenty of VMs in my career running monoliths that were 90+% idle and most RAM free, because the application was bottle-necked on the database. And even if they're "monoliths", there's inevitably some other service not part of the monolith (either b/c it is third-party, or what) that then gets its own ASG, it's own set of VMs for redundancy … and it is waste. Never have I seen exactly 3 VMs running exactly 1 monolith.

(& VMs are like the worse case, too, as they are inevitably hand-crafted snowflakes. But worse, if a dependency, such as a package, is required… what part of the system required it? If I remove a use, is the package still required? Answering these requires reasoning over the entire monolith, something that, once the codebase is big enough, becomes effectively impossible.)

> On the communications front, internal web services are often doubly inefficient by using REST rather than binary transmissions.

… this is beyond wrong and it doesn't make any sense. You can serve Protocol Buffers over REST … is that not a "binary" transmission? (Not to mention that HTTP/2 & later is a binary protocol…) Sure, many people use JSON today, but there's no requirement to do that, and I've written several RESTful endpoints that didn't serve or consume JSON. (Generally because the requirements were such that that would make no sense.) The protobuf vs. JSON is a whole different debate, and each format has its pros & cons, but it is certainly orthogonal to the question of whether microservices are good or bad…

> Code that needs to be shared between the asynchronous services and the web tier should be kept in libraries used by both of them and is not a service call.

If you're going to do a monolith, yeah, this is what one should be doing. I've just literally never seen it done. (In fact, I've suggested it, mulitple times, when the second, third, fourth, fifth use case comes up: "we have code for that, but it isn't in library form. Let's solidify it into a library, & then change the existing consumers to use it, and then your use case is just another consumer" is inevitably met with "but I just want to do $whatever_it_is_thats_the_use_case it's just one more instance of this code, what could it hurt?" … followed by "why am I hitting $corner_case" and "well, that's some old organic growth; the original code, that we would have turned into a library, handles that…")

> The number of which does not really matter, but in a world of 200 microservices

This is strawman is repeated in every "I hate microservices" article. I've never seen microservices taken to that extreme, and yeah, if that's what you're doing, I expect you're in for a world of hurt. But that's not the point, and I doubt you actually have 200 well-defined systems with well-defined boundaries & APIs. But yes, if you take something to the absurd, it breaks down?