Monoliths are the Future?
Tesla has had some bad press around auto-pilot. Multiple crashes have happened due to the driver falling asleep. Is that auto-pilot's fault? I would say the driver should know not to nap on the 405 freeway. So, do we remove auto-pilot altogether or do we learn to use it properly?
We are in the same position in software architecture. People jump on buzzwords and new ideas as if they will fix everything. Lately, this has been centered around the use of microservices and breaking up monoliths. There have been interesting conversations about this.
Why Are Monoliths The Future?
So, why do some think that we will go back to monolithic application stacks?
"Monoliths are the future because the problem people are trying to solve with microservices doesn't really line up with reality." — KELSEY HIGHTOWER
I believe that this is 100% true. The word "Microservice" has been used as a magic pill to fix everything from a dysfunctional organization to a badly engineered system. But, I don't think that the alternative is to go back to "The Monolith."
We are dealing with the expectation versus reality paradigm. Most of this can be boiled down to one of these:
- Lack of planning when it comes to the service layout
- Lack of experience with distributed architectures
- Lack of time for testing and implementation
The Distributed Monolith Pattern
"Now the codebase it's so bad, and you say 'You know what we should do? We should break it up. We're gonna break it up and somehow find the engineering discipline we never had in the first place.' And then what they end up doing is creating 50 deployables, but it's really a distributed monolith." — KELSEY HIGHTOWER
This, unfortunately, is way too common. As the "Magic Pill" people fall into the mindset that smaller is faster and in return, better. Microservices will not fix a bad Monolith. If you make a bad Lasagna it doesn't matter how many pieces you cut it into, its still bad.
Do You Have A Distributed Monolith?
Telltale signs:
You're duplicating the tables (information), without transforming the data into something new (adding information), in another database…
Service X does not work without Y or Z, and/or you have no strategy for how to deal with one of them going down.
2.5 Bonus: there is likely no way to meaningfully decouple the services. Service X can be "tolerant" of service Y's failure, but it cannot ever function without service Y.
- You push all your data over an event-bus to keep your services "in-sync"…
These items all have to be considered in the designing phases. Interdependent services need to either 1) be combined in a microservice, 2) use a queue pattern to ensure that the service can process the item (when available), or 3) both systems can sit behind a micro-orchestrator to handle error conditions.
Event buses are an important part of a microservice infrastructure. But, I believe they should be relinquished to notification only, not data synchronization.
If you move from a Monolith to Microservices you have to use this as the opportunity to re-evaluate and update. The chances are that if you are at this decision point you are talking about a system that has been around for a while. You cannot look at this as a cut & paste coding exercise, you have to go back to step one.
Properly Breaking Up a Monolith
So how can you approach this task without a mental breakdown or giving up?
Plan More Than You Think
You need to have intimate knowledge of the Monolith. For you that might mean that you need to research and understand aspects that you are not familiar with. You need to think of this as a bunch of independent subsystems not as one big system in smaller parts.
It may not seem important, but the way you look at it has a huge impact. This viewpoint will shape every decision you will encounter.
Implement With The Right Viewpoint
For instance, say you have a monolithic application that is an eCommerce platform. You have decided to break the Monolith. You have a few options:
- Smaller is Better — Find the logical division points in the application, use them to create smaller applications that are strongly tied together. Deploy these and claim victory, you are a Microservice master!
- Smaller is Smarter — Take the time to uncover the core capabilities of the Monolith. Consider these as separate end-to-end applications that are required to live independent from the eco-system. Try to expand its ability to handle more use cases. Deploy a stateless application.
So in our example, we might break things up into multiple smaller parts: Cart, Product, Order, etc. In both cases, we may choose the same division points but what we build will be very different. In one case we would separate the services but there would be tight coupling between them. In the second scenario, we look to create a full set of functionality for each.
Ask yourself this for each microservice you create:
"Could I take this microservice and place it in another architecture without making changes to it and fully use all of its capabilities?" — A Self Reflective Engineer
If your answer is yes, you started with the right viewpoint. If not, you have too much coupling, start again.
Break It Up Without Breaking Down
Do I think we should go back to monoliths? No.
Many things follow the microservice pattern, like your car. Your car is made up of multiple smaller components. Some of those components, like your brakes, work for cars other than yours (like a fully independent microservice). Other components, like your windshield, are specific for your make and model (like microservice components that are interdependent).
There is a careful balance that will take planning to implement properly. Like any good architecture, it is never fixed and will evolve over time.
"The second you hit save on a Architecture diagram, its already invalid" — A Wise Architect
A good microservice solution will start with the recognition that you are either making a change because you want to or you need to. If you need to, recognize why that is and avoid the root causes like the plague.
Microservice Reminders
- Microservices are not just about reducing size.
- Your implementation success will depend on the amount of planning you put in.
- There is a wealth of information and design patterns online to be successful.
- Use this as an opportunity to re-create your services and update them.
- Reevaluate your underlying storage and technologies.
- Friends don't let friends "Drink and Design" a software system.