Containers make a lot of sense, emulating an entire hardware layer just to run an application is always going to be overkill. As the industry wakes up to the possibility of these super lightweight, efficient and high performance alternatives to virtualization, its no surprise that Microsoft is working on its own container technology for Windows called Drawbridge.

So far all the buzz about containers has been limited to Linux, as containers depend on capabilities provided by the Linux kernel and thus only work on Linux. Not anymore, with Microsoft in the fray things are going to get decidedly more interesting.

Linux containers use cgroups, chroots and namespaces support in the kernel to give you a lightweight OS environment, with processes and networks in their own namespaces and the ability to control resources via cgroups. The LXC project provides userland tools to bring all these capabilities together to give end users ready to use containers and a collection of OS templates designed to work in a containerized environment. Within this containerized OS environment you can run 99% of Linux workloads. The kernel is shared with the host.

Microsoft seems to be following a similar path with a lightweight Windows OS template and a way to use picoprocesses in an isolated layer. The interesting thing is the use of a lightweight user mode NT kernel within the container.  This is different from Linux containers where the host kernel is shared with containers.

Drawbridge is a Microsoft research project that is still being worked on. The team claims they are already successfully running Windows workloads in containers, but there are no indications of release time lines for public testing or use.

Of course in Linux land the under the radar Linux open source container project LXC baking since 2009 on which Docker is based has had a slow start. The real potential of containers as a high performance alternative to virtualization has barely been tapped. Docker due to a mix of LXC's low profile, misconceptions about the LXC project as 'low level kernel capabilities', 'not ready for end users', or 'too complex' widespread in the Docker ecosystem resulted in a conflation by a lot of users, media and bloggers of Docker's niche use case based on LXC to container technology itself.

The idea that users need to users to understand layers, run extra process managers to manage their apps and where everything from networking to simple management is obtuse is the best way to use containers is moving several steps back. The idea that you don't need an OS and can do without logging, scheduled tasks, remote shells/editors, debugging tools, firewalls, support for 3rd party software for monitoring, backups, systems management is the kind of make believe that leads to these very functions being reinvented by the ecosystem.

Complexity holds back rather than spurs innovation, as tons of projects around Docker just to break through the self imposed restrictions to reinvent functions that are available in stock LXC and in the general Linux ecosystem show.

Moving from VMs to LXC is seamless. Moving from VMs to Docker requires the kind of engineering effort most will baulk at. This is not to say Docker does not have a use case, the tradeoff in complexity perhaps make sense for highly qualified devops teams in PAAS deployments but its not a general use case and trying to force its use beyond that to do what the LXC project does far simply is a bit pointless given the advanced status of the LXC project itself.

LXC paradoxically has always been far easier to use than Docker and represents the larger general use case of containers. Containers offer a lot of scope for innovation in storage, management, orchestration, portability, networking that remain unexplored due to focus on restricted container formats and layers designed for PAAS type scenarios.

For general users being productive with an easy to use container that mimics a virtual machine is more natural than trying to muck about with and understand layers, a constrained single app container OS environment which is nothing like the OS environment they are used to, and being enforced to building loosely coupled containers.

There is already a lot of complexity at the infrastructure and app level and introducing more complexity without clear benefits does not make sense. The vast majority of container use cases lies outside this constricted container environment.

A lot of use cases Flockport highlights would be impossible or very complex to implement in Docker, and with the advanced status of the LXC project itself, it does not even make sense to try. That's something we are trying to address by getting more users excited about the performance, flexibility and portability of general LXC containers.

Features like unprivileged containers that allow non root users to run containers and live migration are features that make containers that much more of an alternative to virtualization, is currently done by a few individuals in the LXC team with little support and outside the spotlight. These are the kind of features that will enrich the Linux container ecosystem and make it competitive to emerging formats.