Mount Mayhem at Netflix: Scaling Containers on Modern CPUs (netflixtechblog.com)

- 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/

Why 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

Articles like this are pretty cool. It’s so interesting to see the behind the scenes that happens whenever we watch a Netflix movie.

Interesting, another case of removing HT improving performance. Reminds me of doing that on Intel CPUs of a few gens ago.

It took them this long to move from docker to containerd?

I 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

Why does using idmap require to perform more mount?

Okay, 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?

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?

Interestingly. This enhancement has been proposed in July 2025, accepted and merged in August 2025, and released in November 2025. The blog post is also from November. And now it shows here.

Interesting blog post. For what it's worth, I count 7 em-dashes used.