Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
netflixtechblog.com
Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
1–10 of 35 posts
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#2- can someone kindly explain why there are 2 websites that all claim to be netflix tech blog?
- website 1 https://netflixtechblog.medium.com/
- website 2 https://netflixtechblog.com/
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#3Why is this so badly AI written? Netflix can surely pay for writers.
At this point I refuse to read any content in the AI format of: - The problem - The solution - Why it matters
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#4Articles like this are pretty cool. It’s so interesting to see the behind the scenes that happens whenever we watch a Netflix movie.
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#5- can someone kindly explain why there are 2 websites that all claim to be netflix tech blog? - website 1 https://netflixtechblog.medium.com/ - website 2 https://netflixtechblog.com/
I mean Netflix is dealing with big, important things like container scaling, creating a million micro services talking to each other and so on. Having multiple tech blogging platform on Medium is not something they have a spare moment to think about.
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#6Interesting, another case of removing HT improving performance. Reminds me of doing that on Intel CPUs of a few gens ago.
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#7It took them this long to move from docker to containerd?
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#8I am not familiar with the nitty gritty of container instance building process, so maybe I'm just not the intended audience, but this is particularly unclear to me:
> To avoid the costly process of untarring and shifting UIDs for every container, the new runtime uses the kernel’s idmap feature. This allows efficient UID mapping per container without copying or changing file ownership, which is why containerd performs many mounts
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#9Okay, I'll ask the dumb question: Couldn't you also reduce the number of layers per container? Sure, if you can reuse layers you should, but unless you've done something very clever like 1 package per layer I struggle to think that 50 is really useful?
Re: Mount Mayhem at Netflix: Scaling Containers on Modern CPUs
#10Okay, I'll ask the dumb question: Couldn't you also reduce the number of layers per container? Sure, if you can reuse layers you should, but unless you've done something very clever like 1 package per layer I struggle to think that 50 is really useful?
> 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 in a well-connected server farm.