“多云”是速度狂人的安全带

文化和方法 体系结构和设计 DevOps 云计算 混合云

摘要：

云爆发！本地！混合云！离场！多重云！本文作者Michael Coté过去十年来在执行有关云技术的分析、战略规划，以及现在进行的技术推广活动中经常听到这些词汇。这些词语每个听起来都很合理，尤其是在包含大量框、线、箭头的幻灯片里看起来美极了。最近他认为“多重云”这个词可能是其中最实际的。

正文：

随着云计算技术日新月异的飞速发展（不同的服务和供应商你方唱罢我登场），云技术锁定依然是很多用户接受云计算过程中的主要障碍。技术锁定意味着什么？如何确保在照顾到“可移植性”的同时通过云计算方面的投入获得最大化收益？

这篇InfoQ文章是“云和技术锁定”系列文章的一部分。你可以在订阅后通过RSS获得内容更新通知。

主要结论

• 使用多种云基础结构的战略将逐渐变得稀松平常。
• 如果在编写和交付应用程序时使用同一个平台，那么即可在该平台支持的任何IaaS环境中运行这个应用程序。
• “多重云”重点不在不同云平台之间的协调，而在于跨云获得的可移植性。
• 如果有人说“速度”是实现成功的核心要求，这个速度通常是指用更快速度投放市场，以及为了对应用程序进行完善而进行快速迭代的能力。
• 重视速度不代表可以忽略规范的过程和充分的防护措施。

云爆发（Cloud bursting）！本地！混合云！离场（Off-premises）！多重云（Multi-cloud）！本文作者Michael Coté过去十年来在执行有关云技术的分析、战略规划，以及现在进行的技术推广活动中经常听到这些词汇。这些词语每个听起来都很合理，尤其是在包含大量框、线、箭头的幻灯片里看起来美极了。最近他认为“多重云”这个词可能是其中最实际的。

之前在451 Research任职时，我们花了很多时间商讨有关“混合云”的定义。老实说，当时的结论我早忘记了：我觉得按照类似美国国家标准与技术研究院（NIST）的说法，使用两个不同“云”的资源为同一个应用程序或服务提供支持，这就可以叫做混合云。例如，某个旅游网站/移动应用的前端运行在Azure这样的公有云中，但同时需要本地访问（以传统方式托管，但不是“真正的云平台”）的预定系统。这个例子中，所有涉及到的组件至少会遇到三个“边界”。实际上最近Gartner预测说：“到2019年，将有大约80%的大型企业所制定的技术战略将涉及多个基础结构即服务（IaaS）和平台即服务（PaaS）供应商，而2015年这一比例还不到10%。”

那么我们就可以猜测，组织将借助多个不同的云平台搭建自己的IT环境。差不多也正是因此很多人将这种做法称之为“多重云”，但我注意到这个称呼还暗含了一套标准化的技术和实践。这一点其实与Java所谓的“一次编写处处执行”比较类似：如果同意使用同一套平台编写和交付应用程序，那么随后就应该可以在能支持的任何IaaS平台上运行这个应用。“多重云”这种想法似乎并不需要在不同云之间进行协调，但是我觉得大部分人还是需要这一点的，大部分供应商也正在提供这样的功能，但用户需要更为关注应用程序和组织知识的可移植能力。这种可移植能力解决了云技术领域最大的一个困扰：技术锁定。

“锁定”对我们自己来说是一种喜闻乐见的情况。我们总是希望避免锁定，但随后又会出乎意料地为类似Apple和AWS的系统锁定“添油加醋”。实际上“被锁定”到具体技术我们是可以接受的，只不过希望同时保留自由离开的权力，这一点正如Simon Phipps之前的意见所说。无论是技术债（“我们很乐意增加你要求的这个功能，不过可能要到两个月后了”），过程（“我们很乐意增加你要求的这个功能，不过要添加的功能很多，这个功能的优先级比较低”），行业管控制度（“听起来不错，但PCI-Level-Infinity不允许我们提供你需要的功能”），或你所使用的技术（“考虑到成本，我们的数据库就是无法缩放到你要求的那么大规模”）...你总是会被某些东西锁定。你打算怎么办呢，只要涉及到企业体系结构，免不了需要对风险和收益进行权衡。

但是对于“多重云”，将应用程序的开发和交付工作锁定到原生云方法中，以此为代价你的应用程序和组织知识将获得更高的可移植能力。以此为代价，你可以在任何公有或私有IaaS环境中运行自己的云平台。你可能希望选择一个开源的平台，例如以不可逆转的基础为代价选择Cloud Foundry。随后就算使用商用的“Open-core”发行版，依然能够获得极大的可移植能力，因为无论在未来选择哪个发行版，应用程序打包，服务和微服务体系结构，以及整体运行时依然保持不变。

目前很多人希望构建自己的平台以便在未来获得最大程度的灵活性，并能随意“离开”某项技术。这种做法的理论依据在于，对于一个东西，如果是你自己构建的，你就能拥有它，进而能控制它。如果你具备为它提供支持所需的源源不断的资源和技能，这也许是一种很有吸引力的做法，并且孩子们最喜欢构建平台和框架了！但是正如我之前提出的，如果你只是希望通过开发一些东西为自己的客户提供差异化价值，这样做其实并不值当。

目前使用Cloud Foundry的组织并未发现遇到锁定的问题，实际上他们正在忙于了解选择一个能为应用程序快速开发和交付提供支持云平台所能获得的收益。最近举行的Cloud Foundry Summit活动“分析师早餐”环节里，来自Comcast、CoreLogic，以及ExpressScripts等公司的专家也表达了自己的看法：他们会选择一个具备商用支持的云平台（而非自行构建），这是因为他们不愿意花费时间精力自行创建和维护自己的堆栈。目前来看，这种方式对他们都很适合。例如Comcast称，他们现在可以在几天内部署新功能，不再像以前需要几周时间。

如果你听到有人说“速度”是目前实现成功的核心要求，这个速度通常是指用更快速度投放市场，以及为了对应用程序进行完善而进行快速迭代的能力。我们目前都身处瞬态优势（Transient advantage）的时代，尽快发布新功能，然后使用早已就绪的过程持续对其改进，这已经成为一种核心能力。与其他任何快速演进的过程类似，为确保大提速后的生产力不会造成严重的后遗症，还需要具备妥善的安全措施。规范的过程有助于预防“跑偏”，可以帮你专注于持续改进，迫使你总是在考虑过程要求中哪些方面对用户的帮助最大。为了更睿智地使用技术，你需要所谓的非功能性需求，尤其是“多重云”多提供的可移植能力。在为“数字化转型”感到激动的同时，通过多重云获得最大化的可移植能力和IaaS环境，这种做法已经成为一种稳妥的、一碗水端平的策略。

关于作者

Michael Coté在Pivotal负责技术营销工作。他曾担任451 Research和RedMonk的行业分析师，负责过Dell软件和云计算方面的企业战略和并购活动，在此之前做过十多年程序员。他的博客和播客地址是Cote.io，Twitter帐号是@cote。

随着云计算技术日新月异的飞速发展（不同的服务和供应商你方唱罢我登场），云技术锁定依然是很多用户接受云计算过程中的主要障碍。技术锁定意味着什么？如何确保在照顾到“可移植性”的同时通过云计算方面的投入获得最大化收益？

这篇InfoQ文章是“云和技术锁定”系列文章的一部分。你可以在订阅后通过RSS获得内容更新通知。