I disagree, microservices can offer many distinct benefits over a monolith. Yes, fine-grained scalability is a huge benefit, but there are many other advantages as well. I was going to list a bunch but honestly they can be found on google quite easily. More importantly though, is what I think is the key to making microservices deliver on their promises: Well defined and designed API's.
Designing good API's is important for all software, but is critical to making microservices work well; and it is not always obvious how to do this well. I can understand why so many people say you should start with a monolith and then break it up into microservices: With the monolith you have already accumulated a ton of domain knowledge so you can break apart the service-boundaries much easier. However, it can still be tricky to do this because not ever module in your monolith should be a service, infact it is likely that most will not. Microservices are a different level of encapsulation than a module. Sometimes microservices should done one thing well and with authority, sometimes they should do many things within the same domain/context, sometimes they should do an entire class of things to their data source, etc. Designing good API's forces you to understand how execution and data will flow through your system and how you can effectively and cleanly delineate between them.
IMO, the most important thing for a microservice, regardless of its size, complexity or role within your system, is it's API. When you have a well defined API you can encapsulate and abstract that entire service from the rest of your system, which is a wonderful thing. This microservice can now be deployed, updated, scaled, refactored or even rewritten entirely without any of the other services in the system even noticing. It brings a tremendous amount of freedom to managing your software platform. You no longer need to worry about things that don't concern your service, just fulfill your APIs and life is good!
I don't disagree with you, but I do disagree that you need microservices for those benefits. Just regular SOA gets you well defined APIs and contract-based interactions. Pretty much every touted benefit except granular scalability is a property of the underlying service architecture, not microservices.
After reading this thread I had to read this [1], which I found helpful in understanding the discussion. I think in some cases it is just more natural to write microservices but at the end of the day if done right the end user won't really know the difference, it's all just SOA(?)
* Single business function. Microservices don't have to be small, but all their calls should facilitate s single business function.
* Automated deployment. Services are deployed and undeployed live based on load.
* Unknown targets. Services are allocated and deployed to machines at runtime. The machine itself may even be allocated on demand. So service discovery is absolutely required.
* Stateless. Services instances can be spun down at any moment, so they can't be holding transaction state.
Designing good API's is important for all software, but is critical to making microservices work well; and it is not always obvious how to do this well. I can understand why so many people say you should start with a monolith and then break it up into microservices: With the monolith you have already accumulated a ton of domain knowledge so you can break apart the service-boundaries much easier. However, it can still be tricky to do this because not ever module in your monolith should be a service, infact it is likely that most will not. Microservices are a different level of encapsulation than a module. Sometimes microservices should done one thing well and with authority, sometimes they should do many things within the same domain/context, sometimes they should do an entire class of things to their data source, etc. Designing good API's forces you to understand how execution and data will flow through your system and how you can effectively and cleanly delineate between them.
IMO, the most important thing for a microservice, regardless of its size, complexity or role within your system, is it's API. When you have a well defined API you can encapsulate and abstract that entire service from the rest of your system, which is a wonderful thing. This microservice can now be deployed, updated, scaled, refactored or even rewritten entirely without any of the other services in the system even noticing. It brings a tremendous amount of freedom to managing your software platform. You no longer need to worry about things that don't concern your service, just fulfill your APIs and life is good!