Drupal Multisite: Much ado About Drupal Multisite

Drupal Multisite: Much ado About Drupal Multisite

We get questions almost every day about "Drupal multisite", a Drupal capability allowing different settings.php files depending on the incoming url. The specifics of this are documented in code, but the common application is to have one common Drupal deployment host a number of domains using different settings to connect to different databases for each, and thus serving multiple user-facing sites. Hence, multisite.

At first blush, this seems pretty cool, and it is! In the world of clever Drupal hacks, this ranks right up there with imagecache (the trick where we catch 404s for thumbnails that haven't yet been derived and do them just in time). The ability to toggle between different settings based on the domain opens up a lot of interesting use-cases, including rapid site testing and building out "site farms" of many similar sites.

But, as with many clever hacks, there can be hidden costs once they go into production.

Learn why Drupal multisite fails.

Single Point of Failure

The foremost issue with Drupal multisite architecture is that it revolves around a single point of failure. That's where the benefits are, where the efficiency comes from, but also the risks.

The most obvious problem of running a lot of sites on one codebase is that any one of them could face a traffic spike, and negatively impact all the others. If you're looking to serve a large volume of sites, the risk becomes non-trivial that one site's "best day ever" is the other 99's worst.

Supposing you have a web-scale infrastructure and you can deploy that codebase across a lot of servers — mitigating the problem of one customer swamping out resources for all the others — you still run a pretty harrowing risk. One syntax error, and all the sites go down.

Even if you're a perfect coder and never make mistakes (ha ha), or if you've got a bulletproof QA system, the single codebase issue inevitably creates un-solvable problems when it comes to upgrades.

It's never really safe to update the code "underneath" a Drupal site without running update.php, and it's also infeasible to run update.php simultaneously across a large number of sites. There's also the reality that some upgrades may not go smoothly. It's up to you to figure out how you want to deal with this, and the results are often... messy.

Standard Multisite Diagram

Standard "Multisite"  - a single point of failure and risky to update

For this reason, stock multisite remains a classic "developers solution". It can provide a lot of value early on and is a clever hack, but it has serious edge-case issues and requires a lot of custom development and/or manual intervention to scale and run over time.

Enter Aegir

One of the great things about the Drupal community is that there are tons of smart people working on solving every problem. In the case of multisite management, this has come to fruition primarily through the Aegir project.

Aegir is a multisite management system built in Drupal for Drupal. You may argue that managing Drupal sites with a Drupal site seems just plain wrong, but it works. I had the pleasure of working with the project (and making some small contributions) prior to founding Pantheon, and have the greatest respect for the community driving it forward.

Aegir solves the upgrade problem via a structure that allows you to switch user-facing domains (Apache or Nginx virtualhosts) between different codebases, one domain/site at a time. It even has handy Drush integration to attempt the upgrade after the switch, and roll it back if it fails.

Aegir "Multisite" - Have to maintain multiple lineages of codebases. The value evaporates as complexity and risk creep in.

For free software, that's pretty amazing, and the expert community around Aegir includes some companies and organizations running over a thousand instances of Drupal within one Aegir system. Clearly, there's value in it, but also some challenges.

The first is setup and maintenance. While there are significant benefits to working with community code as opposed to rolling your own multisite kludgesauce, setting up a working Aegir install takes time and effort. There's a learning curve to how it operates, and it requires ongoing sysadmin knowhow to keep it happy and humming.

The second challenge comes back to the intrinsic limitations of Drupal multisite: platform fragmentation. If you have non-trivial divergence in code or in deep configuration between sites, you will inevitably encounter a situation where the upgrade path forks — most sites will work one way, but others have different requirements.

Depending on how much control you have over the sites, you may be able to avoid this, or at least make it a temporary situation. People providing Drupal as a pure SaSS solution (no user access to code or deep administration) have a fighting chance of managing it this way. However, if you don't have that level of control (and the Drupal expertise to back it up), there's a kind of entropy effect as different sites pull in different directions with their use-cases.

Once you are stuck maintaining multiple different lineages of codebases, the value of Aegir starts to evaporate as complexity and risk creep in. Add the fact that integrating version control and any QA workflow is up to you to figure out, and you can see why there's still no silver-bullet "answer" to the multisite question.

The Pantheon Way: Pantheon One

When we set out to architect Pantheon we knew we needed version control as a core component of the development workflow. We knew we needed to solve the scalability and provisioning problem. We knew we needed to keep sites maintainable over time. We knew that we couldn't burden people with system administration and maintenance tasks.

And we knew that the multi-site use-case was out there; as I said we had a fair amount of multisite and Aegir experience under our belt. We decided to go after it a bit differently though: rather than trying to make Drupal's "multisite" feature workable, we looked at the goals — running a lot of sites off a common codebase — and came up with a different practical answer:

Pantheon One is the fast and simple way to launch brands of all sizes 

Notice we don't have any single points of failure operationally. The common elements are managed via an upstream git repository, but deployed to independent Pantheon site containers. This not only solves resource isolation for scalability better than shared clusters, it also lets you control the pace of upgrades completely, and explicitly allows site-specific development to happen.

Pantheon implements this workflow for all the distributions we support, including vanilla Drupal. Enterprise customers looking for a better answer to running a large number of sites with a common (or mostly common) codebase can set up and maintain their own private upstreams via our "Pantheon One" plan.

The way we look at it, every site on Pantheon is "downstream" from some something — usually a major version release of core. The mechanism you use to get one-click Drupal core updates right now is the same one we use to support the "Pantheon One" use case, which we initially developed for UC Berkeley, and which we're excited to be talking about more going forward.

Multi-Domain != Multisite

Just a final note since I've been asked a few times: Pantheon fully supports putting multiple domains on a single site. This is totally legit for internationalization, brand coverage, or other marketing purposes. You can also do some nice things with Domain Access, though that can also get to be a kludge if you're not careful. However, the module works and we have people using it happily.

If you've got questions about moving away from a multisite solution that's reached the breaking point, we're ready to talk. Drop a comment with your questions below, or contact us about our Pantheon One plans if you'd like to get a demo on why multisite fails and how Pantheon can help..

launch drupal site