Drupal Multisite: Much Ado About Drupal Multisite

We get questions almost every day about Drupal multisite. In our experience, Drupal multisite does not meet the needs of organizations looking for a successful technology solution to manage dozens/hundreds/thousands of websites.

For anyone new to the terminology, a multisite is where you set Drupal up to connect to different databases depending on the incoming url, which allows one instance of Drupal to serve different sites under different domain names. 

Drupal's multisite should not be confused with WordPress's Site Networks feature (which is confusingly also commonly called "multisite"). Unlike WP Site Networks, Drupal multisites have no data structure, UI, or API for management. It's literally just a way to jump the DB connection data and that's it.

That said, it's a really clever hack. Especially for those building and maintaining a lot of very similar sites, it promises to really reduce cost and effort, and is without a doubt the way to squeeze the most sites onto a single server. However, as with many clever hacks, it comes with some significant risks.

Snowflake Sites

Drupal multisite works for cookie-cutter situations, where the difference between the sites is limited to what content they've entered. But customers are always asking for new features, so this can be a challenge to stick to as a policy.

The thing that brings down the most multisite implementations is a proliferation of "snowflake" sites. Once they stop being cookie-cutter—e.g. customizations to code or configurations are made—the cookie crumbles, and the risk of ongoing maintenance can rapidly get out of control.

A sustainable multisite implementation requires zero-tolerance policy on code deviation between sites. Moreover, it also means locking down access to Drupal's admin features. You can't have individual sites changing their content structure, or enabling/disabling modules.  

If this sounds familiar, you can stop reading here, and start thinking about how you should unwind your implementation. The problems below apply even under the best of circumstances, but if you can't prevent snowflaking it's only a matter of time until you'll stuck with your most valuable/senior tech resources spending all their time doing cumbersome, error-prone, high risk mutisite codebase management.

Loss of Open Source / Drupal Value

When you run a multisite, you are effectively turning yourself into a SaaS provider from the perspective of the site owners. They're not going to have access to a wide range of open source solutions. 

In many ways, it would be better if they didn't even know they were using Drupal. In that case, they wouldn't bother Googling up solutions only to be told "no."

If you implement a multisite, you have to be comfortable with the notion that you are going to be responsible for every feature improvement or innovation. Your end users cannot hire their own developer or come up with their own solutions.

Delivering a complete "Website as a Service" solution can be a daunting task. The scope of features to launch may be large, and the long-term responsibility for continued upgrades and improvements is significant. Even for teams who are adamant about delivering a turnkey service rather than a flexible CMS tool often underestimate the amount of work required to get there.

Single Point of Failure

Even if you're interested in being a SaaS-style provider, Drupal multisite's technical architecture (or lack thereof) has some real drawbacks in that it revolves around a single point of failure. That's where the efficiency comes from, but it also makes a bunch of things much more risky.

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.

Further, the lack of segmentation between sites creates a significant security risk. Since there's no real separation between one site and the next, if one is compromised, you should assume they've all been owned.

Human Error

Even if you're an ace coder who never makes mistakes (ha!), backed up by a bulletproof testing system (ha ha!), the single codebase architecture of Drupal multisite inevitably creates unsolvable problems when it comes to upgrades and updates. Human error isn't preventable, and when you update a large number of sites with one go, the risk can be paralyzing. 

In a world where one syntax error can take down a hundred or more websites, teams start becoming very cagey about deployment. The process for testing can become overly cumbersome, and anti-patterns like off-hours/late-night deploys begin to emerge.

Keep in mind, even if you have the utmost confidence in your team's changes, these problems will bite you when deploying updates from Drupal core itself. It's never really safe to update the code "underneath" a Drupal site without running update.php. And it's usually infeasible to run update.php across a large number of sites simultaneously. 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.

Image

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

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 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 folks continuing to drive 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 a handy Drush integration to attempt the upgrade after the switch, and roll it back if it fails.

Image

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 tough challenges.

The first is setup and maintenance. While working with community code is almost certainly better than 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 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. 

If you provide Drupal as a pure SaaS solution (no user access to code or deep administration), you have a fighting chance of managing it this way. Each release is a new platform, and you don’t start work on the next one until the last is put to rest. 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 decline 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.

Site Factory

Acquia® also has a multisite-based offering they call Cloud Site Factory, based on their now-defunct Drupal Gardens project. It’s touted as an “enterprise-grade” approach to multisite, but anyone lured by that tagline should be sure to take a close look at how the technology works.

As with a lot of enterprise software it's hard to determine what it really does or how it works without becoming a customer. That said, users report that it contains a number of site management functions, and is smartly geared towards the cookie-cutter microsite use-case.

However Site Factory doesn't mitigate the single-point-of-failure issues, as it's still a standard multisite architecture. Also, unlike with Aegir, deployments are reportedly all-or-nothing, with no ability to pick a few sites to go first, or hold back some sites that aren’t ready. As of this writing their documentation actually doesn't explain how you deploy updates to your codebase at all, which seems like a telling omission.

The Pantheon Way: Custom Upstreams

As I said, we already had multisite and Aegir experience under our belt when we founded Pantheon, and we wanted to take a different approach. Instead of using Drupal multisite, We developed a model we call Custom Upstreams. This leverages our early investments in version control and containerization to deliver all the value of Drupal multisite, but without the risks and drawbacks.

Image

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

Notice we don't have any single points of failure. The common elements are managed via a remote "upstream" Git repository, but deployed to independent Pantheon containers on their own site project/pipeline. This not only solves resource isolation and scalability better than shared clusters, it also lets you control the pace of upgrades to suit your use case.

This means site-specific development can happen if desired, whether that's your internal staff doing lightweight implementation as part of initial setup, or allowing a site team to do ongoing customization. With the Custom Upstream model, you can deploy and scale hundreds of sites with zero customization as pure SaaS, or choose to allow your downstream customers full access to the Drupal Open Source value, even to hire their own developers. Best of all, you can decide this on a site-by-site basis. 

We know this model scales because Pantheon uses this architecture internally: we maintain core Drupal and WordPress upstreams, and anybody spinning up sites or migrating to Pantheon uses these already. It's how we manage core updates for tens of thousands of instances. 

Institutional-scale 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 Custom Upstreams via our Enterprise or EDU+ plans. Agencies with a Custom Upstream use-case are welcome to talk to us about their project or idea, and we'll help them get set up.

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 do some nice things in Drupal with Domain Access and/or Organic Groups, or using a WordPress Site Network. These approaches increase the complexity in the application architecture and code, but they can all work well and we have people using them happily.

If you've got questions about moving away from a multisite solution that's reached the breaking point, or you want to evaluate alternatives before going down that road, we're ready to talk. Contact us to learn more about how our Custom Upstream solution can work for you, or if you'd just like to get a demo on why multisite fails and how Pantheon can help.

This article has been updated since its original publish in 2013.