JaySmall.com/old

SI changed Web hosts recently, and you might find value in my related exploration of cloud hosting and utility pricing models.

I made the switch while inspired to learn as much as possible about these contemporary hosting options, and how a Web strategy/development business like Small Initiatives could share apparent benefits with clients.

Those benefits apply to businesses that need to start (or restart) Web efforts small, but aspire to scale rapidly and handle unpredictable bandwidth/traffic spikes along the way:

• Cloud hosting (aka cloud computing) gives skilled systems administrators the ability to fire up new virtual servers, or scale existing ones, at a moment's notice. Admins can install operating systems and software suites that fit the intended uses of each server, and control the network relationships among their servers.
• The simplest form of utility pricing puts a usage meter on all aspects of hosting, including processor cycles, bandwidth, databases and file storage. Utility pricing permits a business to pay only for what it uses. Some providers start with a minimum monthly price threshold to defray their own overhead costs. Others may bill customers for usage of components -- say, a processor -- at their full stated capacity for the minutes or hours they ran during the billing period. Costs can add up quickly that way, compared to hosts that use more precise, granular measures.

No provider I tried had perfected the balance between cloud hosting and utility pricing, but several providers offer interesting blends. In general, any combination of the two fits a wide band of possible Internet/Web deployments, but not all.

A small business needing only a few search-optimized brochure pages and e-mail accounts would do better with a $10-a-month shared hosting plan, or an outfit like MerchantCircle, which will handle SEO better than shop owners are likely to do themselves.

Large enterprises may find, as our systems administrators in my day job at Scripps tell me, that virtual servers running databases may struggle to handle big-site demand. In fact, Scripps newspaper sites have moved or will soon move to a combination of virtual Web servers and dedicated database hardware for that reason. Scripps will be "partly cloudy," you might say.

Meanwhile, SI's hosting use case falls in the sweet spot for the cloud/utility model. I run this site plus a few others for clients; maintain several instances of database content management systems; need cleanly defined development, staging and production areas; want full administrator privileges to keep sharp on LAMP technologies; need to handle growth and traffic spikes on any of these ventures; yet do not wish to pay a lot for this muffler.

I evaluated five providers -- OpenHosting, SliceHost, Amazon Web Services, Mosso and GoGrid -- with different models for both cloud hosting and utility pricing. "Evaluated" means, at least, signed up for trial offers or developer betas, then created and booted a LAMP Web/database server environment, then installed and fired up a stock Drupal content management installation. In some cases, I went further, attempting migrations of existing sites.

Of these five, OpenHosting emerged as the best fit for SI needs circa 2009. Knowing that, I migrated all our stuff and transferred domain name service from SliceHost, which had served SI well for more than a year and easily earned strong consideration as part of this exercise. To be clear: SliceHost was not bad. In fact, SliceHost was very good to SI, but OpenHosting's model fits this business slightly better.

My foremost conclusion after all this work: no bad apples. Each of the five providers offers packages that would be ideal for specific subsets of that wide band of use cases for cloud/utility hosting. Each provides a clear, practical description of its product and service lines up front, allowing developers and business owners to evaluate them before committing too many resources. All five deliver on what they promise -- even those services such as AWS components that still carry a "beta" tag. For the most part, any surprises in the evaluation were pleasant, and any failures were ... ahem ... operator error.

As such, you will find no star-ratings, or 1-to-10-scale ratings, because my 10 might legitimately be someone else's five and vice versa. Instead, these notes focus on what I found, or didn't find but wished for, from each provider.

(Anytime I write on technical matters, please understand that I am not a Web programmer, architect, systems or network administrator by training. What I know about any of those disciplines comes from hard-knocks experience building and running a gaggle of Web sites the past decade and a half. Web professionals may find parts of my evaluation naive. If you do, please write comments to straighten me out and make this post more useful.)

OpenHosting

OpenHosting's server control panel includes a near-real-time usage meter that compares resource usage to the monthly commitment threshold.

What it is: OpenHosting, based in Vienna, Va., provides virtual servers on a threshold utility pricing model, running CentOS with a large assortment of Web hosting software packages preconfigured.

OH does not offer pure cloud hosting, in the sense that a Webmaster can sign up for an account and then spin up as many new servers, with as many new software stacks, prepared to draw as much bandwidth, as she can imagine. Call it ALTMOWA ("At Least This, More When Available") hosting. Adding more virtual server instances is fairly easy, but not instantaneous and not completely self-service. Also, the CentOS bundle is the only one you can get.

Typical package: A commitment of $29.95 a month covers a threshold of 15 gb of disk space, 300 gb a month of bandwidth, 1.5 gb of memory and 60 hours of processor time. With any such service, the threshold does not correspond to a real capacity -- if site traffic bursts, the larger shared hardware and bandwidth environments can absorb it within reason. OpenHosting meters service beyond the commitment threshold in very small increments; for example, processor usage in "ticks" (thousandths of a second).

What I found: SI ran on OpenHosting a couple of years back, and some client sites remain on separate server accounts there. I moved SI away because the site at OH experienced more outages than comfort allows; however, in hindsight many of those problems stemmed from the mail server on SI's virtual machine, not from anything OpenHosting did. (Nowadays, SI and some clients use Google Apps and Gmail for business e-mail, eliminating the inefficient tedium of operating a mail server.)

CentOS is a solid underpinning for any LAMP stack, and the OpenHosting software bundle makes setup and migration relatively easy. You get full shell (Unix command line) access or can emulate almost all administrative capabilities by switching on Webmin. OpenHosting provides guidance on setting up and using Webmin securely, which helps given how much access and administrative power -- and potential risk -- Webmin puts into a browser interface.

The billing model comes closest to SI needs for a blend of fixed price threshold and granular utility pricing for overages and bursts.

So far, the SI site and client sites all run nicely, without downtime or difficulties -- though we consume only modest Web hosting resources overall, hardly a brutal test for any of these providers.

Could be better: OpenHosting seems oriented toward self-sufficient developers more than non-Web-focused commercial businesses. A reseller/affiliate/repackager model, even a fraction of Mosso's, would be nice for companies like SI that build custom Internet services on behalf of others. To set up a client with a separate OH instance, it is easier just to put the client's corporate card on the OH account and get a separate set of login credentials, rather than cash-flowing a homemade method of bundling the service.

Technical support (via e-mail) remains responsive and helpful, but what I learn from support staff often is not reflected in the company's on-site documentation or forums. The bias in this hosting model leans toward "you should already know how to do this," though in practice I have found OH staff willing to step back and explain concepts a more talented systems administrator would grasp.

OH offers only virtual hosting, so if a client site takes off in a direction where dedicated hardware becomes crucial, it must go elsewhere.

And others might wish for alternatives to a single LAMP stack distribution, as competitors offer, though the CentOS bundle meets SI needs.

SliceHost

SliceHost provides system status updates on a public-access blog.

What it is: Now a subsidiary of Texas-based Rackspace, SliceHost offers virtual servers on an ALTMOWA model similar to OpenHosting, but with key differences:

• SH gives a choice of several operating system distributions for each "slice," or server instance
• A Webmaster can add multiple slices to a single account on demand
• Threshold prices and package contents vary from OH's bundles
• Slices borrow unused resources from neighbors on the same server, but are guaranteed the specified threshold resources, at least, will be dedicated to them
• SH offers no preconfigured Web server software bundle other than what comes with each operating system distribution
• If you want an on-board administrative interface like Webmin, you must install it yourself

Typical package: $38 a month gets a slice with 512 mb RAM, 20 gb storage and 200 gb bandwidth, more of each resource if needed and available in that slice's environment. Automated backups run an extra $10 a month.

What I found: Excellent reliability. SI sites ran on a slice for more than a year, and unless I restarted it for some reason, it never went down, suffered any memory leaks or even slowed for lack of connectivity.

SH operates a tidy domain control panel that makes the unforgiving process of setting up DNS entries at least a little easier.

Like OpenHosting, SH presumes its customers know more than the average dude about running Web servers. Even so, e-mail support folks respond quickly, politely and precisely when contacted.

Could be better: As with OpenHosting, a reseller or affiliate developer program would come in handy. Now that Rackspace owns SH, some extension of Rackspace's partner program seems likely. Mosso, another Rackspace acquisition, already alludes to SliceHost as a prototype for its promised "cloud server" hosting model.

Dollar for dollar, OpenHosting appears to be the better deal as long as its stock software suits you. SH prices, though not outlandish, run higher per unit of resources.

The SH model would benefit from letting outside developers and administrators build their own disk images, then creating a repository of them like Amazon Web Services offers for its Elastic Computing servers. Then, instead of simply picking an OS distribution and version number, customers could pick from disk images with preinstalled software optimized for specific purposes, such as database serving, e-commerce or content management.

Amazon Web Services

When using Amazon Web Services, an administrator can search a library of hundreds of possible server configurations for myriad uses. Contributors even provide disk images for specific open-source content management systems, such as this list of images set to run Drupal.

What it is: Amazon Web Services, though only a few years old, represents the Web culture's granddaddy of cloud storage and cloud computing. AWS grew out of strategies at Amazon.com to gain full leverage from the company's formidable e-business infrastructure and institutional knowledge.

Components include:

• Simple Storage Service (S3), which is as the name suggests
• Elastic Compute Cloud (EC2), which is where you create and operate virtual servers, and Elastic Block Store, which gives those servers optional persistent storage
• Cloudfront, a content delivery network
• SimpleDB, a basic database server
• Simple Queue Service, essentially a messaging spooler

Typical package: AWS is the antithesis of a package -- you install or store only what you need, run it only when you need it, and delete it when you no longer need it.

EC2 pricing ranges from 10 cents an hour for a small server running Linux to $1.20 an hour for an "extra large" server running Windows. On top of that, data transfer ranges from 10 to 17 cents per gigabyte, depending on monthly thresholds. Storage pricing on S3 varies by several factors.

Best bet: Use Amazon's calculator to estimate costs for AWS components based on forecast monthly usage. None of the AWS packages have minimums or maximums -- some months, my bill from AWS ran only a few cents, when I had only a few files stored on S3.

What I found: AWS, from a systems engineering perspective, remains a marvel. Fire up servers and/or services when you need them, kill them and release that capacity back to the cloud when you don't, and pay only for what you use.

Need a dedicated server to run FFMPEG for video encoding? Fire one up. Better still, grab and install a server image someone else put together with all the software already set up.

AWS' scalability, flexibility and reliability inspire awe. No wonder so many startup companies run their whole enterprise Web infrastructure in here. All great if you know what you're doing and have time to tinker. But ...

Could be better: From a nonexpert administrator's perspective, all the components work as promised, but no one promised it would be easy.

Working with S3 for storage is harder than working with FTP or even shell commands, and that's even after new S3 client capabilities came aboard FTP software such as Cyberduck.

To run a production Web site anywhere else, one trusts that his server files and data will come back after a restart. They can with AWS, but only after you follow the recipe to tie a persistent storage volume to your server instance, and then store an image of your server there anytime you update its contents.

AWS experts and developers offer lots of recipes to build different types of environments, and that helps. For example, I followed two different recipes (WorkHabit | Sunset Lake) to bootstrap and persistently operate a Drupal installation.

I did it with some tweaks and sweat, but both methods seemed more than a little fussy. I could not imagine repeating such recipes every time I needed to implement a new client using AWS.

Every other provider makes servers persistent by default. I understand AWS' reasons for not doing so, but my use cases do not align perfectly with the AWS ideal. Similar cases probably explain the existence of companies such as WorkHabit, which attempt to wrap a more usable shell of tools and services around AWS for people who just gotta run Web stuff there but don't like the tinker-at-3-a.m. lifestyle.

Mosso

The Mosso control panel includes a complete interface to set up clients, manage their billing, and even assign them private-labeled customer support.

What it is: A business-focused take on running Web sites in the cloud, Mosso, recently acquired by Rackspace, seeks to offer the scalability benefits of cloud computing with the limited-control-panel simplicity of shared hosting.

Typical package: Cloud Sites, the primary offering, starts at $100 a month with 50 gb storage, 500 gb bandwidth and 10,000 "compute cycles" (Mosso's measure of processor usage) per month. More disk space is 50 cents a gigabyte, bandwidth 25 cents a gigabyte and compute cycles 1 cent apiece. You get 10 gb of Cloud Storage thrown in.

Within that package, customers can create unlimited sites, databases and email accounts under unlimited domains.

What I found: Mosso makes a compelling case for Web developers with many clients whose needs are mildly to moderately varied -- especially if said developers have little or no need for full-fledged systems administration access.

You can fire up a Linux/Apache Web site instance, and a new MySQL database alongside, with just a few clicks in the control panel, which looks slick and generally works well (a beta version adds more power, including a browser-based file manager, but seems sluggish).

The real brilliance lies in Mosso's control panel for setting up clients' accounts. Mosso can bill clients on your behalf for hosting, based on pricing, packages and markups that you set, and push the payments (less Mosso's share) to your business checking account. Further, Mosso technical support gets private-labeled for your clients as part of the bigger packages. They put in a ticket to report a site down, and as far as they know, they're sending it to you.

Could be better: If only root-level control of the server instances weren't hidden behind Mosso's just-pretty-good control panel. At present, Mosso does not offer its customers shell access or true administrative privileges, though a support agent told me shell accounts are likely in the future.

I also found the process of migrating a large database cumbersome. Clients can access MySQL databases only through phpMyAdmin, which is a good tool but runs up against some sharp limits dealing with large text files, such as database backup files typically used to migrate from one server to another.

More often than not, Mosso support staffers had to load the databases. They did so cheerfully, but eventually the guilt became too much.

GoGrid

GoGrid's control panel excels at letting Webmasters control the relationships between virtual Web servers, database servers, storage devices and load balancers.

What it is: Part of ServePath Dedicated Hosting, GoGrid applies a slightly different spin on the AWS instant-server-elastic-storage model, and the Mosso easy-control-panel model.

Typical package: Like AWS, GoGrid prices on usage with no minimum or maximum. It charges 19 cents per server RAM hour and 50 cents a gigabyte for outbound data transfer.

What I found: You can fire up Web or database servers at will in GoGrid's cloud, and you get a range of public and private network addresses that should be handy for connecting servers to each other. GoGrid's network control panel shows you the virtual topology and lets you strap on load balancers or extra servers quickly.

Unlike AWS, all the servers are persistent, and if you want cloud storage on top of them, you can mount a storage volume much like a network file share. Unlike Mosso, you get full root and shell access and completely control the software on each server instance, starting from a choice of operating system distributions.

GoGrid generally works as promised, and setting up new servers seemed almost too easy. I did not have a use case to try the load balancer, but GoGrid stands alone among these providers in offering an easy, inexpensive way to add it to my virtual network.

Could be better: The pricing by RAM hours adds up quickly, making GoGrid unsuitable for low end uses such as a development sandbox. Perhaps the meter ticking up the costs on the side of the control panel would motivate programmers to work faster, but it only made me jittery.

I found only sparse or unhelpful documentation on setting up servers to connect to each other via the private network addresses. Specifically, I established a Web server and database server, but never could get applications on the Web side to "see" the database server. Operator ignorance may be the culprit, but nothing in the docs at GoGrid bailed me out, and with that little meter running on the side I expected better.

Still, I bailed on GoGrid because it was too expensive, not because I couldn't get that one piece working. The technology seems solid overall.

Conclusions

First, before you ask, if a provider isn't on this list I didn't try it. That goes for MediaTemple's grid server and who-knows-what other hosts that have popped up in this space in the meantime.

In sum, if pressed, any of these solutions could work for SI and its clients. All have different bits of greatness, different quirks, different areas that still need that certain je ne sais quoi. I had more fun than frustration trying them all, and I hope my observations make your decisions a little easier.