Minimize Expenses with Drupal 8

Posted on 16 Oct 2017 by Oleksii Raiu
Minimize Expenses with Drupal 8

Drupal 8 has caused a lot of discussion in both Drupal community and outside, by it being not only more advanced and able than ever, but by also being somewhat more expensive to develop for. In my recent blog post, Why Drupal 8 is not for Small Websites, I have named a number of reasons that have made Drupal 8 more expensive to develop and support than Drupal 7 was. I know that some developers have been frustrated by the increased cost, and by the fact that this change was not even nearly well enough predicted and covered within the Drupal community. I myself have seen the increased cost, and have been saddened by this change. However, Drupal 8 is a wonderful system, flexible and modern, and if there are ways to cut the corners and still use it for the smaller websites, it gives a great flexibility once the owners decide to grow. I have worked out an approach for myself that has been allowing me to cut and still use Drupal 8 for relatively small websites in a financially viable way. I will share some thoughts and experience here, and hopefully, will help you if you are trying to do the same.

1. Why You may Still Want to Use Drupal.

In my recent article, Why and When You should use Drupal, I have demonstrated, that Drupal 8 is a powerful, robust, modern, flexible, scalable, and secure CMS. It does out of the box what some other popular CMS require hand twisting to do. So, aside of the increased costs of development and production with Drupal 8, it’s a very desirable system.

2. Which Expense Can be Minimized for Drupal 8 and Which Not.

In my experience, the cost of development with Drupal 8 has went up by additional 10% as compared to Drupal 7, and the cost of maintenance by additional 30%. The cost of development was initially high, because Drupal 8 was new and lacked documentation and needed some brushing-up in API and packaging. The maintenance and hosting cost has been increased due to the usage of Composer and the requirements it put on the hosting.

Now, let’s sort out what can be minimized and what can’t.

Development cost can be minimized. As I got more experience with Drupal 8 and the way it works, I ended up doing the same things at the same speed that I had with Drupal 7. Some things I actually ended up doing faster, due to optimizations in theming and OOP. Some other things that were easier in Drupal 7, however, became harder due to the same OOP. Overall, my current Drupal 8 development time is somewhat bigger as compared to Drupal 7, but very negligibly so. So I could even say development time for Drupal 8 can become non-issue once you cover certain things.

Maintenance and Hosting cost can be minimized partly. These two are interdependent, and attempts to save a lot with hosting will result in costlier maintenance. The optimal solution is to have hosting meet certain criteria, and that will minimize maintenance costs until they are about additional 10% to 15% as compared to a Drupal 7 site.

Thus, overall, you can round the corners until your total expense with Drupal 8 will be only about by 10% to 15% greater than it used to be with Drupal 7. Correspondingly, it will cut out only a small portion of the client base, the cheapest one, while hopefully allowing you to preserve your business with Drupal.

Some clients may agree to the fact your project will cost 10% to 15% more than with Drupal 7 if they know, that they are getting a superior CMS with better caching, more modern system under the hood, with better value, that will pay off once they start growing.

Now, let’s talk the specifics.

3. Minimize Development Cost.

Learn Drupal 8 API and OOP. A part of the increased development cost comes from the switch to OOP and changes in Drupal API. Once you get up to date, however, this will stop slowing you down.

Use modern code and package management tools. Git goes without saying. Composer is a package managing tool that moder PHP uses. Once you get to use Composer, learn about Drupal 8 YAML based config management, and add it all in git, you will actually see your development process optimized at many points.

Use a good PHP IDE. OOP can be hard if you are searching through the inheritance hierarchy. Modern IDEs have in them internal mapping mechanisms that will help you work with the classes inheritance efficiently. I use PHPStorm. It is non-free, but I find it addressing my needs with PHP and Drupal really well.

Use a Drupal 8 distro for a low start. Last but not the least. If you have a package of Drupal code base that works with composer, has the common modules pre-installed, and has the site already pre-configured for the average use case, with a base theme that has already been tweaked for the most common use cases, all this will allow you to potentially save a dozen or more of hours. In a small to medium project, a dozen of hours can make up to 10-20% of time save, which is a lot.

Talking about a Drupal distro - you need to be careful. If you grab some obscure distro, you may end up trying to understand what is there and why, thus only increasing the time cost. You will need to learn a few distros well and use them. Aquia’s Lightning is one such well known distro that you can trust for support. Alternatively, you can use your own distro that you can pre-build. I have one such. My Drupal 8 distro is called SiteCat. It is there on github and you can use it if you like - though mind that it is a custom, obscure distro of mine.

All this will optimize and minimize your development effort. Though, it’s not a magic trick - you will need to learn some. Since learning is one of my values as a developer, learning has never been an issue for me if I believe the goal is worth it. And I believe being able to use Drupal 8 is a good goal.

4. Minimize Maintenance Cost.

Drupal need core and modules updates to keep it secure. Unless there is a critical security update that needs to be applied ASAP, doing a monthly maintenance is strongly recommended. This is where Drupal 8 can become costly. It’s dependency on Composer means that you can no longer update modules via UI without breaking Composer support and the autoloader.

The optimal way to to perform website updates on a development or staging instance first, test the updates there, and then, if everything is consistent, to push the updated composer file to git, and do composer install on production.

If you have a healthy git and Composer workflow, you will have minimal support time, comparable to that of Drupal 7, or even better in some cases. Once you have everything in place, composer install is no slower that drush up.

5. Choose Optimal Hosting.

As you have already noticed, Drupal 8 depends heavily on Composer and git workflow. Thus, unless your servers run git, Composer, and ssh, you will be having very very hard time to develop and maintain the project in a good way. There is a way to do it on without Composer on production, though, Composer is still required on development servers, which is a must.

So, what are the actual working server requirements for Drupal 8.4? There is a system requirements article dedicated to this, but I will share my own experience. What I will share now are not the minimal, but the optimal server parameters for small Drupal 8 websites.

  1. PHP: 7.1
  2. RAM: 512 MB
  3. SSH: yes
  4. Git: yes
  5. Composer: yes

You need PHP 7.1 and up, because Drupal 8 has PHP 7.0 syntax and a Composer requirement for PHP 7.1. You need SSH, Git, Composer so you can pull and install the updates on production. This will be an ideal scenario. If you have less than 512 MB RAM, composer install command is likely to run out of RAM.

Now, I realize, that all this sounds like too much for a shared hosting, and it does. One of my clients is using Hostgator reseller hosting for the most of their websites. While you can get PHP 7.1 and bump RAM to 512 MB in most cases, getting SSH access requires additional effort, and their system build is very unfriendly to installing custom programs. Getting ssh, and then installing git and composer for each client there is very problematic and takes time, though it is doable. We are also having a number of websites hosted at services like DigitalOcean and Linode, where you can have a self managed server instance for $5/mo or $10/mo and have it perform better than Hostgator VPS in most cases.

If you can create a ready server template and apply it to your new sites, it can speed up things for your hosting and maintenance a lot, and keep hosting cheap. I have also googled for hosting solutions with the suggested parameters, and the cheapest solution I have found as of the moment is $15 packages at Kinamo.

Thus, given that Drupal 7 sites can be hosted for below $5/mo at almost any shared hosting, we face a dilemma - either a self hosted solution, or a $15/mo and up hosting in the best case. The hosting expenses are not really huge, but if you take care of multiple sites for your clients at once, you will be shocked to see the amount go up 3x times at least, but quite possibly, even 4x or 5x as you are looking for a solution with ssh, git, and composer.

There is another alternative, however. It will allow you to keep the cheaper hosting, dropping the Composer, git, and ssh requirement. You will need PHP 7.1+ and RAM though.

This solution is to update your websites on a dev server, and upload the updated code base to the server. This is a good old way of updating websites. It’s not ideal, for two reasons at least - more possibilities for human error, and longer upload times. But it will work. For me, Drupal 8 updates can take 15 minutes if everything is set up in an optimal way, but can take up to 30 minutes, if I end up uploading files via FTP. OOP results in lots of files of small size, that tax my FTP heavily as it struggles through them all, even though FileZilla has been set to handle 10 concurrent files at once.

It’s no-brainer to calculate that with more than a couple of sites, it will be cheaper to find a proper hosting than spend developer’s time uploading multiple files with FTP.

Approaches form colleagues:

  1. Scott Sawyer: You can manage updates on a development server, and serve them via git after modifying gitignore.
  2. Petr Parimucha: You can zip the changed codebase and unzip on on hosting.

6. Conclusion.

Development and maintenance times for Drupal 8 can be strongly optimized, saving 20% or even 30% development cost for smaller websites thanks to using the tools wisely and using ready-built distros for lower start. The hosting, however, can not be the same as it used to be for Drupal 7. Having a cheaper hosting will mean higher maintenance times, which is not worth it. Hosting needs to be optimal, even though somewhat more expensive.