No Standing Still

We write a lot on this blog about our product and our company, as well as providing what we hope are useful accounting tips in plain English for small businesses, but we haven't written much about the technical side of FreeAgent.

Given that nearly 50% of our current team are engineers and many of our customers work in technology and on the web, I thought we should share some of the lesser known details about the app, from the technology we use through to how we develop new features. We'll cover the tools we use during development and the processes we employ as a team to get stuff done, though to the technical details of our Ops side – hardware infrastructure, disaster recovery and monitoring. This first post, however, concentrates on the underlying software – the things that makes FreeAgent tick.

I hope you enjoy the series and we'd love to hear your feedback.

In the beginning

FreeAgent has been running pretty much constantly since mid-2007, and even though the technology we use today is largely the same as it was during our first private beta phase, it has evolved and matured a lot in those three and a half years.

When Ed originally started work on the first prototype of FreeAgent back in 2006 he decided to use Ruby on Rails. Rails was a groundbreaking web framework and received a lot of attention at the time (both positive and negative), but it was a joy to use and it allowed startup founders to execute an idea far more quickly than with any of the more popular web frameworks of the time^[1].

Rails is also open source, as is our entire software stack. In the early days of bootstrapping the company we had little choice, but cost wasn't the only factor in this decision. By embracing open source we get control over the libraries we use, a strong community of support, we operate using open standards and we can contribute back to the community through patches and by opening up some of our own internal work. It's win-win.

Then and now

The first release of FreeAgent used Ruby 1.8.6 and Rails 1.2 and ran on a cluster of four Mongrel instances behind Apache 2 on a single white box server running RedHat Enterprise Linux (RHEL) at the Rackspace UK data centre. Our database system of choice was MySQL. We had no background jobs so every operation was run in request, from email sending (using plain old sendmail) to accounting calculations. We cached nothing, it was slow at times but it didn't matter since we had so few customers.

Our current master branch runs on Ruby Enterprise Edition 1.8.7 and Rails 2.3.10 and we're preparing ourselves for the switch to Rails 3. We no longer run on a single server – we now have six (and counting), a mix of virtual machines and bare metal, all still hosted at Rackspace UK. We use DelayedJob to process requests asynchronously whenever possible – email sending (through SendGrid), attachment processing (stored on Amazon S3), accounting calculations – and we're introducing memcached to take more of the load. We still use MySQL 5 and Apache 2 but we stopped using Mongrel when Phusion Passenger was released and we haven't looked back – our integration servers are now running 3.0 and we'll probably switch to this in production in the next few weeks. The app is now considerably quicker, we have thousands of customers and we can scale out rather than up.

Time flies when you're having fun

But this is really just a snapshot in time – if I wrote this again in six months it would look quite different. The nature of a fast-growing online business means we have to constantly evaluate and evolve our technologies and our infrastructure. There's no standing still.

^* I can state this as fact because I've spent more time than I care to remember writing web applications in Java using EJB 2.0 as well as Struts and Hibernate. They're like chalk and cheese. Joy and pain.