I’ve heard the word, played with Docker 101 and still was left wondering why this technology is important.  After all, we have VMs we can run applications on and they obviously support a lot more apps than Docker does.  Something drew me back though to actually spin up my own machine with a real Docker Engine and get my hands dirty.

Just a recap to explain the difference between containers and VMs.  VMs are full Guest OS running their own libraries and executable, etc.  They should be pretty familiar concepts to most people at this point.  You can use orchestration and provisioning to stand up the OS, Hypervisor, guest OS, and applications.  Normally, many of us on the Tech Ops side of the house are used to doing it the old fashioned way, we have our shortcuts but we’re still touching or tweaking a few things.  Those of us on larger deployments lean much more towards automation, but it’s often overkill for smaller deployments. Let’s place ourselves in the automated camp and say we have templates for the OS, we can provision on bare metal and even push and configure applications.

Containers, on the other hand, sit on top of an engine (Docker, in this case). You have a base OS and then Docker.  Docker isn’t a hypervisor, it does not map hardware virtually as a standard OS does.  It will take applications (and an OS) and allow them to share resources (mainly libraries and bins) with some, all or isolated from each other.  The biggest thing to keep in mind here is persistence.  When Docker updates a container, it doesn’t apply a patch or update, it rebuilds the entire container.  Sure, you can modify in a container, but that isn’t docker, that’s you doing this.  When you want to update or improve, you’ll lose your changes.  What you ought to do is use the Dockerfile to add the applications and components you need.

First thought I had, is how the heck are you supposed to use a database then?  Can’t really afford to wipe that data. The answer is (and pardon the poor terminology) is mapping a container to a volume on the host (can the host see it? Good, you can have a container hit it). Hope that makes sense, so keeping this in mind, I still struggled to find why Docker matters.

In a past life, I spent over a year on a development team (I had little business being there) but techops didn’t like me because I kept thinking like a developer.  So before DevOps was coined, I was a TechOps person planted into Development and it was great.  I learned a lot by managing deployments and watching the process of SVN and code push.

Now, developers usually checkin code they develop on their machine.  Code is supposed to be merged and then run in a test environment (if one exists).  Then it’s deployed in Production (I’m simplifying this).  Most modern methods of Agile development involve streamlining the code deployment (so developer 1 isn’t waiting for developer 2 to finish so they can work).  Also that code should be complete and automated testing should be used.

I know the big problem coming from devops. It’s the environment.  While some shops can afford multiple copies of Prod, they always lack things.  Let’s say we isolate DEV and copy it from PROD.  It’s stale the second you’re done, often it’s not used, there are differences in testing and eventually it’s flushed down the toilet and rebuilt.  Automation can fix this, cloning environments and data is great.  Technology can’t fix people issues though.

With this in mind, Docker clicked for me.  The issue with most environments is the tweaks or the shadow IT that adds things after a deployment.  Every time I heard the word “done” I ask again and usually find out that the person means 90-99.9% done, which is not done, only 100% is done.  Dockers solves this because you deploy on the same engine and if you changed something, you’re caught. It’s rebuilt EVERYTIME.  This is a GOOD thing.  This means that Dev, QA, Preprod and prod are the same and the infrastructure doesn’t get stale because there isn’t much to manage.

Developers like this because there is no change to the infrastructure, ops should like this because it takes them out of the blame.  I think most will not like giving up control, but if you think hard about this, they aren’t, there is nothing to control.  You can backup the container data and have that persist, but just as easily clone and restore if needed.

I have a lot further to go, I’m just a beginner but I thought I’d share how I’m getting some uses for Docker and I really do see it as the future (no clue what date that will come).  BTW, Docker runs on VMware, generic Linux, AWS, Google Cloud and many more.  If the Engine is the same, the apps under it can be used on whatever platform you have.  Think of the savings in management on all those Guest OSes.  What about the licensing and support?!?

Granted, not everything runs on Docker, but everyday more does.  If I were a vendor, I’d be integrating it to utilize Docker before your competitor does.

PS – I didn’t even edit this thing so please pardon the grammar or runons.