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

The Evolution of Container Usage at Netflix

techblog.netflix.com

Post reply on HN
Print view View original

91–100 of 160 posts

Re: The Evolution of Container Usage at Netflix

#91

Post by emptythought »

zaidos wrote: post #88
RcouF1uZ4gsC wrote: post #52

Netflix seems so over engineered to me. They basically have a catalog of a few thousand movies that are negotiated months in advance of actual use. Basically, they just need to encode them and put them on a box and ship them to edge caches. Caching immutable data scales incredibly well.I would also bet that 99.99% of the movies people actually watch on Netflix, would fit on a single box. In regard to the analytics, t…

That is the core of their product. However, there are a lot of by-products and back office software needed to run the company. As a consumer, you most likely are only perceiving a small percentage of the technology running a company. - Applications for all devices Netflix is on (TVs, Phones, Displays, Roku, Apple TV, etc.) and all the support around it. - Recommendation and analytical software within Netflix. Not eve…

Another thing worth noting is that they still support basically every piece of hardware they ever did. Think built in apps on old smart TVs or early blu-ray decks that haven't been patched in YEARS, devices from before 2009~ even.

You can still watch netflix on an original Wii. That hasn't gotten any OS or software patches since like 2011. That's a long tail of legacy clients to have to deal with.

Re: The Evolution of Container Usage at Netflix

#92

Post by tracker1 »

nailer wrote: post #28
retreatguru wrote: post #12

Earlier quoted context omitted.

It seems they value developer productivity and innovation over machine performance. I find this enlightening.

I value developer productivity over machine performance too, but they're doing the opposite here: developer productivity is not helped with an unnecessary second layer of containment. With containers on top of VMs, you now have to manage which containers run on which VMs (and the cloud provider worries about physical boxes), with a pure container solution you just spawn containers (and the cloud provider worries abou…

I've been developing for a while with a simple Dockerfile in the root of a given project's output... from there I rarely care about it.. in dev, I can mount the app path to the container for dev, and use environment variables set for any other services that are needed. I'm much more productive with Docker for (Windows|Mac) than I've ever been with the likes of vagrant, or whatever bastion of technology that manages VMs... I don't have to think of the VMs, that's generally IT/Infrastructure/DevOps job. yeah, sometimes I wear that hat, but not when I'm coding.

Re: The Evolution of Container Usage at Netflix

#93

Post by gbrown_ »

thealfreds wrote: post #66
gbrown_ wrote: post #63

Is anyone else having issues accessing this? $ curl http://techblog.netflix.com/2017/04/the-evolution-of-container-usage-at.html Access Denied body {margin:0;font-family:verdana,sans-serif;} h1 {margin:0;padding:12px 25px;background-color:#343434;color:#ddd} p {margin:12px 25px;} strong {color:#E0042D;} Access Denied You are attempting to access a forbidden site. Consult your system administrator for details.

Work filtering out netflix.com? Old place use to do it and it would bug me I couldn't read their techblog at work.

Yup that appears to be it. Didn't even realise my workplace filtered anything.

Re: The Evolution of Container Usage at Netflix

#94

Post by [deleted] »

yomly wrote: post #89
lmkg wrote: post #62

Earlier quoted context omitted.

At one point, Netflix video streaming accounted for something absurd like 20% of all Internet traffic in the country. Regardless of whether it "scaled incredibly well," I would imagine there are still novel issues with that much scaling. Reliability also matters differently for video than it does for normal web traffic. It's one thing to shuttle 5GB (or whatever) of data over the course of an hour. It's another thing…

Beat me to it. I am sure a large part Netflix's success is how seamless its products are: there's minimal to no loading time and the video stream is virtually always smooth - including during times of action/high frame rate. Creating a video streaming platform is one thing, but creating a content delivery platform that is effectively as reliable as TV that is also cost efficient is no small task if you ask me...

[deleted]

Re: The Evolution of Container Usage at Netflix

#95

Post by jakon89 »

lima wrote: post #48
richardwhiuk wrote: post #6

Earlier quoted context omitted.

Or use something like GKE where the containers should be running directly on hardware, so you only have one layer.

Containers don't actually run directly on hardware with GCE - there's still a virtualization layer in-between. I'm 99% sure that Google runs one VM per container because that's the only way to make it safe. Anything else would be insane.

1 container per VM? What's the point? If you can bypass container sandbox it's very likely that you can do the same with VM.

Re: The Evolution of Container Usage at Netflix

#96

Post by acdha »

pm90 wrote: post #80
jo909 wrote: post #58

Earlier quoted context omitted.

I agree that the typical NAT or SDN setup around container networking could impact performance or at least require additional resources. But I don't see how that would be any worse on EC2 compared to bare metal or any other hypervisor/provider. Maybe I'm just interpreting too much into the OPs wording and he did not mean that it's a specific EC2 issue.

I've mentioned this in another comment but the short answer is: rate-limiting. Now, Netflix, being a priority customer, may get higher limits and such. But average joe public cloud user should keep that in mind before trying to use EC2 for running containers.

Even if that claim wasn't wrong, it's an unrelated question. If there were rate-limiting problems, they'd apply to using EC2 at all even without involving containers.

Re: The Evolution of Container Usage at Netflix

#97

Post by bjornlouser »

"We run a peak of 500 r3.8xl instances in support of our batch users. That represents 16,000 cores of compute with 120 TB of memory."

I get that they are bragging about their implementation, but what number for peak batch processing instances would they be embarrassed to divulge?

Re: The Evolution of Container Usage at Netflix

#98

Post by rsync »

lmkg wrote: post #62
RcouF1uZ4gsC wrote: post #52

Netflix seems so over engineered to me. They basically have a catalog of a few thousand movies that are negotiated months in advance of actual use. Basically, they just need to encode them and put them on a box and ship them to edge caches. Caching immutable data scales incredibly well.I would also bet that 99.99% of the movies people actually watch on Netflix, would fit on a single box. In regard to the analytics, t…

At one point, Netflix video streaming accounted for something absurd like 20% of all Internet traffic in the country. Regardless of whether it "scaled incredibly well," I would imagine there are still novel issues with that much scaling. Reliability also matters differently for video than it does for normal web traffic. It's one thing to shuttle 5GB (or whatever) of data over the course of an hour. It's another thing…

"Reliability also matters differently for video than it does for normal web traffic. It's one thing to shuttle 5GB (or whatever) of data over the course of an hour. It's another thing to shuttle 5GB of data with no hiccups for an hour."

Speaking of which ...

I notice that while youtube continues to buffer video while paused, netflix (and many, many other video players online) do not.

So while netflix will auto-adjust quality for you in response to a bad net connection, you can't just pause it, go brush your teeth, and come back with a big enough buffer to avoid skips through the entire video.

When did video players stop buffering-on-pause ? Why was that choice made ?

On the other end of the spectrum is whatever video player showtime online uses - it does not adjust quality and it does not buffer on pause. Basically it was built for perfect Internet connections and nothing else.

Re: The Evolution of Container Usage at Netflix

#100

Post by aaronblohowiak »

sandGorgon wrote: post #40

> Today, we are in the process of rebuilding how we deploy device-specific server-side logic to our API tier leveraging single core optimized NodeJS servers Is this the core Netflix API ? have they moved from java - previously, their entire open source contributions were around java ( https://netflix.github.io/ ). Hystrix repo was updated barely a day ago. For me, this is more interesting than the VM part.

It is a splitting of the device-specific stuff from the general coordination stuff. So the "core API" as you put it remains in java while letting the device teams write their code in node (much of our UI teams are experts in JS already).

Hystrix is important and won't be going away any time soon.

More info: https://www.slideshare.net/mobile/KatharinaProbst/the-new-ne...

Disclaimer: I'm on paternity leave and not on those teams, but we've talked publicly about this stuff recently..

Post reply on HN