Educase '09: Cloud computing
There have been a couple of presentations on cloud computing so far; one on the in-principle pros and cons, and one on the nuts and bolts of an actual on-premise private cloud implementation. My thoughts:-
- It seems fairly clear that 99% of people talking about cloud computing are actually talking about software as a service – Google hosting your email, or an out-sourced helpdesk or whatever. I’ve spoken to only a couple of people who are doing anything with genuine cloud services such as Amazon’s EC2 or S3.
- People pointing up the risks of apps and data held off-premise seem to have a rose-tinted going on fictional view of life with on-premise services. Of course it’s true that your SaaS arrangement could have privacy issues, availability and SLA challenges, vendor lock-in, contract risks, and lack of control over the evolution of the service. But the unspoken argument against off-premise SaaS seems to be that these issues don’t exist, or exist only trivially, if you stay on-premise. But most universities who run Microsoft Exchange on site, for example, freely admit that they have outages, data losses and meaningless SLAs. And they are just as locked in to a vendor as if they asked Microsoft to hold the data in Dublin. And if you’re in a UK university, then if I say “Contract challenges”, I’d bet reasonable money that the word that comes into your mind first is “Oracle” – for an on-premise, supposedly bought and paid for piece of software.
- Almost everyone has anecdotal evidence of people within their institution going off-site independently of what the central IT service may or may not be doing, be it forwarding email on to a third party provider, using Google Docs to collaborate or whatever. So unless you’re an institution with unusually strong central control (either technically or at a policy level), many of your members have voted with their feet and accepted the risks (possibly unknowingly, for sure).
- An unspoken, but I think real concern, seems to be about the loss of accountability. If you run Exchange on site and it explodes, the thinking seems to be, you could fire someone. Whether you actually would or not is a different question, of course, but the principle that you can point to someone and say “this is your fault” seems to give some people a kind of warm fuzzy feeling. So if the university’s senior management agrees to go off-premise, the argument seems to run, who could they then blame if things went wrong later? Kind of a sad world-view to be planning your blame strategy in advance, I think, but there seems to be some of that floating around.