Explain Docker to Me and When Would I Use it?

My shot at ELYF:

In your computer, everything works because of little things called "processes". These guys talk to each other to keep everything running. But sometimes they disagree at stuff because one thinks something should be black while the other thinks it should be red (for example, because of incompatible versions).

Maybe you built some super cool process that does super awesome things like letting you buy catnip on the internet. That process needs to talk to other neighbor processes that agree with it on which color the road between them should be and have no distractions around it.
Traditionally, you would send your little process to play with others and hope for the best. But the little guy can eventually grow up and change it's worldviews and opinions on road colors. This will introduce disagreements with it's peers.

Introducing: . The point is that you can send your little process to play with others but inside a protective shell. It will have everything it needs to do it's job within it's little bubble. Also, from it's point of view, it'll be completely alone (processes are loners, don't feel bad for them). You will be able to modify it's behavior and it's environment, and test it way before releasing him into the wild.

Once you have all your processes in their own hamster balls running around and playing safely, you can pick them up, move them around and group them using a crane. If any of them pops or starts throwing a tantrum, you can pick it up and put it in a corner to scold it for being a bad boy (saying "kill it" would be too rough for a 5yr old) or just replace it for a new one.

That was a really lame and childish attempt at explaining containers and a bit of orchestration. Don't know if it helped at all, but it was fun to write.

Think of "containers" for shipping goods: If you don't have those, you need to care about what you are supposed to ship. Technical devices will need to be handled in a different manner than, say, books or food.

With "containers", this all pretty much disappears. You do have a standard sized box that can extremely easy be stacked, carried around, liffted on a truck, shipped all around the world - and only the one filling the container and the one unpacking actually need to care what's inside.

With software containers, things are the same. Running a Java application is considerably different than in example running a node.js or Ruby On Rails server. Likewise, a RedHat Linux server system is subtly different to an Ubuntu or Debian server installation. There are a bunch of things an application (directly or indirectly) depends upon, and these things lead to an almost traditional "clash" between developers (who build code) and operations teams (who maintain running code in production systems): Application crashes on a production server, developer says "works on my system" - and everyone is having a hard time figuring out what exactly went wrong.

Enter containers: They try to establish a standardized way of how to packaging an application, including most (best case: all) required dependencies and make sure the operation team has a set of limited functionality (start a container, stop a container, update the container software to a newer version) required to fully operate an application without having to bother much about what technology is being used to build this application or which operating system the developer used for building it.

So from that point of view, containers add a bit more standardization compared to running a virtual machine - and make this process actually usable: You could do the same with a VM indeed, but to achieve the same thing containers can achieve, you would be required not to provide your operations people with an application to run on a VM but instead completely build and configure a VM template they can just import into whatever environment they use (VMWare, ...) and start it without second thought.

There's a load more to containers of course, but that should be the essence I guess...