This is a guest post for the Computer Weekly Open Source Insider blog by Arianna Aondio in her role as field engineer at Varnish Software — Varnish is a content delivery specialist and its HTTP accelerator technology powers content-heavy dynamic website (as well as heavily consumed APIs) including Vimeo, Twitch and The New York Times.
Aondio writes as follows…
We’ve come to believe packaging is essential for delivering anything from sofas to software, but is it really?
Take Ikea, which has teams dedicated to optimising packaging, warehouse space and above all, costs. But is all this really optimal for the customer? No. Because after a customer finishes unloading their roof rack of nice, neat packages, they’ll then have to ‘extract’ everything themselves, assemble and then – if they have any energy and sanity left – recycle all the boxes and tidy up.
True story time
True story: I just bought a new sofa from Ikea and when I was finished putting it all together, I found four screws left over and I had to start all over again.
This is exactly the same type of maddening scenario you can encounter when preparing software packaging, for example, as a release manager or as an end-user installing packages.
Ikea, of course, can’t really get rid of packaging without risking damage to the physical products. Fortunately software has more alternatives. End users don’t want to waste time installing packages; they just want to use the software. So how can we free them from the so-called ‘dependency hell’, having to invest a lot of their own time trying to assemble a lot of moving parts.
A dependency tendency ascendency
I’ve given this a lot of thought wearing one of my many hats, second-line technical support. Our software supports more than one operating system and we have several versions of it out there.
When a customer calls with a problem, I often need to install the version he or she is working on. Invariably, the customer’s installation has multiple dependencies. This means I need to download the same libraries to replicate the problem… and so on and on.
In software, components evolve all the time, along with dependencies. Cutting through these dependencies is unnecessarily time consuming. Containers like Docker are the best remedy I’ve come across to solve all this. Once you’ve invested the time defining the provision file for each of your containers you can then install your favourite software, avoiding the ‘hell’.
Each container runs a different piece of software/application and it’s up to you to decide if you want them to interact or not.
I’m dreaming of software heaven
In my dream scenario – and I see this actually happening – the software industry moves to a place where packaging is no longer necessary at all.
For most developers the easiest option would be to build the software directly from the source code. But as the song goes “you can’t always get what you want”, right?
Fortunately, containers like Docker give us what we need!