Today in all teams when one new solution must be created, the micro-services term is thought before the business. But, do we have knowledge about this subject? Is it better for our context? Does it work for any context?
The micro-service definition is simple following the site microservices.io:
Micro-services - also known as the micro-service architecture - is an architectural style that structures an application as a collection of services that are
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities
- Owned by a small team
For me the biggest problem is understanding what is "Organized around business capabilities", but this I will explain after. In theory, anybody DEV with little expertise can do a micro-service and update his/her curriculum and says: I did one and understand what is micro-service.
The problem comes after and together with the headache. Once a time I saw someone tell: The problem of micro-services is the word "micro", what this means? When we see the word micro, we think that all services must be micro-micro. It starts a problem with other services because of the coupling. So you start doing the opposite of "Loosely coupled". This happens because we study the subject of a literary way and we do not have a deep study of other things.
Recently in a project that I participated in, I saw that we went affected by the wave called micro-services. Why? Because we created two services that in the end could be one. How do I know? Because there were many coupling between services. Note, I said there were because we corrected that error. The same information that there were in service A, almost all, there were in service B or service B was needed.
I know information copy there is when we work with micro-services. But when all domain is copied to another service or it is much used by another service, we must think whether the service is not wrong.
With micro-services, we must think before in problems that start to have but before there were not. For example: having loosely coupling services forces us to work with two things: a database for each service and a broker service to message exchange. When your services call directly other services, in case of failure of one service, all others also fail. Do you want to create services with direct communication between them? You must think better about it.
What about Kafka ou RabitMQ? You can be thinking about these tools, it's OK. These tools are very simple to insert in your solution, but the problem comes up when you have more a tool to take care. Ops! Take care? Yes, We must not only insert tools but take care of them also, ok? This concern is not necessary when we have a monolith system.
I wrote the word "monolith" and whether you are horrified, it is because you already went affected by the wave and at this moment you can be creating high costs to your company without need. Note I said you can...
Have a monolith system is not a problem, the problem is to divide a system in half because you guess that could be many services to attend yourself or because you are studying and liked. You are not being honest.
Once a time, I participated in a project that on the first day the "DEVs" showed the services in which we should create. All drawing was created by the IT team and not the business. Six months after, all services created went deleted and created a unique service and a database. Why did they do rollback? Because the division became bad, the services were so micro that got bad to keep. In that case, micro-service was a good option, but they started by technology and not by business.
More a time, they did not study the item "Organized around business capabilities", they first prioritize the technologies.
But after all, when must I create a micro-service? A thing that I learned time ago is that the services must not be created by IT person but the business must speak the service. How?
A good exercise to know to divide your business in services is first listening to your business. E-Commerce is a good example. A product has many meanings in a company. A product to the marketing has a name, description, images and a price. That product will be shown on the site. The same product to the stock needs only the amount of product, they are concerned with keeping the product on stock. Stock and Marketing have different people, they speak different languages because the product has meanings different for them. Now you know what means "Organized around business capabilities". For me, while we talk the same language we do not need to create another service, but when you cross the border and have other meanings, you need to create another service.
In the cases above, the services were divided wrong, this is the same that using the CQRS for a system that has 4 screens, CRUD. Nowhere you will learn how to divide in services, you have to learn by yourself and gain experience. Whether you desire to learn about micro-services, I orient you learning about DDD, Domain-Driven Design, before. DDD has many patterns like obliques language, domain experts and bounded context that help you to learn about micro-services. After you can learn about Cache, Messaging, API Gateway, and others.
You do not need to be stuck in a monolith system, you can apply a distributed system to a monolith system. For example, in my company, we have a system that manages docs for our clients. These docs when the user does the upload it is processed to extract text through OCR to improve the search after. But this process was slow because the extract was done together with the upload. Using a docker and a mini-program (Worker), we change to process the OCR after. The process now is done by another solution, a micro solution, and with that, the user does not complain because now the upload is much fast.
To conclude, my tip is: Before starting a project thinking in services, study the business, gain knowledge about the subject. Remember yourself, the business talks, listen to it. You can not apply architecture because you like ou because of your ego. You must apply architecture because the business needs. I am not against services ou monolith, I am against using something that I do not need. When I create something that I do not need, my company is that pay the costs and not I.
I hope you liked it, bye :)
Top comments (1)
Is it ubiquitous language?