Microsoft announces Hyper-V Containers

Thanks a lot for your answer. We create a separate container for each application, as it seemed like the correct approach. In our company we do have several "levels" of library (even jvm) version requirements. Containers have been very helpful to easy the pain that was managing that on the server side.

Imagine what switching to linux could do for you.

I've found that building fat JARs with all dependencies bundled solves a lot of the same dependency management issues containers can be used for. And it does it without container overhead.

THE STORY OF THE CONTAINER GOLDRUSH

As seen by a verbose, presumptuous 22 year old.

OPEN SOURCE MOVEMENT lays foundation for containerization:

- linux kernel gains mainstream adoption, becomes standardized across distributions

- kernel matures to support containerization (i.e., namespacing critical OS operations)

- lxc project takes advantage of kernel support, builds tooling around namespace containerization

DOCKER (THEN DOTCLOUD) is first company to capitalize on power of containerization:

- dotcloud demonstrates clear use case for containers, encouraging developer adoption

- dotcloud releases internal infrastructure code ("moves up the value chain") for PaaS

- dotcloud develops project into docker, builds existing momentum into early adoption of docker.

AT THIS POINT other companies begin to emerge around Docker, e.g. CoreOS. Key facts:

- Docker is an abstraction around LXC, effectively a set of convenient scripts for controlling LXC

- Docker is building a platform via a package management system preloaded with their repos

- Platform is a threat to new entrants, e.g. CoreOS, because they risk becoming tenants

CoreOS realized the risk of the Docker platform, and also that Docker is unnecessary for many of its value-adds. Everything Docker can accomplish, raw linux containers can also accomplish. The problem is that scripting LXC is less convenient than using Docker, but Docker depends on LXC, therefore LXC featureset will always be ahead of Docker.

In the developer community, there is a growing acceptance of the fact that Docker is an abstraction over LXC. CoreOS is trying to standardize the abstraction as an implementation of the "app container spec" [0]. This spec puts Docker, Rocket, and lxc-tools on level playing ground.

Despite this apparent acceptance, the market continues to build tooling and platforms around Docker, instead of raw LXC containers. This announcement from Microsoft is just the latest example. If a new product wants to support containers, it needs to support Docker.

Docker is benefitting from network effects even though its product is not defensible from a technical standpoint. Docker is signing deals with competing enterprises like Microsoft, Google, and Amazon, because those companies are its customers.

The risk for Docker is that these big companies eventually cut Docker out of the equation. They may eventually choose to replace Docker with their own "app container runtime," with features only supported on their own platform.

Docker was one of the first companies to capitalize on advantages of containers, probably because they have a seriously talented group of engineers writing their code. But the market has now woken up to these advantages, and Docker is being chased by massive companies with massive resources. I hope they can fend them off and keep the upper hand in the relationship, but unfortunately I think it far more likely that Docker will eventually be cut out of the equation or acquired by one of them. This will result in a fragmentation of container technology as each company rushes to develop their own app runtime engine. Ultimately developers will suffer as platforms divide and silo, increasing developer friction and reducing cloud market competition as users consolidate around the single platform with the most momentum. Eventually, I suspect one company will control 80% of cloud computing.

[0] https://github.com/appc/spec/blob/master/SPEC.md

This is pretty close, but there is not actually a VM in the Hyper-V Container. The key thing is, these containers will take advantage of Hyper-V enforced isolation and virtualization but without requiring the full VM. So, while it has this increased isolation, it is still a container, with what you would expect from a container, including better density, faster start-up times, and portability. And will have Docker platform support to make it more flexible across environments.

Hope that helps?