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

351–360 of 526 posts

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

#351

Post by jasonlotito »

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…

> but there's a kind of irony it's come from an internal Amazon team

Not at all. My time working with AWS reps, they never pushed a particular way of doing things. Rather, they tried to make what we wanted to do easier. And the caveat was always to test and make decisions on what was important to us. This isn't an anti-AWS article. Rather, it's exactly the type of thing I'd expect from them. Use the right tool for the right job.

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

#352

Post by bcoughlan »

I quite like the idea of viewing run cost as architecture fitness function https://www.thoughtworks.com/radar/techniques/run-cost-as-ar....

If your architecture has a high cost to develop, test and run when a cheaper architecture meets your needs, it's a sign that you have overengineered. In my experience there is an order-of-magnitude increase in complexity by adopting microservices that only starts to pay off when your org and user base are huge.

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

#353

Post by andai »

boredumb wrote: post #283

AWS has a great business model of people over "optimizing" their architecture using new toys from amazon and being charged through the nose for it. It's amazing how clients that are doing a few requests per second will want a fully distributed, serverless, microservice + dynamodb + s3 + athena + etc + etc, in order to serve a semi-static web app and print some reports off throughout the day and pay 10-50k a month whe…

I haven't dealt with high traffic systems but isn't a few requests per second well within the capabilities of a $5 VPS?

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

#354

Post by raxxorraxor »

Hamuko wrote: post #176
raxxorraxor wrote: post #169

Earlier quoted context omitted.

For some Alexa integrations it is neat and convenient, but I went back to hosting such small interfaces as a service on another server. Not an EC2 instance, just another hosted unmanaged server. They are as cheap as they can get right now.

I'm not really interested in the operational overhead that brings for these small services. Cost-wise they might be just about neck-and-neck, but at least I don't need to worry about the server going down, or having outdated software. Lambda gives me scaling, load balancing and redundancy for that $2.

From experience I say that the operational overhead to host on Amazon isn't trivial at all.

I like AWS and I would still recommend it. It saves some work but also creates new stuff to do. Especially if you also want the costs be manageable. Automatic updates, configuring a firewall + reverse proxy with automatic certificate renewals and you favorite deployment mechanism isn't more complicated or labor intensive than managing a small application with AWS. You need to interface it just like software you run on your server.

One of the services I host needed to be authenticated by IP. Happens. You easily get a static IP on AWS for incoming traffic. No problem and cheap too. Now try to get one for the other direction... Possible too, but maintenance just became at least as labor intensive as hosting your own machine. AWS just has to fit your scenario and I think many people overestimate how comparatively easier it has become to host a server with feasible security today. Chances are your databases would be less public than if you skip the AWS documentation.

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

#355

Post by jabradoodle »

Scarblac wrote: post #336
kypro wrote: post #282

Earlier quoted context omitted.

I know you're joking around, but no, as they also explained a benefit of cloud (and therefore using AWS) is that it can scale flexibly with their customers' businesses. If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost. With cloud if demand drops you can scale up a…

> If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost. Yes, but that sunk cost is probably still lower than what you paid AWS for the option to scale up and down.

You also have to account for the fact your paying upfront the cost for the lifetime of the infra, vs paying monthly.

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

#356

Post by chrisweekly »

tough wrote: post #278
sverhagen wrote: post #243

Earlier quoted context omitted.

If you talk about no vendor lock in, and you'd want to take your database then to a competitor, like Google Cloud, Azure, or on-premises, wouldn't you exactly expect to do a SQL dump and reloading everything? To me, the one-click move from RDS to Aurora you describe is a nice shortcut, but it doesn't invalidate that you can still do the former if you wanted to move to the competitor. Vendor lock in seems more that yo…

Seems a bit of a dark pattern to have shortcut to onboard and not offer the same shortcut to offboard. Just like easy subscribe-online publications that will have you call during 2 hours with a rep pushing you discounts or whatever to cancel such subscription. Just not cool

I'd characterize this asymmetry (convenient shortcut IN, standard export OUT) as a predictable, transparent, minor annoyance -- not a "dark pattern" representing deceptive or unethical practices.

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

#357

Post by [deleted] »

jon-wood wrote: post #224
Aeolun wrote: post #131

Earlier quoted context omitted.

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.

Having occasionally looked at them for workflow driven tasks I'm not sure what the use case for Step Functions is, unless your workflow being called once an hour or something they seem infeasibly expensive for what they offer, and somehow manage to be more complex than just writing some code to model the workflow.

[deleted]

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

#358

Post by NohatCoder »

gtirloni wrote: post #341
Scarblac wrote: post #336

Earlier quoted context omitted.

> If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost. Yes, but that sunk cost is probably still lower than what you paid AWS for the option to scale up and down.

Most companies will pay way more for the engineers maintaining their on-premises infrastructure than they would for AWS. On-premises still makes sense when you reach a certain scale. When you reach a certain scale.

They kind of need to be there anyway, physically maintaining servers turns out to be a miniscule part of the whole maintenance. If you really care about uptime you still need people on-call who can intervene as necessary.

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

#359

Post by jabradoodle »

awaythrow98765 wrote: post #289
kypro wrote: post #282

Earlier quoted context omitted.

I know you're joking around, but no, as they also explained a benefit of cloud (and therefore using AWS) is that it can scale flexibly with their customers' businesses. If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost. With cloud if demand drops you can scale up a…

> If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost. Cloud vendors also mostly sell minimum use packages for discounts in the range of 20 to 80% (called e.g. "committed use discount" or "compute savings plan"). Lots of businesses use those, because two-digit discou…

It's not really the same spot in that your paying monthly rather than upfront. Devs tend to think about total $, the business/accountants do care about Opex vs Capex.

Also it's going to be simpler to provision your base (commited use) on the cloud and then handle bursts on the cloud, than it is to have your base on prem and burst to the cloud.

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

#360

Post by boxed »

dontlaugh wrote: post #338
boxed wrote: post #112

Earlier quoted context omitted.

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…

You can produce multiple docker images from the same codebase quite easily. You can deploy and scale them separately. None of that requires separate repositories or expensive RPC instead of local function calls.

Who said I have separate repositories?
Post reply on HN