Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Feb 11 2021
Feb 11

Last week one of our clients was asking me about how they should think about the myriad of options for website hosting, and it inspired me to share a few thoughts. 

The different kinds of hosting

I think about hosting for WordPress and Drupal websites as falling into one of three groups. We’re going to compare the options using an example of a fairly common size of website — one with traffic (as reported by Google Analytics) in the range of 50,000–100,000 visitors per month. Adjust accordingly for your situation. 

  • “Low cost/low frills” hosting — Inexpensive website hosting would cost in the range of $50–$1,000/yr for a site with our example amount of traffic. Examples of lower cost hosts include GoDaddyBluehost, etc.  Though inexpensive, these kinds of hosts have none of the infrastructure that’s needed to do ongoing web development in a safe/controlled way such as the ability to spin up a copy of the website at the click of a button, make a change, get approval from stakeholders, then deploy to the live site. Also, if you get a traffic spike, you will likely see much slower page loads. 
  • “Unmanaged”, “Bare metal”, or “DIY” hosting — Our example website will likely cost in the range of $500–$2,500/yr. Examples of this type of hosting include: AWSRackspaceLinode, etc. or just a computer in your closet. Here you get a server, but that’s it. You have to set up all the software, put security measures in place, and set up the workflow so that you can get stuff done. Then it’s your responsibility to keep that all maintained year over year, perhaps even to install and maintain firewalls for security purposes. 
  • “Serverless” hosting¹ — It’s not that there aren’t servers, they’re just transparent to you. Our example website would likely cost in the range of $2500–5000/yr. Examples of this kind of hosting: PantheonWP EngineAcquiaPlatform.sh. These hosts are very specialized for WordPress and/or Drupal websites. You just plug in your code and database, and you’re off. Because they’re highly specialized, they have all the security/performance/workflow/operations in place that 90% of Drupal/WordPress websites need.

How to decide?

I recommend two guiding principles when it comes to these kinds of decisions:

  1. The cost of services (like hosting) are much cheaper than the cost of people. Whether that’s the time that your staff is spending maintaining a server, or if you’re working with an agency like Four Kitchens, then your monthly subscription with us. Maybe even 10x.  So saving $1,000/yr on hosting is only worth it if it costs less than a handful of hours per year of someone’s time. 
  2. Prioritize putting as much of your budget towards advancing your organization’s mission as possible. If two options have a similar cost, we should go with the option that will burn fewer brain cells doing “maintenance” and other manual tasks, and instead choose the option where we can spend more of our time thinking strategically and advancing the mission.

This means that you should probably disregard the “unmanaged/bare/DIY” group. Whoever manages the site will spend too much time running security updates, and doing other maintenance and monitoring tasks. 

We also encourage you to disregard the “low cost” group. Your team will waste too much time tripping over the limitations, and cleaning up mistakes that could be prevented on a more robust platform.

So that leaves the “serverless” group. With these, you’ll get the tools that will help streamline every change made to your website. Many of the rote tasks are also taken care of as part of the package. 

Doing vs. Thinking

It’s easy to get caught up in doing stuff. And it’s easy to make little decisions over time that mean you spend all your days just trying to keep up with the doing. The decision you make about hosting is one way that you can get things back on track to be more focused on the strategy of how to make your website better.

¹ The more technical members of the audience will know that “serverless” is technically a bit different.  You’d instead call this “platform-as-a-service” or “infrastructure-as-a-service”. But we said we’d avoid buzzwords.

Making the web a better place to teach, learn, and advocate starts here...

When you subscribe to our newsletter!

Dec 06 2019
Dec 06

You may have read our previous articles about how to plan for Drupal 6 or Drupal 7 End-of-Life. The important thing to know is that the Drupal 8 End-of-Life is nothing like those. In fact, “End of Life” is completely the wrong idea. Instead, it’s more like one of those spa treatments where you get a full body scrub to get rid of the dead skin cells. You walk out feeling rejuvenated and refreshed. 

Drupal 9 — Same as Drupal 8, But Without The Old Stuff

Drupal release timeline

In each new minor version of Drupal 8 there are some new features, and some old code is marked as “deprecated” (that just means that it’s time to stop using this, because it’s going to go away some day). After nine minor versions over almost five years, there’s now an accumulation of deprecated code. This deprecated code is like those dead skin cells that you go to the spa to get rid of.  So Drupal 9.0 will be the same as Drupal 8.9, just without the deprecated code. The two might even be released at the same time. 

Then, in Drupal 9.1, we see the cycle starting again: some new features, and some old code is marked as deprecated.

Don’t Rely on Deprecated Code

In the graphic above, you’ll notice that 8.9 does not have any more deprecated code than 8.8. That means that once a website is upgraded to 8.8, we can then start the process of ensuring that the site isn’t using any deprecated code. 

If you are an Advomatic client, we’ll create a ticket in your queue to clean out all uses of deprecated code. In fact, if you’ve done a project with us recently, we’ve already started doing this as part of the Q/A process in our two-week sprints. 

A Window of Almost Two Years for This Cleanup

Drupal timeline by quarters

This is the timeline for the next several versions of Drupal.  We’ve got about 2 years to make this change — more than enough time. 

Alternating Minor Versions

We handle all the technical stuff for you. But the purpose of the website is not for us to have a technical toy to play with, it’s to advance the mission of your non-profit. So we want to devote most of our time and effort towards your web strategy. While we could upgrade your website to the newest version every six months, it’s not the best use of your money or time. So we alternate versions. That means that your Drupal 8 website is either always on an even minor version, or an odd minor version. 

We’ll likely continue that pattern as we cross the threshold into Drupal 9. That means that this process could be delayed by 6 months from what you see here.

Flipping the Switch

Once we’ve cleaned up all the deprecated code, then we’re ready to upgrade the site to Drupal 9.  Remember: this is nothing like past major upgrades in Drupal. Instead it’s just like the minor upgrades from Drupal 8.6 → 8.7 → 8.8 etc.

Conclusion

The key takeaway is that this whole process should be almost seamless. We’ll create a few tickets in the queue to prep for the upgrade, and then for the upgrade itself.  But the majority of our time will still be spent on advancing your mission. Over the years to come the website content and its presentation will be able to continually evolve, all without a costly major upgrade. 

Thanks to Amanda Luker for the charts!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web