Cloud hosting and CDNs
by Chris Woodford. Last updated: August 13, 2016.
Cloud this, cloud that—it seems the world of computing has suddenly become very overcast! If you've read our general cloud computing introduction, you'll know that there are lots of different ways you can take advantage of Internet-based computing. If you run your own website, there are two very specific forms of cloud computing you might want to investigate: cloud servers and content delivery networks (CDNs). What are they, how do they work, and how do they compare with existing shared and managed web hosting? What benefits do they bring—and what are the drawbacks?
Photo: Cloud computing questionmarks: Moving your hosting to the "cloud" has advantages but it can bring security and management problems too.
What is cloud hosting?
If you're a webmaster, two kinds of cloud hosting will be of interest to you: cloud servers (which do the same job as a managed or shared server, but in a more dynamic and scalable way) and CDNs (content delivery networks, which distribute "static" files, such as images and CSS, at multiple locations around the world so they load faster for a worldwide audience). Let's take a look at them both, in turn.
Traditionally, web hosting came in two flavors: high-cost managed hosting, in which you have your own private server (an actual computer!) dedicated to running only your website and its applications, and low-cost shared hosting, where your site and apps run on a large server with a number of other sites run by other people. Now there's a third option, widely marketed as cloud hosting in which your site runs on a virtual server somewhere up in the cloud; depending on how it's set up, a cloud server might be an actual computer, but it's just as likely to be a chunk of a much bigger machine—as with other kinds of cloud computing, the point is that it shouldn't matter either way to you as an end user. Rackspace's Cloud Servers, Liquid Web's Storm on Demand, and Amazon's Elastic Compute Cloud (EC2) are three examples of this kind of cloud hosting—and there are many more.
An example cloud server
So what's a cloud server like in practice? It's relatively easy to sign up to cloud services and see for yourself. With Storm on Demand, one of the cloud services I've used, you simply create a billing account and then tick the kind of server you want from a list of common examples (running from 1GB memory and 1CPU up to 96GB memory and 32 CPUs). Then you tick the "server image" (essentially the software you want on the server at startup, including the operating system) and specify whether you want a managed server (where the Storm guys sort out operating system patches and so on) or a self-managed server (where you do these things yourself). Finally, you specify whether you want backups of your data and how you'll pay for bandwidth (either in large, specified blocks of GB or per GB used). When that's all done, you click to create the server and it's all "built" for you, on the fly, in a matter of minutes.
Once the server's created, you can configure it in the usual way (just like a physical server) with software like WHM and cPanel—or however you wish. If you decide you no longer want your server you can destroy it just as easily, and you simply pay for what you've used (an hourly rate for the server and a per GB rate for the bandwidth). It's extremely easy to use. Even with only previous experience of shared hosting and no experience at all of setting up standalone servers, I had this website up and running on a Storm cloud server in a couple of hours.
The brilliant thing about a cloud server like Storm on Demand is that you can scale it up or down at any time simply by revisiting the control panel and changing what you need to. Suddenly find you need more CPUs or more memory? No problem! Just tick the boxes and your server is automatically reconfigured and working at its new spec in a few minutes. That makes cloud servers a great choice for people who need supreme flexibility or whose computing needs are steadily changing. For example, if you're a fashion store, and you have a time of peak demand coming up—an end-of-season sale, perhaps—you could double or triple the power of your machine for a week or two before scaling back down again when traffic returns to normal. You can increase the power of your server at the click of a mouse but, because you're billed on a pay-as-you-go basis, you'll only pay for the more powerful "machine" for the period when you actually use it. Compare that to dedicated hosting: to get the same results, you'd need to anticipate every increase in server power you might need, invest in a more powerful machine in advance, allow time to get it set up and tested, and keep that powerful new machine running (at considerably greater cost) even if your traffic returns to lower levels again in future.
What are the drawbacks? If you run a small-scale website that has very steady or totally predictable traffic, you might find a cloud server is too expensive and demanding. If you don't need the flexibility, you're not worried about sharing a server with other people's websites, and you don't want to waste time monitoring the performance of your server, shared hosting will probably be a better solution for you than cloud hosting. The important thing to remember is that "cloud server" is essentially a marketing term and not a technical description or explanation; well-managed, traditional shared hosting can give you many of the benefits of cloud hosting, though without the flexibility or independence.
Photos: Liquid Web's Storm on Demand allows you to set up a cloud server in a matter of minutes, simply by ticking a few boxes. Every aspect of the service is pay-as-you-go. It's easy to use even if you have little or no experience of setting up or managing dedicated servers.
Cloud servers or virtual servers?
How do cloud servers work? Hosting products described as "cloud servers" are generally virtual slices of large, physical servers running what's called virtualization software (the most common types being VMware® and Xen® hypervisor for Linux and Microsoft® Hyper-V™ for Windows). In other words, they are effectively "virtual servers" (entirely independent virtual machines) running on a real, physical server. How is that different from shared hosting? The virtual servers are essentially independent of one another (though they do use the same processors and memory), so you're not at risk from other people's applications or websites. You have full root access to your virtual server (unlike on shared hosting, where different users' files are simply subdirectories of a single server running a single operating system) and your own unique IP address (so, unlike with shared hosting, there is no risk to your site if other people host "dodgy" websites on the same machine), and you can reboot or reimage, as you wish—you can even run entirely different operating systems on the same physical server. From the viewpoint of the hosting company, the main benefit of using virtualization is reducing the number of physical servers they have to buy and manage: it's a much more efficient use of resources. However, that doesn't necessarily translate into the cost savings you might expect because support costs may be higher and you may still need multiple software licenses for each virtual server.
Cloud-based content delivery networks (CDNs)
Your website can benefit hugely from cloud computing even if you don't want to migrate it to a cloud server. Information-rich sites like this one, with a lot of static content, typically use over 90 percent of their bandwidth serving up images (and other media) and CSS files that probably don't change from one month to the next. With traffic split equally between Europe, America, and Asia, there's no easy way to decide where to locate your main server: wherever you choose, some users will benefit and others will lose out. But putting the static content on a content delivery network (CDN), dispersed across the cloud, will benefit everyone. Simply speaking, a CDN makes multiple copies of your static files and stores them at many different places around the world (called edge locations) so that different users in different continents receive whichever files are nearest (and therefore quickest to download).
How do you set up a CDN in practice?
Suppose you want to speed up your website by moving all your images on to a CDN. You can sign up for a pay-as-go CDN in a matter of minutes (Amazon's Cloudfront and Rackspace Cloud Files are two popular, instant options, but there are plenty of others). Once you've sorted out the billing, you simply upload your files (in a similar way to using FTP) and you'll be allocated a web address (such as abcdefg123456789.cloudservice.whatever) that you can use to link to them. You can either use this address explicitly (referring to it directly in your IMG tags) or (more sensibly) refer to it through a CNAME (effectively a DNS alias) based on your own domain name. When people download your web pages, the images are no longer pulled from your main server but from one of the edge locations around the world—ideally one that's geographically close to where they happen to be.
How does it work behind the scenes? It's easy to see if you do a DNS lookup for whatever domain name you're using for your CDN. Instead of a single IP address, you'll find the name resolves to different IP addresses in different parts of the world. In other words, the files resolve to a different IP address depending on where the end user happens to be. So for a person on the West Coast of the United States, abcdefg123456789.cloudservice.whatever might resolve to a server in Mountain View, California, while for a user in Europe, the same domain might resolve to a server physically located in Paris, France or London, England.
Pros and cons? There is almost always a significant performance boost from moving to a CDN, but if you're paying a fixed-price for your web hosting (or server) bandwidth, using a CDN is going to work out as an extra cost. CDNs rely on your files being copied, periodically, from the central server where you upload them to the edge locations around the world where they're served to users and typically cached for anything from a few days to several weeks or more (you can generally specify the cache expiry time)—so file management and updating can sometimes be a problem. For example, suppose you set a 30-day cache on your main CSS file but suddenly want to change the way some aspect of your site is presented. You can either upload a new CSS file and wait up to 30 days for all the edge locations to reflect the change or rename your CSS file (and all the pages that reference it), then upload a completely new version of your entire website. Either way, you lose a certain amount of flexibility in file management and it's important to remember that different users in different locations may see different versions of the same file for a period of time. That's why CDNs work best for static (rarely changing) content.
Worth a go?
One of the best things about cloud services is that they're generally pay-as-you-go—so it's very easy to try them out, at relatively little cost, and see what difference they make.