Not long ago, Taneja Group and InfoStor jointly ran a survey asking IT managers about their experiences and plans in using public clouds to protect data and host applications. We specified public clouds because of their huge capacity and wide availability at low cost. Taneja Group surveyed 150 IT respondents representing companies with revenues from a low of less than $1 million to greater than $1 billion. The $50 to $100 million segment yielded the most respondents, but all revenue segments were fairly evenly divided. A slight majority of respondents were from the private sector. The rest came from government, education and non-profit entities.

Plans For Data Protection In The Cloud

Only 29 percent of respondents were already protecting data in the cloud, leaving 71 percent that were not –- a distressing picture for cloud vendors. However, 58 percent were planning on moving some data protection to the cloud between 6 months and 2 years; while 24 percent had no plans to do so.

Figure 1: Public Cloud Usage

Those that have or were planning to have data in the cloud varied in their reasons: 59 percent of respondents reported that potential CAPEX savings were important to them, and they would move to the cloud if it would help eliminate secondary DR sites and redundant DR backup storage systems. That same percentage also found cloud storage scalability to be attractive. This is no surprise: On-premise storage scalability is a real issue involving budgetary costs, data migration, provisioning, downtime, data center space considerations and energy costs. IT respondents felt that gaining scalability with cloud-based backup was an attractive proposition for both CAPEX and OPEX savings over in-house storage growth. Simplifying backup management gained a 52 percent response.

Cloud Storage Concerns

These responses all point to the attractiveness of a cloud-based storage solution for cost and IT resource savings. However, if cloud-based storage is so attractive, why aren’t more IT administrators storing to the cloud?

The answer to that question was startling with its solid list of objections and concerns. Cloud vendors are going to have to do a better job of answering these objections in the coming months and years to spur more midsize and enterprise adoptions.

Value Percent
Security concerns 55%
Data availability concerns 45%
Data accessibility concerns 45%
Internal IT policies 56%
Regulatory compliance issues (PCI, HIPAA, SOX, etc.) 47%
Inability to meet RTOs (Recovery Time Objectives) 49%
Cost concerns (e.g. data transfer or storage costs) 43%
Fear of service provider or vendor lock-in 47%

The startling variety of these objections should give cloud vendors pause. Granted, they represent an opportunity, but so many of the marketing pieces we see and hear simply do not address any of these concerns. They are the sizzle and not the steak. But IT professionals are not starry-eyed personal consumers; they are charged with valuable data protection, and they are wary. They should be. How should the public cloud vendors answer an IT administrator’s very real concerns about data availability and accessibility? Or figure out a way to meet compliance or eDiscovery needs, or avoid cloud vendor lock-in? This is where the rubber hits the road. Most sales teams worth their salt know how to answer these concerns with individual clients, but we are not seeing nearly the level of customer education that we would like to see. The result is widespread reluctance to move data to the cloud.

For example, the vendor lock-in objection is a real concern. Moving data between cloud storage service providers is not easily done, and it is in the vendors’ interest to keep it that way. Unfortunately, the difficulty has a long-term effect on making customers leery of moving data into the cloud at all when it is terrifically hard to move out of it again. They must face the expense of mass data migration twice -– once when moving to a cloud provider to begin with, and then when moving to another one. The vendors know that inertia and a reluctance to pay for the second migration is a strong motivator for customers to keep their data with one service provider, but many customers are reluctant to move their data to the cloud in the first place because of these considerations. We don’t blame cloud vendors for hanging on to their customers, but they should at least offer data migration tools or services to facilitate mass data transfers as necessary.

Additional objections ran neck and neck with vendor lock-in. Data accessibility and availability must be defined. That data will generally be accessible and available is a given with large public cloud providers like Amazon and Google, who aren’t going anywhere. (Note that data availability may be a big concern with smaller service provider firms. Some of these smaller firms offer better service level agreements than the big public clouds do, but the customer must be certain that the service provider is in it for the long, long haul.) The question for entrenched cloud providers is how soon data will be accessible and available if given an urgent requirement, and how long it will take to retrieve that data. Answers involve the amount and type of data the customer has stored on the public cloud, and what (if any) migration tools exist to quickly retrieve the data.

Customers must know this going in. They must write service level agreements for prompt data transfer from their cloud vendors, and include both digital data transfer objectives and physical media. It’s pretty ridiculous that cloud vendors must ship data on tape or disk to a customer, but the reality of bandwidth is that the old-fashioned truck can be much faster than the information highway. We urge customers to write the data transfer objectives into their SLA requests. Public clouds that cater to the corporate market will be open and ready for meaningful SLAs, but if the cloud vendor balks, understand why and what you will be giving up if you accede to its demands.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *