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

91–100 of 526 posts

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

#91

Post by NBJack »

tyfon wrote: post #29
alkibiades wrote: post #15

Earlier quoted context omitted.

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

Until one team need a feature in another service that makes their development grind to a halt and the other team is not prioritizing. I have only seen this from the business side (I'm not a developer), but I have seen teams start coding in another teams service just to be able to proceed. It's not always good to create silos like this either.

Sounds like someone has been in the trenches of a certain online retail company.

As a developer, I have certainly seen the same. Pretty sure this very scenario is where I heard the term "away team" used in the industry: send your folks over to change things, and under our guidance they can check in the code.

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

#93

Post by Garlef »

princevegeta89 wrote: post #44
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 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"?

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

#94

Post by kstenerud »

jjevanoorschot wrote: post #57

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 subtitle is "The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs."

And the article itself mentions the 90% cost reduction.

So the title seems pretty much in-line with the original intent.

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

#95

Post by benjaminwootton »

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…

That was my reaction too. I know Microservices doesn’t equal cloud, but putting a big monolith on a big server is tangential to AWS interests to say the least!

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

#96

Post by zoover2020 »

LVB wrote: post #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?

There are internal discount rates per service (IMR), but there's no such thing as free lunch

Also, Prime Video isn't part of AWS but the consumer / devices / other part of (retail) Amazon.

Source: worked there

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

#98

Post by mplewis »

freeone3000 wrote: post #61
kristopolous wrote: post #55

Earlier quoted context omitted.

There's a bunch of things I'd like to have them do. If they could span across machines like clusters that would be amazing. If I could trivially package them up and deploy them locally with intrinsically less effort and wall-time then the old way, that'd be amazing. If I could somehow get the horizontal scaling promises and redundancy as some kind of built-in, like I can with say, memcache, that's be cool. If I could…

Your asks seem easily answered with docker + kubernetes. Actually, this is in fact the use case for kubernetes — a fault tolerant distributed system running arbitrarily, simply packaged code. This has to be what you’ve tried — what issue are you running into?

The issue I encounter is the overhead in setting up a repeatable, easy-to-use dev environment, and working out the bugs locally before I push to a prod-like system.

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

#99

Post by bberrry »

config_yml wrote: post #54
bberrry wrote: post #26

I wouldn't call it a monolith as the number of instances could be scaled up. Mono implies single instance. They just combined multiple microservices into a larger one.

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.

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

#100

Post by est »

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.

> make sense 5% of the time

Micro-services were invented by an outstanding software outsourcing company to milk billable hours and offload responsibilities in large org.

If you want to save cost and not-that-large business, go for monolith-first. Keep it modular.

Post reply on HN