The announcement of LXD by Canonical is leading to even more confusion and unfair comment on Canonical, some of it borne out of ignorance, some of it unbecoming of folks who really should know better.

For those out of the loop Canonical has been the main supporter of the below the radar LXC project, that companies like Docker used to propel themselves in to prominence. Yes Docker was based on LXC, and used LXC containers as a base to abstract the container away to a single app. So its an app delivery platform, compared to LXC which gives you a complete Linux environment. For most users containers as a lightweight alternative to virtualization makes sense more than a single app delivery platform which is suitable for PAAS type scenarios.

Because of LXCs low profile a lot of users first introduction to LXC containers was via Docker resulting in some misconceptions and conflation of a single restrictive use case of containers to container technology itself. And with it a growing ecosystem of projects that paradoxically try to break through some of these self imposed restrictions and do not support LXC itself.

The fact that LXC is a full fledged linux container project dating 2009, and supported by Ubuntu since 2012 that gives you tools for container management, a wide choice of container OS templates, superfast lightweight containers and was actually easy to use, was lost in the noise.

With LXD Canonical seems to have finally realized the potential of its own LXC project, and hopefully they will promote and evangelize it properly. Or someone will put a wrapper on LXD and run away with the momentum.

LXD builds on LXC capabilities to deliver multi host container management with advanced features like live migration and online snapshotting including running state. LXD is developed in the go language and will be developed simultaneously with LXC. Like LXC it's developed mainly by Stephane Graber and Serge Hallyn of Ubuntu. The LXC team also developed cgmanager used for cgroups management and mainly developed to support per user cgroups used in unprivileged containers.

LXD is a daemon that exports a REST api locally over a unix socket and on the network using https. This will be used by the OpenStack plugin and a standalone application. The details are still scant, the OpenStack plugin is already available for preview in Ubuntu, and the standalone application should be available for general use soon.

LXD uses unprivileged containers by default. Unprivileged containers are an important new feature of LXC that lets non-root users run containers. They provide more isolation and security than normal LXC containers and pave for way for multi-tenant workloads and other use cases that require more locked down environments.

Canonical also needs to think very carefully about adoption with LXD. There is little question the adoption of LXC was seriously impeded by lack of good documentation and cross distributions support beyond Ubuntu. There should be baseline set of features that work across distributions without fuss. But if core features depend on updated or custom packages in Ubuntu there will be frustration for users of other distributions, and once again the lack of visibility and widespread adoption of LXC inspite of the fantastic technology will repeat itself with LXD.

For users it basically boils down to how you want to use containers, as a lightweight easy to use alternative to virtualization, or as a single app delivery platform. Given more than 80% of currently Linux virtualization workloads can easily move to containers, caveats and all, it seems clear where the potential of containers lies.

The adoption problem is mainly down to Ubuntu not doing enough to promote LXC and the growth of Docker without clarity among its users and media about Docker's genesis in the LXC project developed by Stephane Graber and Serge Hallyn, both working for Ubuntu. Docker users not interested in constraining a container to an app and yet to discover LXC beyond the misconceptions will be pleasantly surprised by the freedom and usability of LXC.

Evidence of this is in the large number of threads in the Docker forums and projects that try to work around the restrictions of Docker containers to make them more like LXC, which seems a bit pointless given the advanced status of the LXC project itself.

Hopefully we can move ahead with a more informed user base with appreciation of the fantastic potential of container technology and its varied use cases.

Here is a small peek of LXC

Further reading and resources

LXC guides

LXC vs Docker

Flockport Containers