Skip to main content

https://technology.blog.gov.uk/2016/10/10/using-containers-to-help-develop-gov-uk-pay/

Using containers to help develop GOV.UK Pay

Posted by: , Posted on: - Categories: GaaP

gds_2916

We’ve recently begun using container tools on GOV.UK Pay to help us run the platform locally and make development less resource heavy.

GOV.UK Pay consists of several interacting microservices: a citizen front end, a government service admin interface, a public API, and a potentially large number of connectors to let us integrate with different kinds of payment providers (we currently concentrate on card payments but we’re likely to accept other types of payments in the near future).

GOV.UK Pay is a system with lots of moving parts for a developer to keep in mind. We wanted to simplify the development process so developers could spend more time thinking about code and less time thinking about all these different parts in their environment.

Running code locally

In order to minimise bugs and keep feedback cycles short when developing, it helps if developers run all code locally in an environment that closely mimics production.

The alternative would be to keep only the piece of code you’re working on local and then stub, mock or use remote versions of the other parts of the platform.

This alternative approach has two main disadvantages. Firstly, a whole new set of service stubs need to be maintained, and secondly, it’s likely (indeed almost certain) that one or more of the stubs will fall out of sync with the ‘real’ service at some point. This will mean your code may then fail to work in the production environment. So on Pay we aim to run our whole platform locally with as little stubbing as possible.

However running a platform such as ours locally can be a huge headache as it involves installing and configuring a large number of tools. In fact, one of the main developer action points that emerged from the Alpha GOV.UK Pay retrospective was that building, configuring and understanding the system locally was very time consuming.

Choosing to work with Docker

It was for this reason, amongst others, that when moving into the Beta phase we chose to use the open source tool Docker.

Docker is a technology that helps create containers. Containers are like virtual machines in that they are isolated environments with their own file system in which you can run applications. They do differ from virtual machines in that they are very lightweight because they don’t contain a whole operating system (they only contain the userspace) and they share their kernel with the user’s underlying machine. We chose Docker over other container tools because of its relative maturity, giving it a large community and significant support offering.

Similarly to when you write code and push it to central places like GitHub, with Docker, you can push (and pull) containers to and from Dockerhub. This makes the containers extremely portable. To update a component on our platform, I just write some code, test it, build it and push it. Once this code is merged, it’s built into a Docker Image, which will then be used in production, but is also available to other developers to develop against. They can simply pull the latest image from Docker Hub and run it.

This means that rather than having to install, configure and build a suite of different technologies locally, I can, as a member of the GOV.UK Pay team, run our whole platform simply by pulling down the relevant containers from our Docker Hub repository and running them (Docker provides decent networking tools to configure how your containers talk to each other).

Final thoughts

Headache solved? Partly. It would be a lie to say everything is plain sailing now, but it is certainly much simpler than before.

Docker is not a silver bullet: it requires a quite a bit of getting used to, and can be overused, potentially making things more rather than less complicated. It also presents its own set of security challenges.

However, used judiciously Docker can help to speed up development processes and enable developers to get fast accurate feedback about how their work fits into a complex platform, as well as reducing the differential between development and production systems.

If you work in central government and you’re interested in using GOV.UK Pay in your service, let us know.

You can follow Dominic on Twitter, sign up now for email updates from this blog or subscribe to the feed.

If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.

Sharing and comments

Share this page