[tannhaeuser]

But the question is why did we arrive at containers and one OS per "microservice"? Has memory-to-IO bandwidth, scalability requirements, or whatever really changed (like in orders of magnitude) to warrant always-async programming models, even though these measurably destroy process isolation and worsen developer efficiency? After almost 50 years of progress? Or is it the case that containers are more convenient for cloud providers, selling more containers is more profitable, inventing new async server runtimes is more fun and/or the regular Linux userspace (shared lib loading) is royally foobar'd, or at least cloud providers tell us it is?

[bluetomcat]

The traditional Unix IO model broke with the Berkeley sockets API introduced in 1982. The obvious "Unix" way to handle a TCP connection concurrently was to fork() a separate process servicing the connection synchronously, but that doesn't scale well with many connections. Then they introduced non-blocking sockets and select(), then poll(), and now Linux has its own epoll. All these "async programming models" are ultimately based on that system API.

[nijave]

>But the question is why did we arrive at containers and one OS per "microservice"?

I think it makes more sense if you consider the interim transition to other isolation mechanisms like commodity servers instead of mainframes, VMs, then containers as a way to get more isolation/security than traditional multi user model with less overhead than an entire machine.

Obviously cloud providers want to push for solutions that offer higher densities but those same cost/efficiency incentives exist outside cloud providers.

I'd say we've more accurately been trying to reinvent proprietary mainframes on commodity hardware.