The Great Drupal Multisite Debate

Well, that was a little tense.

Thursday afternoon at DrupalCon Austin, we gathered the most over-attended BoF session I've seen in quite a while for "the Great Multisite Debate", in part sparked by blog posts I've written about how I don't believe this architecture is the future for Drupal. Clearly, I anchored on one end of the spectrum.

On the opposite end from me were Jakub and Kris, team members from Acquia®, andChristopher Gervais, a leading member of the Aegir project. Occupying the mushy middle ground was Bryan Ollendyke — leader of the ELMS project — and Frank Cary, now VP of Product at Zivtech, but formerly of Sony Music, where he worked with one of the earliest large multisite builds. Jon Pugh did his best to moderate.

My Position In A Nutshell

I've laid it out in detail before, but to put it bluntly I don't think multisite is the future architecture for Drupal or any other open source website framework. We need something better. There's too much complexity pushed onto developers, and even with a perfect set of deployment tools the risk is still too high.

Multisite paints you into the same architectural corners as shared hosting. People say all the time that "that's not really a multisite thing", and it's true: you can be dragged down noisy neighbors, application complexity, and security problems for a whole host of reasons. However, multisite more or less forces you into these compromises, the same way choosing low-end shared hosting does.

To wit - you have a lot of different end-users (distinct sites) co-located onto a shared set of resources with no partitioning. There's no way around this if you want to run lots of sites on one codebase. If anyone does anything interesting (good or bad) there will be trouble.

That may be the only viable answer if you are on a very tight budget, or it could be an acceptable risk if your sites aren't very important. But it's not the future infrastructure for an Open Source Web. We don't 10x our number of installs by accepting those kinds of tradeoffs.

A Few Caveats

I expected fireworks, but the energy in the room was still was more emotional than I prepared for. After pondering that quite a bit, I think that might be because for many it feels like their work is being belittled when I critique multisite as an architecture. That seems obvious in hindsight, but I don't think I really appreciated it fully.

So: I am not trying to call anyone's work poor or sub-par. I've contributed code to Aegir. I've set up multisites successfully. I'm not saying you're wrong if you do or have done the same.

I am not saying multisite can't work; I'm just saying I've seen it fail. Often. Painfully. Mostly because it has a lot of flaws and risks. But if you're winning with it, more power to you. Please don't be shy about sharing your secrets for success with the wider world.

Likewise, I'm particularly sensitive to the notion that my blog posts could be used by an aggressive sales rep at Adobe or SiteCore or some other proprietary racket to try and warn people off Drupal as a solution, which was Jakub's main concern. That would suck, and I'll have to to start salting all my posts with caveats explaining that Adobe and SiteCore represent a far greater risk for an organization looking for a website platform compared to Multisite.

That Said...

There's a reason that Frank ends up saying things like, "well, if you're going to do something dangerous I want to give you prophylactic advice." There's a reason why many old hands in the Drupal community cast a skeptical eye towards multisite — or as Robert Douglass said in an earlier session, it "should die and burn in hell". There's a reason why Sony Music, which is Frank's main experience with big Multisite, actually moved away from it on their next refit.

I think it's often difficult in Drupal to say that anything is better than anything else, and I think this holds us back. Without the ability to be critical, we won't advance. If we don't advance, we'll ultimately end up being a footnote or less in history.

Just like Drupal core decided to move away from our familiar procedural hook system to Object Oriented programming and Symfony2 with the 8.0 release, I think we need to start looking beyond the status-quo for solving the problem of running a large numbers of sites. We have to do better if we want to see wider adoption.

I felt like as a “debate” we ducked this big question. A lot of the discussion felt like a brainstorming session on how to mitigate the pain that comes with multisite, rather than an honest discussion about the architecture itself, and whether or not we deserve something better.


We also glossed over budget and business in this debate a bit. I think it's important to acknowledge that economics play a huge role:

The last point is the one that matters. The first two just add heat to the debate. Vendors are bound to clash over solutions architecture, but we can all agree that any big-picture answer to the problem of operating sites at volume will need to be able to deliver price-points that can at least compete with piling a bunch of sites on a server somewhere.

That’s a challenge. I think it’s something we should take on as a community to think about and work on. I don't think Drupal should double-down on multisite just because it's what we know historically.

This debate will continue, and I’m game. There's a lot more to discuss. My thanks to everyone who represented on the panel, and attended!

Topics Drupal