云多力量大？你知道多云架构里隐藏的11个秘密吗？

作者：计算机世界 2021-08-04 10:14:15

云计算 在许多情况下，多云架构都非常有意义。但是，在自由选择、提升灵活性以及避免厂商锁定方面，多云可能会给企业带来一些隐藏的成本和潜在的问题。

[[415285]]

云计算有着众多令人眼花缭乱的选项，从首席信息官到实习生都会感到无所适从–那些有24GB内存的服务器看起来不错，新的人工智能图像分类系统看起来也很好。哦，那是什么东西?长期对象储存吗?也给我准备几个ZB(泽字节)吧。

一家云服务提供商提供的服务选项就这么好，那么我为什么不再选择两、三家，或是更多的服务提供商呢?几乎所有人都经历过家庭作业逐渐堆满书桌、食谱越来越复杂直到占满厨柜台面的每一寸空间。对于现代架构师来说，他们会很自然地萌生出想要利用整个互联网中所有可用资源的想法。

多云架构之所以有意义，在于其很好的满足了一些实际需求。更多的云意味着更多的API选择、更多的数据中心位置，以及更多的人工智能算法。只要人工智能算法足够多，总会有一些算法可能会奏效。在新的改进出现后，对多云服务持开放态度的架构师团队可以灵活而充分地利用它们。

多云架构之所以受到欢迎，还有一个原因在于公司希望摆脱厂商锁定。每当合同要续签时，原来的服务供应商就会趁机涨价，直到公司为其引入竞争对手为止。如果公司从一开始就将多云敏捷性加入到体系结构中，一旦供应商销售团队想涨价，那么公司可以很容易地改用其他供应商的云服务。对于公司来说，只需要一个周末的时间即可将自己的业务迁移至另一家供应商的服务上，这点具有不可抗拒的吸引力。

然而所有这些优势都是有代价的。保持足够的敏捷来享受竞争带来的优势，这也存在着一些副作用，有的副作用可能在几周、几个月甚至几年之后才会显现出来。以下是多云隐藏的一些潜在危险，这些潜在危险将会削弱用户的体验。

无法使用专利工具

现代云服务中的许多组成部分都是纯商业产品。厂商销售的实例中的RAM大小都不尽相同，不同用户对Linux的风格也各有偏好。在所有这些看似普通的选项中，有些选项会提供独特而强大的工具，不过这些工具是有专利的，甲骨文的主数据库、谷歌的Firebase和微软的.Net堆栈只是其中的典型代表。

多云使得用户很难充分利用这些专利工具，因为用户很难在另一个云服务中复制它们。如果你的目标是确保自己有其他的选择，可以随时切换到其他厂商的服务上，那么你可能无法享受到真正适合自己的选择。自由选择的最大代价就是用户永远都无法得到一款优秀的工具。

选择受到制约

有时没有其他的选择也不失为一件坏事，做出决定需要时间。选择受到制约时，用户不得不制作大量的电子表格和清单，然后再提交给审查部门进行审查，所有这些工作做下来可能只节省了一些微不足道的费用。

关注厂商变化

云计算的许多组件都是可以相互替代的商业产品。虽然可以相互替代，但是这些组件仍然存在着微小的差别，这需要团队不得不持续关注这些差别：也许一个云服务已经先于另一个云服务切换到了PHP 8，另一个云服务在定价和收费模式方面可能不利于大量带宽的使用。越来越多的供应商和合作伙伴意味着用户的电子邮件通知和视频会议也会越来越多，意味着在年度面对面会议上的广告宣传也将占用更多的时间，团队中的每个人都需要做更多的工作。”多云自由”的代价意味着用户需要长期保持对众多供应商的公告、新闻稿和电子邮件的关注和警惕。

代码故障概率增加

年青人喜欢用”开玩笑/不开玩笑”之类的话来衡量到底有多少诚意，标准制定者也是如此。从理论上讲，互联网与精心制定的标准是不可分开的一对，这些标准确保了互联网中的所有东西都具有互操作性。虽然这句话很有道理，但是做起来却并非完全如此。在用户的Ubuntu、Python，亦或是其他一些所谓的标准版本之间，总是会有微小的差异，当代码遇到这些差异时就会出现异常甚至是崩溃。如果用户在多个云服务上使用自己的代码，那么代码遇到这些微小差异的概率也会增加。诡异的是，这些问题往往会在周六晚上或是假期中出现。

延迟

与将数据包发送到世界上其他地方的数据中心相比，在同一机架中的机器之间发送数据包要更快。如果你想利用南极洲存储价格低廉的优势，那么多云战略可能会遇到更长的延迟。在许多情况下，延迟问题并不重要，因为有些数据包不需要快速传输。例如许多后台计算对速度要求并不高。但是对于为应用程序的交互组件提供支持的主要例程而言，距离核心微服务当然越近越好。

更多的培训时间

选择一个云服务，意味着用户要学习和掌握该服务供应商的愿景和特有界面。选择多个云服务，意味着用户需要多次进行学习和掌握，团队需要不断积累专业知识。目前已经有了简化这个过程的产品。

例如，Backblaze推出了一个可以模拟亚马逊S3 buckets的存储API。遗憾的是这类产品并不多，用户的N个选择意味着要经历N次培训。

价格陷阱

运行流行的开源操作系统的现代实例貌似已成为了商品。用户通常会选择每小时收费价格最低的产品，但是需要注意这类产品往往隐藏着一些重要的潜在成本。例如，有些云服务会对离开其中心的数据收费。在长期使用下，有些云服务的回报可能会更好。云服务定价模式的考虑因素很多，如果用户想选择价格最低的云服务产品，那么他们需要认真评估自己的选择。这些云服务产品只是看起来像商品，它们的定价模式却与普通商品迥异。

整合度不高

用户选择了云服务产品后还有许多工作要做，整个过程更像是用户在交付产品。用户的团队或许能够发挥神奇的作用，为代码层添加一些重要的功能，但是如果用户接触的只是最低限度的代码，那么想要实现超越就非常困难了。许多工作不需要太多的聪明才智，许多任务最好使用最简单的方法来完成。如果用户的要求很高，那么只选择一种云服务或许才是最佳的选择。原因在于多云架构只是最低限度地实现了众多云服务产品的整合。

无法享受折扣

云供应商会为大批量购买的客户提供大幅折扣优惠，特别是当客户承诺长期使用的话。保持敏捷性并准备随时迁移至新的云服务上不仅意味着避免厂商锁定，也意味着无法享受厂商的折扣价格。如果用户将费用分散到多个云服务上，那么他们将难以享受到厂商为大批量采购所提供的折扣。

信任难题

在商业上不要轻信任何人。用户不应将所有的信任都放在一家服务供应商身上，这是非常明智的。自由选择意味着把信任放在更多的厂商身上，但是这种做法会导致厂商们失望或背叛的几率成倍增加。用户可能不会信任自己的云供应商中的每一家，但是多云架构的运行需要更多的信任。如果信任可以量化为数字的话，那么多云架构需要的信任反而要比只有一家云供应商需要的信任要翻好几倍。

法律漏洞增多

坚持使用一个云服务提供商的好处之一是提供商难以推卸责任。假设用户从一家公司那里购买了火灾保险，又从另一家公司那里购买了洪水保险，如果洪水引发电气火灾，那么用户极有可能遇到两家公司相互扯皮的情况，认为支付索赔是对方公司的事情。选择多云意味着用户要签署多份默认协议并对许多合同展开谈判，同时这也意味着这些协议和合同之间更容易出现漏洞，用户也更容易踩到这些漏洞。