Microservices, Monoliths & Amazon Prime

TLDR: Amazon Prime has moved away from microservices to a monolith architecture, which has dominated recent tech chatter. The good versus evil talk is entertaining but misses an important point. Monoliths and microservices both have their place and it’s pragmatism, not point scoring, that should chart the direction you head.

Read on:

The news that Amazon Prime was shifting away from microservices to a monolith has kept tech bloggers busy over the last week. After all, this is Amazon, beacon for the serverless-led revolution.

Everything from "serverless is bad" to "I told you so" to "monolith is doomed" - the click bait is popping up all over.

Intriguing yes, but not as cut and dry as some suggest.

As a business that looks deeply at all shapes and sizes of tech while helping investors buy and sell tech-led businesses, we have seen the microservices v monolith question right up close many times.

Our take? Architecture should never be looked at as a one-size-fits-all. If anything it’s the opposite.

There are some key points from the Amazon Prime experience that indicate that this is their take too.

Software architecture is about choosing the right options and trade offs for the situation in hand, not picking the shinest new thing available that will look great on someone’s CV. The Amazon team themselves use the words “in our specific use case” and “case-by-case basis”.

Architecture is about making pragmatic decisions and trade offs. It also should be able to evolve as needs change. That’s what the AWS team did, they evolved their architecture as they learnt more about the system and how it performed. They came up with something that better suited their use case.

In other words, this is a team evolving their system to better suit their specific requirements. In this case it just happens to be that a monolith is more suitable to them.

The AWS team made sensible choices in the first instance, using tech that allowed them to build quickly and scale.

They thought a distibuted architecture would give them scalability benefits, which it did, but it was at a cost.

When they realised that the cost became prohibitive they rearchitected based on cost and found a different way to address scale.

Seems pretty sensible to me.

In the many businesses we work with we continue to find genuine cases where a monolith is the most suitable model. We also find others where serverless miroservices are optimal.

Rather than get caught up in a microservices v monolith point scoring, it's far better to look for the nuance under the hood.

Interested in digging further?

I shared a paper recently on using Tactical Forking as part of a decoupling exercise. Head here.

Or book a callback using the button below and let's talk.