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

Mount Mayhem at Netflix: Scaling Containers on Modern CPUs

netflixtechblog.com

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs

#31

Post by seabrookmx »

DeathArrow wrote: post #13

So using the "old" container architecture could have been better than wasting time implementing the new architecture, dealing with the performance issues and wasting more time fixing the issues?

This completely ignores all their reasons to move to the new architecture in the first place.

My understanding is that they had a mostly in-house architecture (that predated Kubernetes' rise) and by moving to this new platform, they are now much more closely aligned with standard Kubernetes. They can now utilize EKS for their control plane, and leverage the many community provided features previously unavailable to them.

Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs

#32

Post by ActorNightly »

Hikikomori wrote: post #23
ActorNightly wrote: post #14

Earlier quoted context omitted.

Its not a dumb question. It seems like when it comes to these supposed high tech enterprise solutions, they spend so much churn in doing something that is very complex and impressive like investigating architecture performance when it comes to kernel level operations and figuring out the kernel specifics that are causing slowdowns. Instead they can put that talent into just writing software without containers that ca…

Content is not streamed from these containers.

Then there is even less reason to spin up new containers at the rate they are doing it.

Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs

#33

Post by Hikikomori »

ActorNightly wrote: post #32
Hikikomori wrote: post #23

Earlier quoted context omitted.

Content is not streamed from these containers.

Then there is even less reason to spin up new containers at the rate they are doing it.

So a new instance should stay idle for some time?

Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs

#34

Post by eliaspro »

seabrookmx wrote: post #12
gucci-on-fleek wrote: post #10

Earlier quoted context omitted.

> unless you've done something very clever like 1 package per layer I struggle to think that 50 is really useful? 1 package per layer can actually be quite nice, since it means that any package updates will only affect that layer, meaning that downloading container updates will use much less network bandwidth. This is nice for things like bootc [0] that are deployed on the "edge", but less useful for things deployed…

It doesn't work this way really? It's called a layer because each layer on top depends on the layers below. If you change the package defined in the bottom most layer, all 49 above it are invalid and need re-pulled or re-built.

grahamc wrote down how to optimize this (within the constraints of max 128 layers supported by OCI) to categorize/prioritize packages by popularity/dependencies which lead to dramatic speed-ups for pulling updates or related images.

https://grahamc.com/blog/nix-and-layered-docker-images/

Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs

#35

Post by ActorNightly »

Hikikomori wrote: post #33
ActorNightly wrote: post #32

Earlier quoted context omitted.

Then there is even less reason to spin up new containers at the rate they are doing it.

So a new instance should stay idle for some time?

No, you can autoscale EC2s. The point is that you should be able to run all your software without containers, which means that you aren't wasting cpu cycles with container overhead.

Depending on the EC2 instance it also may be cheaper to have a reserved EC2 instance sitting idle rather than paying for capacity reservation and spinning it up every day as the user count goes through its regular wave.

Post reply on HN