【51CTO.com快译】不管你的企业是做什么的，几乎可以肯定的一些功能会因为云服务的使用，而变得更快、更便宜、或是更有效。但是如何正确地分拣出哪些是该被剥离的，且将其发送到何处，则是一个充满了潜在陷阱的问题。
另外，该问题的另一部分是：当涉及到云服务时，每个人都会有着自己的经验与见解。其中许多是源自他们非常有限的参与，或是来自那些从广义上说，是商业化云服务的所谓“与消费者服务”等效的营销式想法。例如：在某种意义上说，Gmail之类的云端生态服务是肯定无法代表你所寻找的业务模式的。你无法因为是自己繁忙的一周，而要求谷歌单独给你提供更快的服务;你无法无缝地转移到另一个服务提供商;你无法将其服务副本的备份在本地运行;你也不知道什么样的司法控制能访问到你的信息。
云服务能做什么?
在此，我们坦率地说，就是一个合适的商业级的云服务应该能够为你做到你所要求的一切。试想一个最不合理的架构，例如：有一些基于云服务管理的本地服务器，而且有一个提供商愿意为你管理它。那么如果你愿意的话，你可以要求通过以逐个字节进行拷贝的方式，将所有机器转移到远方的虚拟机上，从而把你现有的基础设施变成一个云服务。但是，所有这些都存在着一个潜在的问题：这样做是否会对你的业务发展有好处呢?然而这是一个只有你自己才能回答的问题。
不过，请不要太沮丧，如今有着大量适合云业务的产品，例如：微软的Azure就在运行SQL Server方面表现出色;而亚马逊的Web服务(AWS)，则从根本上彻底定义了Linux和Web应用程序的市场，以至于你很难找到理由不去从使用它们作为云业务的开始(其中一个很好的原因莫过于亚马逊的那套DIY的理论了，即：让你去实现如何处理一个类似业务连续性这样的小目标)。
供应商间的大小区别
在主流品牌之间做出选择是极具挑战性的。虽然我们在此只看大的方面，但那些核心技术人员却有着许多细节之处的思考，例如：亚马逊和Azure在Linux虚拟机可用性方面的差异。此外，请不要将你的搜索局限于那些家喻户晓的品牌。诸如Rackspace、Equinix、Zen或Memset这样的公司虽然可能没有什么典型的客户列表在其彩页上，但它们很可能会更适合于你的业务。
那么你该如何做出正确的选择呢?在收集各种报价或填写订阅表格时，你又应该注意哪些关键问题呢?
首先，在转移至云服务时，要面对的一个更为棘手的方面是：要弄清楚每个提供商所建议的解决方案背后的真正意图。例如，亚马逊和微软都会告诉你：可扩展性乃是王道。所以你只会为你需要使用的部分买单，而这些钱来自于可消耗和运营方面的预算，而不是资本或是银行资金方面的预算。然而他们却不会试图去搞清楚你的业务是否真正需要一个可扩展的架构。而这正是那些劣于营销的提供商所能一展优势之处：他们能提供更多的定制服务，并能尽更大的努力去了解你的真正需求。
不过，最终经费的问题还是会牵制到你的。因为你必须扪心自问，提供商所能提供的是否真正适合你的商业模式?还是你会被迫打造你的运营模式，以适应你的提供商?
虽然厘清自己的需求固然至关重要，但这还离整个过程的结束远着呢。在你准备好做出一个明智的决定之前，你还需要试着将一系列令人眼花缭乱的因素，例如：投资、合同、采购、订阅和架构等变得合乎情理。最近的一个可能会影响到你的云计算方面发展的情况是：萨提亚·纳德拉(Satya Nadella，微软CEO)的有关Azure的英国数据中心承诺已实现。这可能是欧盟公投以来的第一个大发展，而且会影响到许多公司对于托管主机选址的决定。
不要盲目求多
至此，你可能会希望我们在本文的某处展示一张对比的表格，也在疑惑所有这些问题在哪里会被考虑和阐述到。老实说，如果我们能发布一个大得足够将一辆宾利欧陆车作为礼物进行打包的插页纸的话，它将能够陈述和涉及到诸如产品、选择、警告、折扣和所提供的附加条件等广泛的领域。但实际上，我们只能给你指出一般性正确的方向：如果采用的是规模较小提供商的话，其每个提供的细节会有所不同。而更重要的是，各种云平台都会不断推出新功能，因此，很可能在我们刚对这种或那种能力的缺失进行标记的时候，其补救功能就已经被添加出来了。
所以我们不应试图去制定一张明确且详尽的提供商之间对比的表格，而是应该正确地去思考你选择的方法，列出一些更短但确实对你非常重要的方面，并专注地研究它们。
比方说：很多具有良好声誉且反应敏捷的网站，是被相对较小甚至完全不为人所知的托管中心所运营的。因此很有可能在这些中心到达其运能极限后，将无法再提供动态可扩展性。也就是说：它们在你的网站变得炙手可热、访问量飙升的时候，只能单纯地给你扩展出更多的服务器以供使用。但是当你真正以深究的方式开始观察这是如何被触发的时候，你会意识到：在这些更多的资源请求中，实际上包括着很多冗余且无效的流量负载。因此严格的程序代码审查和控制相对较小的请求才是对服务提供商最为重要的。
而在业务的另一个极端，一些公司甚至在没有巨大的扩展能力时，就无法正常运作起来。比如说某公司的业务人员，其工作负载是定位于高负载情况的话，那么他就需要能够一次性产生成千上万笔交易。而面对一张具有各种云服务提供商的详细产品列表，他也只会对少数几列产生兴趣。
简化你的登录
许多企业转向云服务提供商的一个原因是：管理方面的简化，和对它们已经使用的托管服务的支持力度。确实，如果你的技术人员要建立和维护自己的虚拟服务器的话，那么亚马逊和Azure会让你处于其最为基础的层面之上。无疑这对你的业务和提供商来说都是一种保证和平衡。但这种所谓的“平衡”如今正在从具体细节的方式转移到宏观地面向网络的服务之上。毕竟，多年来，你可能一直与这种多个应用的模式打了长期的交道。然而，很多SaaS商家最初采取的却是无障碍的免费模式。试想，一直以来，“分别购买各种软件，并为新的版本支付费用”的模式已根植于我们的概念之中，并成为了业界规则。而今，你却突然碰到了一个能够连接那些所有实用的小程序到一个单一的企业身份管理的系统，而且最好是能纳入到一个商业伙伴的单一服务合同之内。
可见，在这种特定的场景中，Azure已经遥遥领先了。虽然AWS有一些智能化的登录管理，但它们并非建立在活动目录之上。通过亚马逊，你无法将你的业务领域安全模式扩展到云之外;相反地，云模式却延伸到了你的业务之中。
一种模式并非万能
也许你已满足于自己本身的本地系统模式。毕竟，在许多情况下，云服务的吸引力只在于为了减少服务器的数量，你的空间和维护成本。因此，请不要陷入一种思维陷阱，即：认为你可以来一个“将所有旧的服务器连夜关闭，而在早上从其安装到了云端‘克隆’里启动”的反转式迁移。微软总是趋向于鼓励将虚拟机在线迁移到Azure上。这样做的确很“酷”，但这并不意味着它是一个适当的自动化方式。如果有人试图说服你相信这个的话，那么他可能是出于促成你签订合同的目的，而不是帮助你得到正确的业务产出。
事实上，存在着一种混合模式——“将场外离站系统与场内协同使用，而非取代本地系统”的基础设施架构。这将不仅是一个完全可行的选择，而且通常还会是一个更好的选择。从表面上看，相对于一个承诺能包办一切的标准化组件而言，它可能看起来像一种折中且有些复杂的安排。然而，你所选择的一种似乎能给系统的带来最小压力的模式，却往往会衍生出一大堆未预料到的困难。因此，千万不要低估那些为了使得你的服务器能100%符合Azure标准所涉及到的工作量。如果你使用的是一种并非一直处于主动开发状态的产品(如Azure)的话，那么避免Azure模式的“持续更新”政策是很有必要的。你完全可以找一台主机来对那些更新提前进行审查，从而降低风险。
这里还有另一个例子，是关于为什么决策矩阵能使得你的业务独具特色的。正如在同行业的发展道路上，不同人在问自己同样的问题时，很容易得出完全不同的结论那样，云服务的范围程度，及其提供商的大小不同，都会直接导致你的业务的各种服务能否与众不同，且不会产生同质化的情况。因此道听途说式的建议模式可能会对你选择体面的笔记本电脑非常有用，但在指导人们去衡量云服务及其提供商方面则不那么会奏效了。
你的云清单
在签署将各种关键业务服务转移给云服务提供商之前，你至少要确认并完成如下描述：
1) 我理解我所需要的内部和外部资源之间的边界位置，而且我的理由是……
2) 我所需要打交道的公司或其服务的数量为(X)，这是因为……
3) 当外部服务不法正常提供时，我对其的恢复计划是……
4) 我能按照规范转移出我的服务器，并且我正在开始一个全新的产品或是平台。
5) 我相信我所使用的云服务的商业目标，它是和我公司的目标相一致且兼容的。
6) 对于各种最好或最坏的情况，我已经对每月需要移动和储存多少数据做了一些粗略的估计。如果我的估计有些偏离的话，我的行动计划是……
【原标题】AWS or Azure? Choosing the right cloud provider (作者: Steve Cassidy )
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
