Imagine that you are a violin maker, and you have only a chisel and a hacksaw. With such inappropriate tools, you're going to either a) make a really shoddy violin, b) spend an age trying to get the tools to work, or c) develop some tools that are better suited to violin making.
I work on the infrastructure of GOV.UK, and in the infrastructure team we are making the tools that make better violins, so our violin makers (the developers) can get on with worrying about how the instruments sound.
Using others' tools to make thing simpler
At GDS, we're in the business of addressing the needs of our users, the British public. In order to better serve these users, we frequently make use of software that someone else has already built. One of our design principles says "Do less", and for us that means using tools that are already available so we can do things faster and better than we would if we built everything from scratch.
We're not the first to use other peoples' efforts to simplify our jobs. Indeed, the history of computing is dominated by the struggle to manage complexity: the work of others hides low-level detail through the use of "black box" abstractions. Those of us writing the code behind GOV.UK today rarely have to think about where the computer stores our data in its memory, and we certainly don't pay much attention to what particular brand of processors are installed in our servers. There are other tools to worry about those things for us. We don't even really pay much attention to how our servers map on to real physical machines, thanks to virtualisation.
What's all this got to do with how we serve our users?
The tools and systems we build in the infrastructure team act as a layer of abstraction on top of things like virtual machines and web servers. If we do our job well, developers at GDS should be able to concentrate on what really matters — writing code that solves peoples' problems — and spend less time worrying about implementation details.
For example, our developers care that when a user visits a particular page, their application serves it quickly and correctly. They care that they have access to timely logging and monitoring data, so they can use it to inform the improvement of their application. Most of the time, our developers shouldn't have to care about webserver configuration files, operating systems, or load balancers.
Some of the ways we're helping achieve these goals are:
- writing Puppet modules that automate configuring an application in the GOV.UK stack
- making deployment processes faster and more reliable
- encouraging the principles of the Twelve-Factor App in our systems: in particular, "dev-prod parity" (making our development environment similar to our live production environment)
Finishing the instrument
We'd like to share more of the code running our infrastructure, but this is still a messy and emerging field and this means we haven't always been able to do things in the way we would like. In some cases, we've only learnt how best to do things after we've done them the wrong way! There are some pieces we can't share in public yet, but in the coming months we'll be working on opening up whatever we can.
We're also a long way off removing all infrastructure concerns from our developers' lives. We're certainly not running a true platform as a service, for those who know their buzzwords. But that's where we hope to be: a world where getting something up and running as part of GOV.UK is as quick and easy as downloading an app for your phone.
