Consistent Infrastructure Matters

We’ve recently been working with agencies to migrate their existing projects from custom, shared, and clustered LAMP stacks to the Pantheon platform. In practice, this process is 95% forensic. You can’t rely on naming conventions or first appearances, only on manually tracing DNS to Apache virtual host configuration to a webroot to configuration files. Why infrastructure ends up that way is clear, though: different sites have different needs for scale and availability, and we’ve delivered that in the past by deploying each site alongside some cohort with similar needs. We built Pantheon to change that, and we’ve invented some really neat technology in the process.

The Pantheon Way

If you’ve done things the old way, one of the first things you’ll notice about site spin-up on Pantheon is that we don’t lock you into tough decisions about the site’s underlying infrastructure as you create it. All you need to do is name the site and choose Drupal or WordPress. Whether it needs a simple stack or a large cluster is a decision for later—and one that is easy to change.

Forklifting 90s Architecture Onto Cloud Servers

Compare against how you start a project with Acquia® or WP Engine, where the first step—before writing a single line of code—is deciding exactly what infrastructure you’ll be locking yourself into. Acquia® wants to know whether you need a single server, a cluster, or a multisite installation. WP Engine wants to know if you’ll be on their shared hosting or they’ll be racking a cluster of machines for you (which takes weeks, by the way). Because critical, hard-to-change decisions are happening upfront, plan on a long procurement process. And, if your crystal ball of expected site traffic was inaccurate, plan on scheduled downtime and major cost changes to switch infrastructures.

It’s no surprise these companies force one of the most critical and hard-to-predict decisions on you at the infancy of a project: they simply don’t have the load balancing, file system, container, and upstream technology Pantheon has. So, to make up for their inability to offer one product that can scale up and down for all needs, they deploy different variants of legacy-style infrastructure for each set of needs. New need? New product. It does a great job of checking the boxes of buyers until the buyers realize the only thing all the products have in common is branding.

Load Balancing, Containers, Files, and Upstreams

Containers and Pantheon’s custom load balancing go hand-in-hand. Containers offer dynamic scaling for application servers, databases, and other resources. On average, we can deploy additional containers for a site in under a minute (usually far less). The containers we deploy are small, spreading more eggs into more baskets, which isolates failures. But, this would create more overhead than flexibility if we relied on traditional load balancer configurations (static backend configuration and monitoring). Instead, we run our own Go-based load balancer that discovers additional containers on-demand, scaling traffic and seamlessly avoiding failures (without taking the usual minutes to discover that a backend is “down”). This technology means Pantheon customers don’t have to pick ahead of time what application resources the site will need or whether it needs high availability (HA).

Our competitors also require an early infrastructure decision because it affects how they store your files. On a single or shared machine, they’re usually storing them locally, which doesn’t allow scaling up to multiple machines but is cheap and fast. When you pick a clustered configuration, they’re usually deploying GlusterFS or a hardware NAS, which allows multiple application servers but is slower and too expensive to use for smaller sites. (And, if you test the site on a single node and deploy to a cluster, don’t expect predictable results.) At Pantheon, we’ve developed a file system using C and Python that we use for every project from sandboxes to mission-critical enterprise sites. This technology frees customers from having to choose single-node or a clustered configuration at project setup and provides consistency between testing and production environments.

Another decision that isn’t good to make at procurement is whether any sites will need custom development (that is whether they’re 100% rubber stamps of each other). On Pantheon, every site starts as a rubber stamp of its “upstream” (Drupal, WordPress, related products), but it is isolated and can accept custom changes later. It’s all the benefit of multisite, including code sharing, batch upgrades, and visual uniformity without the downsides of inflexibility or the lack of security and resource isolation.

Because there is only one product for building, testing, and deploying sites on Pantheon, every project—large and small—appears in a single dashboard with a unified team-management system. There is no need to remember what infrastructure type a site uses to access tools for that site—or to resort to forensics to find out when you forget.

There are enough hard choices to make when building websites. Kick off projects faster and avoid cost and time surprises by scaling infrastructure as your needs change—not as legacy technology dictates.