Lately, I've been tending to lean more towards employing a monolithic approach in system architecture. On paper, using micro-services seems like an ideal solution. The fact that you can decouple a project into smaller manageable bits is good. However, from experience and a couple of blog posts and videos I've watched, they do introduce a lot of complexities. Just to mention a few would be; giving database access to a microservice poses major security risks if not properly implemented, error handling, and especially if the said microservice is down would essentially make the system fail, connection error, read timeout, resource not found...you have to deal with many error scenarios.
I'm not completely against them, for example I believe a microservice should do one thing and do it really well. A good example would be sending sms notifications. This wouldn't really need to interact with any database. Just accept a list of phone numbers and send out the messages.
So my question is; when are my microservices appropriate and do we really need them as much as folks preach?
Top comments (8)
Monolith vs Microservices is always an interesting topic. The only right answer is "Whatever suits you the best". You don't have to strictly stick with either one. You can build a monolith for your core product development and then as you add features to it you can build smaller services to cater them. The major drawback I have experienced is in the SRE & Monitoring part. If a transaction fails, you have to do a lot to do the RCA. Which microservice exactly failed? Did it fail because of a dependent microservice? Is it down? these are things the developer has to ponder upon. Secondly if you have a small team then microservices can become hell. Finally, if you are getting intended results i.e. latency & scalability with monolith, go with it. A monolith is easier to maintain, in terms of Ops, than microservices.
A majority of the time, the monolith does provide the intended results. Again, it would also be dependent on how fast the features need to be shipped. Well architected microservices can serve the needs of the system given enough time to test them.
I've always worked as an individual developer or worked with a small team, and I think in those contexts monoliths make more sense. I tend to follow DHH's Citadel philosophy: keep your core app a monolith, and if there's anything that feels hard to do inside of it then you can break that into its own tiny service.
I think microservices make the most sense for companies that want small, independent teams that have complete ownership over their little piece of a bigger app. That's more of an organizational decision than an architectural decision though.
interesting take!
Every application should start as a majestic monolith.
Yeah you are right. Also in startup environments, it's usually easier to work with monoliths due to the huge amount of time involved in making microservices work together. The environment there is fast-paced and time must be maximized to ship features.
In software industry it is always hard to know what you are building untill some time, even then, good luck knowing what you are building. So Monolith vs microservice is wrong comparisone in my opinion. It is easy to start with the monolith if you do not know your problem well, or the solution, and you are trying to descover the domain. The observability will be great, you will able to move logic from a module to another and may never end up needing a microservice at all. But when you have a clear idea about the domain and your organization, and you started to need separation, then you start thinking of splitting your monolith. And there are many ways and strategies that can help during that jurney. Untill then good luck
Thanks Hugo for this insightful post. A key takeaway from it is, "the monolith is rarely the enemy". It's only a matter of good engineering.
Also, crazy how the app you mentioned has 30 microservices!! I can imagine the delays on the platform hence why the high paying customer left.
We should always strive for better monolithic architectures. And if you do decide to migrate the monolith to a microservice, then everyone on the team should be able to defend that decision.
I can add my experience to discussion: if you fail to clearly define the microservices domains, then you are going to hit a lot of problems. If you are in the need to implement too much orchestrations involving more and more domains, your architecture will easily become a mess. Anyway microservices world has its own design patterns that can be very handy, but never understimate the importance of put coupled domains in the same microservice.
I think there's both logical and techincal reasons to take on the additional work at the beginning.
From a DDD perspective, domains often align nicely with the expected complexity of a microservice. The ability to containerize the entire service including storage and infrastructure allows you to make new atoms and manage complexity better. From a security perspective, different services have different security requirements. If you package a service's identity with the deployment, it is very easy to provide cloud role permissions. From an application code perspective, aligning to the DDD provides traceability to the high-level design, reducing defects in the long run. From a management perspective, different services can be owned and developed by different teams.
I agree that a monolith is easier to develop. But in my experience, it is not so easy to maintain, or to bring in new people on such projects. If you have any or all of the requirements I mentioned above (traceability, DDD, management), I believe that microservices are an appropriate solution. If these requirements aren't there, a monolith is by far easier to manage in the short-term.