即使云计算的安全性，可靠性和兼容性等方面受到质疑，Amazon， Google， Microsoft 和其他的厂商仍在积极地推进云计算。Serdar Yegulalp在InformationWeek的一篇博文中从七个方面深入探讨并破译了所谓的云计算神话。
什么是"云"？最近一段从来没有一种技术能让大家如此热情，狂热，困惑甚至于误解。 Serdar开篇就对云做了以下概括：
云不是一个神奇的万灵药也不是一个灾难，更不是救世主也不是罪人。它是一个解决问题的新工具。
1.兼容性相关：云计算太专有了
对于这个话题，Serdar的观点是：
当下，没有两个云是一样的，无论是本质还是IT. 亚马逊的云平台和Google、微软的都不同，跟即将推出的云也不一样。"专有"并不意味着"无用"–决不。
尽管随着时代的发展，人们对兼容性要求越来越高。 但是：
第一批云平台的专有性是个不得不存在的特性，但当你使用特定的平台（Amazon.com，Google的Python语言）时，也许这并不是什么问题。
而且像其他IT技术一样，随着云平台的发展，更多通用标准将会逐步建立起来，目前已经有一些组织开始行动了。
2.隐私相关 ：云计算是私密性的终结者
Serdar继续补充道：
对云平台私密性的担心可以被看作一个隐私相关考虑的副作用，云计算只是一个替罪羊……云计算如此的成为一个被隐私保护者所强烈关注的目标的原因不只是因为它是一种新技术，因为每种新技术都可能被怀疑隐私泄露，更多的是由于在表面看来，它是多个IT领域交汇的产物。当你在同一个屋檐下放置了有很多不同的事物时，这可能意味着"单点故障"的存在或"把所有鸡蛋放在一个篮子里"。
而且一旦你的数据和别人放在一起，安全性就不再是你能控制了的：
不仅大多数数据泄露来自于内部组织而不是外部攻击，而且更糟糕的是，把自己的数据存在别人的系统里并没有相关的法律保护。
对于这个问题，Serdar认为：
云计算厂商需要更加主动地面对这件事情，他们应该不惜代价地让他们的客户清楚这种情况而且延时到客户的客户，他们的数据和处理安全能够杜绝外部攻击和内部偷窃，而且他们敢于面对法律。给用户数据提供安全保护实际上并不是最难的事情，有很多例子说明这个应该怎么实现。比如Mozy，在线备份服务提供商通过让客户提供他自己的高级密码解决了私密性问题，Mozy的备份数据不能被任何其他人读取，包括Mozy自己……
3. 可靠性：云计算不可靠
Serdar认为
这就类似于这种断言："如果没能证明无罪就是有罪的"。 云计算的可靠性已经受到质疑。最近T-Mobile的Sidekick服务的崩溃以及丢失大量用户数据的事件受到了来自各个方面的批评，大部分是针对理论上的云的。这件事有个好的结果 –每个人的数据似乎都恢复了–但是还有谁有耐心再来一次这样的经历吗？……人们记住你仅有的一次失误的可能性会远远多于你500天不出问题的升级。
他进一步提出：
云的最大脆弱之处不是在线运行时间，而是数据保护。如果没有其他的处理，它意味着只有一种数据保护– 无论是终端用户还是备份服务提供商来说都是不够的。从单个磁盘镜像到健壮的文件系统，乃至不同的远程备份，云需要多个中心级别的数据保护，并且支持数据移植作为另外一种备份方式。
4. 可移植性 ：云计算是一个单行道
这话听起来很奇怪， 实际上它指的是云数据的导入导出：
不幸的是，对云的抱怨也是一个不争的事实，一旦你把东西（服务，数据）移入云之后，再将它移除来就非常繁琐了。这些抱怨主要来自那些把他们的数据放到基于云的服务之后，发现想要退出时只有非常有限的选择……任何人在建立基于云系统的业务时需要必须马上考虑用户数据如何移入移出云平台的问题。
而且进一步来讲，
数据移出不只是数据格式，一个客户也可能要把它自己的数据导入到某些物理载体–磁带，硬盘等。 这些如移出数据等的成本是不是被假定为客户，提供商，或者两者同时负担可以再讨论。
但是要让所人都清楚，客户选择云的时候不是结果发现走了一条走不通的死路。 提供商不能压迫客户，而是为他们提供服务的。
5. 大事件 ：云计算只是虚拟计算的另外一个名字。它不是什么新东西。
第一次接触云计算的时候，都会忍不住想知道它和如网格计算，分布式计算，虚拟计算等技术的不同。
这样的质疑可能是出于不了解云是做什么的而产生的， 云并非仅是假想的虚拟计算环境–它们除了使用虚拟计算之外还有很多其他技术来完成单个电脑无法完成的工作。
这些困惑可能来自于特定的提供商向开发者介绍云的方式。比如：
亚马逊EC2的例子被描述为一个类似于有固定内存，存储和计算能力的真实的系统。 这样做的原因很简单：当下让开发者领会使用云的方式 最好就是让他们认为和他们已经熟悉的硬件差不多。
6. 网络和存储限制 ：云计算太受限于网络或存储以至于用处不大
对于Web开发来说，这两个资源至关重要个，但这句话并不全对。 因为：
……这完全取决于你在云上有多大的规模和范围、I/O的限制、过程是否可伸缩以及你所选的实现方式。 总体来说， 云的I/O 仍然是个主要的瓶颈，除非我们的连接达到T级光纤。 否则我们要把必须做的工作放到程序端，这对计算能力和程序都有一定的挑战性，但是更灵活……
数据增长的比网络和带宽的增长还要快，我们可能要在多台服务器间同步千兆兆字节数据，试想如果网络速度跟不上，那些所谓的服务的正常运行都无法支持。 除了增加物理的带宽，作者也建议：
通过现有网络的改造或者使用类似于适用低带宽的文件系统，当然这要由你自己来做。其他更多方面要关注如何更有效的利用网络和哪种客户端更适合于与云进行搭配。
7. 可伸缩性 ：云的可伸缩性很难用。
程序员可能有这样的抱怨，
云计算很难支持提高效率的编程，他很容易让一些程序运行起来，但是要是想更容易伸缩那可能是另外一回事了。比如Twitter开始用的ROR，但现在不得不在一点点用Scala重写。
这些遇到的问题大多是由于并行编程还比较新，对可伸缩性的支持还不是特别全面，但除了程序本身，我们可以考虑从其他方面来解决，如：
Apache的Hadoop，Google的MapReduce等用来访问和统计海量数据的技术，都可以支持数据分布在不同的节点上，进而通过不同节点的分别计算并获得最终的结果。但不幸的是，MapReduce 只对特定的操作有效，不是一个全能的解决方案。所以有的时候问题不得不需要改造来适合已有的解决方案。
作者最后总结道：
关于云的神话，宣传，困难和希望是同时存在的。任何人参与云计算的人都应该团结一致坚持到底！
没错，和任何新技术的产生，发展，成熟的过程一样，有苦也有乐。无论是创建云还是使用云，都需要我们不断地参与，反馈，直至改善它的方方面面，才能让云技术不断的成熟壮大。
