I value developer productivity over machine performance too, but they're doing the opposite here: developer productivity is not helped with an unnecessary second layer of containment.

With containers on top of VMs, you now have to manage which containers run on which VMs (and the cloud provider worries about physical boxes), with a pure container solution you just spawn containers (and the cloud provider worries about physical boxes)

I've been developing for a while with a simple Dockerfile in the root of a given project's output... from there I rarely care about it.. in dev, I can mount the app path to the container for dev, and use environment variables set for any other services that are needed. I'm much more productive with Docker for (Windows|Mac) than I've ever been with the likes of vagrant, or whatever bastion of technology that manages VMs... I don't have to think of the VMs, that's generally IT/Infrastructure/DevOps job. yeah, sometimes I wear that hat, but not when I'm coding.

It is helped if the second layer further automates deployment. I would imagine Netflix is better at understanding its velocity than we are.

Yep but Netflix also has a decade of large scale arch wielded to AWS that we don't.

They might not be deploying containers on VMs on bare metal because they want to, but because they /have/ to.

Mind quantifying this overhead you assume containers-on-metal vs VMs will solve?

It's not assumed, it's widely known VMs have poor IO performance, that one of the main points for containers in the first place. Short ver: GIYF.

If you can't provide numbers, then please talk about what technologies you're assuming are involved that create this overhead.

Compute is cheap. People are expensive.

> Compute is cheap.

Not on AWS.

Word on Hacker News is that Netflix is one of AWS' premiere showcase customers and gets discounts that we couldn't dream of.

If you have dynamic workloads, need to be HA, scalable and multi region, AWS is worth every cent.

If you are running a webapp and a database with a known workload, not so much.

The refrain of shitty developers everywhere.

Performance has never mattered. That's why Internet Explorer's map access implementation was exponential instead of logarithmic (to the size of the map).

That one piece of lazy coding held back Javascript on their platform for years, and I'd argue that it as the most significant cause of their browser's market share plummeting (or at last tied with lack of adblockers).

Seems fine for server-side development. For client-side, please don't kill my battery.