Zerg: Boot a VM instance per request, all in under 250 ms
This is a very interesting development!<p>But doesn&#x27;t that mean we are merely reimplementing old concepts on a new level? Almost everything we do on VM level we  already did on process level:<p>- Read-only VM images are essentially like statically linked binaries, just better encapsulated when they run.<p>- Tiny, fast loading VM images are essentially stripped static binaries with dead code elimination.<p>- Starting those by incoming network request is just like old &quot;inetd&quot; versions started custom handler programs on each request.<p>- Same with CGI, just on HTTP rather than TCP level.<p>- Manual maintaining the lifecycle of those VMs like FastCGI in nginx.<p>- Maintaining the lifecycle of such a started VM is essentially like FastCGI in Apache (or nginx + auto-spawner).<p>The only real difference is the improved encapsulation (controlled network access and resource consumption) of the running code, isn&#x27;t it?<p>What might come next?<p>- Multiple VMs could share the same images to save memory, essentially reinventing shared libraries and dynamic linking.<p>- Network traffic into and out of a VM is controlled more tightly, reinventing SELinux. (Perhaps followed by noticing that these profiles are hard to maintain, rediscovering the maintenance issues of SELinux systems.)<p>- Providing the network traffic shape directly with the image, so these can be maintained at a single place, by the original developers. This would reinvent Pledge.<p>- Introducing permissions for network traffic, e.g. such that just one group of application VMs can communicate with the database VMs. Ideally with an ACL system as used for managing file permissions. This would reinvent Unix Sockets.