Acquia Cloud has made me lazy… and I like it.

Over the last few weeks I’ve been involved in setting up a number of servers with other hosting companies—none of them were tailored Drupal hosts, but they were all big, big hosting companies. Some were virtual hosts, some used cpanel or plesk, but all were unbelievably painful!

I need to be fair, though, a significant portion of the pain was not their fault, but rather the fault of Acquia Cloud hosting. You see, it’s made me a bit lazy, and honestly it’s caused me to expect a bit too much from a host.

Let’s start with APC (advanded php cache). Anyone who does a lot of Drupal dev will want to get this rolling on their server. You just can’t run a performant PHP-based site without APC. So away I go with my pecl install apc.

Bam! No dice! The host didn’t have any c-compatible compilers on it. I know its CentOS, so I fire up yum… oh, yum’s not there either. I look up the rpm packages I’ll need to pull down to get yum, and try them. Dang! They have dependencies as well, and trying to get those dependencies puts me into version conflict hell. It turns out that the server’s software is quite out of date and I can’t manage (without more effort than I’d like) to find a repository with the right versions to match what’s on the server.

But wait! The host has an option in their UI to install developer tools and in that list is gcc and yum! I’m saved; I can click this, get my compiler and eat cake. The developer tools installer UI takes about 15 minutes to run, and then tells me that I’m good to go. I go to my bash prompt and hit pecl install apc again. I answer the questions, and then it starts to compile. Again a problem! This time I get an error that my system can’t run C-compiled programs.

Well that’s odd… the packages I thought the UI had installed should have given me this. I look for gcc and don’t see it. So I try to fire up yum. It’s not there either (though a few of its dependencies are).

At this point (because I’m doing this as a favor for a friend) I cut my losses and open a support ticket with the host (who hasn’t responded yet). Theoretically they should know how to update the software on their machine…

I dive into some other areas. Their default install—for a machine with 512MB of memory—is to allow 150 concurrent apache connections (with mod_php, so they all consume extra resources), keepalive off, all of the default timeouts and a php memory limit of 256MB and no execution timelimit! Essentially this server could consume 37GB of memory when it only has 512MB.

Now I know that a lot of these settings are the default in various installs, but that’s not the point. This server is specifically intended (by the hosting company) to be a webserver and their scripts are the ones that installed the software—they could have easily tailored the configs to not make the server fall over as easily as my daughter after she spent the last 5 minutes spinning in the kitchen yelling, “weeeeeeeee!”

Maybe I’m expecting too much, but in 2012 this stuff is fairly nailed down. Some math to ensure that the software running in the server is configured (even roughly) to run within the machine’s spec should not be too hard to perform.

I could go on, but the end result is that I spent many, many hours configuring servers, fighting with permissions where I didn’t have root, and ultimately failing (in one case) to get the server configured to even what I would consider the base-level for Drupal/PHP hosting.

Before I go on I think it’s important to note that I am not on the Acquia Cloud hosting team; or part of the ops or support teams. My group makes stuff for Acquia that we run on our cloud hosting. I’m actually as much a customer as anyone else—a somewhat large customer with over 30 servers.

I live and breathe the Acquia Cloud workflow UI. In fact all of Acquia’s site code (with a few exceptions) is deployed just like a customer would deploy code, and all of our servers are set up by the same teams and with the same configs that our customers get.

And you know what? I have never, ever had to spend any time configuring a server to have the software in place that I need for my work. The full extent of what I’ve had to do it raise or lower PHP memory and processes (inversely) as we tuned sites to need less and less memory to execute.

Need Drush? 4.5 and 5 are both there. Concerned about caching? Check off a box to get memcache rolling on your server(s). Want allll the logs about what is going on—broken out cleanly by site? There they are. Backups? Done. Log rotation? Done. Mirrored dev, stage and production environments? Done.

All I have to do is what I want to do. Build sites and applications in Drupal and host them on infrastructure that will make them shine.