Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Amazon Prime Video has ditched its use of microservices-cum-serverless, reverting to a traditional, monolithic architecture. It vastly improved the workload’s cost and scalability.
I’m Shocked. Shocked.
Analysis: But it depends what you mean by “monolithic”
None of this is a surprise to us old-skool devs. Although the team did need to clone the monolith a few times, splitting up the tasks so as to retain enough scaling headroom. But it shouldn’t be at all shocking—unless you’ve drunk the µservices Kool-Aid.
What’s the story? Joab Jackson reports—“Return of the Monolith”:
“Hopelessly archaic”
The engineering team at Amazon Prime Video has been roiling the cloud native computing community with its explanation that … a monolithic architecture has produced superior performance over a microservices- and serverless-led approach. … Shocking!
…
In theory, the use of serverless would allow the team to scale each service independently. It turned out … they hit a hard scaling limit at only 5%. … Initially, the team tried to optimize individual components, but this did not bring about significant improvements. So, the team moved all the components into a single process, hosting them on … EC2 and … ECS.
…
The IT world is nothing but cyclical, where an architectural trend is derided as hopelessly archaic one year [and] the new hot thing the following year. Certainly, over the past decade when microservices ruled—and the decade before when web services did—we’ve heard more than one joke … about “monoliths being the next big thing.” Now it may actually come to pass.
Not just a scaling advantage? Rafal Gancarz also notes huge cost savings—“Prime Video Switched from Serverless to EC2 and ECS”:
“Single application process”
Prime Video, Amazon’s video streaming service … achieved a 90% reduction in operational costs as a result. … The initial architecture of the solution was based on microservices … implemented on top of the serverless infrastructure stack. The microservices included splitting audio/video streams into video frames or decrypted audio buffers as well as detecting various stream defects … using machine-learning algorithms.
…
The problem of high operational cost was caused by a high volume of read/writes to the S3 bucket storing intermediate work items … and a large number of step function state transitions. … In the end, the team decided to consolidate all of the business logic in a single application process. … The resulting architecture had the entire … process running [as] instances distributed across different ECS tasks to avoid hitting vertical scaling limits.
Horse’s mouth? Marcin Kolny, a Prime Video dev—“The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs”:
“Also simplified the orchestration”
We took a step back and revisited the architecture. … The main scaling bottleneck in the architecture was the orchestration management that was implemented using AWS Step Functions. Our service performed multiple state transitions for every second of the stream.
…
We realized that distributed approach wasn’t bringing a lot of benefits in our specific use case, so … we moved all components into a single process to keep the data transfer within the process memory, which also simplified the orchestration logic. [Then] we cloned the service multiple times, parameterizing each copy with a different subset of detectors.
Is this an Amazon PR fail? David Heinemeier Hansson scoffs—“Even Amazon can’t make sense of serverless”:
“Microservices is a zombie architecture”
Now the real-world results of … the microservices craze that was tearing through the tech industry … are finally in. And it’s clear that … microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse.
…
SOA makes perfect sense at the scale of Amazon. … But, as with many good ideas, this pattern turned toxic as soon as it was adopted outside its original context, and wreaked havoc once it got pushed into the internals of single-application architectures.
…
Microservices is a zombie architecture. Another strain of an intellectual contagion that just refuses to die. It’s been eating brains since the dark days of J2EE. [But] some bad ideas simply refuse to die no matter how many times you kill them.
Braaaiiinns. lastangryman is too shocked to be angry:
My word. I’m sort of gob smacked [Marcin Kolny’s] article exists.
…
My first impression was it’s saying “we went back to basics and stopped using needless expensive AWS stuff that caused us to completely over architect our application and the results were much better.” … There’s a kind of irony it’s come from an internal Amazon team.
Jumping in, Amazon CTO Dr. Werner Vogels is het daar niet mee eens—“Monoliths are not dinosaurs”:
“There are few one-way doors”
There is not one architectural pattern to rule them all. … My rule of thumb has been that with every order of magnitude of growth you should revisit your architecture, and determine whether it can still support the next order level of growth.
…
There are few one-way doors. … If there are a set of services that always contribute to the response, have the exact same scaling and performance requirements, same security vectors, and most importantly, are managed by a single team, it is a worthwhile effort to see if combining them simplifies your architecture.
You say potato and I say potato. Adrian Cockcroft calls the whole thing off—“So many bad takes”:
“Popular trigger meme”
And the internet piled in with opinions and bad takes, mostly missing the point. … The Prime Video team had followed a path I call Serverless First, where the first try at building something is put together with Step Functions and Lambda calls. … When you are exploring how to construct something, building a prototype in a few days or weeks is a good approach.
…
They were able to re-use most of their working code by combining it into a single, long running microservice that is horizontally scaled using ECS, and which is invoked via a lambda function. … The problem is that they called this refactoring a microservice to monolith transition, when it’s clearly a microservice refactoring step.
…
If you need sustained high traffic, low latency and higher efficiency, then you should re-implement your rapid prototype as a continuously running autoscaled container, as part of a larger serverless event driven architecture, which is what they did. … The result isn’t a monolith, but there seems to be a popular trigger meme nowadays about microservices being over-sold.
LOL. “A single, long running microservice”??? Us old-skool devs are yelling, “Get off my lawn.” u/lightwhite met one at a formative age:
When I started my career in IT as a baby sysadmin, I had a mentor … the greatest teacher ever. … One day, I went to him shyly to ask him for his advice for a task I couldn’t figure out. I don’t know what it was, but the solution had too many tools chained to do something.
…
He looked at it, laughed his lungs out, wrote a small script in Perl in 5 minutes and it did the job. Then looked at me with this fatherly look and told me, “You don’t need a machete to make a fruit salad.”
…
This microservice craze is starting to overcomplicate everything everywhere. … I don’t need to bootstrap a whole cluster with 500 lines of configuration to host a small service. I mean you can do it … doesn’t mean you should.
Meanwhile, presidenteloco cuts to the chase:
What this seems to be mainly saying [is] doing stuff in memory is orders of magnitude faster than serializing, inter-process communicating, deserializing. Yup.
The Moral of the Story:
Life shrinks or expands in proportion to one’s courage
—Anais Nin
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or [email protected].
Image: Megan Ruth (via Unsplash; leveled and cropped)
