Microservices: A trend or a necessity

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.

Published by

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s