I Just Heard That Monoliths Are The Future Of Software Development
Monoliths are the Future?
Tesla has had some bad press around auto-pilot (I have one and I personally think that functionality needs to be renamed). Multiple crashes have happened due to the driver falling asleep. Is that auto-pilots fault? I would say the driver should know not to nap on the 405 freeway (I use my auto-pilot, trust me, I couldn’t sleep with it). 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. In case you have not seen it, this is one of the conversations I am referring to.
Listen to the full original conversation
A very considerate co-worker brought these to my attention (partly to inform me and partly to harass me) the other day and I think they make some very interesting and valid points. To really understand how this can help or harm we need to not just point out the bad but instruct for the good. Let's look at each of these.
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” (Queue ominous music).
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
You might not find this one in your “Head First Design Patterns” book.
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?
rubyn00bie in a post at Hacker News points out these telltale signs:
1. You’re duplicating the tables (information), without transforming the data into something new (adding information), in another database…
2. 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.
3. You push all your data over an event-bus to keep your services “in-sync” …
rubyn00bie (I love the name) hits on some great points. 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) 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 the 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 are 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 breaks, 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.