讨论 (讨论的近义词)

技术教程 2025-07-06 22:54:15 浏览
讨论

讨论 | 多云是个陷阱根本派不上用场?

2018-09-25 15:45:03多云因诸多原因而备受关注,但主要分为以下几点:灾难恢复、供应商锁定和定价。我会深入阐述这每一点,然后讨论多云在哪里确实派得上用场。

与客户的多次谈话中常听到多云。我们希望做到与云无关,我们需要避免供应商锁定。我们希望能够在多家云提供商之间无缝地转移工作负载。我要再强调一下:多云是个陷阱。除了取悦可能不太热衷于在亚马逊数据中心运行工作负载的少数几家大零售商外,我想不出多云应受到任何规模的企业组织优先重视的诸多理由。

乍一看,多云策略看似很棒,但它带来不必要的约束,导致劳而无功。对于大多数人来说,它最终会分散注意力,带来的问题比解决的问题还多,得不偿失。眼下,我所说的“多云”是指这个想法:在多家供应商的平台上运行同样的服务,或者设计应用程序时确保它们可以在多家提供商之间顺畅移动。我不是指这个概念:充分利用每家云提供商的最佳服务,或者跨提供商使用更高级别的增值服务。

多云因诸多原因而备受关注,但主要分为以下几点:灾难恢复、供应商锁定和定价。我会深入阐述这每一点,然后讨论多云在哪里确实派得上用场。

灾难恢复

多云号称是实施灾难恢复的一种手段。讨论灾难恢复时,清楚地了解云提供商如何工作很重要。像AWS、GCP和Azure这些公共云提供商有区域和可用区这个概念(Azure最近才在某些区域推出了可用区,它在经历了惨痛的教训后明白可用区是好主意)。区域是某个特定地理区域内的数据中心集合。可用区是一个区域内的一个或多个数据中心。每个可用区由专用的网络连接和电源后备系统加以隔离,区域中的可用区由低延迟链路进行连接。可用区可能在同一建筑物(配备独立的计算、电源和散热等系统),也可能完全分离,相隔数百英里。

波及整个区域的故障很少见。一旦发生,这是备受瞩目的事件,因为它通常意味着半个互联网瘫痪了。由于可用区本身从某种程度上来说在地理位置上是孤立的,肆虐整个区域的自然灾害基本上相当于摧毁弗吉尼亚州的陨石。区域故障的更常见原因是配置错误及其他操作错误。虽然很少见,但确实会发生。然而,区域高度隔离,提供商在交错的时间窗口对它们进行维护,以避免多区域故障。

这倒不是说多区域的故障不可能(这与陨石摧毁美国大陆的一半面积或某个奇怪的连锁故障是同一个道理)。一些骨干基础设施服务可能跨越多个区域,这可能导致更大规模的事件。虽然采用多家云提供商显然比一家提供商的多区域策略来得安全,但是这么做成本很高。灾难恢复是个极其复杂的话题,我认为它没有得到充分的认识;我认为,实际上云端可移植性对于尽量降低那些成本而言收效甚微。不是说非得有多云才能拥有强大的灾难恢复策略――除非你的运营规模达到谷歌或亚马逊的程度。毕竟,亚马逊是世界上最大的零售商之一,所以如果你的灾难恢复策略能与它的策略相匹敌,你的情况可能已相当好。

供应商锁定

供应商锁定及相关的恐惧、不确定和疑虑(FUD)是主张采用多云策略的另一个常提到的原因。博•利顿(Beau Lyddon)在《别再浪费你的啤酒钱》(一文中提到了这点:

云、DevOps、Serverless。这些都是为了将常见需求包装成商品而搞起来的潮流和市场。它们可能不是完美的解决方案。是的,你最终可能会“被锁定”。但我认为,这个险值得冒一下。它没有听起来那么糟糕。Tim O’Reilly有句话概括了这一点:

之所以有“锁定”,是由于别人得益于你的服务,而不是由于你完全掌控。

我们被锁定,是由于得益于某服务。首先,这意味着我们在充分享用该服务带来的价值。而且作为一群消费者,我们享有的远不止这些。那些提供商会尽其所能,继续提供我们受益的价值。这推动其收入增长。正如O’Reilly指出,提供商实际上拥有的控制力比你想象的要弱。它们会构建它们认为有利于市场最大群体的系统。它们会专注于我们(市场上的参与者)注重的东西。

竞争是另一个重要因素。连AWS这样强大的提供商,也有很多云提供商与之竞争。虽然竞争对手试图为它们认为的市场缺口提供差异化的解决方案,但也需要满足基本需求。这就是为什么我们看到这些提供商提供如此多共有的服务。这一切有利于我们。我们应充分利用提供给我们的这一切。是的,从一家提供商转移到另一家仍会有成本,但我认为这些成本实际上远低于从本地转移到云端的成本。一旦你真正接触云,就获得了灵活性。

我看到许多公司为避免供应商锁定而经历的心理活动和赞同多云的诸多“理由”总是令我震惊。令人费解的是,公司企业却愿意把大把的钱花在根本无法让它们实现差异化的东西上。

我觉得这有几个原因。首先,正如博指出的那样,我们往往高估自己的能力,低估自己的成本。这导致我们对自建与外购这个决策判断失误。这也与宜家效应(IKEA effect)密切相关;宜家效应是指,消费者对于他们部分创造的产品赋予了高得不成比例的价值。其次,由于企业组织中的权力和影响力由IT转向业务,尤其是奉行产品理念,我认为这是IT运维部门又一次试图保住控制权和地位。

做到与云无关应该不是驱动关键决策的一个足够重要的目标。如果与云无关是你的出发点,你其实在严重限制全面获得云带来的好处的能力。你只是在租用计算机而已。Pivotal Cloud Foundry和Red Hat OpenShift之类的平台宣称能够在各大私有云和公共云上运行,但这么做本身势必需要一个抽象层将每个云平台的所有差异化功能抽取出来。如果你将差异化功能抽取出来避免锁定,你也就把价值抽取出来。你最终被供应商“锁在门外”,这基本上意味着你无法充分享用服务的价值。抽象是不是将系统简化为一个通用接口不好说。如果真是如此,不清楚它如何利用差异化的提供商功能、保持与云无关。如果不是,不清楚它的价值是什么或者它如何做到真正多云。

别对PCF或Red Hat过于刁难,但由于各大云提供商继续拆分自己的平台、以更大众化的方式重新捆绑它们,这些多云平台的卖点开始减少。在Kubernetes和容器之前的时代,即平台即服务(PaaS)的全盛时期,提供商在讲令人信服的故事。现在,由于容器、Kubernetes、尤其是谷歌的GKE和GKE On-Prem(以及其他提供商的同类产品)这类系统日渐流行,这个故事越来越难有市场。值得关注的是,最近宣布的Knative是与Pivotal和Red Hat及其他公司密切合作开发而成的,此举似乎是为了借助Kubernetes的势头,从企业采用Serverless计算中获取一些价值。

讨论的近义词 讨论的近义词

但有人需要将这些多云平台作为一种服务来运行,但问题就出在这里。这个责任通常转移到了运维或共享服务团队,这个团队现在需要在多个云中运行,可能要与供应商签订服务合同。

部署多云需要多个云平台的专业知识。PaaS可能会替开发人员将这部分抽取出来,但转移到运维人员身上。而我们甚至还没有探讨认证多个平台在安全和合规方面带来的影响。对于现在刚迁移到云的一些公司而言,这会严重破坏现状。一旦我们识破了不切实际的营销噱头,就真正深入了解多云的意义。

一般而言,非战略性系统被供应商锁定给公司带来的风险很低。以数据库存储数据为例。无论是Amazon DynamoDB、Google Cloud>

本文版权声明本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请联系本站客服,一经查实,本站将立刻删除。

发表评论

热门推荐