Microservice Architecture: Amazon Article Reinforces Its Benefits

Recently, the Video Quality Analysis (VQA) team at Amazon Prime Video nearly broke the internet by publishing an article on how they refactored a microservice architecture to a monolithic architecture. The horror.

The title – “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%” – and subsequent reactions to the post had plenty of hyperbole worthy of prime-time news. I am not convinced their refactor was as drastic as it was made out to be. Let’s dive in.

For several years, we have been told the only way to architect solutions is through a microservice architecture. The days of 3-tier monolithic applications had run their course and were considered “outdated.”  Today, we see those application architectures still being used in production, and we use words like “modernize” in a pejorative context as an undercurrent that they need to be re-written – regardless if they do the job just fine or not.

To clarify, it really depends on how one defines microservice. At microservices.io, it’s defined as:

“an architectural style that structures an application as a collection of services that are:

• Independently deployable
• Loosely coupled
• Organized around business capabilities
• Owned by a small team

The author of the article treats the three components of the defect detection system as separate microservices.

The media conversion service, detector service and aggregation service can indeed be maintained as separate code bases and certainly independently deployable. I would argue that each of those microservices independently are NOT a business capability. They are utilities that individually provide little value to the business but collectively orchestrated – provide a business capability.

It is likely also true the same team that worked on or owned all three of those services – I cannot state for fact – but I doubt three separate teams maintained the code bases for these three components.

This defect detection service or tool is a microservice in the larger Amazon Prime Video ecosystem – that has been implemented as a distributed application. An important distinction.

I am not trying to get into a semantic debate and play sharpshooter on the AWS team. The point I believe the author was trying to make is that a monolithic process is not always bad, and I agree with him.

As the author states:

Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis.

This is so true. Just like speed cannot be the only thing we measure “good” or “bad” – as in software development – distributed vs. single process applications (or monolithic vs. microservice) need to consider factors such as scale, extensibility, observability, cost and even team capability. Gaining scale and extensibility while losing the ability to easily observe and troubleshoot may not be worth it.  Especially if you must hire new skills for the increased complexity.

One thing seems to have been missed in the hoopla: Because Amazon Prime Video had a defect detection tool implemented as a microservice, they had the flexibility to change the architecture of their service from distributed to single process. Other parts of the Amazon Prime Video offering were not tightly coupled to implementation of the monitoring tool.

Contrary to the article’s title, I believe the article reinforces the benefits of a microservice architecture while also highlighting challenges with serverless services and distributed systems.

That does not always make microservices the right choice; only, Always and Never can be very dangerous words.