Here’s a link to the actual blog post from Amazon: https://www.primevideotech.com/video-streaming/scaling-up-th...

It’s worth noting that the team that wrote the article is just a small part of Prime Video. The headline can definitely be interpreted to mean the entire Prime Video service.

Previous thread -- https://news.ycombinator.com/item?id=35811741

I ended up having a weird debate on Reddit over this. For some reason people seem to think that there is a single better choice and that if you ever go from a monolith to microservices that the monolith failed or whatever.

One person even made the claim that microservices are easier to maintain and debug even tho a single code base that you can use tools on and easily keep in sync seems miles easier to maintain than microservices where you need to version your interfaces so older services continue to work while you upgrade newer versions.

Then they were talking about with a monolith it takes longer to deploy. I assumed their actual deploy tasks took longer, which I can kind of see. But it turns out they were talking about how often they deploy.

It seems nuts to me that people think switching to microservices from a monolith will suddenly mean their poor practices that got their monolith into a bad state will suddenly disappear. From my experience, it generally just means they develop a distributed monolith and have all the same problems with some extra problems.

I'm of the opinion that if you can't develop a good monolith system you can't develop a good microservices system. A good microservices system while it has it's benefits is, in my opinion, harder to architect, develop, and maintain than a microservices based system.

Monoliths have local CPU L1-Cache speeds, distributed microservices have JSON desearlization,searlization, network round trips.

Distributed stateless monoliths can be faster than microservice.

Carbon foot print, cloud bill of too many microservices is probably high.

This sounds like a bad first design:

- didn’t just grab the whole video (or ~1min segment), but individual frames

- put each detector in its own context, needing its own copy

- created a StepFunction for each tiny piece

This never would’ve passed design review when I worked at Amazon because the combinatorial blowout is obvious and predictable.

I’m sure they switched to what was considered good practice even then:

- a single StepFunction per video

- a batch step across segments

- downloading in bulk, to a single container

- running all the detectors together

The problem wasn’t serverless or micro services: this was just bad design.

Article's headline and text mention this was achieved by switching from Lambda to ECS, which makes a lot of sense. Lambda is expensive for frequently used services.

This is a weird article. They moved from Lambdas attached together with Step Functions to have their video monitoring service as its own program. Since some other service is serving video, handling billing, and all the other things Prime Video has to do,, there is no way that could be considered a monolith.

They've gone from serverless to a microservice.

(Which is interesting, but probably doesn't get the clicks.)

As I recall, https://icloudguru.com/ used serverless to serve their video lessons and said they were paying pennies.

I wonder what they're doing differently. I tried searching for the original article, but it's too ambiguous with their general offerings, so no luck.

A service should solve an entire problem and minimize the count of horizontal network calls. Serverless providers wants you to split things into single tasks but the overhead cost per request is high. A task is not a service.

Don't buy retail, buy wholesale, unless you are buying a small amount.

CPU’s are mind boggling fast compared to data transfer. There are exceptions but for the vast majority of workloads reducing data transfers is the easiest optimization.

But scale is the obvious key component, having CPU’s allocated to doing mostly nothing is such a waste.