Microservices: Getting started

This article covers the main topics that will help you make better decisions about how to create microservices and whether your business really needs this architecture at the moment.

When we think about microservices, the first thing we need to consider is: Can I divide up my application/solution/business into small parts? This means thinking about many things, such as whether our solution will be able to work without dependency, in other words, if each service is independent, will it work separately and perform one task only?

One of the most important principles of microservices is that a service must perform one task only. If this rule is broken, problems can arise when you need to refactor the code. Our goal is to create services that can work separately, without any aggregation or coupling. This means the service can work independently.

The main questions we must ask when building a microservice are:

1-Is it still independent?

2-Does it still perform one task only?

If you can answer yes to these two questions, you are on the right path to best practices in microservices. But you may find that in some situations, it is necessary to have communication between two or more microservices or other types of application. Sometimes, you need to return information that is in a different context and your microservice does not have direct access.

This kind of situation is not ideal when we are working with microservices. If one of the services is not available or does not give the response you were expecting, you may have problems, such as incomplete information or exceptions in your code and usually, the data is so important that without it, your entire service may be unable to complete its task. In these situations, you have to create artifacts that can deal with them.

To solve this problem, we need to build a solution that takes into account our business requirements. Functional requirements are essential; they define the behavior of the service, or what it can or cannot do. When considering usability, scalability, performance and other non-functional requirements, you should also consider how the service is going work, i.e. synchronously or asynchronously.

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 high performance between these two requests, because otherwise, this could result in a bad experience for your user, or a timeout or other type of exception.

When the services are developed with messages, queues and topics, the communication between them will be asynchronous. When one microservice has completed its part of the job, it publishes its result in a queue or topic. Then another microservice, that was waiting, will take this result and do its part of the job. In this way, we can make our solution more independent, so that it is not coupled with all parts of our system, as in a common solution or monolithic application.

The three main ways to implement communication between services are:

1-HTTP request between services;

2-Messages (queues and topics);

3-Event-based communication;

What you need to consider when building your service is: does the origin require the answer immediately upon sending the request? (synchronous) or can it wait for the destination to process the message, and then answer by publishing in another mechanism, such as a queue? (asynchronous).

You might now be asking yourself, why should I consider microservices as a solution for my business?

The answer is: Microservices are useful when you need to build a system that can work easily with flexible scaling, independent deployment, continuous delivery, or multiple teams, or when you want to expand your business simply and reliably.

Did this content help you? Then share with your friends who also need that initial help with microservices.