John Willis joined docker from the recent Socketplane acquisition. John is one of the founding members of the core Devopsdays team and was an early executive of both Chef and Enstratius (sold to Dell).
A little history…
In early February 2013, I received a tweet from Adrian Cole telling me that I should talk to this Dotcloud outfit. I typically don’t ignore Adrian (not a wise move), but this time, in all honesty, I ignored his tweet. At the time, the public PaaS market was a race to the bottom. Heroku was killing Engine Yard and I wasn’t really a fan of this space anyway. I felt PaaS’s were too opinionated for building infrastructure and a Public PaaS made it even worse. About two weeks went by and I received another ping from someone else telling me that I should checkout these Dotcloud people. This time it was Mike Kavis, another person I really respect. Mike built and flipped one of the first AWS based businesses, M-Dot Network.
Now I was curious. Two people that I respect were telling me to look at this public PaaS called Dotcloud. Adrian knew me pretty well and it was confusing why he would suggest that I may be interested in a public PaaS. I was pretty vocal about my dislike for public PaaS’s at the time. I decided to call Adrian and find out what was going on. Adrian is amazing at explaining technology and he has always been a great visionary. He explained to me that the dirty little secret of all the PaaS’s was that they were all using containers under the covers … each with their own little secret sauce. He further explained that the reason why Dotcloud was so interesting was that they were planning on open sourcing their secret sauce. I had always been interested in containers, but never had much time, or quite frankly, much luck getting them to run.
Back around 2008, I was asked to help advise a stealth startup called Cloudswitch. They were eventually sold to Verizon in 2011. I was fascinated by their ability to do virtualization nested in virtualization specifically on AWS. Cloudswitch could take VM images running on VMWare’s vSphere and run them unchanged on Amazon’s EC2. I loved the idea of using one copy of an image and running it on multiple cloud frameworks without having to rebuild the image every time. Another thing I really liked about their product was that they could run multiple VMs within a VM. This was especially interesting for applications on Amazon’s EC2. You could allocate one extra large instance and manage and orchestrate all your VMs within the EC2 instance. Unfortunately for me (not for them), Cloudswitch was a closed source product. John Considine was one of the founders and main architects of Cloudswitch. John came from Sun and I always suspected that he borrowed some of the early micro-hypervisor work they did at Sun, and of course, some of the aspects of Sun’s containerization work into Cloudswitch. However, no matter how many beers I bought him, he never cracked.
A few years later in 2011, another friend of mine, Stephen Nelson Smith, wrote a book called “Test Driven Infrastructure with Chef”. In the book, Stephen described an example of how he used LXC (Linux Containers) on Amazon EC2 instances to do scale out automated testing. This was the first time I had ever seen containers used as a killer app for a continuous deliver (CD) flow. I still had this continued fascination of running lots of compute instances in one large virtualized instance, but this time, an added benefit of fast spin up and spin down time was what really peaked my interest. Until Stephen’s book, I didn’t realize you could even run LXC on Amazon EC2. I went out did some research on how to run LXC on Amazon. After a few nights of frustration, in all honesty, I just gave up. At the time I was managing a team working on a multi-cloud management solution (Enstratius/Dell), and this task was more of a hobby, so I just gave up.
Meeting Docker
This brings me back to late January 2013 and the Dotcloud story. After talking to Adrian and Mike, I asked them for an email introduction to Solomon Hykes, the founder of Dotcloud.
Solomon immediately hooked me up to the private Docker Github repo and the Docker-user Google Group mailing list. I read the original Readme,and this time I had a container running (docker run) on an Amazon EC2 instance in about 6 minutes. Then, I started reading through the Docker Google Group posts. There were only about thirteen topics at the time. I saw this one…
Here are the reasons I love Docker and why I believe you will love Docker too:
#1 Docker Commoditized Containers
Gene Kim, author of the “Phoenix Project”, talks about the Unicorns and Horses. Docker enables horses to use containers. From first touch to running containers … this should not take anyone more than a few minutes to run a container. Since 2013, the eco-system has contributed nearly 100,000 public images on Docker Hub. This enables a first time user to start working with almost any known application stack with what Docker calls a “Batteries Included” approach. If you can’t find an image on Docker Hub, a simple Google search can find a Dockerfile (an image’s source code), example of just about any application. Docker makes containers easier and faster to use for practically any application stack.
#2 Developers Love Docker
Happy Developer = Happy Life.
The keys to a developer’s heart are control and speed. Control starts with a laptop and ends in production. Docker provides full life cycle control. The architecture of Docker images is such that a developer can build, run and test an application service (multiple compute instances e.g.,containers) on a laptop, and know that the same service stack will be running when it’s in production. Although the developer may or may not deploy the service to production, they can be comfortable knowing that on a 3:00 a.m. call, it’s the same binary they built on their laptop.
The second key to a developer’s heart is speed. One of the greatest gifts of the cloud revolution is that it reduced a developer’s ask for resources (generally speaking) from 8 weeks to 8 minutes. The context switch for a developer was reduced from weeks to minutes. This change has created incredible momentum in all aspects of commerce over the past ten years. Now I will argue that Docker has created a context switch reduction that is as significant as what the cloud has done by reducing the time from 8 minutes to 8 seconds.
Developers now say they get mad when a service takes more than a few seconds to start. If a developer finds a bug they have to rebuild the service from scratch to retest. VM’s take around 2 minutes to be in a ready state. Depending on the automation used to connect the multiple systems, it may take 8-10 minutes for the multiple systems to converge. More like 15 minutes, if complex configuration management infrastructure as code mechanisms are used. 15 minutes might as well be an hour. Docker containers and images allows, the service stack to converge in seconds and the developer gets to decide when to take a break.
#3 Operations (Will) Love Docker
Sysadmins of the world will love Docker. They have concerns that I’ll deal with in a future blog post. Sysadmins (operations) now love Devops but five years ago it was a different story. Sysadmins don’t put things in production unless the risk is completely understood and the outweighed benefits can be proven. New technologies with viral adoption typically scare the bejesus out of them. However, once the model proves to be sound, sysadmins embrace and typically improve these new technologies.
Registration is now open for DockerCon 2022! Join us for this free, immersive online experience complete with product demos, breakout learning tracks, panel discussions, hacks & tips, deep dive technical sessions, and much more.
Feedback
8 thoughts on "Why I Love Docker… and Why You’ll Love it Too"