Design rules are the basis for every decision we have made in the development of the beta of GOV.UK and hosting is no exception. The key design rule is not to be locked in to a single supplier and to make it trivial to swap hosting partners.
The beta of GOV.UK hasn’t been built as rapidly as the Alpha that preceded it. But we’ve still been working at pace building out admin systems, developing an accessible frontend, putting together custom tools, and setting up the variety of servers to support it all. Through all of it we’ve maintained the agile, iterative approach that’s been discussed here before, and that applies to writing content and designing user experiences right through to setting up the servers that power it all. When iterating so quickly we needed a hosting environment that would give us maximum flexibility so we wouldn’t be unduly slowed down waiting for new servers when we needed to add another element to our infrastructure.
For short-term expediency, we chose Amazon Web Services (AWS) because for our immediate needs it offers the right balance of stability, high quality tools we could easily integrate into our scripts, a range of complimentary services and excellent technical support. Critically, however, we are not using any unique AWS components or services which we could not easily migrate to a new supplier. Once the G-Cloud framework is up and running we switch as quickly as is prudent to most suitable product in that framework.
Cloud hosting options are continuing to develop rapidly, and so are the requirements for the GOV.UK platform. As parts of our platform stabilise we may well find that we want a hybrid hosting environment, where some aspects live somewhere like AWS and others are hosted on other cloud platforms or even on traditional dedicated hardware. We’re primarily focused on working out what will provide value now rather than being too preoccupied with potential future scenarios, but we have been careful to follow our own rules and not tie ourselves too tightly to any one hosting platform.
So, for example, we’ve chosen to use Amazon’s Relational Database Service for handling our relational databases because as far as our applications are concerned it looks just like MySQL. When developing we can use MySQL and when we deploy we can hand over responsibility for scaling our databases to Amazon without making any changes to our code. That means that if we were to later decide to move that code to another hosting environment we would be able to focus on moving the data, and not have to spend time rebuilding our apps too. We’ll be talking a bit more about the databases in use for the beta soon.
By contrast we were very cautious about using the AWS email service (SES) as there are some quirks in how it handles standard email protocols and so we had to add some specific code to interface with it. We decided to go ahead, but only after we were convinced that switching away again would be a straightforward matter. Thankfully as time passes more and more of the components of most cloud hosting platforms are becoming accessible using standard and well understood interfaces. Long may that progression continue.
Without access to cloud hosting with the flexibility such as is provided by AWS we’d not have been able to develop the beta with nearly as much freedom. And without that we’d have had to spend far more time focussed on the detail of hosting which would mean less time addressing user needs.
James Stewart is Tech Lead on the beta of GOV.UK. You can follow @jystewart on Twitter