Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

primevideotech.com

Post reply on HN
Print view View original

131–140 of 526 posts

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

#131

Post by Aeolun »

lastangryman wrote: post #68

My word. I'm sort of gob smacked this article exists. I know there are nuances in the article, but 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". Which is good lesson, and a good story, but there's a kind of irony it's come from an internal Amazon team. As another…

I feel like it’s an object lesson in using the right solution for a problem. Step functions do not appear to me to be something that you’d use for things that need to be executed multiple times per second.

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

#132

Post by vinay_ys »

AWS is truly a customer first company. I been AWS customer in its early days (2006-2012) and then recently (2022-now). And they have been consistent in being customer-first. In the last year, they have proactively helped us cut our AWS spend by multiples. I'm not surprised at all by this article coming from within Amazon. Kudos for maintaining such a culture.

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

#133

Post by oblio »

mlhpdx wrote: post #78
ad-astra wrote: post #7

Storing individual frames in S3??? Insanity! Their initial distributed architecture is unbelievable.

> AWS Step Functions charges users per state transition Apparently they didn’t know about the EXPRESS execution model, or the much improved Map state. The story seems to be one of failing to do the math and design for constraints rather than an indictment of serverless. I have to agree with others - it is amazing this article saw the light of day.

Someone should save the article :-D

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

#134

Post by andreiursan »

Garlef wrote: post #93
princevegeta89 wrote: post #44

Earlier quoted context omitted.

Microservices have lately seemed to me to be a buzzword for the ears of executives and stakeholders. To someone who isn't technical enough, it seems really "cool" from the outside, but on the inside, it's more than often a shitshow with teams and managers messing around to get these services working with each other properly while wasting a lot of time. If you ask me, if the time and focus is invested properly, it wou…

> lately "lateley" as in "for the last 5 years"?

more like ~10 years. 2014: https://martinfowler.com/articles/microservices.html but also 2015: https://martinfowler.com/bliki/MonolithFirst.html

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

#135

Post by cglong »

bawolff wrote: 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.

My team owns an API monolith that hosts several completely unrelated endpoints. I keep thinking this would be a good candidate for breaking into microservices, but I do wonder if I'm buying into the hype.

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

#136

Post by dragonwriter »

lastangryman wrote: post #68

My word. I'm sort of gob smacked this article exists. I know there are nuances in the article, but 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". Which is good lesson, and a good story, but there's a kind of irony it's come from an internal Amazon team. As another…

> Which is good lesson, and a good story, but there’s a kind of irony it’s come from an internal Amazon team. As another poster commented, I wouldn’t be surprised if it’s taken down at some point.

Why? Using the model they switched to (which uses a different set of AWS services) instead of the model they switched from is a recommendation that the AWS tech advisers that are made available to enterprise customers will make for certain workloads.

Now when they do that, they can also point to this article as additional backing.

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

#137

Post by sgtnoodle »

vivegi wrote: post #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.

Of all the streaming services that have irritated me, I can't recall any serious technical problems with prime. I suppose I have a vague memory of poor AV sync that could have been on prime, it was always a problem at the start of streaming that would work itself out after a few seconds.

Netflix's shiny new compression scheme a couple years ago didn't work on my Sony TV's buggy silicon. The only way I got that fixed was by knowing someone on the inside.

Hulu usually can't make it through an episode without the video freezing at least once. Sometimes it just refuses to work at all until I completely reboot the TV.

HBO Max's UI is just really cheesy and slow, but whatever it's fine.

Paramount+ is my new favorite to hate on. The UI is maddeningly glitchy and lethargic. I pay for no ads, but it plays ads anyway, on Star Trek episodes from 1996. It doesn't remember progress in a show more than once every week or two, just enough to remind you that it's supposed to be a feature. On my phone, it doesn't hide the typical menu overlays unless I do a complex sequence of finger taps. One time I tried to file a bug report from inside the logged-into app, and I got an email back claiming that they would love to consider my concerns but can't because they don't have an account associated with my email address.

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

#138

Post by radicalbyte »

ikiris wrote: post #6

Sending video frames between services is expensive, also doing per state transition hosting on things doing state transitions multiple times per second in a single stream is also expensive... Like, did they even think about cost when designing this the first time?

It stinks of a lack of very basic engineering skills to me combined with a large dose of CV-driven-development.

The latter of course helping Amazon market "serverless" to the unwashed masses as a "solution".

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

#139

Post by IceHegel »

camgunz wrote: post #119

If you came to me with a design that included passing individual video frames through S3 instead of RAM I would honestly think you were joking. What a wild article.

I’m all for big, fast, monoliths - but I’m not sure I want to hear it from the team that saved video frames to s3 in their AWS Step Function video encoder.

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

#140

Post by __turbobrew__ »

YetAnotherNick wrote: post #114
bawolff wrote: 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 works better if you don't trust other team. While having trust seem like a basic thing, this is absolutely not the case for a lot of companies. With microservices, it is easy to see services which are down or have high error rate or latency, have clear API contract and call out the team for breaking API contract, and assign cost for which the teams have incentive to reduce, or at least not increase it.

Another pain with monoliths is that they can only be deployed if the entire monolith is passing all tests. When you cannot deploy your changes because someone else on an entirely orthogonal team broke something in the monolith which is not related to you it gets old really quick.

Large monolithic repos with many independent targets for testing and deployment work the best at huge scales. If you are only a few hundred engineers, monorepo with monolithic deployments and tests work fine.

Post reply on HN