Blog




Dedicated Hosting Providers Suck for eCommerce

A Dedicated Hosting Provider (DHP) is a web hosting service which specializes in hosting a specific Content Management System (CMS). The CMS can be WordPress, Shopify, Magento, Joomla! or any other number of countless CMS’s on the market. The other way to host a website is by using a traditional web server. Most of the world’s websites are hosted this way. DHP’s are a relatively new offering.

First, let’s discuss the pros.

They’re good for anyone without much, or any technical knowledge. They offer automatic backups which can be restored by the click of a button in case anything goes wrong. You’re provided with a list of incremental backups so you may restore the site from any point in the past. They also manage WordPress core updates/upgrades for you. If you’re running a simple (non-eCommerce) website, this is usually a welcome feature. Another advantage is they usually come with a Content Delivery Network (CDN). A CDN hosts images, files, video, downloads, etc. Since DHP’s are one-trick-ponies, they usually have better than average tech support. With a traditional web host, you’re mostly on your own. A traditional host does not offer CMS specific advice or support. If you build custom WP templates for a client, the site can be easily transferred to another account once you’re done. They also offer great out-of-the box security. Even though OTB WordPress is fairly secure, with a traditional web host some of the security “hardening” might fall to you. Most offer a free website restore if your site gets hacked. They also offer various other free services such as SSL certificate management, migrations, malware cleanup and demo sites. They also tend to be cheaper than traditional web hosts, but not by much. Finally, they offer great performance with automatic server load balancing and managed caching. This all probably sounds like a no-brainer, right? Not so fast. As I said at the beginning, they’re great for beginners. It also depends on what type of site you’re running. If you’re running an eCommerce site, a DHP might be good for getting started but sooner or later you’ll inevitably demand more out of your site as your business grows. A DHP may not be able to accommodate your growth, as this means you’ll have to perform more advanced activities involved in development and management. This is where it goes south.

Now, for the cons.

My experiences with DHP’s have been frustrating to say the least. When it comes to the more advanced requests, they’re can’t-do-it sort of places.

Example 1: We had a script that would take the site offline a couple minutes before our desired backup time (11:50 PM PST). This was to ensure no more orders were placed that day, and all that day’s orders would be on that day’s backup. Unfortunately, most DHP’s cannot schedule backups. Rather, they are automated at a random time of the day. While it’s not the end of the world, it’s not ideal. In the event you need to perform a backup, scheduled backups provided the best knowledge of what orders were placed and which were lost.

Example 2: We needed an SSH connection into our MySQL database for some ETL work. They couldn’t do it. There is a workaround, but it was not ideal for what we were doing. It doesn’t matter if there’s a workaround or not, we needed it to be done a specific way that would have easily been done with a traditional web host.

Example 3: They do not disclose server resources. With traditional hosts, you know the exact hardware configuration of your server. It’s usually shared, business class, dedicated or virtual private server (VPS). (All the cloud engineers will undoubtedly weigh in on this one, but were assuming the eCommerce site doesn’t have money-growing trees in their backyards.) Whichever server setup you have, if your store ever slows down you can balance all your efforts to speed it up against your known hardware resources. If you have a VPS running CentOS with 4G of RAM and an 8-core processor and your best efforts to maximize speed still aren’t enough, you know it’s time to upgrade the hardware. DHP’s won’t tell you these specs. They simply “increased your server resources”. But why did you have to call them in the first place? Why are they not monitoring load failures and adjusting resources dynamically? (Cloud engineers, there is where you chime in again.) When it comes to DHP server configuration, you have to fly blind. This does not work well with strategic decision making.

Example 3.5: We’re calling this 3.5 because it strongly ties into example 3. As the business grew, so did the demands on the store. We got integrated with our customers’ procurement systems, fulfillment center, accounting, a sales tax service, CRM, data warehouse and a custom form. These things demand server resources. One day we began receiving strange errors. After a tech support call, the rep “increased our website resources”, but wouldn’t tell me exactly what he did. He wouldn’t reveal what additional resources he allocated. It was frustrating to say the least.

Example 4: Although we didn’t have SSH access to MySQL, we did have SSH access to the web root. Every Linux jockey almost certainly has customized BASH or Z shell profile (BASH & Z shell are to Linux what c:\> is to Windows) to expedite workflow for longer shell commands. Well, DHP’s do not offer this ability. One on the most common aliases is ll (two small case l’s) which is short for ls -al. IOW, you simply type ll and it executes the longer command: ls -al. Not having the ability to customize the profile is just ANNOYING. While this is just a short command, there are much longer ones you must type by hand every time you run it.

Example 5: Every single DHP I checked didn’t offer SMTP (the ability to send email). If you’re running a store, this means you’ll have to sign up and pay for a relay service like MailerSend or SendGrid. So, add that monthly expense. If you go with an eCommerce DHP, they might include this but not necessarily. If you sign a contract, make sure you look into this.

Example 6: We had a page on our store containing how-to videos for some of our products. Everything was fine for a while until the DHP notified us the videos were using too much bandwidth, and we had less than a week to remove them. This was in spite of the fact they offered a CDN along with the hosting service! We had no reason to think it would be an issue, and there was nothing in the fine print about usage limits. We had to drop other priorities to find another way to host them. It was a significantly disruptive PITA.

Example 7: In the interests of fairness, this is more specific to the DHP we were using at the time. Nonetheless, it still serves as an issue you might run into. The DHP offered a staging site which is just a copy of the live site at a different URL for testing and development purposes. A long time ago, a developer set up the staging site with a custom URL. It worked fine for a few years UNTIL….one day it didn’t. It abruptly stopped working. The live site was fine, it was just the staging site we couldn’t access. From there it was back-and-forth tech support hell until they casually mentioned their staging service didn’t support custom URL’s. WHAT? If that was the case, they could have SAID SOMETHING BEFORE blindsiding us like that! They should have done an audit first and set out a warning. Instead, it required a complete re-set up of the entire site and it was a disruptive, time-consuming PITA.

Again, if your site is not eCommerce you have much less to worry about. However, if you’re selling things just know as your business grown you’ll probably outgrow a DHP sooner than later. For eCommerce, do yourself a favor and go with a traditional host.


Posted in Uncategorized