Updated February 3, 2021
For higher education IT departments, it's a familiar scenario.
Your team is in charge of managing hundreds of websites that support different mission-critical areas of your organization. You're in charge of updating the sites, keeping them all up and running, and optimizing their performance.
What's more, each site has its own small team updating content, creating new features, and working within the Drupal admin system. These users are predominantly non-technical and reach out to your team whenever they need help.
📺 Watch: Learn how to take full advantage of Drupal in a university setting with our on-demand webinar 5 Keys to Success for Using Drupal in Higher Ed
Over the years, we've worked with many teams facing these exact challenges. Through our clients' experiences, it's become quite clear that your ability to effectively manage your platform is substantially determined by your architecture.
Drupal 8 (and 9) core includes multisite functionality and is a popular choice that works well up to a certain number of websites.
For a large-scale university platform with hundreds of sites, however, we prefer to use a shared codebase that provides more fine-grained control. This is exactly what Pantheon Custom Upstreams does. Let's take a closer look.
Challenges for Deploying Higher Education Websites
While all of our clients are unique, they also share many of the same challenges. For our higher education clients with large, complex Drupal platforms, we encounter some key pain points time and time again.
- Redundant implementation. When fixing a bug or developing a new feature, the wrong architecture can leave you re-implementing and testing the solution on a site-by-site basis. This can turn a 5-minute fix into a project that takes several hours.
- Cumbersome testing. Testing and deploying Drupal updates across hundreds of sites can get very tedious and time consuming. There are weekly releases of updates for contributed projects, twice monthly core updates, and additional critical security updates when needed, each of which must be tested against every site.
- Difficult system-level updates. System updates like PHP versions are infrequent, but they're critical for maintaining site security and can require code adjustments to keep things working correctly. These adjustments must be discovered, implemented, and tested within both the platform code and per-site customizations, making these important updates a potentially daunting task.
- Significant risk of introducing new bugs, conflicts, and inconsistencies. When hundreds of sites share a codebase or installation profile but also have their own customizations, any change to the platform code has the potential to cause problems at the site level. A new platform feature, for example, might work great on most sites but conflict with a custom module used on a quarter of the sites, several of which have their own revisions of the module that may cause additional issues... it can get quite messy.
📚 Read next: What's the best CMS for higher education in 2021?
Possible Architectural Solutions
It's clear that these challenges are big enough to deserve a good solution. There are two main approaches to architecting large-scale Drupal platforms, each with their own advantages and disadvantages.
With Drupal's multisite setup, separate, independent sites can be served from a single codebase, each with its own database, configuration, files and domain.
Multisite has the advantage of being relatively simple and intuitive to manage. Having a single codebase means less code to administer, and updates are rolled out to all of the sites at once. Additionally, individual sites can incorporate their own themes and modules as needed.
However, it also comes with some disadvantages, which are amplified when managing large-scale platforms:
- Having a single codebase and single server means you also have a single point of failure. An issue in your server or codebase will affect all of your sites, potentially taking down the entire platform.
- Deploying updates or fixes to selected sites is difficult because all of them share the same codebase. Anything deployed for one site has the potential to affect any other site on the platform.
- Drupal updates deploy to all sites at once, and cannot be reverted on a per-site basis. This means that either all sites must be tested before any can receive the update, or some sites will be in a broken state until they can be fixed individually.
- Teams come up with homemade solutions to circumvent some of the challenges involved with maintaining a multisite installation. These solutions can be difficult to maintain if documentation is not properly written, or if they function in unexpected ways.
A shared codebase can include a set of modules, an installation profile, a Drupal distribution, or other code that's used for multiple sites on your platform. Rather than all running off of the same code, however, each site has its own copy. Individual sites can also have their own customizations as long as they don't conflict with the shared codebase.
Shared codebase pros:
- Bug fixes, new features or even security updates can be added to the shared codebase and pulled into each site when its team is ready to work on it, rather than all sites updating together on a forced schedule.
- Customizations can be applied to each individual site without having unintended effects on other sites.
- Avoiding a single point of failure at the server level eliminates the risk of an error or conflict taking down the entire network of sites.
Shared codebase cons:
- Applying shared codebase updates to each site individually requires doing work for each site, which can take more time.
- Multiple servers or hosting environments must be administered and kept consistent across the platform.
Custom Upstreams: The Pantheon Approach to a Shared Codebase
Pantheon hosting platform has introduced the concept of Custom Upstreams to solve scenarios like the one described above. With this solution, you can standardize design and functionality across multiple Drupal sites that share a custom upstream managed by your organization.
This governance does not compromise the customization of individual sites. Instead, it offers a sustainable and scalable solution for handling updates across massive site portfolios. When used well, Custom Upstreams frees up developer time to focus on higher-impact work, and makes it possible to spin up new sites quickly, without repeating foundational work.
Deploying updates to the upstream is as easy as pressing a button in the dashboard to pull the update into the development environment and then deploying this update to test and live environments. Further automation is possible with Terminus, even to the level of running a single script to update and deploy all of the sites at once. There is a lot of good documentation from Pantheon about creating Custom Upstreams and related topics.
Pantheon Custom Upstreams provide solutions to those challenges and also mitigates the disadvantages of the architectural solutions explained above:
- There are no servers for you to administer.
- The PHP version can be changed globally and overridden per site if needed using the pantheon.yml file.
- Security updates, new features and global bug fixes can be applied to the custom upstream and pulled into all of the sites either manually or through some automation.
- There is no single point of failure at the server level, and the Pantheon folks are really good at managing their infrastructure.
- A lot of automation can be done by using Terminus and Terminus plugins.
There are always tradeoffs to make when attempting to balance power with complexity. Drupal's multisite setup—a solution that is initially simple and intuitive—can evolve into a quagmire as the platform scales up to meet the requirements of higher education institutions.
Over years of experience working on higher ed websites, our team has forged a set of preferred best practices for architecting and managing these exceptionally challenging platforms with a shared codebase. Pantheon's Custom Upstreams provide tools and automation to relieve some of the complexity of administering independent sites and their environments, while retaining the powerful benefits of such an architecture.
If you'd like to learn more about our toolbox for large-scale Drupal platforms, check out How to Set Up BLT and GitLab CI to Work with Pantheon Hosting (Part 1) and (Part 2), or reach out to our team for personalized assistance.
Check out these other resources: