richardking · June 12, 2014 15:47
diff --git a/dockercon b/dockercon

 #### tl;dr:

 Dockercon was definitely one of the most educational conferences I've been to. It's rare that a technology gets people so universally excited and eager to use it. And the problems Docker are solving - getting local code into the cloud, ship great software quickly // getting dev code to running and serving prod traffic - are definitely something for both developers and DevOps to be excited over.

 The benefit of such a new, quickly-embraced technology is that a lot of smart people are working on it, and tools around it. However, the drawback is that there is a lot of repeated work. This was shown when multiple talks (at least 4) were about custom built orchestration tools for Docker. This also showed the need for solutions to manage Docker images and containers once you are using it with a multi-layered production application.

 However, it seems to me that Docker is definitely the future; Google, redhat, Rackspace, Amazon are just some of the companies throwing their full weight behind it. It seems like just a matter of time before Docker and its tools become more standardized, polished and used everywhere.

 #### Outlines of a few talks

 Atlassian talk about being a happier developer with Docker, by Nicola Paolucci. 
 Outlined some common workflows for using Docker:

 1. Develop inside a single running container (as you would a VM)
    * by using ```docker run -t -i ubuntu /bin/bash```
 2. Leverage containers and modularize
    Techniques:
    * embrace re-usability in Dockerfiles
    * update code locally and then build a Docker image
    * share folder from host to container

 Regarding sharing a folder from host to container, he listed out three ways

 * using guest additions in Virtual Box (though it is slow performing)
 * using NFS
 * using Samba

 I still need to experiment with these techniques.

 auto.com (subsidiary of cars.com) modified their entire infrastructure and workflow to use Docker. They made sure all of the layers (using containers) were almost exactly the same in layers/containers in dev, test and prod. They even went as far as switching from Amazon SQS to RabbitMQ when they couldn't replicate SQS in a container in dev. Also they used Docker in a unique way, where rather than attaching to a Docker container to access its shell, they ssh'ed into them. Unfortunately I'm not too familiar with the details there, but just interesting the different ways people use it.

 One of the most interesting but not Docker-specific talks was by Gene Kim, who studies DevOps processes at thousands of companies. He showed empirical evidence that high performing DevOps teams makes the software deployment process more agile (30x more freq deployments, 8000 faster lead time than peers), and the product more reliable (2x the change success rate, 12x faster mean time to repair)[^source]. High performing companies not only iterated faster, but they also were not afraid to make changes when it mattered most, during peak traffic seasons. Highly recommend checking out the video once its out. 

 #### Some tools that were talked about
 **Helios by Spotify**
 http://github.com/spotify/helios
 Makes sure your containers are deployed and running exactly where you want them.

 **Centurion by New Relic**
 https://github.com/newrelic/centurion
 Rake application with tasks and dependencies used to talk to a fleet of docker servers at once. Handles rolling deployment and makes sure containers you want running, are running.

 New tools that were just open-sourced by Docker:
 **libcontainer**
 https://github.com/docker/libcontainer
 -- a standard container for OS sandboxing (lower level than Docker)

 **libswarm**
 https://github.com/docker/libswarm
 -- a minimalist toolkit to compose network services (hopefully will help standardize open-source Docker orchestration tools like Helios/Centurion/Geard/Mesos/etc)

 **libchan**
 https://github.com/docker/libchan
 -- a lightweight communication protocol for distributed systems (similar to Go channels over the network)

 [^source]: Source: http://puppetlabs.com/2013-state-of-devops-infographic. Interesting infographic overall.

	#### tl;dr:

	Dockercon was definitely one of the most educational conferences I've been to. It's rare that a technology gets people so universally excited and eager to use it. And the problems Docker are solving - getting local code into the cloud, ship great software quickly // getting dev code to running and serving prod traffic - are definitely something for both developers and DevOps to be excited over.

	The benefit of such a new, quickly-embraced technology is that a lot of smart people are working on it, and tools around it. However, the drawback is that there is a lot of repeated work. This was shown when multiple talks (at least 4) were about custom built orchestration tools for Docker. This also showed the need for solutions to manage Docker images and containers once you are using it with a multi-layered production application.

	However, it seems to me that Docker is definitely the future; Google, redhat, Rackspace, Amazon are just some of the companies throwing their full weight behind it. It seems like just a matter of time before Docker and its tools become more standardized, polished and used everywhere.

	#### Outlines of a few talks

	Atlassian talk about being a happier developer with Docker, by Nicola Paolucci.
	Outlined some common workflows for using Docker:

	1. Develop inside a single running container (as you would a VM)
	* by using ```docker run -t -i ubuntu /bin/bash```
	2. Leverage containers and modularize
	Techniques:
	* embrace re-usability in Dockerfiles
	* update code locally and then build a Docker image
	* share folder from host to container

	Regarding sharing a folder from host to container, he listed out three ways

	* using guest additions in Virtual Box (though it is slow performing)
	* using NFS
	* using Samba

	I still need to experiment with these techniques.

	auto.com (subsidiary of cars.com) modified their entire infrastructure and workflow to use Docker. They made sure all of the layers (using containers) were almost exactly the same in layers/containers in dev, test and prod. They even went as far as switching from Amazon SQS to RabbitMQ when they couldn't replicate SQS in a container in dev. Also they used Docker in a unique way, where rather than attaching to a Docker container to access its shell, they ssh'ed into them. Unfortunately I'm not too familiar with the details there, but just interesting the different ways people use it.

	One of the most interesting but not Docker-specific talks was by Gene Kim, who studies DevOps processes at thousands of companies. He showed empirical evidence that high performing DevOps teams makes the software deployment process more agile (30x more freq deployments, 8000 faster lead time than peers), and the product more reliable (2x the change success rate, 12x faster mean time to repair)[^source]. High performing companies not only iterated faster, but they also were not afraid to make changes when it mattered most, during peak traffic seasons. Highly recommend checking out the video once its out.

	#### Some tools that were talked about
	Helios by Spotify
	http://github.com/spotify/helios
	Makes sure your containers are deployed and running exactly where you want them.

	Centurion by New Relic
	https://github.com/newrelic/centurion
	Rake application with tasks and dependencies used to talk to a fleet of docker servers at once. Handles rolling deployment and makes sure containers you want running, are running.

	New tools that were just open-sourced by Docker:
	libcontainer
	https://github.com/docker/libcontainer
	-- a standard container for OS sandboxing (lower level than Docker)

	libswarm
	https://github.com/docker/libswarm
	-- a minimalist toolkit to compose network services (hopefully will help standardize open-source Docker orchestration tools like Helios/Centurion/Geard/Mesos/etc)

	libchan
	https://github.com/docker/libchan
	-- a lightweight communication protocol for distributed systems (similar to Go channels over the network)

	[^source]: Source: http://puppetlabs.com/2013-state-of-devops-infographic. Interesting infographic overall.