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

41–50 of 160 posts

Re: The Evolution of Container Usage at Netflix

#41

Post by jo909 »

nailer wrote: post #3

They're killing performance (one of the main reasons to use containers) and adding a massive extra layer of management if they're running containers on EC2. I suspect Netflix are too wedded to AWS (which is weird as Amazon is their biggest threat) but Triton or Red Shift (both of which actually isolate containers using SmartOS and SELinux respectively) make way more sense for other people who want to use the blazing…

Could you elaborate on why containers don't perform on EC2?

I'm not running that combination myself so I wouldn't really know, but I'm not aware of problems with that specific combination or can think of anything obvious.

Re: The Evolution of Container Usage at Netflix

#42

Post by 1_2__3 »

qeternity wrote: post #18
retreatguru wrote: post #12

Earlier quoted context omitted.

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

Compute is cheap. People are expensive.

The refrain of shitty developers everywhere.

Re: The Evolution of Container Usage at Netflix

#43

Post by draw_down »

skrater wrote: post #34
dominotw wrote: post #31

> We implemented multi-tenant isolation (CPU, memory, disk, networking and security) using a combination of Linux, Docker and our own isolation technology. Curious what their 'own isolation technology' does that docker doesn't. Also, what does Fenzo do that marathon doesn't . Looks like Fenzo sits on top of marathon and sends it some sort of recommendations for scheduling. I need to find a good example of what this i…

Justifying high engineering salaries, i see this a lot in great companies.

Yeah, boo on those evil developers who want to make money and work on interesting stuff. What are you, their CFO?

Re: The Evolution of Container Usage at Netflix

#45

Post by lima »

nailer wrote: post #3

They're killing performance (one of the main reasons to use containers) and adding a massive extra layer of management if they're running containers on EC2. I suspect Netflix are too wedded to AWS (which is weird as Amazon is their biggest threat) but Triton or Red Shift (both of which actually isolate containers using SmartOS and SELinux respectively) make way more sense for other people who want to use the blazing…

SELinux is NOT isolation. The main issue is the large kernel attack surface and SELinux, while important, only solves a small part of that.

Re: The Evolution of Container Usage at Netflix

#47

Post by throwasehasdwi »

jo909 wrote: post #41
nailer wrote: post #3

They're killing performance (one of the main reasons to use containers) and adding a massive extra layer of management if they're running containers on EC2. I suspect Netflix are too wedded to AWS (which is weird as Amazon is their biggest threat) but Triton or Red Shift (both of which actually isolate containers using SmartOS and SELinux respectively) make way more sense for other people who want to use the blazing…

Could you elaborate on why containers don't perform on EC2? I'm not running that combination myself so I wouldn't really know, but I'm not aware of problems with that specific combination or can think of anything obvious.

Containers use LXC in the Linux kernel underneath. Overhead is even lower than HVM virtualization which is a couple percent for most things. Containers are really just a smarter way of dividing resources between users on a shared linux box, something that's been going on since the dawn of time.

It might add another 1% overhead for most tasks to run containers on HVM virtual machines.

The one giant exception is network performance. The network is usually virtualized at the VM level, unless you have an "enhanced networking" VM with SR-IOV enabled. For containers it's virtualized a second time.

This makes the combo potentially terrible if you're trying to run high bandwidth stuff on low performance VM's.

I still like the combo because it allows you to give the big ole finger to AWS if they try to lock you in one day. Since your containers are isolated from the VM you can easily spin them up pretty much anywhere else.

Re: The Evolution of Container Usage at Netflix

#48

Post by lima »

richardwhiuk wrote: post #6
nailer wrote: post #3

They're killing performance (one of the main reasons to use containers) and adding a massive extra layer of management if they're running containers on EC2. I suspect Netflix are too wedded to AWS (which is weird as Amazon is their biggest threat) but Triton or Red Shift (both of which actually isolate containers using SmartOS and SELinux respectively) make way more sense for other people who want to use the blazing…

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.

Re: The Evolution of Container Usage at Netflix

#49

Post by meddlepal »

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.

They use a mix of everything but most of the back end microservices are JVM tech - Java, Groovy and I heard they were using some Kotlin awhile ago.

Re: The Evolution of Container Usage at Netflix

#50

Post by barrkel »

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 think it's a refreshing change from the ageism of much of the rest of the industry. It probably gives them a compounding competitive advantage.
Post reply on HN