35
Okay, I read it What is an Microservices architecture? and articles on the subject, I know what it is and how it works. But I still don’t 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 the operation of the solution?
And the disadvantages? It seems to me that it generates a overhead. Gives the impression that the solution becomes more complex.
33
I’ve had a good experience with Microservices, come on:
Team division: When your system grows and the development team also ends up coming the need to break a large team into smaller teams to facilitate communication and task division. With the Microservices paradigm, teams can attack different services without the risk of one change affecting the development of the other team (collisions in merges, etc).
Scalability: When you need more performance in the monolithic model you usually duplicate the whole server or increase its capacity. With Microservices (or any distributed systems 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 afterward that your entire system is already very mature and I’m talking about the code part 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 contained.
Quick update of frameworks: As each microservice is independent, it is easier to move up the version of a certain framework without fear of side-effects in other parts of the system. The work is also smaller, since the solution is very small and can simply be rewritten if this is the case.
Setup: The setup of your application can get much longer depending on your context. You have to think about Gateways API, Discovery service and all Microservices orchestration, things that are not normally needed in monolithic applications.
CORS: If you make AJAX calls for 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: Same thing as CORS, it can be solved in several ways (API Gateways + tokens for example), but it generates much more work at the beginning.
Logs: logs are decentralized and should be centralized somewhere for full diagnosis.
Deploy: This is the worst part. If you already have problems deploying with your monolithic application, don’t even think about Microservices. All problems will be multiplied by the number of services, since instead of 1 single, simple deploy, you have to do several.
Testing: Testing the application as a whole takes a lot more work on each developer’s sandbox. End-to-end debugging becomes more complex as you will be working with each service. Container technologies can help.
API Gateway Bottleneck: If you have a team looking after the Gateway API, it can turn your development Bottleneck if in your case every new feature has to go through there.
Backup: As each microservice ends up having its own database, you will have many more backups to do and manage.
Transactions: With multiple databases you will get the problem of distributed transactions and perhaps some data replication.
The Microservices paradigm is trendy and a lot of people are using a lot to think about the pros and cons. There is nothing wrong with monolithic applications, it all depends on your context.
As with any decision to use any 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? It’s worth it?
And one last tip:
If your company does not have a strong culture of devops, Forget Microservices. Nurture and strengthen this culture and only when you’re really good at it start thinking about this paradigm. Deploy will be key to the success or failure of such a system.
13
It’s kind of a cliché, but that’s pretty much it. I will try to put what I understand that architecture tries to solve, but of course the subject is quite extensive. Briefly I would put the following points below as main.
Systems tend to become more complex as they add new access technologies and new functionality that users demand. With the breaking of a system into smaller parts focused on a function, it becomes simpler to understand the problem and its solution. It is not necessary, for example, for the whole team to know the whole 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 control of functions, since companies usually put small and focused teams in each function so that changes and evolution happen in an agile way.
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 parties need not all be developed with the same technology. With this separation it is also possible to instantiate several times the same services and distribute the processing.
Another need to split into parts also has to do with the cost of cloud services. Companies offering these services charge per resource use and processing power. So, if you have a monolithic system you’re going to need a very large infrastructure to put in the air and scale. With separation, you can have, for example, 5 light instances, to serve 100 users using the billing module, a light instance running to meet the 10 users of the purchase 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 parts and easier to manage. I believe that these attempts to get out of monolithic systems is something that is always being tried. I understand that micro-service architecture focuses more on how to do than on the conceptual, so maybe it’s gaining more strength.
Of course, in theory it all looks very good, but on the downside side the problem is to make those parts work, both on the system side and on the development side. The separation brings a greater complexity to make the whole system work and at this point comes the part of the Devops which is the other part that can be called a "trend", which makes perfect sense when you adopt this distributed architecture. Without good communication between infrastructure operation and development teams it does not have to work in an agile way.
The other disadvantage of separating has to do with data integration. As everything is separate there is an additional effort, because everything ends up being replicated so that it works separately and the synchronization to join the data for a consolidated report or even not to duplicate information from common registers, such as customers, products, etc. requires developers to use other techniques and technologies such as a Nosql database that adapts well in this distributed and eventually consistent scenario. Usually developers are used to SQL databases that control all the consistency of the data and this change is not very easy to make for those who are long working with SQL.
There is much more to be explored and the best (short) articles I have read on the subject and I leave the indication are the Martin Fowler, of Chris Richardson and of Robert Sheldon
Browser other questions tagged software-architecture microservices
You are not signed in. Login or sign up in order to post.
Good clarification, but some of the disadvantages are not inherent to the architecture of Microservices, but to policies and technologies not (or poorly) implemented and that bring problems both in one scenario and in the other, as the deploy problematic, for example.
– dellasavia
Hello @dellasavia, yes, but regardless of its maturity with deploy, it is always more expensive and complicated to deploy from multiple applications than from one.
– andrecarlucci
In time, if you want to see a real-life example, read about the Predix (http://www.predix.io) that GE (General Electric) released. It is a platform for Iiot (Industrial Internet of Things) based on Microservices.
– Leonardo Pessoa