Drupal MegaSite vs. ManySites

While planning the migration of a large website to Drupal, a key architectural question emerged: one large "MegaSite" versus numerous "ManySites". The oragnization is large association with many divisions and groups with different levels of autonomy to manage their own sub-site. Why not go with many Drupal sites, one for each organizational unit, and use Aegir to manage the sites?

Would the simplicity and reduced number of contributed modules in the individual sites outweigh the additional burden of maintaining 15 – 20 individual sites with Aegir?

We are looking for feedback on our thoughts on "ManySites" vs. "MegaSite" for Drupal 7 for this project, but also for other large sites. The "ManySites" option could be implemented as traditional Drupal multi-site or numerous single Drupal installs. The "MegaSite" option could be implemented using a mix of Taxonomy Access, Context/Spaces, Organic Groups, Themekey, etc modules to manage numerous sub-sites all as one mega Drupal site.

We are looking for feedback and other developers approaches to large drupal driven sites

Performance is not an issue in this case as many of the pages are publicly available and will be cached or varnish’ed. Maintenance and training is an issue because it is important for roughly 300 content contributors along with the IT staff to take over maintenance of the sites after the migration.

Security Model

ManySites. If each site can have its own trusted set of users, the built in drupal role structure will do the trick with a handful of roles such as Content Editor, Content Approver, etc. Administrator privileges are for only that site. A shared user table or a common user account back-end can ensure that users get a single login and password that works for all the sites. A disadvantage is that it could be lots of effort to add or remove an account that has permissions to many of the sites.

MegaSite. Taxonomy Access, Monster Menus, custom node access modules, etc. are needed, but can only control certain Drupal structures like nodes. Menus, blocks, etc become more difficult to apply granularity and many modules such as taxonomy don’t offer any granularity of permissions.

Edge Case Modules. Modules needed, but not needed everywhere.

MegaSite. Modules enabled are executed for all sites, though well written ones are not a performance hit. Dependency can be hard to track. A module may be enabled and not used or used on only a particular part of a site. Some modules are difficult to figure out where functionality is in use. User interface can get complex for site admins. Once a module is enabled on MegaSite, developers may leverage it even if its usefulness doesn’t outweigh its maintenance burden.

ManySites. Modules are only enabled on sites where in use so dependencies are easier to track.

Shared Content.

Content that is shared across many divisions can be shared out via webservices to promote standards and avoid being locked in to any particular solution. Shared user tables take care of some obvious shared content needs. So MegaSite vs ManySites with regard to shared content isn’t so relevant. Because most of their sites have quite a bit of content, the Content Management Filter module will likely be needed anyway for making content indexes usable and accessible to non admins. (Anyone know when they will release a D7 version?)

Theming and Theme variations

ManySites could have a single theme for a site and avoid theme switching module functionality such as context or themekey. If only one theme were used on a site, block placement could possibly use the blocks UI, though its likely to become unwieldy and need context for block management.

MegaSite would need multiple themes so the built in block admin interface would be unwieldy and contexts module would be needed.

Blocks, views, path aliases, etc.

How do you prevent blocks, view paths, path aliases, etc. from being placed outside a site admin’s site in a MegaSite?

Workflow

When workflow is different among different divisions of an organization or non existent for micro sites, how do you change workflows on the same drupal object (content type, block, etc.) within a single part of a MegaSite?

Points of Failure and Reliability

ManySites has many points of failure, MegaSite has less, but failure may take down all the divisions’ sites. Database corruption incidents or a site being hacked in a ManySite model means only one site needs to be recovered.

Training and Educational Materials

Staying closer to out of the box drupal makes out of the box drupal training and documentation material more useful. There is also less need for hoping a module you are using has good documentation.

Rolling Migrations, Upgrades, and “New Content” releases

ManySites has more flexible migration and upgrade timing.

ManySites can shift all content editing to the dev or staging version of an individual site during a new rollout and push the entire site out. With MegaSite this could only happen if the entire organization were rolling out new content.

Microsites

With ManySites a microsite (short term, narrow focus site) is simply a new site with perhaps a particular install profile or features build.

With Megasite, its just a new set of pages, and perhaps a new theme.

Tag Clouds Across Sites

Done by default with a MegaSite, hard to do with ManySites.

Tag Cloud Isolation Between Sites

In a MegaSite it can be accomplished by having many vocabularies. In ManySites it is done by default.

Taxonomies Shared Across Sites

In a MegaSite it is done by default. In ManySites we could use shared taxonomy tables or taxonomy import feeds. A master ALA site might contain shared taxonomies.

Taxonomies Isolated Between Site

Done by default in Multisite, hard to do in Megasite.