Live data from Hacker News

Scaling up the Prime Video audio/video monitoring service and reducing costs

primevideotech.com

31–40 of 526 posts

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#31

I love how some of developers jumped on the serverless bandwagon with some of the least "serverless" workloads first "Let's make our entire website serverless now" erm, no? It's cargo culting of the worse kind

It's the same story as NoSQL. "Let's migrate our transactional data that requires strict referential integrity to CouchDB... Oh, wait..."

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#32
post #20

Earlier quoted context omitted.

microservices make a lot of sense organizationally where each feature team can own their own feature service.

OR each team can write their features as a python package, rust crate, go module to be included in the main app. Libraries, versioned.

Which brings along all kinds of headaches that greater segregation solves. You can go in circles all day about this stuff.

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#33
post #23

Earlier quoted context omitted.

microservices make a lot of sense organizationally where each feature team can own their own feature service.

I mean even then, it's still easier just to share one code-base and then shard service aspects if you have to. You need truly gargantuan scale before things become logically separate code-bases.

Not in my experience.

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#34
Of all the video streaming services I have used, PrimeVideo is the one where the video/audio sync becomes terrible progressively.

It is pretty bad. It happens in 8 out of 10 movies. There is some misconfiguration in their AV transcoding pipeline.

And here, we have an article talking about Monolith vs. Microservices improving user experience.

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#36
Clickbait title. The expensive part was passing around individual frames and the associated S3 operations. It's not clear if they could've kept a distributed architecture but made the work units be chunks of frames or even whole videos. Monoliths can inefficiently use S3 and other cloud services to rack up a huge bill.

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#37
> Moving the solution to Amazon EC2 and Amazon ECS also allowed us to use the Amazon EC2 compute saving plans that will help drive costs down even further.

So various parts of Amazon have to work through the AWS same pricing programs that the rest of us do?

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#38
post #10

I'm pretty convinced that microservices are one of those things that make sense 5% of the time and the other 95% is cargo culting.

microservices make a lot of sense organizationally where each feature team can own their own feature service.

My opinion is that there is a point where that is true... but its at a really high scale. Each team owning a separate service introduces a lot of complexity in managing all the services. There is a point where communication complexity of not microservices overwhelms the complexity implicit in microservices, but i think it is at a really high scale.

You also have to consider things like it is now harder for people to see the system as a holistic whole (the tricky bugs are often in the composition of components) and a lot of subtle effects that beings. Even just increasing the friction for people to move between teams or friction for security people to apply consistent standards across all groups.

Re: Scaling up the Prime Video audio/video monitoring service and reducing costs

#40
post #20

Earlier quoted context omitted.

microservices make a lot of sense organizationally where each feature team can own their own feature service.

OR each team can write their features as a python package, rust crate, go module to be included in the main app. Libraries, versioned.

Yeah I see a lot of things that could be libraries packaged as services, so now each invocation incur in network latency and every transaction needs a two phase commit. And because each service need its own replica, deployment pipeline, and versioned internal api, production and deployment cost skyrocket
Post reply on HN