A Technical Deep Dive into Pantheon’s Offerings

July 18, 2017

Blog | Development | A Technical Deep Dive into Pantheon’s Offerings
A Pantheon Partner Interview: Technical Deep Dive

In our last interview post with our partner Pantheon, I sat down with Pantheon’s Community Engineer Steve Persch to educate our clients on their services, the benefits they offer, and the things that set Pantheon apart from other hosting providers out there. In this post, we’ll take a technical deep dive into Pantheon’s workflows, continuous integration, command line tools, and site performance. Let’s dive in…

Workflow

Pantheon has a development workflow allowing users to provision multiple environments almost instantly. Can you provide insight into what is available out of the box and how a Pantheon user may best leverage each environment?

Steve: Out of the box Pantheon offers three environments, Dev, Test, and Live, with each environment having its own copy of the database. Content changes can happen in Live, while developers are testing and debugging changes to the code in the Dev environment. This enables a workflow where content editors can make updates to the content while developers are making ongoing changes in Dev and pushing them up to Test for QA before pushing Live.

In addition to Dev, Test, and Live you can have what are known as multi-dev environments.  Multi-devs are basically an additional Dev environment that can be used for things like pull requests, or developer specific environments.  One of the nice parts of having these separate environments is New Relic Pro which provides detailed performance stats about each site. If a developer is making a change that may have performance implications in one environment,  it becomes easy to test that environment’s performance stats against the performance stats of the live site.

Pantheon uses the idea of Custom Upstreams instead of classic Drupal Multisite.

What are Pantheon Upstreams?

Steve: Upstreams are how we control updates to Drupal or WordPress Core. For someone spinning up a normal site, whenever a new version comes out, they see the change become available in their Pantheon dashboard. From there, they can simply click a button and that update is automatically applied. One click updates to both Drupal and WordPress have made it easier for developers and site owners to take responsibility for these updates.

A user may also choose to create a Custom Upstream.  To do so, a user can fork the base git repository to create their own copy of the repo with their own set of plugins and modules.

For instance, some universities have specific themes or modules they use on every site. By using the same upstream, it allows admins to make updates to core, modules, and theming customizations in one place, then push them out to however many sites they may have.

What makes upstreams different than Drupal’s traditional multisite?

Steve: There’s a key difference between the two models. With Pantheon Upstreams, every site runs on its own infrastructure, this is a big deal for sites that have sporadic traffic spikes.

For example, we were recently working with a political site – whenever they had an event that would cause a spike in traffic on a single site, like during the debates, it would affect every site on their server. To eliminate unintended side effects, they switched to Custom Upstreams isolating each site.

Upstreams can also be useful when making site updates. It’s possible that the newest version of Drupal Core won’t work on one of your 100 sites, but you can still make updates on the other 99 and then figure out what is wrong with the one remaining site and fix it.

Continuous Integration

You’ve done a lot of work with Continuous Integration through CircleCi on Pantheon’s platform.  What role can Continuous Integration play on Pantheon’s platform?

Steve: Depending on how you define CI, I’d say Pantheon already offers it. I would define CI as bringing together, on a regular basis, all of the elements necessary to make a website run. If those elements are as coarse as the code, database, and files then Pantheon already does it. The communities are now thinking of the code base itself in more granular terms, where Sass needs to compile to CSS, and dependency managers like Composer need to run. In that mindset where your codebase alone is a build artifact, GitHub and CircleCi are where it’s at.

Pantheon has no intention of competing with a service like GitHub, we don’t do pull requests, but we would use continuous integration services like CircleCi or Travis as an add-on. What we are working on is a tool that automatically sets up a relationship between a repository and a 3rd party such as CircleCi.

Can you speak a little bit about why you chose Circle CI?

Steve: A lot of our team members have gotten comfortable with it because you get SSH access to each build which gives developers the ability to debug mysterious fails in real-time. It also offers simple, readable config files. In addition, CircleCi has a freemium model that makes it easier for agencies to experiment with CI. A lot of these services charge $200-300 a month so it can be a blocker for agencies dealing with a lot of sites. Having a free container, agencies have the ability to experiment with a real site that’s still in a private repository, but you don’t have to pay more until you decide you like it.

Drupal 8 introduced configuration management as part of Drupal core.  What can a developer do within a Pantheon environment to take advantage of this new tool?

Steve: Pantheon offers our Quicksilver Platform Hooks that give you the ability to have scripts run in response to Pantheon deployments.  One way you can leverage these hooks is to have your configuration import run every time you deploy code into a test or live environment.  Doing this automatically ensures your configuration is always up to date, and eliminates the manual steps involved in a normal configuration update. The Drupal community itself is still determining what the best strategies are when it comes to configuration management, but leveraging the various tools Pantheon provides is certainly a step in the right direction.

Command Line Tools

Drupal has two major command line tools, Drupal Console and Drush. What is your favorite command/use for each?

Steve: For Drush I like the user login command, “drush uli”. For Drupal Console I use the debug commands a lot: “drupal plugin:debug”, which gives you a list of every plugin type and every implementation of those plugin types. There are “debug” commands for lots of subsystems like routes and the container.

Do you see a day when Drupal Console will replace Drush entirely?

Steve: I don’t know. Drupal Console is only available in Drupal 8, it doesn’t offer support for Drupal 7 – for the moment, that seems to be the biggest split between the two. In the early days, Console seemed like it would be used in the development of modules, some of the most impressive parts of it were related to that, over time more and more commands have been added to Console.

Pantheon has its own command line tool, Terminus.  How would you describe Terminus to a new Pantheon user?

Steve: I’d explain Terminus as a way of doing everything you can do in the Pantheon dashboard on the command line. One of most powerful things about Terminus in my opinion, is how it can be used in scripts. Having the ability to script things like database backups, etc. are a big deal.  Plus, sometimes it just feels faster to do things on the command line.

Caching/Site Performance

Caching plays a large role on any high traffic website. How does Pantheon’s approach to caching differ from other hosts?

Steve: We provide Varnish caching across the board to all sites on Pantheon, so long as a site has implemented normal Drupal or WordPress page headers, they will immediately get the full page caching benefits of Varnish. It’s typical for a Drupal or WordPress site to take hundreds and often thousands of milliseconds to produce a page, that’s pretty slow.  But Varnish can serve that page from cache in a single millisecond or two. This drastically cuts down load time on sites that don’t have Varnish and/or are struggling with full page caching. (This is important considering bounce rates increase by 50% if your website takes 2 seconds extra to load according to Junto.)

The global CDN we are rolling out now will allow for much more fine grained caching. Basically, it allows a site to clear specific pages in an archive. If a 2 year old post gets updated, they don’t have to do anything fancy to get the site to clear out pages, just that page will be cached.

Pantheon also bundles Redis, an in-memory object cache, as a add-on to Professional, Business, and Elite plans. Redis provides the ability to reuse data objects that typically require requerying the database or additional application processing to generate.

The latest versions of Drupal and WordPress both support PHP 7.  What types of performance increases can a developer or end-user expect to see?  

Steve: Huge performance improvements, very consistently we’ve seen response times drop in the range of 30-40% in the time spent in PHP. New Relic makes it very easy to see the change.

A huge thanks to Steve for taking the time to sit down with me to educate our clients and other developers about Pantheon’s initiatives and things that are going on in the Drupal community in general. If you missed our first interview with Steve, you can read it here: What’s the Pantheon Difference?.

Drew Nackers

Technical Lead
Tags
  • Drupal
  • Pantheon Hosting
  • PHP

Was This Helpful?

Hopefully it was! If you think that GeekHive could help you or your organization further, let us know, we're here to help.

Recent Work

Check out what else we've been working on