Once a project gets bigger in size and more complex in business logic, the monolith applications start to cause a lot of problems, being difficult to maintain, test, and deploy them quickly and efficiently.
Then, a lot of questions start to appear:
⦁ Should we rewrite the entire application from scratch?
⦁ Should we decompose our application into a set of services?
⦁ Which Decomposition patterns to use?
This is when Microservice Architecture Pattern comes in handy, and opens a wide range of possibilities to develop a high-quality product.
Overview
Microservices Architecture Pattern structure an application as a set of loosely coupled, independently deployable and small services.
They are self-contained, independent application units that each fulfill only one specific business function.
Pros
⦁ Highly maintainable and testable – each service is relatively small, being easier to understand, change and test.
⦁ Independently deployable – you can add changes in one service and deploy it independently without affecting the other services, making the Delivery of you your project easier, safer and faster.
⦁ Team productivity – it enables you to organize the development effort around multiple, autonomous teams and also allows a quick rump up for the new members speeding up the development process.
⦁ Advantage of different technologies – you may find that a specific framework, programming language, etc., best fits for a particular task/business logic. Therefore, using Microservices, it will allow you to update a service or create a new one based on the technology stack you need, without having to update/refactor/alter the other services.
⦁ Failure isolation – if one service fails, the other ones will continue to handle requests without bringing down the entire application.
⦁ Granular Scaling – individual components can scale as per need, adding more resources only to the services that really require them and not to the entire application.
Cons
⦁ Complex model – there are also a lot of principles and design patterns that you need to know in order to create a better solution.
For example:
Decomposition patterns: Decompose by business capability, Decompose by subdomain, Decompose by Transaction, etc.
Integration patterns: API Gateway pattern, Aggregator pattern, Chained Microservice pattern, etc.
Database patterns: Database per Service, CQRS, Event Sourcing , etc.
Observability patterns: Log Aggregation, Performance Metrics, Health Check, etc.
Cross-Cutting Concern patterns: Service Discovery pattern, Circuit Breaker pattern, etc.
⦁ Advanced skills required – developers must have a good knowledge of distributed systems, inter-service communication mechanisms, maintaining data consistency, failure handling, testing the interactions between services, etc..
⦁ Deployment complexity – you should have a good deployment process in place in order to manage all services, especially when you continue to add new features and new services to the whole application. Practicing Continuous Integration and Continuous Deployment should be a routine and not an optional choice.
When to use it?
Of course Microservices Architecture add more complexity to your project, that`s why it can slow down the development process for startups or companies that want their product quickly on the market.
Thus, when you have a small project, it might not be the most common and obvious choice to make at the beggining, but it is for sure the first option taken in to account when you end up with a monolith application difficult to maintain.
Most big web sites like Netflix, Amazon, Uber and eBay have evolved from a monolithic architecture to a microservice architecture.
Therefore, predicting the growth of your application complexity when you still haven’t validated your business idea, it`s not an easy task.
But, You should definitely invest more resources and effort at the designing phase, at least to create your solution in a way that will be easy to decompose and refactor if you’ll need to do that, to not spend even more later on.
CG 
Published by