Why using Microservices Architecture?

Microservice introduction for beginners :D

Monolith Architecture

Before we go to microservices, we need to talk about monolith architecture first. Monolith architecture is a system architecture that contains a single application with many features or services. No matter what type of business and features that the system handles, this architecture will only have one application. So when there are some changes, we need to deploy the whole application. And usually, this architecture only has one database system.

There are some pros when using this type of architecture, i.e:

• Easy to develop, means we only create one project and simply put all features there. When there is any change, we just change the code in the same project.
• Easy to deploy, which means we only deploy this one application and done.
• Easy to test, we just need to run one application, and then we can test all features locally.
• Easy to scale, since we only have one application, we can easily just run another node for this application to scale.

Then the question is: If monolith architecture has all these benefits, so why we need to use microservices architecture? Actually, it depends on our needs. If we think that our application still able to handle the business with this type of architecture, we don’t need to change to microservices architecture. But the monolith usually has some of these problems.

• Intimidating for new joiner developers because the monolith project usually big and sometimes not structured well since all the features are put in one application.
• It’s hard to do developer scaling. When there are many developers work in the same application, there is a possibility to have many conflicts in the code.
• Hard to change the technology used. Because every new feature will be developed in the same application so we need to use the same technology that we used in the first place (e.g. programming language, database systems, etc).
• We cannot scale a specific part of the application. When we want to do scaling for certain features, i.e. transaction feature, we must scale all of them because all features are in the same application. The scaling process is easy but it wasting the resource.
• Running monolith application is heavy because of the size of the application.

So only when you face this problem, means it's time to change to microservices architecture.

Microservices Architecture

Microservices is a collection of small applications that work together. Each of the components of the system is called service. Each of these services focuses on one main task or business and that makes the size of the application small. For example, there will be one service that focuses on member data, and there is another service that focuses on product data, etc. And also each service can use a different database and database systems from the other service.

Each of these services is independent and each feature can run separately. This means a new feature can be deployed and running without waiting for another feature to be done first. Usually, the service communicates with others using network-call.

The pros of using microservices are:

• Easy to understand, because the application is small and focuses on one thing.
• Easy to develop and maintain because the size of the application is relatively small.
• Easy to change the technology used (i.e. programming language, database system).
• Able to scale specific service, i.e. scaling only for the transaction service.
• Can be developed by a small team and less conflict.

Besides all the benefits, microservices is also had cons and problems.

• Distributed systems. There are many services in the system and all of them are integrated with each other. This means a lot of works need to be done here.
• Communication between service is prone to error. It because the communication is using network and it has latency and a great possibility of error. So we need extra effort to handle service communication.
• The integration test is more challenging because we need another service to run or must mock the service.

When creating the microservice, we need to define each task or business that each service will handle. There are several ways to define each service, for example by its business domain i.e. shipping, product, merchant, etc.

How small the service should it be? There is no certain answer for this but there are some opinions.

• Single responsibility. Each service only handles one thing well.
• As small as possible so it can understandable by one person.
• Can be developed by ‘X’ number of people.

Conclusion

From all of the information above, we can conclude that:

Monolith

• Simplicity: only use one application and easier integration.
• Consistency: because the application only using a single database.
• Easy to refactor: many IDE already provides refactoring feature and because we only have one application the process will be easier.

Microservices

• Partial deployment: we can do deployment only for developed services.
• Availability: when there is one service down, some services still able to run.
• Multiple platforms: we can choose technology based on the business handled by the services.
• Easy to scale: we can scale specific services based on necessity.

In the end, microservices architecture is not always the best choice. It depends on the business and necessity. If the system still able to handle the business with the monolith architecture, keep using it. But when your systems start to encounter problems as previously explained, maybe it's time to use microservices architecture.

Reference:

https://www.youtube.com/watch?v=CHBfpPMILaQ&list=PL-CtdCApEFH-MtoBwQ0F3xNG21yjt5Kvs&index=2&t=76s&ab_channel=ProgrammerZamanNow

https://www.youtube.com/watch?v=W96gPBQ0blE&list=PL-CtdCApEFH-MtoBwQ0F3xNG21yjt5Kvs&index=3&ab_channel=ProgrammerZamanNow