We hosted Drupal websites at Hetzner for a few years. While it's unbeatable on price, it requires a skilled Linux sysadmin, which weights on personnel costs. Our guesstimate was that we'll pay a third more for a Drupal hosting, but our sysadmin costs would go down by ⅔. Add in non-material considerations, such as lower personnel turnover risks and better DDoS protection, and alternatives to Hetzner start to look almost attractive.
So, we decided to check Drupal cloud hosting solutions and asked for quotes from Pantheon and Acquia. Pantheon was less expensive and had more features. It also edged out Acquia on technology by using Linux containers instead of Amazon Web Services as underlying infrastructure. Unfortunately, Pantheon servers were located near Chicago, while most of our readers are from Europe, so we had no choice but to go for Acquia.
The pricing policy of Acquia is strange. They charge separately for AWS services and for the added value of Acquia. We did not compare down to the last cent, but buying AWS through Acquia is roughly equivalent to bying from Amazon directly. In contrast, the price of the added value, the so called Acquia 'Enterprise-level' subscription, was huge compared to AWS costs.
We have a fairly complex setup, and our main website required a custom Varnish configuration. There were reservations about site speed on AWS, as it is known to be relatively slow. We have not been offered a trial period, so instead of buying a full-blown Enterprise-level subscription, we decided to try out Acquia gradually. We'd first sign up to the 'Developer' subscription, migrate a couple of smaller websites to Acquia, then after a week or so, we'd grow our Amazon EC2 instance, bump up the subscription level to 'Professional' and move several bigger websites there.
Acquia suggests to install the Acquia Network Connector module to migrate into Acquia Cloud. Just install the module, provide your Acquia credentials, click the migrate button, and your website is automatically migrated into Acquia. Unfortunately, it does not work in practice. We tried it on two tiny websites, but it failed on both, showing an obscure error message. This is not a big deal as there are other ways to migrate, but it gave bad impression — some potential clients should have tried Network Connector, failed and abandoned the idea of going with Acquia at all.
The smallest AWS package and a Developer subscription cost $165/mo and work only for tiny websites. A multisite with a database of > 1GB was clearly lacking resources. To serve 1mln pageviews/mo, you'll need to upgrade your AWS instance to at least 4 ECU/7GB RAM, which will increase the cost to $430/mo.
Surprisingly, the most useful feature of Acquia so far has been its development workflow. We've been struggling for months to maintain a coherent set of environments to work on. We had live, staging and multiple development environments, but we constantly redefined how we would use them, as we progressed. Acquia imposes a simple and elegant definition that everyone understands. There are actually two workflows:
- Before you release your software, you work on
dev
, test onstaging
and deploy inproduction
, so your workflow is as follows: dev → stage → prod. - After the first release, you work on dev, deploy code on
staging
fromdev
, and database — fromproduction
, so your workflow looks more like dev → stage ← prod. You are only allowed to push code to production, but never — the database.
Lack of a decent git workflow came as a bad surprise. Until recently, we had git repositories at docroot with Drupal modules imported as git submodules. This has two benefits:
- With your own git repository at docroot, you can add Drupal upstream repository as a git remote and update to the next minor version of Drupal by simply issuing
git merge && get fetch 7.26
. - With the git_deploy module, you can see Drupal update status even when using git submodules.
Acquia does not support git submodules, so developers are left with two options:
Use git subtrees and forget about Drupal update status — you'll have to handle security updates manually.
Just add modules as new directories into your main git repository, ditching their upstream histories and using git as an incremental backup mechanism, not as a version control system.
Both options hurt our productivity.
Another pain point is Acquia's website. It's hard even to figure out how to login. Once inside, there's a confusion of names: subscription, site, docroot… you name it. Navigation is counter-intuitive. The most basic features are missing. In order to delete a site, you have to file a ticket. You can rename a site, but it's not really renamed. That is, Acquia relabels it in its user interface, but the server still uses the old name, and there's no way to rename that one… except probably by filing a ticket?
We wanted to upgrade the subscription level from Developer to Professional. I searched for a button, googled… just to find that you have to file a support ticket for that. Come on, guys! You earn money from subscriptions, make it easy for customers to pay you!
OK, I filed the ticket, it took 3 days to execute it… partially. One can have 10 sites with the Professional subscription, but the web interface did not let us create a fourth website. Another ticket, some waiting time… Another partial solution… Third ticket… it's been a week, and I am still waiting for the resolution.
And it's not even that the support is unskilled. They are certainly overworked and do not keep up with the current rate of tickets. But they gave a clear and precise answer to a tricky question on Varnish configuration and to another question on the details of migration to an Enterprise-level subscription.
We've been using Acquia less than a month, and they already changed their ticketing system and introduced a big new feature called Teams. If only they could pause for a while and fix those annoying UI bugs to unload support and make their existing clients happy.
We are still using Acquia. Our websites run OK, and we'll likely get an Enterprise subscription. We only wish that they become a bit more customer-friendly.