Tuesday, December 12, 2017

Docker for Everyone

Why Docker?

So back when I was a kid, back in the 90's we used to install our software applications directly onto the iron. That is, you'd get some hardware. You'd install the OS. You'd install the App Server and Database, and then you'd install your application into the app server and configure the app server to talk to the database. Installing the application was fairly straight forward. For JEE applications you just copied your EAR or WAR or JAR file into a folder and that was kind of that.

The downside of this, is if you wanted to run on more than one server, you had to do all of this stuff a second, and a third and an n'th time... depending on how many servers you wanted.

The other downside of this is that you could have a big expensive piece of iron that only used 5% of its capacity for this one program.

To recap:
 - Setting up an environment took days if that's all you were working on.
 - Deploying apps could be as simple as copying a file to that environment, and restarting the servers.
 - Cloning the environment for redeployment was arduous and error prone.
 - CI and CD tooling had not been invented yet, but would have been really tough.

--
So, along came virtualization technologies (unless you are an IBMer and had been using virtualization on the mainframe since the 1960s).  And this solved the first problem because now all you had to do was copy these VM files to a new machine and it just worked. So much faster than installing all the app servers and databases and whatnot.

The other thing VMs did was that you could run multiple VMs on a single hardware box. So you could get better utilization of the hardware. That meant smaller data centers, less power requirements. Good stuff.

 - Setting up an environment was easy because you could copy a preexisting template.
 - Deploying apps could be as simple as copying a file to that environment, and restarting the servers.
 - Cloning the environment was easier, although there could be complications with fixed resources. But more importantly environments could be very large, moving them required lots of storage and lots of network bandwidth.
 - CI and CD tooling was just coming into play, being able to spin up dev/test environments on the fly became a thing.

--
Then in 2006 AWS said, "Hey, there's this cloud we've built from our leftover computing resources does anyone want to use it?"  And the world said, "YES".

The dynamics of the cloud changed a lot of our programming paradigms. Think about this. In the "old" days if you wanted set up a new app environment, maybe all you had to do was copy the VM to a new server. But VMs tend to be HUGE.  It's one thing to copy them across a corporate network. But if you ever tried to copy a VM up to the cloud you know that it could take days. At least it used to take days.  But still very large and a long time.  At any rate, not very agile.

A lot of clouds still support running VMs because it's a very solid way to do things. But it takes forever make a change and upload a new VM.  Also, moving or lifting and shifting workloads to the cloud got really time consuming and consumed a lot of bandwidth.

As a result of all this a lot of people started building cloud native applications. That is, apps that were built in the cloud as opposed to built on-site and moved to the cloud.

--
So among the many. many paradigms that came about changing the way we deploy things to the cloud, one of them was Docker.

Docker is neat because a docker container is really about the smallest possible deployable thing you can have. Much smaller than an entire VM. And each docker container is isolated and highly scalable.

 - Setting up an environment was easy because you could copy preexisting templates for small pieces, a container for the appserver, another for the database, etc.
 - Deploying apps got a little more complicated because you had to build a container of your app deployed to an app server. But DevOps tooling did most of that heavy lifting once you set it up.
 - Cloning environments became easy because the components were small and easy to move to the cloud.

--
So today, if we want a "Run Anywhere" cloud solution Docker can be a good choice. It's small, lightweight, and portable across Linux platforms. It can require a substantial retooling of your devops and deployment scripts, but once that should be a one time cost.