Because it's hard to find programmers who can do it.
Overwhelming majority of programming today is happening in userspace. And even there, it's typical to be far removed from system interfaces. Popular language runtimes s.a. Python or Java or JavaScript create a layer of obfuscation on top of system interfaces.
Programmers who could realistically pull this out are either in embedded field or in OS / system field. OS / system is very tiny compared to everything else, but even with embedded being larger, the problem is also the lack of expertise necessary to tie the knowledge necessary to deal with unikernels with knowledge necessary to develop enterprise or user-facing applications.
Another aspect is the lack of support from large cloud vendors. In principle, you could create RMIs (AWS EC2 VM images) from scratch, but it will be hard to integrate them with the rest of the cloud infrastructure. Popular tools that create RMIs aren't designed to deal with unikernel applications. They often assume that UNIX shell is available or that cloud-init is available etc. It's even worse with VHD. I don't know what the state of events is in GCP, but wouldn't expect that to be any different.
Yet another aspect is the lack of instrumentation for debugging. A lot of common instrumentation assumes or relies on stuff like UNIX shell or presence of standard UNIX utilities. This is even more noticeable in automation / CI side.
Containers are a lot easier because they rely on existing, however bloated and broken, infrastructure. They aren't better, and the way forward for containers promises no increase in quality... but it's the easy way "forward" (in temporal sense), and that's why it's being taken.
Definitely agree with the top part, however, I should note that, ops, the tool's, whole existence is to create disk images and upload them to any cloud, any hypervisor.
In particular, both https://ops.city && https://nanos.org are Go unikernels running on GCP and their deploys take just a few seconds to push out. AWS can be even faster cause we skip the s3 upload part. We also have lots of people using Azure which would be utilizing vhdx.
Overwhelming majority of programming today is happening in userspace. And even there, it's typical to be far removed from system interfaces. Popular language runtimes s.a. Python or Java or JavaScript create a layer of obfuscation on top of system interfaces.
Programmers who could realistically pull this out are either in embedded field or in OS / system field. OS / system is very tiny compared to everything else, but even with embedded being larger, the problem is also the lack of expertise necessary to tie the knowledge necessary to deal with unikernels with knowledge necessary to develop enterprise or user-facing applications.
Another aspect is the lack of support from large cloud vendors. In principle, you could create RMIs (AWS EC2 VM images) from scratch, but it will be hard to integrate them with the rest of the cloud infrastructure. Popular tools that create RMIs aren't designed to deal with unikernel applications. They often assume that UNIX shell is available or that cloud-init is available etc. It's even worse with VHD. I don't know what the state of events is in GCP, but wouldn't expect that to be any different.
Yet another aspect is the lack of instrumentation for debugging. A lot of common instrumentation assumes or relies on stuff like UNIX shell or presence of standard UNIX utilities. This is even more noticeable in automation / CI side.
Containers are a lot easier because they rely on existing, however bloated and broken, infrastructure. They aren't better, and the way forward for containers promises no increase in quality... but it's the easy way "forward" (in temporal sense), and that's why it's being taken.