Docker 101 - and how it can make shipping apps easier

Docker is an interesting technology that is very new and recently released version 1.0. The story behind it is that the founder Solomon Hykes ran a Platform-as-a-Service (PaaS) company a few years ago and wanted a convenient way to allow customers to ship their application to his PaaS.

In a couple of the talks I saw on Youtube by Solomon, he empasizes the reason for the rapidly growing popularity of Docker is due to a much larger underlying trend which is that consumers expect apps (web and mobile) to act like the Internet / cloud. That is, apps should always be available, quickly accessed anywhere around the world, and deliver a consistent experience.

At the same time, development shops have oriented themselves around service-oriented architectures (SOA) and creating loosely coupled components. Instead of having a monolithic stack, today's web apps are being built on top of a myriad number of choices.

To make a long story short, what makes Docker so appealing is that it attempts to bridge the gap between your dev server (e.g. laptop) and your production servers (e.g. hundreds of instances on AWS / Google Cloud / Azure / what have you). Instead of trying to spin up VMs and configuring them so they are 'normalized' (which is difficult to do because they may be running slightly different versions of the OS and have different dependencies installed), you create containers, which contain the dependencies, the settings, and the application itself. In fact the container runs on a copy of the host OS.

Unlike traditional virtualization (VM), where the host OS contains a hypervisor that spins up multiple guest OS, there is only one OS when using containers.

So why choose Docker? Well, there's (at least) 3 different choices you can make.

Docker

  • Pro: Provides a replicable, normalized environment that you can deploy to a wide variety of machines
  • Pro: By using a versioning system like Git, only the incremental changes need to be sent to update a container. This means you don't need to send large VM files
  • Con: Technology is less mature than other solutions, less documentation and support on using Docker (although this is quickly changing as more developers get excited about using it)
  • Con: Security is a concern as you are sharing the OS and underlying binary files.

VM

  • Pro: Ensures maximum consistency between one environment and another. (In essence you are deploying the same machine on multiple physical boxes).
  • Con: Sending enormous files (you are including an entire OS) takes up a significant bandwidth and sending a large payload may overwhelm the production environment that you are trying to upload to.
  • Con: If you need to run many VMs because you have many services for your app (particularly if it's complex and you follow a loosely-coupled SOA paradigm), it can easily overwhelm your Macbook dev machine.

Configuring Production Environments Manually / Using Tools

  • Rather than listing the specific pros and cons as there are a wide variety of ways to accomplish this, the biggest takeaway is that this is an uphill battle as you are trying to normalize environments across many machines. Even if you use an automated tool, it's still hard to ensure that these environments are normalized. And even with automation, there are still instances when you are manually SSH-ing into a production server to make changes because something isn't working properly.
views