MicroService Architecture ​

Abstract

Monolith

Think of any MVC pattern-based API code base, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, built and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below; i.e. all the various responsibilities are together.

Monolith Pros

• Less Cross-cutting Concerns
  Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging.
  
  
• Less Operational Overhead
  Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize.
  
  
• Performance
  There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC).

Monolith Cons

• Tightly Coupled
  Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.
  
  
• Harder to Understand
  Due to many dependencies, monolithic architecture easily becomes harder to understand.
  
  
• Deploy all or none
  When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly.
  
  
• Scale all or none
  Scale up/down, it’s for entire functionality.

Microservice

Gartner defines a Microservice as a "small autonomous, tightly scoped, loosely coupled, strongly encapsulated, independently deployable, and independently scalable application component."​ Microservice has a key role to play in distributed system architecture, and it has brought a fresh perspective.

Unlike monolith, a microservice strictly follows the Single Responsibility Principle (SRP) due to being tightly scoped around the business capability/domain for example Payment. Think of an MVC pattern-based API code base where a controller and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed for just one single responsibility i.e. business capability. This microservice architecture will then lead to having many such projects and each business capability having its own database.

Microservice Pros

• Easier Deployments​
  Monolith was deploying all or none. Microservice is a small service, the dev team has complete control on what needs to be deployed and leave another feature’s code untouched. I.e. if changes made in Payment service, only payment can be deployed. This was not possible with a monolith.
  
  
• Scalability
  Being a small tightly scoped service design, it gives freedom and flexibility to scale whichever service you want. For example, if needed only Payment can be scaled up/down/out.
  
  
• Easier maintainability
  Each microservice service is autonomous and so being small service it’s much easier to maintain than a monolith.
  
  
• Problem isolation
  Each service has its own code base and is deployed in its own space. Hence, any problem with self or other services remains completely isolated.
  
  
• Single Responsibility
  Single Responsibility Principle is at the core of microservice design. This drives all other goodness microservice architecture offers.
  
  
• Separation of Concern
  Microservices architecture leads towards building tightly scoped services with distinct features having zero overlaps with other functions.
  
  
• Deep domain knowledge
  Microservice encourages the product mindset and leads towards establishing deep domain knowledge with “you build it, you run it” mantra. ​

Microservice Cons

• Cultural Changes
  It requires a cultural shift and organizational alignment to adapt microservice architecture. The organization will require a mature agile and DevOps culture. With a microservices based application, teams need to be enabled to manage the entire lifecycle of a service.
  
  
• More Expensive
  Microservice architecture leads to growing costs, as there are multiple services. Services will need to communicate with each other, resulting in a lot of remote calls. These remote calls result in higher costs associated with network latency and processing than with traditional monolith architecture.
  
  
• Complexity
  Microservices architecture by nature has increased complexity over a monolith architecture. The complexity of a microservices based application is directly correlated with the number of services involved and a few databases.
  
  
• Less Productivity
  Microservice architecture is complex. Increased complexity impacts productivity and it starts falling. Microservice development team usually requires more time to collaborate, test, deploy and operationalize the service which certainly requires more time.

Summary

Microservice and monolith architecture both have their pros and cons. Microservice architecture is not a silver bullet, but for teams that aspire to be digitally transformed and writing services with a product mindset, microservice architecture is certainly worth consideration.