Microservices: Getting started

This article has focused on exposing the main topics to help you make a better decision about how to create microservices and if you really need this architecture for your business at the moment.

When we think about microservices, the first thing that we need to answer is: Can I distribute my application/solution/business into small parts? This means that we need to think about a lot of things, for example, if our solution will be able to work without dependency, in other words, if each service is independent, they can work separately and do only one task.

One of the most important principles of microservices is that a service has to perform only one task. If you broke this rule, you will probably have problems when you need to refactor the code, and our goal is to create services that can work separately, without any aggregation or coupling. This makes the service work independently.

The main questions that you must ask yourself when you are building a microservice are:

1-Is it still independent?

2-Does it still perform only one task?

If you assume yes for these two questions, you are on the right path to microservices best practices. But maybe you will find some situations where it is necessary to have communication between two or more microservices or other types of applications. Sometimes you need to return information that is in a different context and your microservice does not have access directly.

This kind of situation is not desirable when we work with microservices, if one of the services is not available or does not give you the answer that you were expecting, you will have trouble like incomplete information or exceptions in your code and most of the time the data is so important that your entire service will be not able to finish its task. For those situations, you should create artifacts that can deal with them.

To solve this problem, we should build a solution considering our business requirements. Functional requirements are essential, they define the behavior or what the service does or not. When you are wondering about the usability, scalability, performance and other non functional requirements you should also consider how the service must work, synchronous or asynchronous.

If you have a synchronous service that also has a dependency on another one, and you need this other service to deliver the data in time execution, you will probably need a high performance between these two requests, because if not you can provide a bad experience for your user or maybe a timeout exception or other exceptions.

When the services are developed with messages, queues and topics, the communication between them will be asynchronous. When one microservice finishes its part of the job, it goes to publish its result in a queue or topic, after that another microservice, that was waiting, will consume this result and do its part of the job. With this, we can make our solution more independent and will not be coupled with all parts of our system, as in a common solution or monolithic application.

There are many ways to implementing communication between services and the top 3 ways are:

1-HTTP request between services;

2-Messages (queues and topics);

3-Event-based communication;

What you should think when you are building your service is: if the origin needs the answer at the same time that was sending the request, synchronous, or if it can wait for the destination to process the message and answer by publishing in another mechanism, for example, a queue, in an asynchronous way.

Maybe now you are asking yourself, why should I consider microservices as a solution for my business?

The answer is: when you need to build a system that can easily work with flexible scaling, independent deployment, continuous delivery, work with multiple teams, and also when you want to easily expand your business with reliability.