Website Hosting Tech: Shared, Dedicated, Cloud – What to Choose and Why?

      No Comments on Website Hosting Tech: Shared, Dedicated, Cloud – What to Choose and Why?

If your head is spinning from the deluge of tech product announcements that make you feel like you’re always trying to catch up, no matter how close you stick to technology developments – breathe deeply, you’re not alone. Here are a few pointers to frame how to think about the costs and benefits of various types of web hosting.

In short, there is no silver bullet, and like most things it’s all about cost-benefit trade-offs. Yes, “the cloud” is becoming better and new solutions seem to crop up like mushrooms after rain, but you can spend days researching vendors that in the end, are pretty close to each other and won’t impact much how your business is doing. To remain sane, ask yourself these key questions:

  • How technical is your team? How much handholding do you need to set up, upgrade, and troubleshoot your web infrastruture?
  • Do you have big bursts of increased traffic or steady needs? How much will you need to grow?
  • How much control do you need over the finer grained aspects of your tech platform?
  • How married are you to your current technical choices (OS, web server, database, framework/CMS)?

This is what you need to worry about, rather than chasing the latest fad which is already proclaimed obsolete by the time you get to it. At the other end of the spectrum, if you settle for traditional mass market shared hosting and refuse to acquire any tech skills internally, know that you’ll overpay for an inferior product, because that’s what happens to uneducated customers.

Table of Contents show

1. Hosting Categories Pros and Cons

In a nutshell, as seen from the perspective of a small business that nonetheless expects to do more online than deliver brochureware:

  • Shared hosting should be reserved for smaller and simpler websites. Beyond a few tens of visits per month, you probably want to get a VPS so that your site is not insanely slow from running on an oversold server running who knows what else. That said, I recently moved to shared hosting (more on that below) and was pleasantly surprised by the experience. Make sure they use SSDs and check the host’s reputation in online forums.

    For the love of god, separate your registrar from your DNS from your email from your web hosting. Putting all your eggs in the same GoDaddy basket is simply not giving you enough control over your core online infrastructure.

  • VPS or PaaS can help scale things up and down quickly, but they’re not necessarily as affordable as many people seem to think, nor is the cloud magic. Things can break down or at least get complicated in unexpected ways, and offerings keep changing. VPS are relatively straightforward but you need to read a lot of fine print and keep up with cloud vendors. That said VPS offer good bang for the buck and they’re well worth investigating, especially if you have some basic technical understanding. Docker can be a good combo with this infrastructure choice.
  • If your traffic is a relatively known and stable quantity, dedicated hosting with a decent host and a good sysadmin is the way to go provided you negotiate your leases well, renew your hardware (get SSDs and plenty of RAM), or even buy your servers rather than lease them.
  • I’m not a fan of platform-specific hosts (commonly dedicated to PHP or even more narrowly WordPress) because they feel stifling and mostly look like slick marketing pitches to decision makers who have little tech culture. Which is fine, but I like to have control under the hood beyond what your typical WordPress host will allow, and I’m not committed forever to any single tech. What if you want to mix and match Node.js with PHP? Hosting choices should not structure what’s in someone’s software stack.
  • I also resent plans whose pricing scales with the number of website visitors much more steeply than the underlying costs. You shouldn’t have to give the plumber a cut of your revenue. Be wary of teaser intro plans that turn into hundreds of dollars per month just because you happen to have non-trivial web traffic. You’ll often see this type of pricing structure in the platform-specific hosts that target non-technical business owners or managers.

2. Cloud Sound Check: Using Red Hat’s OpenShift

I experimented with Amazon EC2 + Bitnami in early 2012. It worked, but took a bit more work than I’d have liked, and it seemed you really couldn’t do much while staying within the EC2 free tier. Since then the market has continued to evolve, in 2014 I started using OpenShift’s free service to quickly stage tests or host side projects and experiments. If any of these sites get significant traffic, I can always move to Bronze pricing for about $15/mo. Aside from storage and scaling limitations, the free plan’s drawback is the lack of support of SSL certificates for custom domains. IMO they should support Letsencrypt in the free plan.

Here are some notes on how to run WordPress on OpenShift:

After giving it a try, I ran into the obligatory newbie snags (it’s ok to stumble!):

  1. You’ll want (see why next) to install the OpenShift Client Tools (rch), which in my case bumped into this error: “Unable to pull data from ‘https://rubygems.org/“. This was solved by switching gem sourcing to http.
  2. Install one of the older, recommended Ruby versions, because with 2.3.0 rhc setup doesn’t work. Make sure to select “Add Ruby executables to your PATH” during installation. I found that 2.0.0-p647x64 worked for me with Windows 10.
  3. RCH is necessary to fully set up a domain name alias (that’s not mentioned in the Tut Tut tutorials linked above). Creating a CNAME entry alone led to a weird redirect to https://www.example.com/app even though I just had set up CNAME to point http://www.example.com to my OpenShift app.

Once I took care of these two things I had one of my domain names pointing to the front-end of an OpenShift WP app I had just installed. Sweet.

The other hurdle for people used to traditional hosting is the use of private/public keys instead of passwords to authenticate sftp of ssh sessions. Here’s what you need to know:

  • Set up SSH keys (when you install RCH) then, if like me you’re a Windows user, follow the instructions from that link to convert your id_rsa key into a .ppk file using Puttygen. The login instructions at the bottom apply not just to Putty but also to WinSCP. Lately I’ve replaced Putty with MobaXterm, which has its own SSH key generator.
  • If you’re using FileZilla, here’s the how to.
  • The Openshift path for WordPress uploads is detailed in the Tuts+ tutorial I mentioned earlier.

When you’ve done all that you can pretty much manage your WordPress install as you would with regular hosting with a control panel + ssh. I haven’t used Git integration yet but that looks relatively straightforward.

To SSH into your Openshift app from Windows, assuming you installed Git for Windows:

rhc ssh –ssh C:\PROGRA~1\Git\usr\bin\ssh.exe -a <appname>

A word of caution: MySQL’s InnoDB engine uses a file named ibdata1 that only keeps growing over time, and after two years it had consumed most of my 1GB quota. If your OpenShift account is at 100% quota, your application will crash and you won’t even be able to restart it. I learned the hard way! I had to create a new app within Openshift and recreate by blog from scratch there. I’m diligent running UpdraftPlus backups to Google Drive so at least I didn’t lose any data.

October 2017 update: Openshift effectively discontinued their free plans, and I always found it cumbersome to administrate, so I moved my blog to SiteGround shared hosting, and I was really impressed with how well they handled migrations for me. I used this move as an opportunity to switch to https, a very smooth customer support experience, especially at these prices (I chose the GrowBig plan). When you don’t want to mess with low level settings, there’s something to be said for managed hosting.

3. Docker Hosting

I have so far only used Docker for local development, but may use it in production at some point. For now I’m collecting links and research here.

3.1. Docker Registry/Repository Hosting

Where to source public images and/or build and store private ones. See Docker registry.

3.2. Orchestration and management

Optional layer to manage the link between images and deployed containers. You need this only past a certain scale in terms of Docker containers and infrastructure nodes, otherwise its unnecessary complexity and overhead.

3.3. Physical Infrastructure/Hosting

Where to run your actual live containers. Some of these options blur the line with the previous category by providing tools to ease the build/deploy workflow.

4. See Also

Leave a Reply

Your email address will not be published. Required fields are marked *