It's not impolite to point out impoliteness.
Public cloud like AWS and GCP does all the networking, volume management and everything else for you - for free. That's arguably one of the reasons for using it in the first place. There is no need to put something on top. That's kinda the whole point here.
a) I don't necessarily agree with that statement - witness HashiCorp's recent raise:
https://www.sdxcentral.com/articles/news/hashicorp-scores- 175m-funding-round-5b-valuation/2020/03/
b) The vast majority of container users run their workloads on public clouds like AWS and GCP which run on top of virtual machines to begin with.
I'm not stating you need to use terraform (I definitely don't) - what I'm saying is that you can use the underlying orchestration provided by the cloud of choice - be it the networking or the volumes. There's no need to replicate that on top as container workloads do. When people who speak of kubernetes/container complexity - this is what they are complaining about.
If you look at a lot of the configuration mgmt software out there - chef/puppet/ansible/salt/terraform/etc. it all involves configuring a linux system whereas with unikernels it's literally just one application and instead of having to plumb your network together or ensure that your workloads or 'stateless' vs 'stateful' you just use the underlying cloud facilities. That's the magic. It actively removes complexity from the provisioning.
A lot of older unix abstractions have been heavily broken when we all started running tens, hundreds, or thousands of vms on the public cloud. Users are relegated to IAM. Most databases can't even fit on a single server. Many webapps are load balanced to begin with.
The classic monolithic 'server' named Mars or Jupiter outgrew itself cause we all were consuming so much software. So part of what we are asking here is why do we have 2 layers of linux? We have the underlying one for the hypervisor but all these legacy abstractions are still present in the guest.
Container orchestration is not the first silver bullet that has grown a large following that makes money off of it, whether reasonable or not. I do have a question though. Say you have a bunch of microvms processing your workload or serving dynamic pages. How are you going to manage your fleet of MicroVMs? Would you perhaps write a microvm orchestrator of some sort?
Got a huge kick out of the first comment on the linked page:
> You know what you call a "micro-VM that's purpose-built to run one application" if you're a Unix person?
> A process.
> And now we've come full circle. Everything old is new again!