DockerCon 2015 was filled with some pretty awesome stuff, but there was one thing that really stood out to me... Docker is creating an application infrastructure platform.
Everyone remembers VMware as this hypervisor that allowed us to run virtual machines. Then along came vCenter, then SRM, then tons of other products. The same thing is happening in the Docker ecosystem right now. Docker started off as a fancy little container engine and I'm going to explain why everything else they have built will take off. History is going to repeat itself. Virtual Machines aren't going away any time soon, but they will become the new legacy.
Docker Engine: The heart and soul of Docker. Sort of like ESXi to VMware. It makes all the magic happen. All of this wouldn't have been possible if it weren't for Docker being OSS. The mindshare and buzz happening in the industry is hard to not notice.
Docker Machine: Docker Machine allows you to provision Docker-ready hosts to any cloud or local laptop environment using Virtualbox or Fusion. It won't be long until Docker has figured out
the PXE booting stuff to allow you to spin up bare-metal Docker-ready hosts instead of virtual machines in the cloud. I see Docker Machine as the eventual abolishment of configuration tools such as Puppet, Chef, Ansible, and the like. Let me explain... Configuration management tools are there as blueprints of how a virtual machine or bare-metal host will be setup to run a certain application. That means the virtual machine is installed with all the binaries and libraries necessary for that application to run successfully. Docker has eliminated the need to do any of that. The runtime libraries of the application all live inside the Docker container/Dockerfile. The host itself doesn't need to be outfitted with additional libraries for containers to run. So poof, there goes those products. This time next year we will probably see things like CoreOS and bare-metal PXE built-into Docker Machine. We're also getting ready to start working on some interesting things here with EMC {code}, stay tuned!
Docker Swarm: Clusters multiple hosts to be seen as one big Docker Engine. Think of it like the vCenter of the Docker world. From the command line, point your Docker cli to the 
Swarm cluster and newly provisioned containers are dispersed throughout the cluster. There is a master-slave relationship and containers are distributed with a few different load balancing mechanisms. Oh, did I mention that this works ACROSS CLOUDS!?!? With the addition of libNetwork, your containerized application can be geo-dispersed without any additional configuration (Read more below). Creating a Swarm cluster through Docker Machine is made incredibly simple through the use of the --swarm flag. That's it. I can't wait for these two products to be more feature-rich and production-ready. As Docker Swarm matures, I believe we will see less Kubernetes talk. Why? Take a look at the VMware strategy in regards to products and offerings. VMware rounded out a catalog of products to fit almost every aspect. Docker will end up doing the same thing and since it's all native Docker toolsets, you can expect high quality.
libNetwork: Docker networking, simplified. One of the things keeping Docker containers out of production was the fact that networking is hard. For the longest time, all you could do was link containers on the same host. Then we could link containers by specifying IP addresses of neighboring hosts, but that was an administration nightmare. The acquisition of Socketplane.io has implemented some killer SDN technologies for Docker. They have created the SDN that no one else has been able to do up to this point, it's completely transparent and just works. Microsegmentation, VXLANs, and more without configuring a single thing. Creating a link between containers on a Swarm cluster automatically builds the VXLAN without any user interaction. It's one of these things that you probably didn't even know existed unless you were told about it.
Docker Compose: a yaml specification to provision your application with multiple containers. This is everything VMware's vApp always wanted to be. It's a way to build your application by specifying the Docker container/Dockerfile, networking between all of them, how to mount volumes, etc. There are all sorts of rules like affinity built-in so your application is dispersed evenly among hosts in your Docker Swarm cluster. Scaling the application is incredibly easy. How you ask? $ docker-compose scale web=20 worker=30. Yep. One command and you have as many instances of a type of a container that you want all networked and ready to go.
Here's the craziest part... all of this is really simple from an administrative/provisioning part. If you want to try it for yourself, checkout my last blog post Deploy ECS with 5 Ways of Docker to see how I provisioned an ECS cluster in EC2 using all of these Docker tool sets. (warning, I need to update it since many of the RC code bases have now been released as stable). I would encourage you to test out these tools so you can see I'm not full of smoke. I would also encourage you to go checkout Nigel Poulton's PluralSight courses Docker Deep-Dive and First Look: Native Docker Clustering. Nigel has done a great job walking any beginner through all of this.
All of the DockerCon 2015 talks have been posted to a YouTube Playlist, so please go watch them.