Deep in Drupal's core is a theoretically neat piece of functionality that allows you to run many websites off the same codebase-on-disk, and it's called multisite. You set up several different sites/*/settings.php describing different databases (and hence sites); alongside each settings file you can also add modules and themes specific to each site: from D7 onwards, a sites/sites.php acts as the junction box, directing traffic on a per-domain basis to a given subfolder and hence site. Most or indeed all code can be shared across all sites and therefore updates to code rolled out across them all at once.
If you've never used multisite—or even Drupal—before now, then this sounds like a win-win situation, right? Reduced maintenance overhead, fewer copies of code that might diverge: clearly a cost saving. Well, it's a bit more complicated than that.
Historically I've personally witnessed serious drawbacks with using multisite, some of which Pantheon also discuss in some detail:
- Third-party contrib can be a bit funny sometimes. Prior to Drupal 7, replicating a production site locally required moving directories around (the subfolder name needed to match the incoming domain), and certain caches—especially modules that ran their own entirely custom caching system—would sometimes go ballistic and prevent the actual rebuilding of those caches until you added symlinks to the old folders etc.
- Not all sites are actually guaranteed the same. Even with D7 and beyond, the fact that you can have the codebase mostly shared, but override some aspects on a per-site basis, can rapidly lead to many substantially different "effective codebases" for each site; you're back in a non-multisite situation, with all the disadvantages of having your sites coupled together heterogeneously and in a way difficult to analyse. Even if you outlaw site-specific modules or themes, site-specific configuration can be drastically different: some sites might hit bugs during an update, while some sites might have other bugs fixed by that same update.
- Database updates still must be run separately on each site. While codebase updates can be theoretically rolled out across all sites very quickly, any associated database updates must still be run across all those affected sites, and exit successfully, before you can breathe easily. Having seen the aftermath of a 26-site multisite install which broke 1/3 of the way through the sites' databases being updated, I don't see this as reducing maintenance overhead so much as turning the otherwise routine maintenance into a white-knuckle rollercoaster ride.
- Separating off a high-traffic site ruins the advantages. As soon as one site dominates in terms of traffic and performance requirements, it's going to need its own server. At which point at the very least you have to replicate the codebase, and you start to wonder: why am I using multisite again?
However, I don't want to go hating on multisite too much. Robert Douglass' comment that multisite should die and burn in hell is now legendary, and doubtless grounded in very bitter experience: as you can see from the above, I feel his pain. But large vendors, including Acquia, are offering multisite as a solution, albeit in a very specific niche: as was mentioned in passing at our recent Ask the Agencies OxDUG session, they also apparently have a database-updating procedure that also reduces the likelihood of problems during update time. For them, operating at the scales they do, they felt the extra investment in such a procedure was worth it, and now see multisite-plus-their-own-workarounds as "enterprise": in the sense of "massively scaleable for very many clients/products..html" Different Drupal vendors, therefore, feel very differently towards multisite.
What I'd like to see is people only adopting multisite once they genuinely appreciate what it does and doesn't provide (which I think is difficult for newbies to appreciate right now.) Unless you're running (or planning to run) more than a hundred identical websites from your multisite codebase, you're probably not going to get much out of the system. So try to see multisite as an optional vendor product (albeit a free, bundled one) that you have to find an active use case for, rather than as a passive component that you can just switch on to reduce maintenance costs. Because if you see it as the latter, it probably won't turn out that way.
Ultimately, if you're not sure if you can tailor your finished products to align absolutely maximally with the way multisite really behaves, you probably shouldn't be using it at all.
