Did you hear the one about the Cloud?
Did you hear the one about the Cloud being like the electricity grid?
It goes like this. IT vendors build large datacentres that let them share computational facilities across multiple customers. Customers then plug into the datacentres via the Internet, drawing off as much computational power as they need, when they need it. Just like electrical power.
Everyone wins. Vendors get an ongoing revenue stream. Economies of scale mean that customers get higher levels of reliability and flexibility than they could afford to build into private datacentres. This is great news for organisations that have highly variable demand, e.g. when running seasonal campaigns, or any online campaign with unpredictable take-up. You can push all the complexities of capacity management out to the computational cloud.
But here’s the punchline. It’s the electricity grid of the 19th century that we’re talking about here. Some cloud vendors are running AC and some are running DC. Some are on 50 Hz and some are on 60 Hz. Everyone is running a different voltage. And the overall cost depends on what you plug into it: it can cost more to run a dozen lightbulbs than a toaster, even though you’re drawing exactly the same amount of power either way. This is the electricity grid before we converged on a common set of standards.
What does this mean for people who are thinking of using the cloud?
For a start, it’s going to be very difficult to compare different vendors. They’re all offering something different. You’re going to need to do a lot of work to find a common basis to compare their service levels and pricing.
It’s also going to be difficult to predict your ongoing costs with any level of certainty. Even if you have a reasonably well-defined set of demand projections, you need to include a wide range of different cost factors in order to account for the different pricing models. And these pricing models are probably going to change as vendors jostle for position.
And, once you commit to a vendor, there’s a strong risk that you’ll get locked in to their way of doing things. It’s not necessarily that difficult technically to move your applications and data between different vendors, but all the surrounding stuff – the operating and support models, the pricing structures, etc – adds dramatically to the pain. Switching vendors is going to turn into a substantial project in its own right. Not at all like switching electricity suppliers.
Finally, there’s the risk that you’ll get blindsided when standards do emerge. If you’ve chosen a vendor who’s backed the wrong horse, than you risk being stranded off the mainstream.
The good news about the cloud is that the technology works. Much of it is simply an evolution of stuff that we’ve been doing for decades. Virtualisation dates back to mainframes. The Internet isn’t new any more. The economic model, of renting rather than buying capacity, dates back to mainframes too. We know this model works: the potential cost savings from economies of scale aren’t illusory.
The underlying truth is that the market for cloud services is still pretty immature. A few “visionaries” have genuine cloud offerings. Many of them struggle to back their offerings with the guarantees and service levels that most organisations need. And the rest of the pack is mostly selling rebadged hosting rather than a true computational service. They still think in terms of servers and blades. You might talk to them about the amount of power that you need, but they need to turn this into a technical configuration before they can give you a quote. When did your electricity supplier last talk to you about generator design?
This will change. Standards generally take longer to emerge than we expect. Infighting around these standards is normal. The electricity grid of the 20th century grew out of that of the 19th. Manufacturers who’d thought about how to exploit it and positioned themselves for the new reality did very well out of it. But for now, you have to plan for a learning period, with all the pain and extra work that entails.