Desperate times call for desperate measures; and if you are one of the handful of companies that suffered serious downtime following the problems at (insert IaaS provider here) you know what’s meant by desperation.
Whether its storage or the very infrastructure that forms the backbone of the services, outages—some of which have been extended—have been garnering more press than the cloud services companies themselves these days.
So what is the solution for this problem of perception? And what aren’t SLAs offering that provide cloud customers with the sense of comfort needed to make the move?
Dr. Alexander Pasik, CIO for the IEEE recently caused waves with his suggestion that enterprises considering cloud computing might be more inclined to implement it if they felt their investments and data were protected under an insurance policy. This stands as a supplement to the SLAs offered by nearly all IaaS companies.
Pasik reminds us that SLAs are guarantee agreement for service quality-related issues but they will not address security breaches. He says that a provider will be very unlikely to cover security lapses. His solution is as summed up as follows:
“Suppose you have [your own corporate] data center that’s running at three nines [reliability]. You feel that you have to consider whether you want to put in the investment to take it to four nines. That is an investment question. How much additional revenue do you think you’re going to get from taking it to four nines? An insurance paradigm would enable multiple players in cloud services to come in and say, we have implemented x, y and z standards for security, while another one might say, we’ve only implemented x and y, but if you get hacked we’re going to pay you for every record that’s been exposed because we have insurance.”
When asked who would be providing this new form of insurance, Pasik said that traditional insurance companies would be suitable providers, as would startups with that had the background and willingness to tackle the cloud computing security space.