尽管丹麦乃至整个欧洲，以及亚马逊都对一些事情保持着沉默，但是似乎有迹象显示他们遇到了一次黑客攻击或是一次成功的拒绝服务攻击。我是在2019年10月知道的，Google自动完成功能也会提示“AWS DDoS攻击”。这些事情实际上会经常发生。

拒绝服务攻击的历史是否与互联网的历史一样悠久我们不得而知，因为数据中心运营商或托管服务提供商缺乏坦率的态度。过去，我们是通过防止整个网络被瘫痪来保护我们自己，如今我们依然需要保护我们自己，但是方法变成了使用由不同运营商运行的多个数据中心，即多云。

多云战略以在多个服务提供商的云端上展开部署（或是保持能够在多个服务提供商的云端上进行的能力）为开端。这意味着用户要将软件保留在AWS和Azure上，甚至可能保留在GCP上。用户需要放弃使用任何可能会阻碍自己进行转移的提供商服务，追求允许进行跨数据中心扩展的数据架构。

单一云的优缺点

依托单个服务提供商的云，用户可以享受云提供商提供的服务，有时候这服务的成本很低。通常，用户可以无缝地添加这些服务。也就是说，如果用户是AWS客户，那么他们可以使用Amazon Elasticsearch Service，而不用构建自己的搜索集群。如果用户使用的是Google，那么他们可以使用库Google Cloud Datastore文档数据，而不用自己动手部署。

但是，与所有服务提供商平台策略一样，这些也是有代价的，即用户的自由。这听起来很沉重，但是请听我说完。当然，用户的云服务提供商现在正变得更加便宜，但是情况会一直如此吗？此外，随着云服务提供商转变战略，价格上的优惠是否有一天会被无理地取消？他们甚至可能永远不会真正宣布这一消息。如果用户所在地区的AWS数据中心长时间停机，变慢或变得不可靠怎么办？用户能够承受损失吗？

在这些服务提供商提供的服务中，某些服务（尤其是亚马逊的服务）是一些著名开源替代产品的分支，它们应该维护API兼容性。此外，有些还是著名的发行版本。对于缓慢升级的大型企业来说，通常情况下是没有问题的。但是“通常情况”并不意味着没有特殊情况。

如果情况需要，即便是规模更大的企业也必须迅速采取行动。如果当前版本中存在无法修复的重大安全漏洞，那么用户要进行转移。如果下一版本中有某些功能是大规模扩展所必需的（而用户也正需要），亦或是用户自己的下一个版本需要某些其他功能，那么云服务提供商的发展规划势必会导致用户落后于形势变化。

在使用云服务提供商的服务时，有一个问题很重要，那就是思考一下每个运营者或脚本作者“他们的动机是什么？”当然，他们可能希望在其IaaS产品之上获得30％的额外加价，但是更有可能的是，他们希望将用户留在自己的平台上，并获得用户计算支出中的每一分钱。

尽管云服务提供商已经变得越来越可靠，但是他们还没有变得百分之百的可靠。每年会发生多个区域性，甚至是多区域服务中断。有些中断还会持续较长一段时间。如果用户不能将代码安装到其他地方（更好的作法是，将其作为流程的一部分存储在其中），那么当灾难来临时（确实会发生），用户将束手无策。

最后，在进行价格谈判时，如果用户得知自己已经离不开某一云服务提供商，那么用户还会认为云服务提供商具有很高的灵活性吗？

多云的优缺点

多云策略不仅需要服务提供商保持中立，还需要更具弹性的架构选择。这意味着更多的前期复杂性，也意味着用户要与多家服务提供商进行谈判。同时这还意味着要确保谈判时能够综合考虑到现有技术和当前的安全性。

但是，与使用单个云服务提供商相比，多云策略为用户提供了更多的自由和安全性。我们在平台大战期间学到了这一点，许多企业会先在大型机上进行标准化，然后在DEC、HP和Sun上进行标准化，然后再尝试在Windows NT上进行标准化。

单一的云服务提供商平台常常无法兑现他们的承诺。请记住，在20世纪90年代甚至21世纪初期，Microsoft的技术往往集成性良好但并不成熟。然而情况很快就迅速发生了变化。经验丰富的开发人员想起了数据访问技术、DAO、RDO、OleDB和ADO（它们都已被陆续发布并被提倡使用）。更不要提.NET过渡和发生的错误营销了（即Windows.NET）。不仅仅是微软。我的职业生涯开端是编写OS/2设备驱动程序。后来IBM又发布了Warp 4，然而如今它们都已经不再被使用了。

尽管平台独立性会带来前期成本，但是追求平台独立性的公司往往会有更具弹性的架构。这些公司在应用程序之间采用标准接口。他们会为使用的用例选择最合适的技术，而不是选择平台所推动的任何技术。最重要的是，当服务提供商被证明是不可靠的合作伙伴（或抬高价格）时，平台独立的公司可以自由退出。

多云策略的最低要求

多云策略中最重要的一点是依靠开放标准和行业标准作为关键接触点。以下是其中的一些重点：

·Kubernetes。这一开源容器管理平台目前已经成为了部署服务的行业标准。如果用户要创建在笔记本电脑上运行的标准Kubernetes部署，那么它们应在多个云服务提供商上运行。

·开源。用户的核心架构要使用开源工具和技术。这样可以确保在平台策略发生调整时，用户可以选择其他路径。

·开放标准。这并不是说用户需要参与到应用程序服务器集群当中，而是指与其他软件的所有接触点都应遵循开放且服务提供商中立的行业标准（例如JSON）。

·注意品牌服务。如果用户需要固定IP和各种DNS服务，那么用户可以选择亚马逊推出的一些常用网络工具。虽然用户不需要运行自己的分布式DNS，但是他们必须要使用提供商提供的固定IP的方法。不过这并不意味着用户面临着厂商锁定，因为它们只是配置，并且在Azure和GCP上的工作方式是相同的。但是在使用机器学习服务时，用户应该保持谨慎的态度。

最后，“那就放手做吧！”除了让服务在两个或更多的云端上运行之外，没有其他方法可以确保用户能够快速实现转移。即使出于各种成本或会计原因而选择主要是将流量引导至一个云端，那么用户也应该在另一云服务提供商的云端上拥有备用数据库和文本。当发生不可避免的服务中断或服务提供商因财务原因而倒闭时，用户可以实现迅速转移。

作者：Andrew C. Oliver为开源NoSQL数据库产品提供商Couchbase的产品营销主管兼布道师。

编译：陈琳华

原文网址：https://www.infoworld.com/article/3529476/cloud-outages-show-multicloud-is-essential.html

责任编辑：周星如