Microservices are an architecture pattern of information technology, where complex application software is composed of independent processes that communicate with each other with language-independent programming interfaces. The services are largely decoupled and do a small job. This enables a modular design of application software. Microservices require a lot of infrastructure, which is implemented by separate services and discussed in our other articles.
Advantages
Because microservices can be distributed and developed independently, teams can work independently. This enables the scaling of agile development processes without much communication and coordination effort. Microservices are small. This keeps them clear and easy to develop. If necessary, they can be replaced with a small to manageable effort by a new implementation. Often unwanted dependencies creep in and eventually the original architecture is completely lost. The architecture of the microservices system remains stable because dependencies between microservices must be introduced through the API. This is complicated and does not happen by mistake.
Because the microservices remain maintainable and the architecture of the entire system remains intact, microservices also allow for a long-term productive development of the system. Microservices can be scaled independently. Microservice systems can be secured against the failure of other services, so that the overall system is robust. Continuous delivery is easier because of the size of the microservices.
Each microservice can be implemented with a different technology. This simplifies experiments with new technologies and prevents the obsolescence of the technology stack.
Microservices can also be used to extend legacy systems without having to make too many changes to the old code base. Facing the event of an overload, uncritical services can be reduced or shut down to free resources for critical services.
Disadvantages
The distributed architecture creates additional complexity, especially network latencies, load balancing or fault tolerance. As there are more systems failing than monolithic services, the likelihood that at least one component will fail increases. It should be noted that the failure of a microservices does not affect the overall system, which compensates for this disadvantage in the normal case. The variety of services makes software distribution and testing more complex. The cost of migrating existing systems is considerable and usually also means adapting the communication culture in the organizations involved. Logging and monitoring becomes more complex as several systems are involved, which may use different logging and monitoring technologies. Therefore, in addition to decentralized logging and monitoring solutions, central logging, monitoring and OpsDB services should be used.
Since this is a potentially distributed system, not only different time zones of the client applications but also different time zones of the hosts have to be considered. A time synchronization between the hosts (eg by means of NTP or even better PTP) and the use of suitable time libraries is therefore absolutely necessary. Since microservices are a distributed architecture, the availability of the application and the consistency of the data must be chosen based on the CAP theorem. However, this contrasts with the fact that a monolithic service in the event of a fault, for example in the event of an overload, is also not always available. In addition, data can not be guaranteed once it has been displayed to the user. Because the services can be implemented in a variety of programming languages and software stacks, the requirements for development tools and platform management increase. In addition, the functionality of libraries must be partially duplicated.
---
