Live data from Hacker News

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

primevideotech.com

141–150 of 526 posts

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

#141
post #112

Earlier quoted context omitted.

I agree, my intuition would put it to 1% vs. 99% (difficult to quantify of course). I haven't yet seen a project/product which would need microservice architecture for technical reasons. If you need to scale, you can just scale monoliths (perhaps serving in different roles). The use case for microservice architecture is IMHO an organizational / high level architecture driven. I've worked in a big company (20K employe…

I built a little microservice on the side of my monolith for PDF creation. It used headless chrome and ghostscript to render html to a nice PDF. The problem I had with having that code inside the monolith was that it increased my docker image creation for deploys by a lot . And that code pretty much never changed anyway. I did feel a bit embarrassed having to make a microservice after having argued against them so mu…

That honestly seems like a reasonable use case for (what I call) auxiliary services serving the monolith. As I imagine, there's no real business logic, no data storage / transactions, no authentication/authorization (besides the service being hidden in the private network probably).

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

#142
post #70

The title is editorialised to be clickbait. The original title is "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%". They changed a single service, the Prime Video audio/video monitoring service, from a few Lambda and Step Function components into a 'monolith'. This monolith is still one of presumably many services within Prime Video.

The worth here is that Amazon is writing about not going into AWS PaaS native programming (what Lambda is) because it is too expensive for them. That has some newsworthiness and the title kind of reflects that.

> The worth here is that Amazon is writing about not going into AWS PaaS native programming (what Lambda is) because it is too expensive for them.

…and going to a newer AWS service (ECS), instead.

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

#143
post #99

Earlier quoted context omitted.

I am not sure if you’re joking.

I don't see whats funny about my statement. Please elaborate on your definition of monoliths vs scalable microservices.

To most people, "mono" refers to a single codebase, not a single deployed instance. I've worked on many monoliths that run multiple instances in production.

Microservices are no more or less scalable than a monolith. The main benefit of Microservices is allowing multiple teams to work independently from each other without everyone "stepping on each others toes". You can have scalable monoliths and unscalable microservices.

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

#144
I guess what AWS sells is not servers, but software to manage them automatically, to load balance, to replicate etc. Once, in a short time, GPT can write such (pretty standard) software for you, Amazon will, too, go down.

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

#145

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…

Yep, expect the Lambda team to raise hell.

Probably an unpopular take and my experience is almost 10 years old, but I would be surprised to see the Amazon I worked at try to bury something like this. If the product isn't what the customer wants, it isn't what the customer wants - move on and build something the customer wants.

Yes agreed there were some funny business like not selling Chromecast, but the guiding principle was generally to make things customers want...

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

#147
post #56

Earlier quoted context omitted.

From Amazon's PoV, AWS is on-prem ;-)

Tongue in cheek, but > Amazon Web Services, Inc. is a subsidiary of Amazon So it’s technically another company. Another comment seems to confirm this akshually comment ^_^’ https://news.ycombinator.com/item?id=35812230

It’s still all Amazon, the single publicly traded company. Legal shenanigans/optimizations don’t change that. The other commenter was referring to AWS the org over Amazon Retail or Devices (other orgs).

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

#148

As a former AWS employee I can almost guarantee that the person that made the original design got a promotion over it.

They put individual video frames as images in S3. That’s ubsurdly dumb. It’s like putting a frame buffer on an HDD.

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

#149
post #8

I'd be surprised if this doesn't get taken down as it casts AWS lambda in an unfavorable light (and rightly so). That's the impression I have of Amazon's leadership but maybe I'm wrong.

> I’d be surprised if this doesn’t get taken down as it casts AWS lambda in an unfavorable light

“There are use cases where Amazon EC2 and Amazon ECS are a better platform than AWS Lambda” is…not actually a message that anyone involved in AWS has ever been afraid to put forward.

I mean, the whole reason that AWS has a whole raft of different compute solutions is that, notionally, removing any one would make the offering less fit for some use case.

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

#150
post #70

Earlier quoted context omitted.

The worth here is that Amazon is writing about not going into AWS PaaS native programming (what Lambda is) because it is too expensive for them. That has some newsworthiness and the title kind of reflects that.

> The worth here is that Amazon is writing about not going into AWS PaaS native programming (what Lambda is) because it is too expensive for them. …and going to a newer AWS service (ECS), instead.

IMHO, ECS is more closer to IaaS than PaaS. And therefore the lock-in is much less bad than with the serverless PaaS approach
Post reply on HN