Yes, yes, I know, microservices are all the hype. But their claims correspond to reality? Let's do a some fact checking.

Let's pick a random article with shameless microservice propaganda. It's not hard, given how many of them already exists and how many new ones published every day. For example, this one will serve the purpose very well. It contains the following statements:

What do Microservices Offer?

As services become smaller, the benefits are realized in multiple aspects

• The foremost advantage of it is improved maintainability. Each service is relatively small and so is easier to understand, modify, and test.
• As each service is independent, you are free to choose a different technology stack for its development. This eliminates any long-term commitment to technology.
• As services are smaller, they can be independently tested in a comparatively less time frame. We do not need to wait for all the other modules to be validated before we push it for the next stage of deployment.
• One of the best offerings is independent deployment. This helps in faster delivery through continuous deployment. Software development can be more organized into smaller, autonomous teams. “small team” is a relative term though. Typically it consists of 5–10 people.
• Our application becomes more robust in terms of fault tolerance. If one service is down, it will not bring down other services (as was the case with monolith applications). Our application will still continue to serve other requests with increased availability.
• As the services can be deployed independently, we can scale-up or scale-down the service instances based on traffic. This improves the overall scalability and availability of our application significantly.

Let's take these claims one by one and analyze them.

The foremost advantage of it is improved maintainability. Each service is relatively small and so is easier to understand, modify, and test.

Sounds logical, but let's remember, this has very little with the microservices itself. It's the matter of organizing development process. If some organization set up a development process, so each team will work on the service independently, but the final product will be built and deployed as a monolith, maintainability will be exactly the same. But there will be no microservices. Oops!

As services are smaller, they can be independently tested in a comparatively less time frame. We do not need to wait for all the other modules to be validated before we push it for the next stage of deployment.

This is exactly the same thing as above - this is purely a question of organizing processes, there is nothing specific to microservices.

One of the best offerings is independent deployment. This helps in faster delivery through continuous deployment.
Software development can be more organized into smaller, autonomous teams.

Independent deployment is a bold claim. The problem is that this is true only in a narrow set of situations: only when the new version of the service is backward compatible with the old version. Again, this is not specific to microservices, exactly the same can be achieved, for example, by using OSGi container to deploy services (or any other way to dynamically load/unload modules/classes/etc.). Unlike microservices, OSGi even provides built-in version management and allows deploying several versions in parallel, which makes handling of different scenarios (for example, transition to between incompatible service versions) much simpler. Microservices have no such functionality out of the box.

Our application becomes more robust in terms of fault tolerance. If one service is down, it will not bring down other services (as was the case with monolith applications). Our application will still continue to serve other requests with increased availability.

This one is often repeated and, perhaps, one of the most interesting. At first, the claim about monoliths is not true. How the application handles service failures is specific to the particular implementation. It may fail completely or continue to operate. Usually, properly designed application must fail in case of non-recoverable error. This prevents loss or corruption of data by partially working application. But, again, this is a design decision, not an inherent property of the monolith. For some reason, microservice proponents declare a partially working system "available" and claim that this is an advantage! Partially working system can be considered "available"? Sounds like a free interpretation of the term "available".

As the services can be deployed independently, we can scale-up or scale-down the service instances based on traffic. This improves the overall scalability and availability of our application significantly.

Who decided that services could be scaled only by deploying more instances? Even if this is true for the most microservices-based systems (after all, they are designed this way), there are many other approaches to scaling. For example, an application may launch more instances of the same service internally. This might sound not so appealing in the case of the monolith, but for the clustered solution this is a perfectly fine approach. Moreover, cluster may start/stop service much faster and resource consumption per instance will be much lower. Interestingly enough, there are no technical limitations for the clustered solution to deploy more instances if necessary - this enables a second dimension for scaling.
But this is only about how instances are added. Let's examine "scalability and availability" claim further. It appears that microservices could be scaled only by launching more service instances with all relevant expenses - one more container, one more runtime, one more instance to maintain, monitor, collect logs, etc. But there are other ways to scale application. For example, a clustered application can split tasks across cluster nodes. Tasks can belong to one service or different services. Another scaling strategy (especially suitable for data grids) - launch several instances of the particular task across nodes which contain relevant pieces of data (so-called "data affinity") and effectively turn remote data access into local! All these techniques are far more flexible, fine-grained and scalable. But microservices can propose only the coarse, resource-heavy scheme - "scale by deploying new instances".
For some reason, technically inferior, inflexible and limited capability is advertised as microservices "advantage".