Microservices have a lot of advantages, and they become more evident in the long term when the application becomes more complex. The microservice patterns primarily introduce complexity and enforce you to be very strict around development in order to avoid losing track of the entire application.

To start with, developers add to the complexity of the distributed system. This distributed system enforces a network communication -- not only do the services need to communicate with each other; they also need to find one another using some kind of service discovery technique.

This adds the need for a stable network to exchange requests. It adds layers of complexity just to exchange a simple request. It will also add an extra layer of security, both for development that needs to support it and for the operations that need to address it. As has been said previously, using bootstrap is harder than using a monolith application.

The operations team can also see some complexity in deployment. It's better to look at several services as separate components for deployment. This is actually as they should look for this architecture. They can, in the long term, even use some of the deployed architecture for new applications. Still, complexity for operations deployment and monitoring is even bigger.

Although not a direct disadvantage, because the architecture is loosely coupled and each service can be built using the best tools for the job, this can increase the heterogeneous environment, which will require operations to have knowledge of a broader technology scope. This can potentially lead to mistakes. Try to look for the second-best tool for the job if that tool is already used in operations.

The operations team will also have to possibly manage more third-party services, such as message queues, as they're commonly used to enable service communication. Other added services that might be added for scalability are service discovery. In a fully scalable application, operations just deploy new services and they register themselves and get used by all of your application's ecosystem.

As you can see, although development might get easier and you'll be able to parallel the application development across teams, there's also an added complexity if you intend to fully scale your application.

As a recommendation, do not plan your application to scale to millions of requests unless you really know it will handle that amount in the near future. Plan your application to have small and lightweight services to start with. It will be easier to do than upgrade the services to scale.

As a possible macro strategy, split your application using these three guidelines:

• Split services by capabilities
• Try to keep subdomains on a single service
• Prepare for scale, but don't scale while there's no need to