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 GoDaddy, Bluehost, 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: AWS, Rackspace, Linode, 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: Pantheon, WP Engine, Acquia, Platform.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 Advomatic, 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 that 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.

Oct 05 2020
Oct 05

Why did we build local development and web hosting solutions?

The complexity of early enterprise Drupal projects such as www.popsci.com demonstrated the difficulty of moving between stages in the development process and replicating the stresses of the production site during development. Every team member had to configure their local AMP stack for every project they touched, with no easy way to ensure parity from one machine to the next. Delivering a code base and assets to the client’s internal operations team for deployment meant physically flying to headquarters and sitting down with the team to communicate the requirements of the application and associated services. 

That meant that any time a project moved, whether between team members for collaboration or to staging and production servers, environmental differences between development and delivery often surfaced, leading to hours of debugging and validation. As we struggled with handoffs to other team members and to the client’s operations team, we began to realize something was seriously broken with the process and the tools. How could a 15 minute code update take over 3 hours to get everything synced and updated live?

The problem was complexity. Each project needed environment configuration, importing assets, setting up customized services, databases, configuring web servers, memory allocation… etc. Once the site was delivered it would be under load experiencing pressure that was not easy to replicate in development. As complexity increased, we needed more hardware and extremely talented engineers who could navigate complexity and who weren’t easy to find. This led to exploring a solution that could manage the complexity in a way junior engineers could adapt to quickly. 

Solving complexity in web development

To start solving this problem of complexity and collaboration, we began by simply documenting the process. By writing down the steps required to get a project set up on a local machine or moved to a production server, we were able to standardize and at least smooth out some of the speedbumps. Still, creating these complex sites for clients with lofty goals and very specific plans was causing us some big problems. A manual checklist wasn’t going to be enough for us to do this at scale, for multiple projects or multiple clients.

This realization led us to the major focal points for what would become the DDEV solution. First, even using scripted installation profiles and migrations, subtle differences would surface in environment configurations. We needed a more unified, reliable way to replicate production environments on local machines.

We also had to have a way to merge and deploy changes automatically, in a way that could be viewed, tested and approved as a whole project, rather than individual PRs. It became difficult to find a place to host the projects clients had us building. None of the hosting providers at the time provided managed services that were designed to help the site succeed, hence the need on our team for engineers skilled in multiple disciplines to do the server management. 

The concept of improving local development began to take hold initially not by planning to build a tool, but by scripting our checklists into installation and migration profiles. These scripts were then converted to Jenkins jobs to ensure management of external environments. While that was a huge improvement, it was very fragile and prone to unexpected errors in different environments.

The concept of finding a way to pull all of the changes together as a whole and run them in an environment that was fast enough and could meet our needs led us down the road to “self-hosting.” At the time, as an agency building these sites, we realized that while we could build a self-hosted production environment, that really was not our core business.

Building on the lessons we learned from managing agencies, building enterprise sites, combined with deep open source knowledge, we decided to spin out DDEV as a separate company. Our focus would be on advancing developers in open source communities by sharing the tools and processes we built to solve our own problems.

It was at this intersection that we realized there was a significant gap for web developers, specifically PHP developers, that we were right in the middle of trying to solve. Like most startups, we looked in the mirror and said, “We can build a product to do this… it can’t be that difficult!”

It turns out that solving a complex problem is complex. Our overarching design goals from the very beginning for DDEV were focused on:

  • Reducing and managing complexity in the development process
  • Creating an easy way for team members to get a local copy of a project to work on
  • Creating a repeatable way for teams to work together using this process
  • Making best practices the easiest choice for developers

If doing something the right way isn’t also the easiest and fastest way, then developers won’t be happy about it and their productivity will be adversely affected. To unify and simplify the experience, we’ve focused on providing a complete end to end solution for the development and deployment of complex web projects. Docker and Kubernetes have also enabled us to build the platform we envisioned thanks to mature container technology and communities.

We’ve taken into account the many steps in the process of designing, building, deploying and maintaining web apps and digital properties. Each project has unique requirements. Each client has different technologies in play. Each developer has unique skill sets. We are focused on creating a solution that allows each developer, client, and project a way to work together no matter what part of the project they are working on.

DDEV local development and hosting today

In 2017 we released our first supported version of our local development tool, DDEV-Local. The tool is fully open sourced under the Apache license and has benefited from over 100 contributors adding to the code, documentation, as well as giving presentations on usage around the world. DDEV-Local has attracted thousands of developers to adopt it as their standard because of the quick startup time, ability to run multiple projects at once, share with colleagues and collaborators, and customize configurations.

There are DDEV-Local quickstart guides available for Drupal, TYPO3, WordPress, Backdrop, Magento and Laravel, but just about any PHP project will easily run in DDEV. Some other top web applications that use DDEV include Sulu, CraftCMS, Symfony, Flexitype, Bludit, and plenty more, thanks again to the contributors who share their recipes and blogs.

Some common daily use cases include sales demos, client sign off, team input, testing new modules or code and reviewing patches in the issue queue. DDEV has become part and parcel of daily work for thousands of PHP developers. As teams and individuals see success with DDEV, scaling that success by encouraging workflow changes, creating clean development environments and increasing collaboration is something that DDEV is committed to and drives the continued innovation of this product.

In 2018 we released the first version of DDEV-Live, our Kubernetes-based hosting platform. Earlier this year, in March of 2020, we released the second major version of DDEV-Live, focusing on more cloud native principles, GitOps concepts, and designed around an API-first architecture to allow developers an easy way to communicate directly with the platform.

What’s next?

Later this year we will be releasing some new functionality that will act as a bridge between the DDEV-Local development tool and the DDEV-Live hosting platform. We will continue to focus on enabling teams to have the best workflow dynamics possible through developing the DDEV API to offer flexibility and customization for all team project needs.

Share this post:

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