先问一下，云计算面前最大的绊脚石是什么？是难以迁移现有的应用程序？是使用公司自身数据中心外面的计算功能引起的法律、监管和业务风险？是云计算供应商缺少相应的服务级别协议（SLA）？是云计算的总体拥有成本据称高于内部运行系统的成本？还是缺少针对云计算应用程序的传统系统管理工具？
之前讨论了企业采用云计算面临的这每一个阻碍。对于这每一个阻碍，我强调这方面的情况并不像提出这些问题的人描述的那么严重。比如以缺少服务级别协议（SLA）为例，我强调，有些云计算供应商在提供SLA。我还讨论了这个事实：非云计算服务供应商（如外包商）提供的很多SLA其实不是非常到位――它们并没有保障正常运行时间；而是说，一旦供应商没有提供双方约定的正常运行时间，就向客户给予赔偿。另外，赔偿条件通常相当严格，通常局限于服务供应商退回无法使用服务的那段时间的费用。换句话说，SLA赔偿并不承担用户的经济损失，只是承担了供应商服务的成本。所以，声称SAL方面存在不足就否认了云计算的潜力是一种遁词，而不是理由。
可以从同样的角度分析上述每个障碍。如果客观地加以分析，每个障碍都有办法得到缓解。当然，没有一个是不可逾越的障碍。
有意思的是，很多读者觉得我的文章是在说云计算的坏话――没错，我也认为这每个障碍完全是使用云计算面临的绊脚石。我看到的很多留言表明读者其实没有读完（或可能没有读懂）我的文章。另一方面，很多留言证实了这种观点：云计算没有“准备好迎接黄金时期。”
这其实不足为奇。只要技术方面出现巨变，很多人就会抨击新技术缺乏某些关键的特性功能。我记得当初互联网热潮向IT行业席卷而来时听到过类似言论。“你会让外人访问自己的系统吗？这太疯狂了。”“带宽不够用，任何真正的应用运行不了。”“这不够安全。”“找不到拥有相应技能的人。”按前一代技术的标准来看，这些言论自有其一定的道理。在早期，互联网安全方法不一致、不全面。然而从很多方面来看，现有的解决方案在饱受诟病的几个方面其实强不了多少，绝色存在自己的不足。
正视云计算存在的问题
我刚看到昨天有人在云计算论坛上发布的一个帖子，是抨击虚拟化的：“操作系统有安全政策和执行机制。虚拟机管理程序对操作系统而言是看不见的，更不用说对客户机应用程序而言了。如果得到妥善管理，现代的操作系统能防止入侵。而在虚拟机管理程序下运行的操作系统防止不了或察觉不出破坏虚拟机管理程序安全的活动，如果破坏方是数据中心的正当授权员工更是如此。”
这番话是对的。然而，其假定是操作系统得到妥善管理，但这种情况通常是不存在的。很多数据中心没有遵守系统管理、补丁管理和应用程序更新等方面的最佳实践。很多用户遇到过这种情况：得到妥善管理的操作系统照样遭到了攻击，这表明安全漏洞还是存在。我个人觉得，我更宁愿漏洞可能出现在占用空间较小的虚拟机管理程序中，而不是出现在由数百万行代码组成、包括数百个维护不力又很少更新的应用程序的操作系统中。
因而，人们对云计算发表保留意见是可以理解的。连有些绝对、让人无法接受的批评都是可以理解的。像云计算这些新兴技术通常都会遭遇这种批评。新技术常常没有全面完善起来。它们缺乏功能。只有遇到了实际情形，暴露了当前实际运作方面的不足后，关键的核心用例（Use Case）才会得到彻底而全面地考虑。新技术本来就不如现有的传统替代技术来得完善。
然而一段时间后，创新技术得到了改善，能够解决存在的问题。比如就虚拟机管理程序安全而言，我在Xen峰会（关注开源Xen虚拟机管理程序的开发人员和用户的大会）上感受到了这种自省：所开发的API提供的就是能够执行安全政策的那种安全监测。
不过，这种批评没有明白这点：人们愿意忍受技术的不足是有道理的；这些道理与新技术带来的显著优点有关。就虚拟化而言，尽管存在前面所述的种种问题，这项技术还是得到了极大的采用。而这是因为这项技术提供了不可否认的经济回报：提高了利用率、减少了能源使用，并且提高了应用程序的可用性。这些优点非常显著，以至IT部门一直愿意、甚至渴望忍受伴随这项技术而来的种种挑战。
所以更重要的问题是，云计算的优点是不是足够显著，能够压倒当前的不足――别忘了，我们在评估技术时还必须考虑到当前解决方案存在的不足。对云计算体现出来的热情表明，人们厌倦了如今现有的计算架构。存储需求在急剧增长。尽管摩尔定律在稳步发展，但用在硬件方面的资源似乎与过去一样多――由于处理需求增长、应用程序散乱现象激增，需要越来越强的计算功能。网络的规模和密集在不断增长。而管理种种复杂情况变得更有挑战性。正如我的一位朋友所言：每年你需要增加35%的服务器，才能满足处理需求，但是对系统管理员这份工作有兴趣的人其数量基本保持不变。这不是数据中心取得长远成功的方法。这可以解释为什么云计算如此迅速地激发了人们的想象力。
当然，IT行业的很多厂商似乎对云计算的优点深信不疑。IBM、惠普和微软等各大厂商都摆好了往云计算投入巨额资金的架势。这表明它们已进行了评估，得出了这个结论：就算这项技术不是代表未来，至少也代表了在未来的重要地位。
那么，这是否意味着人们在云计算方面提出的问题就不存在或不重要呢？根本不是这样。每个问题在某种程度上都是有道理的，但没有一个是绝对不能解决的。从这项技术的积极方面来衡量，这每个问题都是可以解决或忍受的。举例来说，最近宣布IBM/Juniper合作期间，Juniper公司的基础架构产品高级副总裁Manoj Leelanivas被问及云计算安全时回答：“在我的职业生涯中，我发现每当安全性和生产力发生冲突，生产力总是占上风。”换句话说，尽管云计算存在缺点，业界还是会积极接受。
因而，谨慎的做法就是承认云计算存在的问题，又要奋力继续前行，确认在哪些场景下可运用云计算、用极小的风险获得最大的回报。在当前环境下，强调问题、以此作为无所作为的理由，这不是成功的办法。拒绝改变意味着到时就会落后。
各大厂商的云计算架构
我与从事云计算领域的人作了一系列颇有意思的谈话；反常的是，这些人认为云计算不适合企业，至少现在不适合。
我说反常是因为，他们每个人都在大型技术公司从事云计算工作；人们可能会认为，这种工作角色会让他们竭力主张采用云计算。那么，为什么缺乏足够的热情呢？对其中几个人来说，云计算的功能其实还没有准备好适用于企业。对另一些人来说，云计算是个太模糊的术语，企业并不真正明白其涵义。对另一些人来说，云计算不会――也许永远不会――提供企业IT所需要的必要的实用因素。尽管我认为他们说的话都很中肯，但我还是对这些就是无法得到解决、永远不变的问题有所怀疑。
我与他们的谈话中得知，企业采用云计算面临五大障碍。这五大障碍分别是：
• 目前的企业应用程序无法方便地迁移
• 法律、监管和业务方面存在风险
• 难以管理云计算应用程序
• 缺少服务级别协议（SLA）
• 云计算缺少成本优势
目前的企业应用程序无法方便地迁移。各大云计算供应商（亚马逊的Web Services、Salesforce的force.com、谷歌App Engine和微软Azure）都提供了与常见企业应用程序架构不一样的架构。
亚马逊的Web Services在这方面提供了最强的灵活性，因为它提供了“空的”镜像，你可以把什么都放在里面，但是应用程序不容易迁移，这是由于其独特的存储架构所限，这意味着它们无法轻松迁移。
Salesforce的force.com这个开发平台与专有架构联系起来，该专有架构又与salesforce.com紧密集成起来，与常规的企业应用程序架构根本不一样。谷歌App是基于Python编程语言的一套应用程序服务――如果你的应用程序用Python编写、适应谷歌应用程序服务，那很好；但是企业应用程序、即使用Python编写的那些应用程序还没有针对这种框架来设计。Azure是基于.NET的架构，提供的服务基于现有的微软开发框架，但它不提供常规的SQL RDBMS存储，因而需要不同的应用程序架构，从而很难把现有的企业应用程序迁移至该环境。
据我采访过的一个人说，把应用程序从内部数据中心迁移至云计算平台是企业热衷于采用云计算的主要因素；一旦它们发现把应用程序迁移至外部云有多难，原本高涨的热情就会消退。
我会说，这对企业来说肯定是个挑战，因为要是把应用程序迁移至云计算环境很容易，肯定有助于用户积极采用。可又很难理解一些云计算供应商像现在这样不遗余力地提供云计算服务是出于什么样的动机。谷歌致力于Python有点费解，因为Python绝不是当前最流行的脚本语言。谷歌有时似乎一旦认准了技术上一流的东西，就会坚持不懈，尽管有迹象表明这会阻碍采用。至于Salesforce，我肯定能理解致力于主业的这家公司决定充分利用force.com架构来开发附件的做法，但是如果不付出相当大的努力，现有应用程序不可能迁移至force.com；当然，只要企业考虑为专有平台编写新的应用程序，就会存在被专有技术锁定（lock-in）的问题。相当奇怪的是，微软没有为用户把同一应用程序部署到本地或部署到Azure提供方便；尽管Azure架构能够开发很多先进的应用程序，但缺乏易于迁移的功能会让很多微软用户打消探究使用Azure的积极性。
另一方面，一种架构与现已得到接受的企业应用程序架构不同，未必意味着它就有缺陷，或者太难把应用程序迁移过去。迁移现有的应用程序方面存在一定程度的磨擦，这么说可能更合适；这个磨擦程度不一样，取决于人们想迁移至哪个目标云计算平台。
当然，云计算服务厂商在技术上似乎完全有能力开发物理至云计算（P2C）迁移工具，从而完成迁移所必要的所有或大部分技术工作。当然，这种工具需要能够兼容几种不同的云计算架构。
即使自动化工具没有开发出来，服务供应商还是有能力高效、低成本地执行迁移服务。
自然，执行这种迁移不会是免费的；不是要购买软件，就是要为服务掏钱。关键在于，这并非不可逾越的问题，而是难度有限的问题。
采用不同架构的云计算方面更可能面临的挑战在于员工技能方面。让技术人员尽快熟悉云计算在架构、实施和运作方面的需求并非易事：事实上，人力资本是最难提升的一种资本。不过，云计算代表了一种新的计算平台，IT部门在过去已经多次经历了平台转型。在眼下Windows开发人员不稀罕的时期，人们很容易忘了这个事实：曾经一度，Windows NT技能好比大海捞针一样难找。
总的说来，现有的应用程序缺少一条便利的迁移道路将会阻碍云计算的采用，但并不代表就是永远存在的障碍。
云计算带来了法律、监管和业务风险
大多数公司的运营受到风险约束。比方说，美国的上市公司都要遵守《萨班斯－奥克斯利法案》（SOX）规定的法律要求：披露财务报表。视公司从事行业所定，可能会有针对特定行业的法律和法规。在医疗行业，数据隐私方面就受到《健康保险可携性及责任性法案》（HIPAA）的约束。还有针对数据处理的其他更加一般性的规定，要求能够跟踪变化、对变化进行跟踪记录等等，尤其是在诉讼环境下。在其他国家，由于国家的隐私需求，客户数据必须得到非常认真的处理。比方说，欧洲某些国家规定信息必须保留在国内；不可以把数据存放在另一个地方，无论是存储文件还是存储数据。
说到业务风险，问题更多地与运营控制和遵守政策的确定性有关。有些公司会非常不情愿日常运营不在自己的直接控制之下，所以它们可能会坚持在自己数据中心里面的自有服务器上运行应用程序。这个问题不是云计算特有的――软件即服务（SaaS）及更加一般性的云计算服务方面常常也存在这个问题。
除了特定的法律、法规和政策外，我采访过的人提到了企业会提出来的总体风险问题：与云计算供应商本身有关的风险。一些人特别指出，亚马逊的云计算服务不是其核心业务。然而有意思的是，他们认为亚马逊的核心业务是“销售图书”。我认为，亚马逊的业务活动绝不仅限于图书；有人会有这样的反应，可能表明他不熟悉亚马逊的整个业务系列；然而，对亚马逊的核心竞争力及重心放在计算上提出问题是有道理的；如果这家公司有很多分散的项目，可能会有更多人提出这个问题。
对其他云计算供应商（它们可能被认为是更加“传统”的技术公司）来说，这个核心竞争力和重心问题不是直接让人担心的问题。不过它仍让人担心，因为有人会发觉每家供应商提供的云计算服务不是其主要的业务重心；因而，在将来某种情况下，该公司可能会觉得云计算服务偏离了主业，或者拖累了财务，于是会停止服务。谷歌最近停止了几项服务就证明了这种担忧。
所以总的来说，企业在使用云计算方面可能会有与风险有关的很多问题：从法律或法规强制实施的特定问题，到依赖外部供应商引起的一般性的运营风险，不一而足。
广义的风险问题
然而，很多提出这些问题的人过于担忧了；在我看来，提出的问题过于宽泛了。让我解释一下。
首先，云计算供应商明白自己面临的很多法律和监管风险。它们认识到，自己需要解决掉这些风险，那样才能吸引主流的企业用户。然而，为了开始上路、积累经验和发展势头，它们并没有把精力放在非常有挑战性的功能和流程上；相反，亚马逊等供应商一直主要针对新兴公司和非关键的公司应用程序。
在我看来，这是明智的策略。你只要看一下SAP公司拖延了提供一项特性类似于软件包的按需服务的行动，就明白试图一开始就满足要求很高的功能会如何严重阻碍任何进展。然而，云计算供应商会继续扩展功能，以便消除掉这些方面的风险，对此我有信心。
此外，讨论这种风险的很多人认为只有内部数据中心才能解决该风险；也就是说，恰恰正是云计算的性质使得它无力应对风险特性。我与同事John Weathington作了交谈，他的公司Excellent Management Systems实施管理风险的合规系统。他对云计算天生不适用于合规架构这个观念提出了质疑。他提到，合规结合了政策、流程和技术。在他看来，坚持声称风险管理与云计算无法统一表明对合规管理的了解很有限。
过于宽泛地认为云计算风险过大的第二个因素就是，对当前的风险管理方法持过于乐观的看法。与John讨论这个话题时，他举了一些例子，表明公司在内部IT系统中没有适当（其实根本没有）管理合规工作。正人先正己这句老话似乎仍适用于此。从某个方面来看，这种态度体现了一种普遍的人性：低估与当前情形有关的风险，而高估了新情形的风险。然而，抨击云计算无力支持风险管理、同时忽视当前风险管理的缺点其实毫无帮助，抨击人士可能让人觉得缺乏成熟的想法。
与这第二个因素有关、但不同的第三个因素就是，很容易把所有风险当成最糟糕的场景，这种态度要不得。换句话说，以为一些数据要求就意味着明确需要有严格控制的现场存储，并得出一般性的结论：云计算对每个系统来说风险过高。指出云计算满足不了一些情况或数据管理需求带来了这种危险：所有系统或场景都拒绝利用云计算。你可能不相信这种过于宽泛的评价会持续下去，但我听到过有人在谈话时随口说出“HIPAA怎么办”的话，然后心满意足地转到其他话题，信心十足地认为问题已得到了解决。
不过，出于本能反应声称存在这样的风险是可以理解的。很多IT部门在接受外部云方面因假定存在的风险而缺乏热情，这可能归因于他们面临的风险不对称。也就是说，如果数据出现了什么问题，他们会碰到大麻烦；但是实施风险评估流程、通过利用外部云计算资源来降低风险并没有太多的利好。有人可能会说，IT部门在数据安全方面老是担心，这会影响他们对风险的看法，可能会促使他们在这个问题上显得非常保守。
然而，考虑到由于云计算能提高IT灵活性、IT部门面临剖析云计算的重大压力，坚持这种空洞的观点：“云计算风险过高；毕竟，XX怎么办？”，其中的XX是公司经营所要遵循的某个法律或法规，由此抵制云计算，这恐怕不是什么好办法。
如何解决风险管理？
那么，你应当如何着手解决云计算的风险管理这个问题呢？
首先，要明白你的风险和合规需求到底是什么、现在如何用内部系统应对这些需求。没有比这种态度更糟糕的了：声称云计算因存在的风险而不合适；被问及“如今我们该如何处理这个问题”时，又没有明确的答案。
其次，落实风险评估机制（假设还没有落实），确定风险级别，并让这种机制成为系统开发生命周期的一部分。要是没有这种机制，不可能评估某个特定系统是不是适合在云计算环境下运行。
第三，评估一下潜在云计算托管运营商的风险管理方法。掌握了这方面的情况后，项目就可以针对云计算供应商来进行风险评估，并且做出云计算托管是不是适合该系统的决定。
应当把云计算托管风险评估当成是一个动态目标，而不是静态情形。整个领域在迅速发展，今天的评估在六个月后恐怕就不准确了。
在接下来的12个月里，IT部门会感受到成本方面的压力，尤其是需要弄清楚要不要认为云计算是一种部署方案。如果落实了风险管理框架，就能做出合理的决定，并证明这个决定是必要的。
云计算服务级别协议
接下来探讨反对云计算的另一个常见因素：服务级别协议（SLA）。
云计算方面最常见的问题之一就是，可能会出现停运时间――这段时间内无法使用系统。这对业务应用程序来说是个关键问题，因为服务停运意味着一些重要的业务功能无法执行。关键的业务应用程序包括：接受订单、与客户进行联系和管理工作流程等等。当然，企业资源规划（ERP）系统属于这一类，面向很多行业的垂直应用程序也属于这一类；比方说，制造公司的数控机床软件，或者监测石油天然气和发电厂等行业中传感器的软件。
面对应用程序可用性的重要性，很多人对可能使用基于云计算的应用程序持以谨慎、甚至恐惧的态度。有些云计算供应商不提供SLA，有些供应商提供的SLA不够到位（保障正常运行时间方面），这就更让人担心了。
造成所有这些问题的根源是人们怀疑你无法真正信赖云计算供应商来启动及运行系统。有人对依赖外部机构来确保关键的业务连续性很是担心。客观地说，云计算供应商遇到过服务停运的情况。近些年来，Salesforce就遇到过几次停运。不久前，亚马逊也遇到了一两次停运。
这样看来的话，可以理解一些企业不敢把至关重要的关键业务系统放心地交给可靠性成问题的云计算供应商，觉得这是个SLA问题。
不过，这就是理解这个问题的最佳方法吗？
如果你看一下SLA在其他环境下的使用，它们有时只是公司内部承诺的一方面――比如营销部门让IT部门实施新系统后，IT部门保障提供一定级别的可用性。不过更为常见的是，SLA是外包协议的一方面；这种情况下，公司选择像EDS这样的外部供应商来运营其IT系统。
当然，这方面的SLA备受关注。在谷歌搜索引擎上搜索“Outsource SLA”（外包SLA），会出现好多页的“最佳实践”、乐于帮助拟订含有SLA内容的合同的组织、SLA关键原则方面的建议文章――众多途径可以帮助确定严密的SLA需求。如果搜索“Outsource SLA Success”（外包SLA成功），遗憾的是一个链接也没有。所以有人可能会以为：SLA未必有助于获得高质量的正常运行时间；不过要是出了问题，它为冲突协商提供了基础――就像是婚前协议。
解决SAL的基本需求
如果说SLA的目的更像是事后解决冲突的指导准则，言外之意是，SAL“涉及”的很多情况不是非常好；换句话，经过了种种最佳实践研讨会、事无巨细的协商之后，它们还是没有基本上实现这一基本需求：系统可用性。为什么会这样呢？
首先，我刚才提到了这个问题：SLA的存在未必改变实际的运营；它只是为双方提供了协商的渠道。关键在于系统的正常运行时间。
其次，到最后，SLA通常并不能保护企业避免制订SLA的目的：系统正常运行时间出现减少。SLA通常仅限于托管服务本身的成本，而不是停运造成的机会成本（即用户公司损失的钱或者没有赚到的钱）。所以除了SLA毫无成效外，说到对供应商进行经济惩罚，SLA其实没有任何强制实施的有效手段。我承认，就内部SLA而言，惩罚可能是负责的相关经理丢掉饭碗，这种惩罚相当厉害。但SLA绝不会让受害方完好无损。毕竟，让IT部门付钱给营销部门只是把钱从一只口袋转到另一只口袋。
最后，SLA的存在促使提供方的行为符合协议的字面条文，但可能并不符合用户的实际需求；另外，协商过程越困难，供应商“按章办事”的可能性越大，这意味着履行协议的基本要求，而不是解决问题。没有什么比怀揣实际需求去找外部服务供应商、结果实际需求不在协议范围之内更恼人的了。
然而，你应当客观地看待云计算的服务级别，不管有没有制订SLA。
达到服务可用性的建议
记住，目标是服务可用性，而不是与目标关系很松散的合同承诺。所以给出以下这些建议：
首先，关注SLA，但要记住它是争取现实的目标，而不是能够确保万无一失的最后通牒。还要记住：云计算供应商就像所有外包商一样，制订SLA是为了尽量减小自己的经济风险，把赔偿对象限制在停用服务的成本，而不是停用服务带来的经济影响。
其次，使用合适的比较评估标准。问题不是云计算供应商会把什么内容写入到合同，而是云计算供应商与可用的替代方案相比如何。如果你的外包商老是无法兑现正常运行时间方面的承诺，就肯定有必要换一个新的外包商。如果比较的两个对象是外部云计算供应商和内部的IT部门，有必要进行同样的评估。
第三，记住，内部正常运行的质量与IT部门的成熟程度直接有关。尽管大企业承担得了众多IT人员和先进数据中心所需的成本，但世界上的大部分公司形势艰难：资金不足的数据中心、糟糕的自动化以及人手不足的操作人员。它们的运行随时处于非常时刻，正常运行时间得不到保障。对这类公司来说，云计算供应商也许能大幅改善服务质量。
第四，就算你对当前正常运行时间的质量觉得满意，也要分析一下为此花了多少成本。如果你在用到大量的人工干预和随时待命的人员，并且全天候配备人员，为满足正常运行时间要求所付出的成本太高昂了。比较一下云计算和内部工作（或外包服务）之间的正常运行时间和成本，你可能会受到启发。我采访了谷歌公司的一名工作人员，他强调照谷歌的运营规模来看，人工管理是无法想象的；只有完全自动化后，才会投入运行。如果你以旧方式获得正常运行时间，那么从经济层面来看，考虑使用云计算可能情况会好得多。
第五，即使有一些应用程序因正常运行时间方面的严格要求而绝对有必要在本地加以管理，你也要认识到：这并不适用于你的全部应用程序。很多应用程序没有规定要满足如此严格的正常运行时间要求；利用与关键任务型应用程序一样的管理框架来管理这些应用程序、并且采用相同的运营成本，这从经济层面来看是不负责任的做法。仔细分析一下当前及将来的所有应用程序，根据严格的正常运行时间要求来进行分类。评估一些应用程序是否可以迁移至保障正常运行时间方面功能可能稍差也没关系的较低成本环境，然后跟踪一下你在使用这些应用程序方面的体验，以了解云计算正常运行时间方面的实际结果。从而获得的数据可以确定比较关键的应用程序是否可以同样迁移至云环境。
从某种意义上来说，最后一个建议类似“风险”部分的那个建议。那方面的其中一个建议就是，根据应用程序的风险状况来评估所有应用程序，确认哪些应用程序可以安全地迁移至云计算架构。这个正常运行时间评估是适用于评估框架中的另一个评估标准。
所以，“云计算的SLA”并不是矛盾的形容法，它也不是避免尝试、评估云计算在如何帮助你更有效地开展IT运营的一个理由。