I came across an article in InfoWorld about a survey that TheInfoPro conducted among Fortune 1000 firms regarding their use of public cloud storage offerings. The bottom line: they haven't, they aren't, and they won't. Eighty-seven percent of respondents stated they have no plans to use public storage-as-a-service, while only 10% say that they will. Clearly, the survey indicates this market segment has no use for cloud storage.
But then I thought about the Cedexis survey I wrote about a few weeks ago. Cedexis evaluated a number of enterprise applications and found that, far from avoiding use of cloud computing, 35% of those applications touched the eastern region of Amazon Web Services sometime during their operation. Speculation at the presentation was that many of these applications included external services that accessed storage located in Amazon's S3 service.
How can one comprehend such different outcomes in these surveys of a fairly similar user base? Of course, there are the obvious reasons:
1. Maybe they aren't that similar. While they both describe their survey sample as enterprise, they might define enterprise differently and therefore get different results.
2. Maybe they have skewed samples. The two companies that performed the surveys might survey companies that they, for one reason or another, are more comfortable with or know better. Skewed samples lead to inaccurate results, as notoriously demonstrated in the Literary Digest polling fiasco of 1936.
3. Maybe they talked to different types of people. TheInfoPro may have talked to infrastructure or storage managers, who have no plans to use cloud storage. Cedexis, on the other hand, focused on applications (indeed, it was not clear from the presentation I saw that they talked to anyone, but rather traced execution paths of actual applications). In other words, the sample sets represented two entirely different roles, and the results reflected cloud storage use by that type of role.
I think it is this latter explanation that approaches the truth, and it reminds me a lot of discussions about open source within enterprises over the past decade.
Open source software was the cause of many embarrassed conversations with senior IT management. During a discussion about the benefits of open source, a CIO or senior IT executive would emphatically state: We have a policy against using open source software. There's no open source software in any of our systems.
Of course, if one then wandered the cubicles, one found that technical personnel readily admitted that they were using open source software components left and right. Reasons cited for this included:
• Ease of acquisition. Open source components were easily downloaded, with no need to experience overly aggressive sales people or confront uncooperative procurement personnel. Need a component? Do a search, hit the download link, and ten minutes later you're moving forward with your engineering task.
• Better functionality. Open source software often seemed more fully featured and higher quality than the packaged alternatives. And, in any case, getting access to the latest version did not require a lengthy negotiation for an upgrade license.
• Low cost. Many times I heard developers explain that they had been forced to turn to open source because strict project timelines has been forced upon them with inadequate funding for software procurement for components necessary for application development. Open source enabled project teams to get the job done with much lower costs and nobody higher up ever knew how such cost-effective projects were possible.
The net result of this disconnect was that many IT executives were unaware of the actual on-the-shopfloor practices of their own organization. A famous example: Jonathan Schwartz, erstwhile CEO of Sun, recounted in his blog an interaction with a CIO who maintained that no MySQL was used anywhere in her organization; the Sun sales rep then pointed out that 1300 copies had been downloaded by people with e-mail addresses from the company's domain.