What is the difference between cloud and virtualisation? Possibly the longest jargon buster question to the shortest possible seed question will now follow.
Many people with decisions to make about buying into a cloud service are hesitant not because they want to fully digest every last nuance of every buzzword, but because they are astute judges of human nature, and can pick up a whiff of insincerity, a snippet of glib buzzword-ism from the moment the management proposal or sales pitch gets rolling.
It wasn’t possible to do cloud before the gurus had cracked the whole virtualisation thing, not just packing several servers into one box, but allowing those servers to float about between boxes - even mid-run - with minimal human intervention. If you want your giant web farm to scale out, to add clones of heavily loaded servers to keep the users happy, then the argument goes that you can’t do this without virtualisation.
Sadly, this assertion manages to be both correct, and useless. User (read: buyer, director, decision maker) experience of cloud has been overwhelmingly set by the big public web services, which as an idea long pre-date the widespread adoption of virtualisation. Hotmail was around roughly a year before Google started (1996 vs 1997) and like it or not, most CEOs take their sense-checking and benchmarks for cloud credibility from services like these, which manifestly got along fine without any form of virtualisation at all.
The reason they used to do without is that the loads they were working with were reasonably smooth and predictable. The amount of compute time needed to satisfy a web search or show you an inane, short email is incredibly small, and was small even by mid-90’s standards, when Sergei and Larry at Google were making their early server cases out of Lego.
This makes for thousands of users per server, and happy systems design people, who can make decisions about server counts and specifications on a reasonably relaxed schedule. This is the world of the Software-as-a-Service cloud, where users interact with a slickly designed, bandwidth efficient, up to date, secure and easily modified web page (average containing file count, say anything from 10 to 200 files. Here the unit of scale-up or scale-down is a tiny little web transaction. That’s hugely different from some planet-sized brain (human, or machine) deciding that you need another entire Windows server (average containing file count: 250,000 according to me!) to start up as a new virtual machine.
That’s Infrastructure-as-a-Service. And, yes, I curse the day that someone decided to gather together such distinct and incomparable technical platforms under the same buzzwordy banner. I believe that a rather wider-cast selection of jargon terms would go a long way to helping with the “Google incredulity problem” cropping up in those sales pitch meetings.
But I am not yet done with Virtualisation. While there are a lot of noises made about semi-automated load management in IaaS deployments (ouch! sorry...) and all of this is done with smart management tools that cost a respectable chunk of the implementer’s IT budget, I am far from convinced that the entire topic of elastic demand is actually representative of most businesses’ cloud requirements.
This counts as a heresy in many quarters. Demonstrators (of software, not with placards) love to show instant provisioning with a few clicks - ironically, using an SaaS management interface to control an IaaS resource pool, and then to show incident logging coming back to the same pane of glass, so that misbehaving or redundant VMs can be identified and given the virtual neck-pinch of death.
The reason why these features look so popular, and why much of the material you will read emphasises control, is because cloud also depends on - for a lot of its appeal - cloud providers as a moneymaker, on not just variable capacity, but variable pricing. It’s in the cloud industry’s interests to take inefficient, old-tech copies of your existing servers and host them inside central hardware, when that central hardware is charged back to you at a rate which they can vary to suit their quarterly results...
This isn’t some evil plan, though - it’s just perfectly understandable and transparent commercial behaviour. If you’re convinced that a cloud service can expand and contract on demand, then you won’t complain about the Superbowl rate day, or something like Uber’s much-noticed “burst pricing model”, because of course your Cloud investment makes you more money, even as it’s costing you more. ...Doesn’t it?
It doesn’t take much examination of Cloud-Priced virtualisation projects to realise that Cloud pricing works far more sensibly when you’re not an infrastructure type user. The closer you can get to the Google/Hotmail ethos with your data and users, the less painfully variable the cloud bill will be, assuming your business is variable to begin with.
Virtualisation has to be present somewhere in the enormous stack of hardware and software that delivers your cloud services; but it does not have to be managed by or visible to you, as the operator of that basic, simple web page shown to you by a mega provider. You don’t need to understand every delicious, elegant little tweak of the virtualiser’s art, in order to use Google. That’s the difference between cloud and virtualisation.
