“云”成为热门词语已有一段时日了。虽然这个概念大概10前就已经存在了，但如今它在IT行业俨然是超级明星，种种错觉和误解随之而来。

　　即使说到什么是云，这方面仍存在误解。与云八杆子挨不着边儿的技术也取了这个时髦的字眼；厂商竭力兜售云托管（cloud hosting），声称这种方案有望解决企业主可能面临的各种问题。

　　因此，我们在谈论云计算的优缺点之前，有必要了解“云服务”这个术语的真正含义。云计算的主要特点如下：

　　按需提供

　　自助服务

　　可扩展、可衡量

　　更具体地说，使用云服务时，用户应该可以随时选择资源的类型和数量，只需要为实际使用的这部分资源付费。为什么我要细谈这点呢？因为这些特性决定了云技术的主要优点，也就是：

　　全面访问易于使用的控制面板和API，能够快速进行微调，不需要熟悉故障单和支持系统的专家干预；

　　降低了管理和支持工作系统的成本；

　　几乎无限制扩展的机会，可以轻松应对需求猛增和显著下降的情况；

　　应用程序和产品容易获得高可用性。

　　尽管有这些明显的优点，但是牢记这一点很要紧：这根本不意味着迁移到云的任何应用程序会：a）运行更快，或者 b）成本更低。实际上，如果你只是将网站从一台物理服务器移到虚拟服务器，向某家云服务提供商购买了基础设施即服务，极有可能只会增加托管成本。

　　“怎么会呢？”你可能会问。“云服务不是应该更具成本效益吗？”这个问题的答案是肯定的，但前提是，要以一种让云服务具有成本效益的方式来利用它们。我不妨解释一下：如果你购买一辆马力大得多的丰田坦途（Tundra），换掉原来那辆不起眼的大众高尔夫，可是继续在同样道路上开车，负荷一样大，到头来你得支付更多的油费，却享受不到任何额外的好处（除了开一辆更新更大的车子，但这不是你的初衷）。想通过云计算获得经济优势，你应该试着最大限度地使用它，总是把效率放在首位。

　　如果考虑到这一点，再让我们回到网站那个例子。如果网站有一群长期的受众，不会被硬件故障导致的资源暂时无法使用轻易吓跑，就没必要改变什么，最好还是继续使用物理服务器。然而，一旦未来计划包括一项吸引新用户的广告活动，开始考虑向云迁移是明智之举。否则，很难有效地应对数量越来越多的用户。

　　谈到向云迁移时经常提出来的另一个问题是安全性。许多企业组织不希望自己的信息存储在外部。然而，使用云服务就好比把钱存在银行。肯定会有一些相关的风险，但是把钱存在银行通常比把钱藏在床垫下来得安全。

　　对云服务提供商来说同样如此，因为提供商数据中心的安全级别高于大多数企业组织所提供的安全。还可以尽量减小内部威胁的风险，企业组织通常极难防范内部威胁。

　　云端的项目基础设施：一个例子

　　一家公司开始开发一个大系统。它需要产品管理软件（缺陷跟踪、源代码控制、持续集成和需求管理）。最后，它选择使用托管在虚拟机上的微软Team Foundation Server。

　　做出这个选择的原因如下：

　　由于订阅MSDN，已经获得了Team Foundation Server（TFS）的许可证；

　　该公司不想往自己的基础设施作投入（也不想填补或增设系统管理员这个岗位）；

　　开发人员很容易自行安装系统。

　　这一招管用吗？并不管用。开发团队耗费了大量时间和精力后，项目负责人开始考虑尝试Visual Studio Online。

　　那么，问题出在哪里呢？

　　TFS管理：即使安装成功后，TFS仍需要管理方面的一套程序。TFS数据库开始迅速庞大后，一名开发人员不得不专门处理数据库，放弃以前的项目，以便更改设置，并安排定期清理任务。

　　资源的成本：开发团队选择了许多虚拟机，但结果证明，为了更快交付构建的版本，为了日益壮大的团队有效地控制源代码，势必需要更多的资源。自动扩展虚拟机也不是一种可行的办法，因为这种操作挺耗费时间，必须避免进一步延迟原本很冗长的版本构建过程。

　　结果就是，尽管项目基础设施迁移到云端，不可能得益于云计算具有的主要优点，因为其功效几乎如同普通服务器，因而白白浪费了钱。

　　在类似的场景下，最好从两种方案中作一介选择：将软件放在专用物理服务器上，或者使用Visual Studio Online之类的SaaS解决方案。不妨详细比较一下这两种方案。

　　专用物理服务器

　　优点：

　　资源成本低（比云托管便宜多了）。然而，系统管理员的工资应该算进去；

　　全面控制硬件。

　　缺点：

　　时间延迟（需要物色系统管理员、转移知识和架设系统等）；

　　需要管理员；

　　无法保证系统始终可用（不过这点可以接受，对一些用户来说，哪怕24小时无法使用也不是大不了的事）；

　　万一项目规模缩小，投资可能无法获得回报。

　　SaaS解决方案

　　优点：

　　节省时间（工作系统立即可用）；

　　无需另外的专家；

　　正规的服务级别协议保证了正常运行时间达到99.9%（这并不重要，但仍是一个优点）；

　　成本仅取决于用户数量和版本构建工作人员所花的时间。

　　缺点：

　　成本高昂。

　　正如大家所见，使用基础设施即服务（IaaS）的自托管方法并不是最佳方案。最好还是尽量最大地限度地使用云资源（SaaS），不然还是走相反的方向：改用内部配置的专用服务器。

　　云外面测试

　　在另一个例子中，主要目的是节省测试环境方面的开支。主系统使用Azure云服务（PaaS）来托管，传统虚拟服务器用于测试。执行这些步骤是为了：

　　省钱（传统虚拟机比较便宜，又需要较少机器，因为测试系统的可用性不如运行关键业务型应用程序的系统来得重要）。

　　避免被单一提供商锁定（以这种方式来测试证实了没有Azure也行）。

　　一年后，它决定将测试环境全面转移到Azure云服务，另外更积极地使用Azure。下面是有助于改变策略的几个因素：

　　测试错过了Azure特有的某些功能，可以在更早期的阶段发现这些功能；

　　其他的非Azure解决方案需要大量时间来开发和测试，它们更像是桩模块（stub，没人果真把它们当成生产就绪的解决方案），而且给人以独立于某家特定的服务提供商这种错觉。

　　节省测试环境方面的开支可能乍一看是个好主意，但另一个方面却重要得多：测试环境应该尽可能类似生产环境。否则，就会错过好多重要的问题。还有其他方法可以降低成本――到了晚上关闭测试环境，或者减少云服务虚拟机的数量及/或大小。

　　挨得太近不适――被提供商锁定

　　如果担心被PaaS提供商锁定，这里有几点需要牢记：

　　像Azure、谷歌和亚马逊这些提供商或多或少证明了其可靠性（想想多年来成功可靠的运行，客户网站停运的几起重大事件也情有可原）；

　　这类级别的提供商提供的解决方案已针对大量用户、在不同情况和场景下进行了测试；因此，它们比刚开发的内部解决方案可靠得多；

　　支持两套备选方案需要为每一套提供同样的多测试资源，这让测试成本翻番，通常根本无法接受；

　　没有采用特定提供商的方案，改而使用所谓的“中立”方法，比如将文件存储在磁盘上，而不是存储在Azure blob上，这导致最充分优化的方案被忽视（因此所提供技术的潜力没有最大限度地发挥出来。）

　　这里的教训是，最好不要让你的工作复杂化，而是使用提供商提供的所有现有工具。当然，确保架构层面的灵活性，以便从一种解决方案轻松切换到另一种解决方案，这始终是个好主意。

　　另一个有用的举措就是为本地开发环境实施桩模块，以便简化设置、提高生产力。开发人员开发的桩模块并不会造成独立于提供商的错觉，只是一个开发工具而已。然而，如果将桩模块用作质量保证测试工具，可以得出结论：就正常运作而言，Azure也许根本没有必要。

　　结论

　　尽管云方面存在种种误区和误解，但是它的使用范围越来越广，不过有必要知道在哪些情况下云效果最好，哪些情况下传统托管方案更有效。

　　在绝大多数情况下，使用云技术在经济上可行。但是有必要了解如何以最有效的方式，充分利用云提供的机会。

　　通常，这意味着使用更高层的SaaS或PaaS的解决方案，而不是基本的IaaS。