3 ms·
<future>I'd like to see $CLOUD selling micro-VMs with burstable memory in the tens of MBs, billed by actual CPU time used, similar to what AWS Lambda does.</fut
by mato 12y ago
<future>I'd like to see $CLOUD selling micro-VMs with burstable memory in the tens of MBs, billed by actual CPU time used, similar to what AWS Lambda does.</future>
As for lack of VM resizing, that is a hypervisor/Unikernel implementation detail.
- derefr 12y agoThe problem with micro-VMs in the current world is the overhead of the "control plane" eating most of the VM's capacity. I'm not referring to the "OS stuff" (in Linux, kernel daemons and so forth) but rather the software components any sensibly-engineered application needs if it's going to participate in a larger SOA architecture: logging, queuing, access control, service discovery, load monitoring, subprocess supervision, etc. These things (or at least stub clients for them) need to exist in each and every VM, and making the VM a single-purpose worker drone doesn't eliminate the need for them. If you want to see what happens when you aim for a single-purpose isolated unikernel design, but then bake it fully for operational requirements, look at an (embedded release package of an) Erlang application. There's still a lot of "stuff" there—a lot of attack surface that has nothing to do with achieving the purpose of your app per se—but it's all necessary to keeping your app healthy and stable in the greater ecosystem of services it interacts with. (This is presuming that you can't just shunt off these responsibilities to the hypervisor. If logging means "your unikernel writes to the console and Xen pipes it to rsyslog" then a lot of problems do go away.)