The case of the Monoliths vs Microservices

If the title of the story feels like a gripping book by Erle Stanley Gardner, there is a reason for it. We will need to dig in a little deep and do some investigative work for ourselves when we come across these architectural design decisions.

The post that started the articles on Linked is the the one from Amazon Prime Video team

There was a lot of reaction to this post, a couple of them listed below:

1. Adrian Cockcroft

So many bad takes — What is there to learn from the Prime Video microservices to monolith story

2. Kelsey Hightower

Monoliths are the future

There were a few good reasons for the Amazon video to make this choice

• Cost — 90% reduction in cost
• Performance — remove the scaling bottlenecks caused by AWS Step Functions

When the post was published, the tech community had views on both sides of the fence on picking monoliths vs microservices. This is another fair reminder to stick to first principles thinking and clean software engineering principles (S.O.L.I.D./DRY/KISS) when picking a solution.

This table from the initial serverless draft deck from Adrian is a good guidance for starters.

I see it not as a polar decision of using Monoliths or Microservices. It’s picking the right tool for the job at hand. Kudos to the Amazon Prime video team for being Agile and simplifying the design and adjusting to scale. Hat tip to Amazon Leadership Principles (Invent and Simplify and Frugality).

Take aways:

1. Using Microservices is a good architectural framework when you have a truly distributed well decoupled system that models a business with distributed disconnected modules/submodules.
2. The business problem should dictate the architecture. Do not try to use Microservices to break a “monolithic” business domain problem into multiple microservices thereby introduce latency, external state management, orchestration issues. Following Domain Driven Design to understand the business domain and defining sub domains and bounded contexts will help you to model the software as close as possible to to the practical business operations
3. Be agile and nimble to change — Any product that is built for scale is subject to change. Pay a close attention to this statement — “built for scale”. The products that scale have ongoing design tweaks. These can be in the form of additional features, adjusting for performance to scale, or ongoing tuning by reviewing the monitoring logs in an automated way. These are really fun problems to solve! These require continued retrospective of the product evolution and making the necessary tweaks to support growth and scale.