Microservices are the new normal for development of applications that operate at scale. They allow individual services to be small, self-contained, horizontally scalable, clean separation of code lines and operations. Microservices also help with faster rollouts of changes compared to traditional monoliths, as the changes are localized to specific services. As long as tests asserting contracts between services are passing, a lot of time need not be invested in testing the whole application stack.
Then why does anyone want to develop a monolith? And does it even make sense to develop a monolith application? The answer to this question is - Cost.
The goal of any business is to make profit for stockholders. And profit for any business is Total Sales - Cost of goods. Now, there are two ways to increase the profit, either increase the sales or reduce the costs, better yet - do both.
Sales is a function of multiple different parameters - customer demand, marketing, sales, connections etc. Increasing sales is complex and often times not all parameters are in the control of the company. But cost of goods is totally in the control of the company. For software companies, the major cost of goods is employee (engineering) salaries and cost of running the application. Both of these are driven by application architecture.
Running microservices comes at a cost, a microservice application stack requires deployment of core application services, API gateway servers, Service registry servers, config servers. Multiple instances of each of these services per data center are required for fault tolerance. And the total cost of this setup in AWS or GCP, can run into thousands of dollars per month per application. Compare this setup to a monolith, the just spin up two servers and put a load balancer in the front, the app can be up and running.
Every day now, I make the decisions whether a particular functionality should be a standalone services or can be part of core service or if it can be moved to a Cloud Function. So far, I found Cloud Functions to be amazing specific to the use cases I am solving. I can split out non-core application functionality into individual Cloud Functions and integrate it with PubSub and deploy the functions across the globe with minimal overhead. It okay to bundle multiple services into one application to save, after all code can be refactored any time and can be split out to standalone services at the right time.
I am not saying microservices are bad, in fact that discussion is already settled and microservices have won. But, my argument is just from cost of running a business perspective. Developing microservices just for the heck of it, only to kill the business with unsustainable costs just doesn't make sense.