"Why Drupal Multisite Is Not Enterprise Grade" - Pantheon introduces new multi-site product

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Garrett Albright's picture

The folks at Pantheon recently posted an article listing their grievances with multi-sites (I presume they're referring to the standard core approach), then pitch a new product they're offering to address them called Pantheon One. The best I can tell from the details in the article, it involves spinning up a separate container or jail for each site (like a VM, but with a shared OS; only the user-level processes and disk regions are separated), though I might be mistaken. At any rate, I'm not really sure how their new product shares any files like standard multi-sites do… so maybe it's just a system for managing multiple separate sites?

At any rate, give the article a read. And if anyone at Pantheon can clarify how this product works in relation to standard multi-sites, please do.

Comments

Multiple sites

joshk's picture

Hey Garrett,

The short answer is that you're correct in that it's "a system for managing multiple separate sites". Though that's selling it a little short.

Our runtime environment uses Linux Containers (cgroups, etc) to provision resources and isolate security within a large host OS. We have a big matrix of those, running hundreds of thousands of PHP and MariaDB containers, which we wire up to provide service for Drupal sites. That's how everything on Pantheon works, from a free sandbox to a gigundo enterprise doing millions of pageviews a day.

The Pantheon alternative to Multisite — which we call "Pantheon One" — is to leverage Git, system automation, and the capabilities of platform to allow you to deploy common code from a single "upstream" repository to N number of sites with ease. In the same way that we let normal people track Drupal Core and get updates via Git, Pantheon One lets you do the same thing with your custom codebase, and push out updates to your network of sites.

The win here is that in the case where there's variation between sites — e.g. you're allowing deep configuration, or providing customization on a base distro — is that you have flexibility around when an individual site needs updating, and Git make sit straightforward to manage site-specific code development in addition to common "upstream" changes. Because we're not literally deploying the same code, you don't have terrible lockstep catch-22 update fails.

In an environment where all the sites are exactly alike — Drupal as a Service — the win is that unlike multisite this architecture is truly partitioned. It's actually secure, and no single site having a big traffic day (or DDoS, or spam attack) can ruin the experience for anyone else.

We think our model of combining efficient containerization, the full power of git, and the ability to meaningfully partition sites is the right mix to really deliver Drupal at scale.

There's more info on other blog posts/etc:

https://www.getpantheon.com/blog/much-ado-about-drupal-multisite

https://www.getpantheon.com/blog/who-really-benefits-multisite-anyway

https://www.getpantheon.com/blog/drupal-saas-multisite-vs-pantheon-one

https://www.getpantheon.com/blog/building-sites-common-codebases-pantheo...

https://www.getpantheon.com/pantheon-one/drupal-multisite

P1 rocks

stovak's picture

As a current customer, I can say, It FREEKIN ROCKS.