GOV.UK - Not Your Father's Stack

I'm not sure what I was expecting the stack GOV.UK used at launch to look like. Maybe some messenger owls and lots of cobwebs? But not so at all. So much not so I thought any organization looking at their own stack for ideas could learn something from the considered choices of others.

The diversity of technologies used was surprising. They use "at least five different programming languages, three separate database types, two versions of an operating system." Some may think of this as a weakness, but they think it a strength:

The reason we operate such a diverse ecosystem is that we are focused on solving real problems. Our first task is to understand the problem or need we are solving and then to choose the best tool for the job. If we restrict ourselves to moulding the need to the tools we already have, then we risk not solving the initial problem in the best way possible for the user. By restricting software diversity or enforcing rigid organisational standards on a project, there is a possibility of descending into a cargo cult, where we simply repeat the same patterns and mistakes in everything we make.

This "use the best tool no matter what" policy is outlined in a blog post Benefits of diversity. The only choice that wouldn't be found in a modern startup is the use of Skyscape as their cloud provider. I'm assuming this has to do with legal issues around data sovereignty as this is government site, but otherwise it's all straight out of standard modern web practice: monitoring, dashboards, continuous release, polyglot persistence, distributed source code control, etc. Good to see a government getting it.

What stack are they using? (it's a direct copy so feel free to read the original)

Frontend:

• HTML/CSS/JS - using HTML5 where appropriate, with a heavy focus on accessibility, and validating where we can
• We use jquery as our primary javascript library
• Video playback with the Nomensa Accessible Media Player
• Backend admin systems make use of Twitter Bootstrap
• We use SCSS, as seen in our frontend toolkit
• We’ve worked with A2-Type for font production.

The core of the servers:

• We’re making use of Infrastructure As A Service from Skyscape
• We use Akamai as our Content Delivery Network
• Our servers are running Ubuntu GNU/Linux 10.04, we’re hoping to upgrade to 12.04 soon.
• Servers are managed with Puppet, using PuppetDB
• Web serving is handled by nginx, proxying to unicorn for our ruby applications. We’re also using gunicorn to run some supporting services. One of the team wrote Unicorn Herder to make Unicorn play nicely with upstart.
• We load balance internally with haproxy and cache requests using Varnish

Redirection:

• nginx deserves an extra mention as it’s letting us do all our redirection
• we’re using perl to manage and test our redirections
• there’s some php to add useful links to the “gone” pages where DirectGov and Businesslink content has been retired
• node.js was used to build a side-by-side browser for reviewing the redirections

Applications:

• The majority of our applications are written in ruby, based on either Ruby on Rails or Sinatra.
• A few components are written in Scala and built on top of Play 2.0
• We’re running Mapit from MySociety which is built on top of Django

Databases and other storage:

• We use MongoDB for most systems, with a few apps also making use of MySQL. PostgreSQLis used by Mapit and Puppet.
• Most search on the site is powered by Elasticsearch, though solr is currently the backend for the need-o-tron.
• A few event-driven systems use RabbitMQ

Monitoring, managing and alerting:

• We gather metrics from our apps with statsd
• We collect logs with logstash
• We monitor systems with ganglia
• Graphite helps us make many, many graphs to understand what’s going on
• Nagios tells us if we need to act on any of that data

Supporting Tools:

• All our code is tested by Jenkins, which we also use to deploy it to servers
• We track usage of the site with Google Analytics, using their API heavily to build dashboards
• We occasionally use New Relic RPM for performance reviews
• DNS is hosted by ja.net / Dyn
• Email (internal alerts) sending via Amazon SES
• Font handling and preparation with FontForge and FontTools
• We keep on track and in touch using Google Apps, Pivotal Tracker and Campfire
• Github helps us manage and discuss our code
• Zendesk keeps the feedback flowing
• We use jekyll & heroku for some of our prototyping
• We’ve built all sorts of internal dashboards. They’re very much our playground and you can find them written in a mixture of Ruby, Clojure, Node.JS, and PHP