The concept of microservices is simply breaking a single large potential service into many smaller services that work together, hence, the name.
One very obvious advantage when it comes to building an application with a microservice architecture would be the very obvious fact that certain parts of the application are more used as compared to other features. A very common term that one would probably hear in the industry can come up when one tries to optimize and improve the performance of their application is the term hot path. The hot path is essentially part of the application that will be called more frequently than the rest of the application. It will be the main reason why an application would need to be scaled out.
Another obvious benefit of building applications in a microservice architecture would be the fact that we now potentially made the application more resilient to failures.
A third benefit that one can observe is the impact of how having an application with microservices architecture on the delivery timeline of an application. With a microservice architecture for the application, each application team within the company can release the feature they are in charge of on their own schedule (in the ideal case). This will involve ensuring that the right tooling and processes are in place in order to allow them to do so. This would allow teams to release features as soon as they are ready (no longer bound to release cycles), and each team can dictate how frequently their feature will be updated. It would be highly likely that the core features of an application (for example, user authentication/authorization) in the application would not be updated as frequently as some of the business-related features that the application provides.
One disadvantage that may immediately come up will be the complexity of deploying and running an application with a microservice architecture. First things first will be the fact that a developer team needs to deploy more than 1 service in a microservice application. The only logical way is to have a small team write up a bunch of whole automation scripts and have rigid, battle-tested processes to ensure that such microservices are managed well.
At the same time, there is only the other consideration that the applications would need to communicate with each other over the network. This is where many developers trip and assume many things with how their application would work when there is a need to communicate over a network. Any communication over a network would introduce potential lag to the entire system. In case if two microservices exchange a lot of data with each other, it would not make too much sense to have them as two separate microservices. Let us go with the scenario where applications are built to follow REST HTTP interfaces and respond and reply with JSON blobs to each other. The amount of network overhead and amount of CPU resources wasted on JSON marsling and unmarshalling just to be able to support the services as two microservices would make us rethink if microservices are truly a good idea.
Another major disadvantage also pertains to communication between services in an application built with a microservice architecture. All the microservices would need to have some way to reach to each other over the network. One naïve approach for this could be the hardcoding of IP addresses for other addresses in the configuration file, but naturally, that would not scale that way. We would also need to take into account of scenarios in which some of the IP addresses assigned to individual microservices could be lost or misassigned to other services—making it not as reliable. The task of ensuring that microservices have a system to communicate with each other is service discovery. This mechanism can easily be quite complex once we add more complex requirements, such as whether it would be possible to have autoscaling as a feature in the platform.
