Skip to content

Why Docker?

Posted in Docker

By Dušan Dželebdžić

Photo by frank mckenna on Unsplash
Photo by frank mckenna on Unsplash

Docker is an awesome tool for web app development. Back in the stone age (i.e. pre-2010), if you needed a specific version of PHP with a specific set of extensions and a specific version of MySQL, your dev environment had to be... well, pretty specific.

Developers had to adjust their working environment to whatever the current project needed. That was a cumbersome task, so most of us settled for "close enough": the PHP version would be somewhere in the ballpark of what was required, there might be a few extra extensions lying around, and most of the time it was fine. Except when it wasn't.

The next logical step was to create isolated environments used only for development. Some sort of virtual machine, so to speak. Actually, that's exactly what they're called. The process is very easy: download a Linux ISO, spin up a VM, install a fresh Linux on it, install Apache, PHP, and every extension and config you need, set up the network share and the virtual network interface, and within a week or two you're good to go. Rinse and repeat for every project you're working on. You might understand why this wasn't anyone's favorite option.

Enter Docker Vagrant. This tool was a great helper in the early 10s. Instead of messing with virtual machines by hand, you described what you wanted the VM to look like, and from then on simple up/down/destroy commands did the respective things to it. Vagrant was essential for replicating production on a development machine, but it still carried the overhead of running two (or more) entire operating systems at the same time. Not great for performance, battery life, or your carbon footprint.

Enter Docker. Depending on the host OS, it introduces practically no overhead while still letting you run anything on anything. You can give every service its own container and have them talk to each other over an internal network, expose any port or map it to any other port, and bring the entire app environment up or down using only one command.

That's the whole pitch: production parity without the week of VM setup. Once you've worked that way for a while, going back feels like hand-cranking a car.