8 Benefits of Microservices

Microservices are small, independent services that work together. In other words, these services are small, highly decoupled and focus on doing a small task at a time.

• Follow the Single Responsibility Principle
• Resilient/Flexible – failure in one service does not impact other services.
• High scalability – demanding services can be deployed in multiple servers to enhance performance and keep away from other services so that they don’t impact other services
• Easy to enhance – less dependency and easy to change and test
• Low impact on other services – being an independent service, this has less chance to impact other services
• Easy to understand –  since they represent the small piece of functionality
• Ease of deployment – microservice support agile development
• Freedom to choose technology – allows to choose technology, best suited for a particular functionality
• Process-centric components – Each microservice typically runs in a separate process as distinct from a thread within a larger process. This ensures the component is neither too small nor too large.  
• Data-driven interfaces –  with a few inputs and outputs. In practice, most productive Microservices typically have only a few inputs and outputs (often less than 4 each). Communication between Microservices is document-centric an important feature of Microservices architecture.
• Focused functionality :  A Microservice is typically organized around a single, focused capability: e.g. access/update a Database, Cache input data, update a Bank account, Notify patients, etc.
• Independent interfaces: Each Microservice typically has a GUI Associated with itself, for end-user interaction and configuration.  Each Microservice is essentially a ‘product’ in its own right in that it has defined inputs and outputs and defined, non-trivial fun
• Easier Governance : since each Microservice runs in its own process and shares no dependencies with others, it can be monitored, metered and managed individually.
• Decentralized Data Management : Each Microservice can store data as it pleases : a given Microservice can use SQL, a second MongoDB, a third a Mainframe database, etc.
• Automated Deployment and Infrastructure Automation : Implementation independence allows assemblies of Microservices can be ‘moved’ from one deployment environment to another (for example, Development —> QA —> Stating —> Production), based just on profile settings.
• Orchestration and Choreography: Synchronous vs. Asynchronous :  If the Microservices are orchestrated using a classic synchronous mechanism (blocking calls, each waiting for downstream calls to return), potential performance problems can occur as the call-chain increases in size. A more efficient mechanism is to use an asynchronous protocol, such as JMS or any other enterprise-messaging protocol/tool (IBM MQ, MSMQ, etc.) to choreograph the Microservices. This approach ensures that there are no bottlenecks in the final application-system since most of the communication is via non-blocking asynchronous calls, with blocking, synchronous calls limited to things like user-interactions. A simple rule of thumb is to avoid as many blocking calls as one can.

•  

  Disadvantages to using a microservices architecture :
  
  • Services form information barriers.
  • The architecture introduces additional complexity and new problems to deal with, such as network latency, message formats, load balancing, and fault tolerance; ignoring one of these belongs to the "fallacies of distributed computing."
  • Testing and deployment are more complicated.
  • The complexity of a monolithic application is only shifted into the network, but it persists.
  • Too-fine-grained microservices have been criticized as an anti-pattern.
  • Overcoming the Domino Effect (Cascade Failure)
    When working with microservices, it’s possible for a microservice you don’t even know about to cause a cascade failure. When microservice A fails and there is no available failover, microservice B could also fail, which might bring microservice C to a standstill as well.
    The point is to be proactive in assuming that failures will occur in order to avoid potential cascade failures.