Colophon for the GOV.UK beta
We’ve been cataloguing the technologies and tools we’ve used in producing the beta of GOV.UK. Naturally our technology stack is always evolving, but this list captures its state at the moment when the beta was released. You can see the equivalent list for alpha.gov.uk here.
We’ll be updating this post with links to more detailed blog entries on various tools and technologies over the coming days.
Hosting and Infrastructure
- DNS hosted by Dyn.com
- Servers are Amazon EC2 instances running Ubuntu 10.04LTS
- Email (internal alerts) sending via Amazon SES and Gmail
- Miscellaneous file storage on Amazon S3
- Jetty application server
- Nginx, Apache and mod_passenger
- Jenkins continuous integration server
- Caching by Varnish
- Configuration management using Puppet
Languages, Frameworks and Plugins
- Most of the application code is written in Ruby, running on a mixture of Rails and Sinatra
Rails and Sinatra gave us the right balance of productivity and clean code, and were well known to the team we’ve assembled. We’ve used a range of gems along with these, full details of which can be found in the Gemfiles at https://github.com/alphagov - The router is written in Scala and uses Scalatra for its internal API
The router distributes requests to the appropriate backend apps, allowing us to keep individual apps very focussed on a particular problem without exposing that to visitors. We did a bake-off between a ruby implementation and a scala implementation and were convinced that the scala version was better able to handle the high level of concurrency this app will require.
Databases
- MongoDB
We started out building everything using MySQL but moved to MongoDB as we realised how much of our content fitted its document-centric approach. Over time we’ve been more and more impressed with it and expect to increase our usage of it in the future. - MySQL hosted using Amazon’s RDS platform
Some of the data we need to store is still essentially relational and we use MySQL to store that. Amazon RDS takes away many of the scaling and resilience concerns we had with that without requiring changes to our application code. - MaPit geocoding and information service from mySociety
MaPit not only does conventional geocoding (what’s the lon/lat for a postcode) but also gives us details of all the local government areas a postcode is in, which lets us point visitors to relevant local services
Frontend
- HTML & CSS (naturally), with elements from HTML5 & CSS3 where appropriate
- Javascript uses jQuery, jQuery UI, Chosen, and a variety of other plugins
- Gill Sans provided by fonts.com
- Google web font loader
Misc
- Accessibility testing with Jaws, NVDA, VoiceOver, Window Eyes, and a range of other tools.
- Video playback with the Nomensa Accessible Media Player
- Dashboards/Information Radiators in Clojure, Node.JS, and PHP
- Campfire for team chat
- Google Apps
- MediaWiki
- Pivotal Tracker
- Many, many index cards
James Stewart is Tech Lead on the beta of GOV.UK. You can follow @jystewart on Twitter
27 Comments
Post a comment
Trackbacks & Pingbacks
- MongoDB at GOV.UK: The Power of the Document Model • myNoSQL | Programmer Solution
- GovCamp 2012 – public sector ‘unconference’
- The Open Source Behind gov.uk Revealed
- Open Source dibalik gov.uk Di Publikasikan | LinuxBox.Web.ID
- Links for 10 March 2012 - Chris Unitt's blog
- After the watershed – five reasons why nothing can be the same since the launch of Gov.uk/government « BASIC CRAFT
- Open Government with Principles | The Marketing Society
- The software we’ve used to build GOV.UK | Government Digital Service
Now that is a tech stack any government project should be proud of. Stirling work.
Fantastic information – and interesting implementation.
Are you planning on releasing (either stubbed/genericised) your various application configurations/VCL/etc, as well as your code? I had a scan through GitHub and couldn’t spot it.
I’m also quite interested in your deployment approach – the choice of mod_passenger vs Unicorn, if you already have nginx in there. Are there any plans to expand on that kind of information?
We’ve mostly used passenger because we had it in place early on and the pace of development didn’t leave time to switch to Unicorn. Switching to Unicorn is high on the list of things to work on post-release as it’ll help us simplify a few dependencies and reduce disruptions around deploys.
The varnish config, a few bits of application config and our provisioning scripts are private at the moment as we’ve got quite a lot of sensitive information in them. We’re going to try our best to get as much of that public as we can, but it’s going to take a while to get there as there’s a lot to work through.
There’s a blog post coming soon on how we’ve managed provisioning servers and our use of puppet, but if you have any specific questions I’m happy to try and address them here or we can use them to guide future blogging…
Looking forward to that blog post – sounds interesting! :)
You might want to check out Passenger Enterprise (Phusion’s premium product), it has zero-downtime (rolling restart) deploys – https://www.phusionpassenger.com/enterprise
Thanks Ryan. Passenger Enterprise is an interesting option but we’re actually in the middle of migrating all the ruby apps to use Unicorn as it fits much better with the way we’re now running our servers.
One of the team has recently written a tool to help us use unicorn with upstart – https://github.com/alphagov/unicornherder – which is working very nicely.
Am so excited to see such a great set of technologies in use. Very cutting edge, and more organizations would do well to try some of these things out. I also think using a decent tech stack is a helpful in attracting and retaining good techies to work on your sites, which is very important given how hard it is to find people these days.
It pretty much matches the stack we are using for our healthcare projects in NHS orgs. Great tech. Good job.
Rob
Thanks. And always glad to hear of other people using stacks like these in the public sector. Is there anywhere we can read about those projects?
Soon! Soon you’ll have a similar detail on two projects we are working on in healthcare (a LAMP stack in Acute care and Playframework in Primary Care)
It pretty much matches the stack we are using for our healthcare projects in NHS orgs. Great tech. Good job.
Rob
We too have a similar stack over here in Shropshire, but tended to go for consistency in codebase over performance, simply due to the small team.
I did a write up a while back, giving a rough idea of what we were using, but more in the context of how we were using open source.
…if anyone is interested..
http://shropshire.gov.uk/projectwip/2011/05/open-source-yeah/
Great. Thanks for sharing that link. Out of interest, why did you choose to develop your own search engine rather than use something like Lucene/solr?
yes. this is really very usefull. Thank you for your help.
Thank you so much , good job.
I am French and I envy you for this stack (you can be happy now).
Not sure I can see an example of Chosen (http://harvesthq.github.com/chosen/) in use on the site…
We’re using it in some of the admin systems rather than anywhere publicly accessible.
Out of interest, why dyn.com? Which subscription did you go with? We’re currently debating between Dyn and DnsMadeEasy…