I thought I'd share some experiences we've had lately with Web hosting companies. From time-to-time, we're asked by our customers for guidance related to cloud platforms and hosting providers. This story revolves around one of our clients who asked us to recommend a hosting company for their new, Drupal-based website.
Some background first: Innovent Solutions' own website is located at a company which I'll refer to as "Company A." Now, Company A has performed adequately over the life of our website, but we have mostly static text and not a lot of data-driven content.
Our client, however, has a Drupal website with content driven by an Apache Solr Server running under Tomcat, is using a MySQL database, and has tons of images that are rotated through the site. Based on our experience with Company A, we began the process by provisioning a shared server, and using a combination of the CPanel tool and tech support, began installing and configuring the required software. The next step was to transfer over the site code and the images. After a couple of calls with Company A, to configure items that we, on a shared server, had no access to (such as opening a firewall port to Tomcat), the site was up and running - a somewhat painless implementation.
We were live on Company A, on a shared server for about a year. Solr is used to provide a list of products to the main website home page, so it's easy to tell when that goes down - ZAP! a non-working home page. Let the fun begin - how many times in a year can Tomcat (and thus Solr) go down? Too many, and each and every time the client made two calls: one to us, and one to Company A's tech support. Being a shared server, we couldn't restart it and we had no access to start and stop Tomcat, so we were at the mercy of Company A's technical support. And let's just say, they were not very responsive - sometimes up to 4 days later.
Could you live with a public-facing website being down for 4 days? Our client could not, naturally. So the search was on for another hosting company. We and the client found Company B, another similarly-sized hosting company, and begin the process of provisioning the server and installing software, copying gigabytes of images, etc. At the point we had everything installed and working, and were just about to switch the DNS entries to point to Company B, and WHAM! Company B goes down for FIVE days, during which they were totally unresponsive. Could life be any better?
What to do, what to do. Back to Company A for three reasons: they gave the client some free months; they promised to be more responsive; and they switched our client to a VPS (Virtual Private Server), saying that it should cure all of the world's ills (that was sarcasm, by the way). So, we're off and running, provisioning the server, installing software, and once again, copying all of those images. And life was good for about 5 months, until a symbolic link to the correct Java magically disappeared. Really?? Someone or something deleted a symbolic link that caused Tomcat to fail, which caused Solr to fail, which caused the website to stop working.
About Company A's promise to be more responsive: it only took a couple of days of arguing with tech support that the missing link wasn't our fault. They finally acknowledged it was a problem with upgraded software on their end, and their fault, and they fixed it. So, the client's website is back up. For 4 months, this time. Yet again, a missing Java symbolic link. As I looked for a wall to bang my head against, Company A's tech support takes another two days to acknowledge the exact same problem and fix it.
This should be the end of the story, my friends, but wait, there's more!
Guess what happens in the middle of October of this year, eight months after the client's site went down last time? BAM! Down we go again. Same problem again, the missing symbolic link. This time, the client's site is down one day, two days, three days... No help from Company A's tech support, even after escalating the problem to the so-called "gurus". Now we're left with another "what to do".
This time we convince the client it's time to change venues. With their approval, we're off to Amazon Web Services and their Elastic Compute Cloud services (ec2). We've worked with several other clients over the years and have had great experiences using ec2 and have found it very easy to deal with. So, while Company A is still being unresponsive about the site being down, we gather everything up, install it, copy images (once again), and bring up a fully working ec2 instance in less than a day. After the client signs off on this new setup, we change the DNS entries and we're off to the races! The best thing (in this author's opinion), is that we have complete control over the ec2 instance: rebooting, restarting software, upgrading or not upgrading software, adding users - all under our control.
Scary stuff, right? The last communication from Company A's tech support was "I
apologize however we no longer provide tomcat support". Come to find out that Company A and Company B are now owned by the same people, which is probably why they are so fun to deal with. And back to our own website? We're planning the move from Company A as I write this.
Since going live, we've used Amazon functionality to add logging, create system metrics, and alarms to automatically alert us if there's a problem. To see what's involved in setting up an ec2 instance at Amazon and adding these customizations, check out my next blog post.