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

101–110 of 160 posts

Re: The Evolution of Container Usage at Netflix

#101

Post by sdflkd »

rsync wrote: post #98
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…

"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…

> I notice that while youtube continues to buffer video while paused

Not anymore, or at least not for long periods of time.

Re: The Evolution of Container Usage at Netflix

#102

Post by [deleted] »

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.

[deleted]

Re: The Evolution of Container Usage at Netflix

#103

Post by always_good »

aquilaFiera wrote: post #69
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…

This sounds like one of those developer estimates that takes 10x longer than stated.

"Netflix is over-engineered, it's just videos lol"

Classic HN hubris.

For example, Netflix dynamically adjusts video quality on demand. Pretty easy feature. The top HN comment will explain how they would implement that in five minutes -- hypothetically, of course!

Re: The Evolution of Container Usage at Netflix

#104

Post by rubiquity »

throwasehasdwi wrote: post #78
psiclops wrote: post #74

Earlier quoted context omitted.

AFAIK the early go versions of docker used LXC underneath, but that was ~3+ years ago

Sorry . It's hard to keep up these days, I'm 112 in Javascript years.

Wow. Your knowledge of computers is excellent for only being 4 months old.

Re: The Evolution of Container Usage at Netflix

#105

Post by curun1r »

tybit wrote: post #20
yeukhon wrote: post #15

Netflix Engineering team amazes me a lot. They literally took all the available apis, and build their own platform despite some of the features are already in the AWS offerings. I suppose they did it mainly because the native service isn't flexible and robust enough for their use cases. BTW, their opening positions are always prefixed with "senior" title but I guess that makes sense; Netflix builds pretty much everyt…

They specifically only hire seniors, they don't want to provide positions for juniors as they would prefer to pay more for more seniors than pay indirectly for training juniors. I think this reflects poorly on them, just as much as companies that use OSS but don't contribute anything back.

I personally find it short-sighted since I find mentorship opportunities to be a hugely rewarding part of my job. I wouldn't want to take a job in an environment with no junior developers since it would deprive me of that perk. I'd imagine Netflix misses out on other senior engineers for the same reason.

It's also interesting considering a quote I remember from Google about their preference for junior engineers..."fewer bad habits to break."

Re: The Evolution of Container Usage at Netflix

#106

Post by RangerScience »

billfor wrote: post #83
chii wrote: post #35

Earlier quoted context omitted.

"unlock innovation potential"

You have to do it holistically though.

Holistically-caused emergent innovation velocity and acceleration?

...The scary thing is I think that makes sense, actually. I can understand that sentence as a thing I would want - Twiddle with your company culture so that individuals come up with (and make) new ideas, in such a way that as time goes on, their ability to do that grows...?

Makes sense to go at it from a systems view (holistic), rather than components view.

How about -

Homeopathic synergies for creative empowerment and evolution?

That sounds properly almost, but not actually, sensical.

Re: The Evolution of Container Usage at Netflix

#107

Post by pm90 »

acdha wrote: post #96
pm90 wrote: post #80

Earlier quoted context omitted.

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.

I think you're ignoring the fundamental issue when deploying container based services v/s services on a multiple VM's. Usually, the architecture for containers involves spinning up a bunch of VM's and deploying some kind of layer on top of that (either K8s or Swarm or something else). When you deploy containers, they may not be on the same VM, or the overlay network itself may require some kind of communication to another container on another VM. This usually creates a lot more communication b/w hosts and rate limiting becomes the bottleneck.

Re: The Evolution of Container Usage at Netflix

#108

Post by sandGorgon »

aaronblohowiak wrote: post #100
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 t…

This is very interesting. And very indicative of convergence. If someone at the same of Netflix has a strong drive towards cross pollination of talent from device to server, then I suppose the js ecosystem is far more successful than I thought.

Re: The Evolution of Container Usage at Netflix

#109

Post by orf »

always_good wrote: post #103
aquilaFiera wrote: post #69

Earlier quoted context omitted.

This sounds like one of those developer estimates that takes 10x longer than stated.

"Netflix is over-engineered, it's just videos lol" Classic HN hubris. For example, Netflix dynamically adjusts video quality on demand. Pretty easy feature. The top HN comment will explain how they would implement that in five minutes -- hypothetically, of course!

"Responsible 20% of the entire us internet traffic? Solved problem mate, i could do it on a single machine with mongodb. Overengineered!"

Re: The Evolution of Container Usage at Netflix

#110

Post by outworlder »

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.

> I'm 99% sure that Google runs one VM per container

I'm 100% sure you are wrong. You might as well just use VMs.

Containers are not only about safety, you know.

Post reply on HN