As we close out 2023, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.
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)
