Re: proposal: unik & cloud foundry
I really, really like this Unikernel approach, and the proxy idea for CF is very clever. It would remove a lot of adoption roadblocks from the security perspective, since you are now dealing with fully hardware-protected instances.
I think my main concern is that in essence, you are now booting micro-VMs, not containers, so the artifact is now openly exposed and protected only by whatever security group the IaaS can provide. This can be appreciated in the video of the talk when the IPs for each running app instance can be clearly observed. So they can't take advantage of constructs like Cell NATing, ASGs or Isolation Segments, AppArmor, Seccomp, etc. At least not apparently.
Could unik-spawned AIs live in overlay space with Netman? that would work nicely with the new networking model. If policy can be applied to the AI and enforced by the CNI-based SDN layer, then it would be a nice adaptation.
On a similar note, we now shift the scheduling responsibility from Diego to the IaaS essentially. And albeit the images are very small, are all IaaS capable of handling the speed and the transient nature of AIs constantly scaling up and down? Can all IaaSs achieve the 250K instance capacity that we know Diego with Garden can?
Ramiro Salas | @ramirosalas | Ecosystem Engineering @ Pivotal