警惕多云陷阱

Sat, 22 Sep 2018 11:04:21 +0800

和众多客户进行了沟通之后，我们得到了一些普遍需求：云无关、避免厂商锁定、能够在不同云供应商之间把工作负载进行无缝切换。这里我要再说一遍：多云是陷阱。大型零售商可能不想依赖在 Amazon 的基础设施上，除此以外，我想不出任何理由，让任何规模的组织将多云支持作为优先需求来考虑。

如果只是纸上谈兵，多云策略是很棒的；但是这一过程会引入了不必要的麻烦。绝大多数情况下，这种方法都会是一个兵分多路的过程，在用更多成本来解决旧问题的同时，造出更多的新问题，最终只能是竹篮打水一场空。这个说法似有危言耸听之嫌，后面会进一步进行说明。首先画个范围，这里提到的多云，指的是在不同云供应商的设施上运行同样的服务；或者一种允许用户在供应商之间平滑切换应用程序的设计方法。这一称谓不包括利用各不同供应商各自的最佳组件或者使用更高级别的跨供应商抽象方案的情况。

多云方案有很多值得关注的原因，主要是以下几个方向：灾备、供应商锁定和花费。我们会逐一进行讨论，并在最后看看多云实际发挥作用的方向。

灾备

多云方案经常以灾备方案的面目出现。当我们讨论灾备的时候，首先要对云供应商的运作方式有个清晰的认识。AWS、GCP 和 Azure 这些公有云供应商都有分区和 Availability Zone（AZ）的概念（Azure 在受到教训之后，最近在部分分区提供了 Availability Zone（AZ））。分区是一组在特定地理区域范围内的数据中心；而 AZ 是分区之内的一或多个数据中心。每个 AZ 都有独立的网络连接和备用供电，一个分区内的多个 AZ 之间会有低延迟网络链接。不同 AZ 可能处于同一个建筑内（配备独立计算、供电、冷却等设施）或者完全分开、甚至可能在几百英里以外。

分区一级的服务中断非常少见，然而一旦发生，就意味着互联网发生大规模的瘫痪，因此一定会成为万众瞩目的焦点。因为 AZ 本身在地理上是孤立的，除非是有陨石摧毁整个弗吉尼亚，否则很难干掉整个分区。更能导致区域故障的原因可能是配置或者其他方面的运维问题。虽然少见，但是确有发生（案例 1，案例 2）。然而分区是高度隔离的，并且服务商的维护活动会在特定的时间窗口进行，从而避免多分区同时故障。

当然不是说多区域故障不可能发生（比如流星毁灭半个美洲大陆或者一些奇怪的蝴蝶效应）。有一些主干设施可能会跨区工作，也有可能引发大规模事故。这样看来，多个云供应商很明显比提供多区域服务的单一供应商要安全，但是灾备是个跨度极大的话题，这种成本之中，云服务的移植性在成本构成上只占很小一份。你可能并不需要用多个云供应商来提供额外的灾备保障——除非你具备 google 或者 amazon 的规模。毕竟 Amazon.com 是世界上最大的零售商，如果你的灾备需求达到这一等级，你的规模也可想而知了。

供应商锁定

供应商锁定是一个关于恐惧、不确定性以及怀疑的话题，这个话题经常被当做多云策略的理由。Beau 在他的文章中说过：

云、DevOps、Serverless 这些都是用于将普遍需求进行商品化的尝试。它们可能不是完美方案。是的，可能造成厂商锁定。但是我认为这是一个值得尝试的行为，并没有听起来那么可怕。Tim O’Reilly 有一段话：

锁定的出现，是因为有人能从你的服务中受益，而不是受控于你。

之所以我们会被锁定，一定是因为我们从这一过程中获得了好处。首先这意味着我们利用了这一服务的全部价值；另外作为众多消费者中的一员，我们还可能拥有超出认知的更多好处。服务商为了能够持续提供我们从中受益的能力，也必须与时俱进升级换代，以此来保障收入。O’Reilly 指出，供应商的控制能力其实是小于客户认知的。服务商的主要任务就是根据自身对客户需求的认识，构建系统以期最大程度上满足市场需要。它们的动力就是市场上的用户的价值。

用户权益的另外一个重要来源就是竞争。强如 AWS，仍然有为数众多的竞争对手。当竞争者看到市场空档，要提供不同的方案时，也必须同时满足市场上的基础需求。这个就是我们在各个供应商的方案中都能看到通用功能的原因。这都是利益驱动的。我们当然要善加利用。不可否认的是，在供应商之间迁移是要有投入的，但是如果相对于从自建基础设施首次迁入公有云的过程来说，这种投入规模要小很多。一旦进入了公有云，同时也就具备了更好的敏捷性。

我经常看到有公司为了避免供应商锁定做出种种匪夷所思的怪事，然而用这个理由来推进多云方案，则是让我感觉最震撼的一件了。原本应该用于建设差异化业务的成本，却投入到趋同的建设中去。

这种行为的产生，有很多原因。正如 Beau 指出的，我们常常高估自身能力，又经常对成本估计不足。是做还是买？两种方案很难对照。这有点像宜家效应，消费者总是给自己参与建设的产品以过高的估价。另外当前的趋势是，企业重心从 IT 改为业务，尤其是产品思维对企业转型产生了巨大影响，这种奇怪的方案，可能也算是是 IT 部门尝试保持控制权的一种尝试。

云无关特性的重要程度还不足影响关键决策。如果以此思维作为起点，系统设计就会受到严重的限制，同时也无法完全享有云带来的好处——搞得好像你只是租了新的主机。Pivotal Cloud Foundry 和 RedHat OpenShift 这样的平台提供了能在主流私有云和公有云上运行的能力，这种做法实际上是做了一个虚拟层，把每个受支持的云平台的差异能力都进行了抽象。这种抽象在远离锁定的同时，也远离了价值。避免锁定的意思就是，避免全面使用已经购买的服务。这种抽象如果把一种差异化能力抽象成了一种通用接口，很难相信在保持云无关性的同事还能从供应商的差异功能上受益；如果没有抽象成通用接口，那这种平台的存在价值以及他如何做成多云就难于澄清了。

抛开 PCF 或者红帽子不谈，但是主要云供应商一直在对自家平台进行解绑，并且用一种更加民主的方式进行重新绑定，这种举措让多云平台的价值被大幅削弱。在 Kubernetes 前期以及容器时代，也就是 PaaS 的全盛时期，多云还是一个好故事。然而随着容器、Kubernetes 尤其是像 GKE 以及 GKE On-Prem（以及类似的其他厂商）的大行其道，多云故事越来越难吸引听众了。有趣的是，最新发布的 Knative 是与 Pivotal 和 RedHat 紧密合作建立的，似乎是在利用 Kubernetes 的势头，在企业拥抱 Serverless 的盛宴上分一杯羹。

但是有些人会把朵云平台作为一种服务，这其中存在一些问题。这种过程通过一个运维团队来完成多云操作的——也有可能是和供应商直接签订了服务协议。

多云部署需要对多个平台的了解。PaaS 可能可以把开发者从中解放出来，但是责任并没有消失，只是转移到了运维的身上。我们还没有谈到安全以及合规方面的事务。对某些还在观望公有云的企业来说这些因素都是负面影响。只有绕过华丽的市场词令，才能看清多云方案的实际情况。

现在已经没有多少空间留给自建的 PaaS 平台了，只是因为跟业务无关。我认为 Pivotal 和 RedHat 的收入很大程度上就是来自于提供服务。这些平台的价值就在于为专业服务牵线搭桥。

总的说来，非战略系统的厂商锁定所造成的风险并不高。例如用于存储数据的数据库，不管是 Amazon、google 还是 Azure 的，技术上有一些区别，但是归根到底只是用来存储和读取数据的。在这些数据库中进行迁移一定要投入成本，但是客户一定是为了获得好处才需要进行迁移的，这个好处一定是远大于迁移成本。但是运行重要业务逻辑、触及公司关键的核心系统还是应该避免供应商锁定的。正如 Joel Spolsky 所说：“不管怎样，关键业务功能还是要自建的。选择你的核心业务能力和业务目标，在内部完成。”

价格

价格可能是多云的理由中最弱的一个。实际情况是，随着商品化程度的不断深入，所有的供应商都在压低价格。在供应商之间的价格比较，最终都是某个方面花费更多，某个方面花费较少的选择。多云之间的价格套利只是部分人的臆想。一方面，这种设想很不现实；另一方面，这种做法会失去用量折扣。我曾经在 AWS 和 GCP 的对比中说过我的经验，不同的供应商侧重点不同，做好这一选择才能真正的节约成本。

Beau 也说过，云厂商利用锁定优势坐地起价这种事情很不合理。首先，这不是规模经济的运作方式。初次上云之后，在云供应商之间的迁移成本会大大降低，所以杀熟并不是云服务商的最佳选择。他们的首要任务是获得最大市场份额，竞争环境强制降低 IaaS 的成本。因为竞争环境和获取市场份额的需要，定价会趋于一致。云服务商必须将技术栈向 SaaS 以及增值服务方向发展，才能获取更好的效益。

另外多数公有云提供了批量折扣。例如 AWS 的 Reserved Instance 有高达 75% 的 EC2 折扣，其他的 AWS 服务也有批量折扣，并且 Amazone 提供合并账单选项，可以合并组织内成员的账单，从而尽可能的提供合理的折扣。GCP 则提供了持续使用折扣，在计费月份的大部分时间内运行 GCE 应用则会自动应用此折扣。它们还提供了一个称作 Inferred Instance 的功能，将部分实例打包成为单个实例，防止实例替换时丢失折扣。GCP 也有和 AWS Reserved Instance 类似的 Committed Use Discounts。如果资源分散在多个不同的云上，可能就很难获得这些优惠了。

多云的适用场景

我再次声明，多云方案对多数组织来说，除了分神别无用处。如果你的公司刚刚开始涉及云端，这种方案不但毫无助益，还会让你无法看清真正的重点；同时会拖慢进展速度，并埋下不安的种子。

一些公司试图同时在多个云服务上进行建设，避免把鸡蛋装在同一个篮子里。我认为这会适得其反，实际上会降低生产力，提高失败的风险。对于较小的组织，应该选择供应商并集中精力进行生产。尽可能利用托管服务，不要使用多云作为理由。对于大型公司而言，多云方案并不是不合理的，但应该通过受控实验来完成。这是云的优势之一，我们可以进行有限的投资和实验而无需大量的前期支出，只要注意一下多云 PaaS 和服务合同即可。

但是这也不意味着多云方案就完全无用了。真实世界从来没有这么干脆。对于具有多个业务机构的大型企业来说。多云的存在有其必然性。不同的产品团队可能有不同的成熟度、IT 基础设施，另外还有合并以及收购产生的结果。多云方案在这里存在一点存在价值就是——各有所好。这其实就回到上面的话题，云供应商的服务栈升级，不断提高的差异化水平和对应的增值服务会让多云方案更有意义。还有一种可能的情况就是数据主权。但是随着分区和 AZ 的普遍存在，这种情况会越来越少。但是 Google Cloud Spanner 这样的“全球可用”服务会放弃 AZ 粒度，因此可能会影响到 GDPR 之类的法规。对于拥有主机托管设施的企业来说，混合云最终会成为现实的解决方案，虽然这种方案更加复杂更加难于向多云方向迁移。

对于还处在试水阶段的用户，多云策略不应该处于备选方案的前列。而且绝对不应该是一个指导目标，也不应该是个影响业务方面核心决策或策略的选项。多云方案有一定的适用条件，除去这些特例之外，只是平白无故的消费掉了宝贵的注意力而已。

Tyler Treat | 伪架构师

警惕多云陷阱

灾备

供应商锁定

价格

多云的适用场景