I got into this business for the software – I still like to write and direct software, but it has personally taken 4-5 years to start making progress on the software plans that I was really interested in. That’s because when Bytemark became profitable from our early efforts, the customer service really started to eat into the time I wanted to do development. But I realised that if we wanted to make a success of a hosting business, we had to commit to supporting our customers first, and developing new products second.
So for years we carried on answering difficult customer questions and maybe getting one day a week of difficult development done. But it paid off – we carried on rolling up new customers into a big ball, and made the smaller development time count. It’s taken years to be profitable enough to employ people to increase that development time, but now I’m able to look at what our next products will be.
It’s probably not a surprise that I’m focussing again on our virtual machines, and where to take them next, so it was a minor distraction to find that in the last few years, virtual machines seem to have acquired a new name: they’re not machines, they’re The Cloud (cue angelic chorus, ah-ahhhhhhh sound). The Cloud is “computing on demand”. You only pay for the resources that you use, and cut your costs in the process. You can choose your own Cloud Computing provider and skip between them, hosting becomes completely interchangeable. Add resources on demand, drop them on demand, pay by the hour. And there are lots of people selling you this already. Hooray for the future! It’s here! Not at all like 1960s mainframes! I like the plan, but think the dream is further away than it looks, and that most of the work hasn’t been done yet.
Taking a shot at the cloud
Why’s that? Well firstly, an uncertainty with any hosting product is that the vendor tends to have no idea how fast their products will go; the typical answer is “fast enough for most things, sir” in the hope that the customer trusts them. On the other side, application developers also have no interest in benchmarking and are willing to accept the “fast enough” answer. Rarely, a developer will ask, “well how can I really measure what I’ll need?”. I don’t always have a great answer, but I tend to point them at siege, a simple benchmark tool. It hammers their application in the same way that lots of visitors do, which allows the developer to set sensible limits for the number of visitors that the site will handle on particular hardware. Sometimes they’ll even use it.
This kind of wooliness is tolerable when you’re more than likely paying for some headroom in your hosting, but that’s not The Cloud! In The Cloud, you pay for *exactly* what you need, when you need it, because you’re saving money. Do you see developers coming up with benchmarks for their hosting providers? Do you see hosting providers advertising benchmarks to potential customers? No, nor do I. It’s still “faster than you’ll need” from the hosts, and “not sure about demand” from the customers. Actual decisions are made on reputation of the hosts and comparisons of the type “Joe is paying $100 for hosting X, and your application won’t do half that”. You wouldn’t tolerate that from an electricity supplier, but it’s still OK with hosting because most people don’t (yet) pay for it by the hour.
When it comes to virtual machines, there is tons of competition in the $10-30 per month category, and almost all of the products are “good enough for most things”. Lots of static sites, a single moderate use database application, thousands of mailboxes, life is pretty good for customers at that end of the market. Cloudy offerings compete pretty well at that end, but aren’t really any different, other than the promise of “scaling well” if the time comes.
Up through the atmosphere
The problem with The Cloud based on a few current offerings, is that the moderate-spec hosting becomes expensive, and the high-spec hosting is eye-watering. Take the example of one of our customers, a popular forum which gets regular mentions on morning television and has hundreds of people logged on and posting messages at a time. Right now the web node runs comfortably on a 4-core AMD Phenom 9550 processor with 8GB RAM and mirrored discs. Here’s how much it would cost to commit to those resources based on a price-comparison at various “cloud” providers, from cheapest to most expensive, per month:
- Plain old dedicated server with 200GB / month allowance £120
- Amazon EC2 (high spec server, 7.5GB, one core, excluding transfer fees) $288
- Flexiscale (assuming 50GB storage and 100GB / month transfer) £601.70
- Joyent Accelerator (two cores) $1000
I’ve picked on three companies who offer smooth “cloud” scalability promises, but I’m sure you can find others, and just looked at their advertised prices.
That’s not a “fair” comparison because the customer won’t be using all the cores and all the RAM all the time. Surely the Cloud providers should win by allowing the customer to dial up and down according to demand? The question is: who turns the web site power up to 11 when it gets mentioned on GMTV? Not the customer; they might be lucky enough to know when their spikes will occur, but not how far to turn the dial to be *sure* their web site stays up. Not the hosting provider, after all they’re just an on-demand utility. Even if they did, would you trust them to only give you what you need, and not simply make the most profit from a spike? And the customer’s application (along with 99.9% of other packaged web applications) is a PHP program that doesn’t know how or when to order a new server. So the typical hosting customer is on their own with managing demand for their “on demand” service, and will simply err on the side of paying for more than they need. If you’re doing that and need this amount of power, you may as well pay for a dedicated server.
To get those prices in perspective, the processor, board and RAM for this server cost £200 retail, and might draw £20-50 per month in running costs. Our £120/month price for a dedicated server is driven by the obvious concerns: the cost of rack space rental, power draw for the server, spare parts, support staff and the fact that about a zillion other companies are doing the same thing. I’m not that I’m claiming ours is the lowest price in the world, just that it’s cheaper than any Cloud computing provider is currently willing to offer, even Amazon as the oldest and best-established.
The last piece
What’s missing from the jigsaw is competent open-source applications with “cloud support” baked right in, applications that can say to their hosting platform “I’m struggling to fulfil demand on this host, order another server, and start serving customers on that too”. San Francisco start-up types are adding this simple trick to their next-big-thing application, to make sure it stays up, and it really will save them up-front investment. Of course it will be at the cost of some programming wizardry, and they’ll still pay through the nose if their site takes off, see above. But compared to most of our hosting customers, mostly time-pressured developers and entrepreneurs who have something other you do than work on infrastructure, you do need to be a wizard to implement that kind of early economy for your own project. And it would be a Herculean effort to write a “cloud-aware” application that anybody could deploy, even more so if you wanted compatibility across more than one Cloud provider. The standards just aren’t there yet, so typically your cloud-aware application can only run on one Cloud. And if you want to test it outside of the single commercial Cloud you’ve written your for, you’re out of luck – none of the providers have made their provisioning software public.
The Cloud will need much more than the hardware and APIs to create reliable virtual machines; it’s about a programming framework too which has barely got started, and one which needs to be agreed among fast-moving competitors. While programmers are still writing applications where “throw a bigger server at it” is the only supported answer for scaling, The Cloud will still require expensive wizards to fulfil its economic promise. Whether those wizards sell you the application in the first place, or promise to adapt your application to The Cloud, or run a Cloud on which you host your stuff, you will be dependent on them for your application to run. And while you still need a wizard involved, it’s just not for everybody.
The older, unfashionable alternative remains the cheap one for now. If you think your application will scale, and are able to think ahead more than about two days at a time, call your hosting provider, tell them about your application, and ask them about a traditional scaling strategy with real or virtual boxes – for a few more years at least, real people thinking ahead and doing the provisioning can still beat The Cloud on economy.
Back to putting my development head back in the, umm, where it was.