Abstract
The microservices architectural style is an evolution of the Monolith SOA (Services Oriented Architecture) architectural style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With the addition of every new technology, our responsibility also increases to be abreast of pros-and-cons the new member has and the pain points it is designed to solve.
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.