​DevOps: How packaging and convenience shapes what we use and build

How do you get people to use your software? You make it convenient and you package it well.

box.jpg
AndreaAstes, Getty Images/iStockphoto

A couple of weeks ago we attended one of London's more interesting developer events, Monki Gras. Run by the RedMonk group of analysts, Monki Gras focuses on the craft of software development, looking at not just how people do things, but also why, and how that reflects into and out of the wider world.

This year's event was structured around the concept of packaging; exploring how we package software and how that affects how it's built and how it's used. We're in the middle of a wave of digital transformation, driven by the cloud, by virtualization, and by the rise of the container.

They're all technologies that are changing how we deliver software, and as a result, changing how we package and deliver things.

RedMonk co-founder Steven O'Grady set the scene, delving into the tension between packaging and convenience, starting with a history of 7-Eleven and the convenience store. Making it easy to buy food and common household goods changed the way an ice company operated, with each successive change reconstructing its business as it found new ways to sell new things, and better ways to sell the old.

That model is at the heart of much of what we do in the world of software. Not everything is the most efficient, or the most modern. However, it is often the most convenient that wins. As O'Grady noted, the story of open source software is one where the winners are the most convenient: firstly Linux was easy to download and install. It just wasn't convenient compared to Windows, of course. You can look at the various distributions as a wide choice of different packages to meet different end user needs with minimal work on their part.

But while software is the visible side of the open source movement, the key to how it operates are the various licenses. You only have to look at sites like GitHub to see which have become successful, with both Apache and MIT licenses making the biggest gains. The secret of their success isn't their openness, it's the fact that they're permissive. That's why companies have been able to build businesses around them, while still being able to give back to the community.

The convenience of these licenses is that they clearly detail your rights and responsibilities to the code and to the community, while they also acknowledge that for many large projects things can't be purely built by volunteers, and that there's a need for corporate sponsorship. That way open source projects can grow and still support businesses. It's an approach that works well for companies where open source is only part of their business, and for companies that depend on open source completely.

Convenience is, in many cases, the reason why we make decisions. As humans we're fundamentally lazy, hardwired to find the quick and easy way of doing things rather than taking the hard way. You could argue that's why the public cloud has become so successful, so quickly. Why not hit a button on a control panel to spin up a virtual server from a library, when the alternative is waiting weeks for a new machine to be delivered, and then longer still to configure the operating system and the software you want to use.

Way back when, when I was building large-scale systems for clients, I'd have to budget the time needed to build not just the final deployment infrastructure, but also the development platform, and the test systems (and sometimes possibly a staging environment). Now, thanks to the power of convenient packaging, those systems aren't only running on cloud infrastructure at a press of a button, they're now automated into a continuous integration build process, where the output isn't just an infrastructure, it's also the software containers that run on it. Now deploying software also means deploying infrastructure; all wrapped up in a convenient set of packages.

O'Grady talks about the idea of a "convenience spectrum", a way of moving from one type of package to another, from a high convenience, highly packaged environment where you get what you see, to a low convenience unpackaged space, where you have to build everything you want. It's like comparing Oracle Database with MySQL with Amazon Aurora.

Oracle's Database is a low-convenience, unpackaged solution. You have to build servers, define databases, set up replication structures, and manage availability (and navigate the world of licensing). It takes time, but it's highly tunable and extremely powerful. MySQL is less customizable, and is ready to go nearly as soon as you install it. You do get some tuning and customization, but most of the time you just set it up and let it run. With cloud services like Amazon Aurora things are different. Everything is ready to go as soon as you click the subscribe button. You don't need to worry about resources, about configuration, just about what data you want to store, and the bill at the end of the month.

What's clear is that how you deliver your code matters as much as the code itself; first understanding what level of convenience your users are expecting and what they need. Then you need to understand how you're going to package that delivery, finding the right way to turn code into a product and to deliver that product to your users - whether it's using the right license or delivering it as a ready-to-go container.

7-Eleven's evolution from ice store to 24-hour convenience store makes a (hah!) convenient metaphor, but it's one that's well worth keeping in mind as you think about how your software will change over time. What's conveniently packaged today, may need to change how it's delivered tomorrow, as while your packages stay the same, the world changes and what it sees as convenient will change as well.

Read more