In recent times, I have observed a series of events that make me reflect on the use and abuse of microservices. Below, I will describe the events that led me to reconsider the tools I typically use when designing an application’s architecture. Perhaps this will also help you reflect on your development habits.
I have been involved in a project where we were defining the architecture, even when the requirements were not yet clear. However, what we did know was that we needed the application to scale to serve hundreds of thousands of users across the continent.
It was at that moment when everyone, including myself, agreed that we should design an architecture based on microservices. Additionally, we needed to have a finished product in a few months, and that’s when the challenges began.
When you’re looking to accelerate development, you tend to prefer a simple architecture, without many configurations or entities, to be more agile in delivering intermediate results.
When Everything Looks Like a Nail to Your Microservice Hammer
In theory, everything looks perfect, and creating a service is reduced to a simple rectangle in a diagram (It’s Hammer Time). However, when we try to implement this, we start encountering elements like SQS queues or Redis for message delivery, and programmers who want to use a different language than another application. This leads to the emergence of a stack of diverse technologies that were not initially planned.
Perhaps what you’re looking for is a middle-ground solution.
One of the agreements we reached was to avoid over engineering the system’s needs. For example:
- Do we really need a message queue?
- How many messages are actually received? Are any lost?
- Do the retries of each microservice when calling another using the Circuit Breaker pattern to avoid overloading the other microservice affect response speed?
- Does excessive requests influence performance?
Sometimes, out of inertia or because we have the idea that the system will be automatically deployed by Google or Amazon and subjected to heavy loads, we forget that initially, it won’t be the case due to initial adoption or that it may never reach the expected scalability.
Opting for Security: The Gradual Approach
Perhaps it’s best to opt for security and start with a well-structured and organized monolith. This will allow you to split it into larger services in the future if needed. Later on, you can further subdivide them into more specialized services that can adapt to handle the load. This way, not the entire system will constantly be under maximum stress. My recommendation is to identify and act as needs arise.
The Case of an Uncontrolled Monolith
Recently, I’ve observed the opposite case: a close-knit team built a monolith to avoid halting development progress and to incorporate more features. However, the monolith grew so much that it became an unstable Jenga tower that no one wants to touch for fear of breaking a feature they don’t even understand. Additionally, adding a developer to that team becomes a titanic task due to the enormous scope of the monolith. Several teams must integrate their pull requests, and there’s always the fear (justified by past experiences) that one line of code could bring down the entire monolith, thus preventing transactions from taking place.
Conclusion
Choosing the monolith is often swimming against the current, as it requires constantly exposing your motivations and convincing even the most staunch supporters. However, I don’t see this as a negative thing. If the problem genuinely necessitates using microservices, you can naturally pivot towards that approach if you start with a well-organized and structured monolith, for instance, following DDD guidelines. But just because this architecture is “unpopular” by default doesn’t mean it should be dismissed. It remains a tool that every samurai developer should be able to appreciate and comprehend.
References
https://world.hey.com/dhh/how-to-recover-from-microservices-ce3803cc
https://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html
Be First to Comment