Containers

In the beginning, there was XVM. XVM provides free computational resources to MIT affiliates through the use of virtual machines. However, there are a number of problems with virtual machines:

• They take up a fixed amount of resources, and it takes a lot of time to create and boot up new virtual machines. This means that services that run on virtual machines are not easily scalable.
• Each virtual machine has a large amount of overhead: it's wasteful to spin up an entire XVM just to run a Zephyr client.

This is because virtual machines emulate an entire machine, over which you run an operating system to run your paltry web apps. A better solution is to use containers, which run on top of the existing operating system. Different containers on the same machine can be isolated by, for example, allocating each of them a different root filesystem and different sub-namespaces in kernel realms.

Unlike VMs, which have persistent mutable disks to mimic a real server, containers have immutable file systems instantiated from a fixed image. This limits the damage caused by spontaneously halting a container (such as in the case of a hardware failure), which improves the reliability of infrastructure based on containers -- and since the container image is stored in a filesystem in RAM, containers don't need to access the network to get at their critical system files.

Containers are generally launched with a container manager, like docker or rkt. See our wiki page on rkt.

[insert more stuff about how containers work here]

Since containers are lightweight, and have immutable disks, we can create and destroy them easily. The fact that containers can be ephemeral helps us to make the entire Hyades cluster architecture resistant to random hardware and network failure.

Additional Resources

• Kernels
• Hardware virtualization
• Operating-system-level virtualization