Microservices, and nothing else matters!
After reading My microservices hurt I felt so distressed that inspired me to write this. In my short experience I have worked with different architectural styles: desktop applications, web services, SOA and Microservices, cloud native apps and many things in the middle that I don’t know how to tag.
In recent years, I have been asked occasionally about Microservices. I see many times that the architecture is decided with poor analysis or well before anything else. Mainly I have been faced with “we need this to be faster so we are migrating to microservices” or “the software is too big and we are going to split it, so we are migrating to microservices”. They have come to me because they think I can help them and what I usually do is bring the worst of Microservices! Doing software development in the style of Microservices could be painful and it will be worse if you are not prepared, even worse if your client isn’t.
Microservices are complex
Microservices are more complex by nature. First of all you are creating code that will be executed in different places, so if you have dealt with trying to not duplicate code in a monolith, then it is harder here. On top of that you have communication between the services, where things like latency or load balancing enter the game, that you might have not worried about before. Maybe smaller services are easier to test independently but when running together they are not, and troubleshooting will be painful if you are not doing proper logging and analytics.
Deployment complexity is increased as well, imagine two services consuming each other and you introduce a breaking change to one of them. If you deploy the modified first, the second will fail but if you invert the order you will not have the functionality of the first at all. So deployment strategy becomes a problem, and this translates into money in the end. These make Microservices more expensive and you will need to consider more infrastructure because you have many components now.
These are the things that you will need to consider when designing your architecture as they will be your future problems. More important if you are building for a third person, you will need to consider as your inputs the client’s budget, time and team composition.
Monolith, the bad guy!
It seems to me that an application built as a monolith is the enemy in the present time and the remedy is Microservices. If you have a monolithic application and you have some issues, migrate to Microservices and all your problems are gone. This is a false premise. I would argue that you will have even more problems as I have mentioned before.
Monolithization
A monolithic solution is not the problem if built correctly. Recently I read about the term Monolithization, as a technique that enables you to scale your microservices better. When there is a little to no load in your system, you can consolidate your services in a single monolith. This will help you deal with the usual problems of communication between the services and have a cheaper overall solution, then being able to split components into different services. I would also recommend this when doing a new solution, build your components decoupled, deploy as a monolith, test your system, split your services and deal with communication problems later.
Microservices have its advantages but you need to consider if this is a style you would like to use after a minimum analysis. It requires a cultural change on both sides, the team and the client and you will need full investment from the client to be successful.
Monolith vs Microservices
If you reached to this point and you are still considering going through with Microservices, doing so will have its pros. If not let me list some of them so you have a better picture. If you ask me what are the benefits of going with a Microservices architecture I will say independence and scalability, these two are for me what triggers many others.
Independence of the services will translate into fault isolation, easy to modify services, framework and language agnostic, improved lifecycle management, better testability of decouple functionality, faster release cycle and even into scalability. Been able to scale services independently is a huge benefit in times of highly and fluctuating demand services.
Microservices gives you a boost in doing agile development where you could focus on faster delivery and benefit the client with rapid market time. This would help drive the product in the right direction as you will get quicker feedback.
Nothing in the middle
All and all this is not a war between Monolith and Microservices, and you should not be choosing a side. Instead, you should be looking at your problem at hand and analyzing how one of these will help you solve it. If not, maybe look somewhere else, maybe something in the middle.
Distributing a service does not always mean migrating to microservices, there are patterns to move out code or attach to our system that help us solve a specific problem. Ambassador o Sidecar are clearly examples to move in a direction of a more distributed system.
Ambassador & Sidecar
The Ambassador pattern can help you with adding some good features to your system keeping modifications low. Things like circuit breaking, routing, metering and monitoring, and the ability to make network-related configuration updates could be implemented outside of the main code and keep risk at low. The Ambassador could be as well shared between multiple processes and escalated independently accompanying the life cycle of the consuming application.
Sidecar is another pattern that provides a way to extend our system in a distributed manner keeping changes to original code at minimum and adding the functionality we are expecting. Often we are faced with requirements for monitoring, logging, configuration, and networking services that will impact heavily on the system. Implementing them as a separate service can help isolate and decouple them from the main application, allowing us to use different languages and technologies. An Ambassador is a clear example of a Sidecar.
These are not microservices but you will find some benefits that are common on a microservice architecture, and maybe, just maybe it is what you were looking for when you thought of Microservices!
Conclusion
To sum up, there are other solutions that can solve your problem and are neither a monolith or microservices, and in the end you should put your quality attributes before your architectural style.
