Okay, I've read What is a microservice architecture? and articles on the subject, I know what is and how it works. But I still do not know what problem it tries to solve.
What are the advantages of using it from the point of view of software development and maintenance and how the solution works?
And the disadvantages? It seems to me that it generates an overhead . It gives the impression that the solution becomes more complex.
I've had a good experience with microservices, come on:
Teaming: When your system grows and the development team also comes up with the need to break down a large team into smaller teams to facilitate communication and division of tasks. With the microservice paradigm, teams can attack different services without the risk of one change affecting the development of the other team (collisions in merges, etc.).
Selective Scalability: When you need more performance in the monolithic model you typically double the entire server or increase its capacity. With microservices (or any distributed system paradigm), you can scale only the part of the system that really needs more performance, without touching the rest.
Development Speed : This part only applies after that your whole system is already well mature and I'm talking about part of the code only. Smaller solutions compile faster and are easier to work with.
Freedom to choose technologies: Each microservice can be written in the language and use the most interesting database to solve that specific problem. New technologies / frameworks can be tested quickly and closely.
Rapid Framework Update: As each microservice is independent, it is easier to upload the version of a certain framework without fear of side-effects in other parts of the system. The work is also smaller, as the solution is quite small and can simply be rewritten if this is the case.
Setup: The setup of your application can be much longer depending on its context. One has to think about API Gateways, service discovery and all the orchestration of microservices, things that are not normally needed in monolithic applications.
CORS: If you make AJAX calls to multiple services, you may have the CORS problem. This can be solved with a reverse Gateway / Proxy API (more work, more items to manage).
Authentication: The same thing as CORS can be solved in many ways (API Gateways + tokens for example), but it generates much more work in the beginning.
Logs: Logs are decentralized and should be centralized somewhere for full diagnostics.
Deploy: This is the worst part. If you already have problems deploying with your monolithic application, do not even think about microservices. All problems will be multiplied by the number of services, since instead of 1 single and simple deploy, you have to do several.
Test: Testing the application as a whole gives a lot more work on each developer's sandbox. Debug from end to end becomes more complex since you will be working with each service. Container technologies can help.
API Gateway Bottleneck: If you have a team taking care of the Gateway API, it can turn your development bottleneck if in your case each new functionality has to go through.
Backup: As each microservice ends up having its separate database, you will have many more backups to do and manage.
Transactions: With multiple databases you will have the problem of distributed transactions and perhaps some data replication.
The Microservice paradigm is fashionable and a lot of people are using it without stopping to think about the pros and cons. There's nothing wrong with monolithic applications, it all depends on your context.
As with any decision to use some technology, the question you have to ask is:
What problem do I want to solve with microservices? And what problems will I introduce with them? Is it worth it?
And one last tip:
If your company does not have a strong culture of devops , forget Microservices. Encourage and strengthen this culture and only when you are very good at it start to think about this paradigm. Deploy will be a key part in the success or failure of such a system.
It's kind of cliché, but it's basically that. I will try to put what I understand that the architecture tries to solve, but of course the subject is very extensive. In a nutshell I would put the following points below as the main ones.
Systems tend to be more complex as they add new access technologies and new features that users demand. With the breaking of a system into smaller parts focused on a function, the understanding of the problem and its solution becomes simpler. It is not necessary, for example, for the whole team to know all the functioning of the system to build and evolve. The architecture predicts that each service will have a clear separation of its domain by providing input and output interfaces that use only the domain for which the function was designed.
Separation also facilitates the process of testing, planning, and controlling functions, as companies typically place small, focussed teams on each function so that changes and developments happen swiftly.
The idea of having separate parts also allows different technologies to be used to solve different problems. Once an input and output interface and communication protocols are defined, the parts need not all be developed with the same technology. With this separation it is also possible to instantiate the same services several times and distribute the processing.
Another need to split in parts also has to do with the cost of cloud services. The companies that offer these services charge for use and power processing resources. So if you have a monolithic system you will need a very large infrastructure to put in the air and climb. With separation, you can have, for example, 5 lightweight instances to serve 100 users who use the billing module, a lightweight instance running to serve the 10 users of the purchasing module, and a heavier instance running consolidation reports.
The idea is not new. SOA (Service Oriented Architecture) also preaches a separation of systems into smaller and easier to manage parts. I believe that these attempts to break out of monolithic systems are something that is always being tried. I understand that the micro-services architecture focuses more on how to do than on the conceptual, so maybe it's gaining more momentum.
Of course in theory it all looks very good, but on the downside the problem is to make these parts work both on the system side and on the development team side. The separation brings a greater complexity to make the whole system work and that's where the part of DevOps comes in, which is the other part that can be called "trend", which makes all sense when you adopt this distributed architecture. Without good communication between the infrastructure operation and the development teams, it does not have to work agile.
The other disadvantage of separating has to do with data integration. Because everything is separate, there is an additional effort, because everything ends up being replicated so that it works separately, and synchronization to join the data to a consolidated report, or even to duplicate information from common subscriptions, such as customers, products, etc. requires that developers begin to use other techniques and technologies with for example NoSQL database that fits well in this distributed and eventually consistent scenario. Usually developers are accustomed to SQL databases that control all the data consistency, and this change is not very easy to do for those who have been working with SQL for a long time.
There's a lot more to be explored and the best (short) articles I've read about it and leave the mark are the Martin Fowler , from Chris Richardson and from Robert Sheldon
