CoreOS bags $12m, touts Tectonic – a DIY Google cloud for big biz

Re: #2, performance, my personal experience has been that there are three axes: instantiation time, cpu/mem utilization during running, and network performance. Instantiation time is better on containers, but doesn't matter to me as my apps tend to run for months at a time. CPU/mem is a wash - actually, the long pole in the tent for me is filling the host CPU's cache and making sure my guests (VMs or containers) always have the data they need in the cache. Network performance is a big problem for VMs relative to containers. There are hacky things like SR-IOV but they don't feel "right" (although they work well). Containers essentially give you bare metal speeds as they don;t have the encapsulation overhead. 'Course, container networking is strange at best and downright perverse at worst, so you have to be prepared to think in different ways if you go down this path, but it can be worth it for the network speedup alone.

The benefits of containers are really twofold, one is efficiency for ops, the others is standardisation for development.

For ops, containers really can be seen as just the next step in virtualisation. They give lower isolation guarantees than VMs, which in turn give lower guarantees than bare metal. Containers give much of the same benefits as VMs too, potentially denser deployment of software.

This density can be seen in the lower overhead they have as compared to VMs

Memory overhead of just booting a VM on vsphere (ie, before the OS is loaded)

https://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.resmgmt.doc/GUID-B42C72C1-F8D5-40DC-93D1-FB31849B1114.html

Comparison of VMs and containers (PDF)

http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf

Overall, containers have a lower penalty on CPU usage, and a much lower overhead on memory usage, as the guest OS and hypervisor penalties are removed. This comes at the cost of using linux as the host and overall lower isolation. It's a trade off. For the linux as host point, it has a larger surface area to attack as compared to VM hypervisors.

For development, the container acts as a standardised deployment artifact, that is much, much, much (really) smaller than a VM image. It'll effectively be the application binaries, with supporting scripts. The lower levels are stored as seperate portions and downloaded separately.

They are a good tool, and not a replacement for VMs. Instead, it let's use be a bit more nuanced in the way things are done. They certainly will replace VMs in many situations, but by no means all, and probably not the majority, in my opinion.

RE: Performance

>Anon because I'm at work.

The only one I can speak to is performance. I spend a lot of time using Proxmox which is just a nice web interface for Debian with both KVM and OpenVZ installed. Performance vs bare metal works like this (your mileage may vary depending on what those VMs/Containers are up to, my stats are for primarily LAMP "servers"):

KMV/QEMU (VM) - about 10-15% slower than bare metal, and there is notable memory/CPU overhead

OpenVZ (Container) - about 3-4% slower and there is no perceptible overhead

So 10-15% or 3-4% more latency and fewer total sessions before things bog down. This roughly lines up with most of the literature I've read so I think my results are pretty normal. Honestly, I'd almost rather managed a bunch of microservers but that's another story. Also keep in mind that in most cases it will be "disk" I/O that slows things down, not your choice of virtualization strategy.

Re: @1980's ... Yeah but you have to like the name...

> "Tectonic ... try and copyright it. :-P"

I think the word you're looking for is "trademark".