“Installation is a Software Hate Crime” – Pat Kerpan, then CTO of Borland circa 2004.

Today’s hate – meta installers

I’ve noticed a trend for some time that when downloading an installer rather than being the 20MB or so for the actual thing I’m installing it’s just a 100KB bootstrap that then goes off and downloads the actual installer from the web.

I’ve always hated this, because if I’m installing an app on multiple computers then it means waiting around for multiple downloads (rather than just running the same thing off a share on my NAS). This is why most good stuff comes with an option for an ‘offline’ installer intended for use behind enterprise firewalls.

One possibly good reason for this approach is that you always get the latest version. That however is a double edged sword – what if you don’t actually want the latest version? What if version 10.5 is an adware laden, anti virus triggering turd (I’m looking at you DivX) and you want to go back to version 10.2.1 that actually worked? Bad luck – you don’t actually have the installer for 10.2.1.

Yesterday’s great hope – virtual appliances

When I talked to Pat a few years later about the concern of virtual appliances he figured out straight away that it would ‘solve the installation problem’. Furthermore he went and built Elastic Server on Demand (ESoD) to help people make and deploy virtual appliances.

Virtual appliances are still hugely useful, as anybody launching an Amazon Machine Image (AMI) out of the AWS Marketplace or using Vagrant will tell. Actually those people won’t tell – using virtual appliances has become so much part of regular workflows that people don’t even think of using ‘virtual appliances’ and the terminology has all but disappeared from regular techie conversation.

Virtual appliances had a problem though – there were just so many different target environments – every different cloud, every different server virtualisation platform, every different desktop virtualisation platform, every different flavour of VMware. Pat and the team at Cohesive bravely tried to fight that battle with brute force, but thing sprawl eventually got the better of them.

Today’s salvation – Docker

Build, Ship, Run is the Docker manta.

• Build – an image from a simple script (a Dockerfile)
• Ship – the image (or the Dockerfile that made it) anywhere that you can copy a file
• Run – anywhere with a reasonably up to date Linux Kernel (and subsequently Windows and SmartOS)

A Docker image is a virtual appliance in all but name[1], but the key is that there’s only one target – the Linux Kernel – so no thing sprawl to deal with this time[2].

The most important part of this is Docker Hub – a place where people can share their Docker images. This saves me (and everybody else using it) from having to install software.

If I want to learn Golang then I don’t have to install Go, I just run the Go image on Docker Hub.

If I want to use Chef then I don’t have to install it, I just run the Chef image on Docker Hub.

If I want to run the AWS CLI, or Ansible, or build a kernel for WRTNode[3] then I don’t have to Yak shave an installation, I can just use one that’s already been done by somebody else.

Docker gives you software installation superpowers

Docker gives you software installation superpowers, because the only thing you need to install is Docker itself, and then it’s just ‘docker run whatever’.

This is why I’ll probably not ever get myself another PC running Windows, because I’ve done enough installing for this lifetime.

Notes

[1] Docker images and Xen images are basically just file system snapshots without kernels, so there’s precious little to tell between them.
[2] This isn’t strictly true now that Windows is on the scene – so 2 targets; and then there’s the ARM/x86 split – so at least 4 targets. Oh dear – this binary explosion could soon get quite hard to manage… the point is that there’s not a gazillion different vendor flavours. Oh look – CoreOS Rocket :0 Ah… now we have RunC to bring sense back to the world. Maybe the pain will stop now?
[3] These are all terrible examples, because they’re things where I made my own Docker images (so they’re in my page on Docker Hub), but even then I was able to stand on the shoulders of giants, and use well constructed base images whilst relying on Dockerfile to do the hard work for me.