Aegir is ten!

Ten years ago today Adrian Rossouw committed the first code for the Aegir project. ComputerMinds have been involved in Aegir for many of those years, particularly one of our senior developers: Steven Jones. We asked him some questions about it to mark the occasion.

When did you get involved in the Aegir project?

I went to a session at Drupalcon Washington DC in March 2009 and Adrian was presenting this mad thing: Drupal managing other Drupal sites. At ComputerMinds we were looking for something to help manage our Drupal hosting and help update sites and generally make things reliable. Aegir seemed like it might work, but after having a play with the 0.1 version it didn’t seem to actually make anything easier!

About a year later I installed it again, and it seemed much more mature and usable at that point. It was working well and we managed www.computerminds.co.uk and many other sites via Aegir.

I continued to make changes and additions to Aegir and in March 2011 I was added as an Aegir core maintainer.

What has Aegir allowed you to do that you wouldn’t have been able to do otherwise?

We landed a project to build a platform for a UK political party that would host almost all of their websites, basically a site for every one of their parliamentary candidates, and suddenly we needed to be able to create 300+ sites, run updates on them and generally keep them working.

We knew that Aegir would be able to handle managing that number of sites, but we needed a quick and easy way to create 300 sites. Because Aegir was ‘just’ Drupal and sites were represented as nodes, we wrote a simple integration with feeds module: Aegir feeds and imported a CSV of details about the sites into an Aegir instance. A few moments later we had 300 sites in Aegir that it queued up and installed.

If we’d have written our own hosting system, then there’s no way we’d have had the reliability that Aegir offered, catching the odd site where upgrades failed etc. Aegir affords a Drupal developer like me a wonderful ease of extending the functionality, because, deep down, Aegir is ‘just’ Drupal.

What parts of the Aegir project have been particularly valuable/useful to you?

Aegir has had weekly scrum sessions on IRC for as long as I’ve known it, mostly for the maintainers to talk about what they’re doing and plan. They were a great way to get a feel for what the project was about and to get to know the people involved.

Mig5’s contributions, especially around documentation, have been incredibly valuable and even inspirational: topics like continuous deployment were not just dreams but mig5 laid out a clear path to achieve that with Aegir.

Aegir forced a shift in thinking, about what exactly your Drupal site was, what an instance of it was, what parts of your codebase did what and so on.

It’s been fun to do the open source thing and take code from one project and use it in Aegir. For example, I was always bothered that I had to wait for up to 1 minute for tasks to run to create a site, or migrate/update a site. I spotted that Drupal.org was using the waiting queue project to run tasks off a queue as quickly as possible, so I nabbed the code from there, wrote about 10 extra lines and Hosting queue runner was created. Tasks then executed after a delay of at most 1 second.

Aegir has always been open to contribution and contributors are welcomed personally, being helped generously along the way.

How has your use of Aegir changed since you started using it?

We’ve moved away from using Aegir to host sites for most of our projects, but are still using it to manage over 1,000 sites. It's still essential for managing 'platform' projects that cover hundreds of sites.

It’s hard to pick an exact reason of why we moved away from it, but mainly we’ve reverted to some simpler upgrade scripts for doing site deployments, using tools like Jenkins.

We’ve compromised on the ‘site safety’ aspects of deployments, we no longer have a pretty web UI for things and we now lean heavily on the technical expertise of our developers, but we have gained significant speed and comprehensibility of deployments etc.

What Aegir does during a Migrate task is a little opaque, whereas having a bash script with 20 lines of code is easier to understand.

Aegir is still awesome when you want to change how something works about the hosting environment over lots and lots of site like:

• Configurable PHP versions per site
• Lets Encrypt support
• Writing custom config for Redis integrations

What do you think the Aegir project could look like, 10 years from now?

Aegir will become ‘headless’ and decentralised, having lots of instances working together to record, share and manage config. The Drupal UI will be a lightweight frontend to manage the Aegir cluster.

Alternatively, Aegir will become some sort of AI and start provisioning political cat gif websites for its own diabolical ends!