Why Aren't Desktops Managed Like Containers?

By Avi Deitcher

Containers, the management and packaging technology for applications, are useful for many reasons:

  • Packaging is simpler and self-contained
  • Underlying operating system distribution becomes irrelevant
  • Performance, therefore density, and therefore cost, is much better when working without a hypervisor layer

To my mind, though, one of the most important elements in any technology is how it affects culture and incentives. For example, MVC development frameworks are helpful for many reasons, but the most important is that it encourages (and sometimes forces) a cleaner way of thinking about and building software.

The particular benefit of container packaging, and particularly Docker images and ACI, is the encouragement to think cleanly about immutable applications and mutable data as distinct entities.

When I run an application as a container, I need to think about both of those elements:

  1. My application binary is identical to every other instance of that application running everywhere else in my company and, if a public image, the entire world.
  2. My data is kept outside the container and made available to/from the container.

Practically, this means that I can take any computer instance at all (that supports the container format), tell it to run my given images as containers with a given set of data, and I am precisely where I started before.

Many systems have arisen over the years to simplify this replicability, from cloud-config to chef/puppet to docker-compose/fig.

This near-instant replicability is the basis of the "cattle not pets" paradigm of systems. If I can reconstruct any system with a high degree of reliability and speed, I don't have to worry about each system; they become disposable.

This begs the question: why are desktops still pets?

This past weekend I upgraded my (very old) MacBook Air from El Capitan (OS X 10.11) to Sierra (macOS 10.12).

Since it is pretty old, and has accumulated a lot of "cruft" over the years, I decided to do a clean install:

  1. Back up all of my data. Actually, back it up twice: once to an online backup service for critical data, and the entire system via Time Machine to a local drive.
  2. Wipe my drive and do a clean Sierra install.
  3. Restore my data from my backup drive.

Unfortunately, I hit a few snags on the way with a poorly-unmounted 1TB USB drive, which led to a very long period of macOS running fsck and me praying the drive was recoverable. (Why they don't use ZFS to eliminate these problems is a topic for another day...)

This is the way we have been doing desktop migrations and/or reinstalls for decades; very little has changed. Sure, we now have Time Machine to ease backups, online backup services like BackBlaze/Carbonite/CrashPlan, and Migration Assistant to ease the restore. Even so, it shouldn't be that hard.

Here is what desktop migrations should look like:

  • All applications are immutable images, just like container images.
  • All data is separate from the application and available locally and encrypted online.
  • The entire set is stored as a single configuration, like a compose file.

Restoring my entire system requires just one piece of information: the configuration file.

Upon start, I feed my configuration file to the operating system, which does the following:

  1. Install the standard images of the correct versions of my applications
  2. Replicate my data from the cloud
  3. Finish

To some degree, this is how iOS works with iCloud backup. Of course, iOS has a much more rigid (and enforced) rules as to what an application can and cannot do. This allows it to constrain how apps are packaged; where data resides; and how many pieces of information are required to replicate them (exactly two: app ID+version; and data location).

However, achieving this on a desktop doesn't require rigid constraints on a general purpose operating system. As long as three simple rules are met, applications will comply:

  1. Make is easier to follow the rules than not.
  2. Make all necessary services that an app could require available.
  3. Make it obvious to customers see how easy it is when an app "behaves".

It shouldn't be too hard to get general purpose operating systems like Mac, Linux and Windows there as well. It is high time desktop operating systems caught up to the advancements elsewhere in computing.

The 1990s are calling; they want their operating system management back.