Inside Pantheon: DROPs
Inside Pantheon: DROPs
One of the hardest things to understand about Pantheon is the DROPs model. It's different than what most people think of when it comes to web infrastructure — our design is inspired by the likes of Google App Engine and Heroku — but there are good reasons we're doing it this way. We first started explaining this at BADCamp 2011, and the slide deck from that presentation is a good resource for understanding our overall thinking.
To put it directly, we decided it was time to break out of the conventional "shared hosting vs. vps vs. dedicated server vs. cluster" frame of reference for infrastructure. While there's nothing wrong with these traditional solutions per se, we felt they were holding the Drupal project back. Plus, they're so '90s. We wanted to create a service that could offer the best possible performance and features for Drupal, handle use-cases from the bottom to the top end, and do it for literally millions of sites.
The result is DROPs: Drupal Runtime Optimized Processes. Our infrastructure is built from many very large servers, each of which houses a number of isolated process pools: that's what a "DROP" is.
Each DROP consists of:
- A custom Nginx front-end
- PHP-FPM worker with APC and other tuning
- A git clone of your Drupal code
- Service-bindings to mysql, our Valhalla filesystem, Apache Solr and so-forth
Processes are isolated for both security and resource-allocation, preventing "noisy neighbor" problems and providing piece of mind. Every DROP is bound to its own TCP port, to which requests delivered via our "Styx" routing mesh — a system that deserves its own "Inside Pantheon" blog post at another time — which combines reverse-proxy caching, a firewall, and our custom "Yggdrasil" DNS system to insure users reach one of the available DROPs for the site they're requesting.
This means we can add, remove and re-distribute DROPs in seconds, and your site may be served from one of many host machines from request to request. This lets you scale Pantheon at the per-process unit, and do so quickly and safely. Rather than trying to decide whether you're ready to bring a new server into a cluster you can expand (or shrink) your resource footprint in much more granular increments.
As a robotic "share-nothing" matrix, DROPs also eliminates the risks that come from traditional heterogeneous cluster environments. Since every DROP is provisioned automatically on identical cloud infrastructure and can only be managed via Pantheon's automated tools, there are no gotchas where servers get out of sync due to manual adjustment or where treacherous configuration changes are needed to bring new instances into service.
DROPs also makes redundancy much more affordable than with dedicated virtual machines or bare metal hardware. Since the resource cost of an individual process is far less than even the tiniest cloud instances capable of running Drupal, you can spread out across many machines without breaking the bank.
We're constantly making improvements to DROPs under the hood: adding new PHP libraries, optimizing settings for performance and robustness, tweaking the wider matrix for balance and optimized throughput. With your site running on Pantheon you can be sure you'll stay on the cutting edge.