Similar to the concept of serverless, the design strategy, which is the microservice-oriented strategy, has also been very popular recently. This architecture design existed a long time before the idea of serverless came into existence though. Just as we tried to understand the serverless architectures from the technical definition on the internet, we shall try to do the same for microservices. The technical definition for microservices is:
Planning and designing the architecture in the form of microservices has its fair share of positives and negatives, just like serverless architectures. It's important to know about both, in order to appreciate and understand when and when not to leverage microservices in your existing architecture. Let's look at this and understand the positives of having microservice architectures, before moving over to the negatives.
Microservices help software teams stay agile, and improve incrementally. In simpler terms, as the services are decoupled from each other, it is very easy to upgrade and improve a service without causing the other to go down. For example, in social network software, if the chat and the feed are both microservices, then the feed doesn't have to go down when the software team are trying to upgrade or do minor fixes on the chat service. However, in large monolithic systems, it is difficult to break things up so easily in the way one can do with microservices. So, any fix or upgrade on even a small component of the architecture comes with downtime with the fix taking more time than intended.
The sheer size of the code base of monolithic architectures itself acts as a hindrance progress in the case of any small failures. Microservices, on the other hand, greatly help in boosting developer productivity by keeping code bases lean, so that they can fix and improve the service with very little or no overhead and downtime. Microservices can be much better leveraged via containers, which provide effective and complete virtual operating system environments, processes with isolation, and dedicated access to underlying hardware resources.
However, microservices come with their own bunch of disadvantages and downsides, the major one being having to deal with distributed systems. Now that each service is surviving on its own, the architect needs to figure out how each of them interacts with the others in order to make a fully functional product. So, proper co-ordination between the services and the decisions regarding how services move data between them is a very difficult choice that needs to be taken by the architect. Major distributed problems such as the consensus, the CAP theorem, and maintaining the stability of consensus, and the connection, are some issues that the engineer needs to handle while architecting for microservices. Ensuring and maintaining security is also a major problem in distributed systems and microservices. You needs to decide on separate security patterns and layers for each microservice, along with the security decisions necessary for the data interaction to happen between the services.
