Microservices Are Something You Grow Into, Not Begin With
Most of the time, I've found a push to microservices within an organization to be due to some combination of:1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution.  Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able to deliver.2) Inexperienced developers proposing microservices because they think it sounds much more fun than working on the system as it is currently designed.3) Technical people trying to avoid addressing the lack of communication and leadership in the organization by implementing technical solutions.  This is common in the case where tech teams end up trying to "do microservices" as a way to reduce merge conflicts or other such difficulties that are ultimately a problem of human interaction and lack of leadership.  Technology does not solve these problems.4) Inexperienced developers not understanding the immense costs of coordination/operations/administration that come along with a microservices architecture.5) Some people read about microservices on the engineering blog of one of the major tech companies, and those people are unaware that such blogs are a recruiting tool of said company.  Many (most?) of those posts are specifically designed to be interesting and present the company as doing groundbreaking stuff in order to increase inbound applicant demand and fill seats.  Those posts should not be construed as architectural advice or _best practices_.In the end, it's absolutely the case that a movement to microservices is something that should be evolutionary, and in direct need to technical requirements.  For nearly every company out there, a horizontally-scaled monolith will be much simpler to maintain and extend than some web of services, each of which can be horizontally scaled on their own.I also wrote https://adamdrake.com/enough-with-the-microservices.html as a way to communicate some of this, including some thoughts on when and how to structure a codebase (monolith) and when it might make sense to start moving towards microservices, etc.  There are cases where it's reasonable (even advisable) to move towards microservices, but they are rare.