艾锑人带您了解企业IT如何避免云服务锁定

云计算提供商的网络性能有哪些不同

每个云计算提供商的网络连接方式各不相同，这会导致网络性能和可预测性方面的地理差异。随着越来越多的企业考虑将业务迁移到云平台，尤其是软件定义广域网(SD-WAN)和多云，了解每个公共云服务提供商提供的服务以及如何进行比较至关重要。

ThousandEyes公司在2018年进行了一项基准研究，对全球三个主要的公共云提供商：亚马逊网络服务(AWS)、微软Azure(Azure)和谷歌云平台(GCP)的服务进行了评估。该研究收集了有关网络性能和连接架构的数据，以指导用户在规划阶段的工作。

2019年的研究提供了一个更全面的视角，在其研究名单上又增加了两个云计算提供商：阿云和IBM云。研究报告比较了2018年和2019年的调查数据，显示了每年发生的变化以及引发这些变化的原因。

ThousandEyes公司在四周的时间内，定期从使用这五个公共云提供商的全球数据中心的98个用户位置收集双向网络性能指标，例如网络延迟、数据包丢失以及抖动。此外，还研究了美国领先的宽带互联网服务提供商(ISP)的网络性能，其中包括AT&T、Verizon、Comcast、CenturyLink、Cox和Charter。

然后，该公司分析了超过3.2亿个数据点，以创建评估基准。

提供商之间的网络服务并不一致

ThousandEyes公司在最初的研究中发现，一些云计算提供商十分依赖公共互联网来承载用户流量，而其他云计算提供商则不是这样。在2019年的研究中，云计算提供商在双向网络延迟方面总体上表现出相似的性能。

但是，ThousandEyes公司发现网络架构和连接性差异对流量在用户与某些云计算托管区域之间的传输方式有着很大影响。AWS和阿里巴巴主要依靠全球互联网来传输用户流量。微软Azure和谷歌云平台使用其专用骨干网。IBM公司与其他公司不同，采用二者混合的方法。

ThousandEyes公司检验了AWS Global Accelerator是否优于全球互联网的理论。AWS Global Accelerator于2018年11月推出，该服务采用的不是默认的全球互联网，而提供使用AWS专用骨干网，并向用户收费。尽管其在全球某些地区的网络性能确实有所提高，但在其他情况下，全球互联网比AWS Global Accelerator更快、更可靠。

即使在成熟的美国市场，企业用来连接每一个云计算提供商的宽带网络服务提供商(ISP)的服务也并不一致。在对6个美国网络服务提供商(ISP)的网络性能进行评估后，记录了次优的路由结果，在某些情况下，其网络延迟是预期的10倍。

地点至关重要

云计算提供商的服务在穿越一些国家的过滤防火墙时，通常都会遇到丢包的情况。该公司在2019年的研究中，仔细检查了云计算服务提供商在一些国家的运营费用，这对在线企业而言是极具挑战性的地理位置。

在世界其他地区，拉丁美洲和亚洲表现出所有云计算提供商最大的性能差异。例如，由于反向路径不太理想，谷歌云平台的托管区域从里约热内卢到圣保罗的网络延迟是其他五家云计算提供商的六倍。但是在北美和西欧，所有五家云计算提供商均展现了强大网络性能。

这项研究的结果证明，地点是主要因素，因此，企业在选择公共云提供商时应考虑用户到主机区域的性能数据。

多云连接

在2018年的研究中，ThousandEyes公司发现AWS、谷歌云平台、Azure的骨干网络之间的广泛连接。在2019年的研究中还有一个有趣的发现，在将IBM公司和阿里云添加到调查列表中时，多云连接变得不稳定。

ThousandEyes公司发现IBM公司和阿里云尚未与其他提供商完全建立直接连接。那是因为他们通常使用网络服务提供商(ISP)将其云平台连接到其他提供商。另一方面，AWS、Azure和谷歌云平台可以直接相互对等连接，并且不需要第三方网络服务提供商(ISP)的服务进行多云通信。

随着多云计划的兴起，在评估多云连接性时，应将网络性能作为一项衡量标准，因为它似乎在云计算提供商和地理边界之间不一致。

ThousandEyes公司的综合性能基准可以作为企业确定哪个公共云提供商最能满足其需求的指南。但还是需要谨慎，选择公共云连接的用户应该考虑全球互联网的不可预测性、如何影响性能、面临的风险，以及运营复杂性。用户应通过个案收集自己的网络情报来应对这些挑战。只有这样，他们才能从云计算提供商所提供的内容中充分受益

艾锑人带您了解企业IT如何避免云服务锁定

IT管理人员频繁地使用云服务，以此作为摆脱厂商锁定的一种方式。企业要结束对某个厂商的依赖源于其降低成本的需要，以商品驱动的方法获取基础设施服务将是实现上述目标的一种途径。企业的态度不难归咎于厂商昂贵的费用，因为厂商通常按照年度基准提出大额发票，并且几乎没有谈判的余地。然而厂商为何要谈判？企业用户已经依赖于厂商的单源技术。似乎通过创建一个竞争的环境使企业摆脱对单源技术的依赖是一种合理的方式。
在企业的IT生命周期中有两个里程碑是厂商必须要参与竞争的：实施前技术选择(厂商锁定建立于此)，以及实施后购买。
诸如服务器硬件这样的组件在市场中是标准化的，然而像内容管理系统(CMS)这样的关键组件又是高度分化的，导致用户只能选择单一厂商的服务。在此过程中并不是所有的决定都依赖于厂商，但是这些厂商仍然起主导作用。操作系统和编程语言的选择并不依赖于特定厂商，但是他们会限制未来的选择。
开始于项目初始阶段的厂商锁定成为不了企业的痛点，直到你进入IT生命周期的采购阶段。企业很快发现他们的主要成本动因是非商品化部分，而那些单源技术厂商此刻占据了符合他们谈判利益的最佳形势。
在服务的后期，上述困难将会变得尤其突出，当巨大的生产收益记忆消退时，企业将只留下对成本的担忧。雪上加霜的是，商品化部分的成本随着时间推移往往伴随着摩尔定律不断降低，同时随着其他可成倍改进的技术，如网络技术和存储技术的发展，迫使这些商品化组件在企业当前的成本模型中占据更小的比重，这一切都使企业更加关注单源厂商的作用。
最直接的做法是向厂商要求结束依赖。但这样做并不能解决所有问题，不要忘记这条原则——相关并不意味着因果。很多企业似乎拥有相关的组织结构来进行针对系统组件的不完备的成本价值分析。供应商管理只能被迫专注于降低成本，但即便如此也不一定能够通过整体迁移以及单源组件扩展估算出相关价值。
在实施过程中可以选择这种组件以期最大化系统价值。但是在项目开始阶段适用的方案在整个项目生命周期中可能并不总是奏效，这就是分析结论一团糟的原因。组件的成本必须经由组件迁移的价值来担保。在此分析下会出现下述两种情况之一——如果组件还有价值，企业就应该支付订单；如果没有，就更换组件。但后者是昂贵的，并且需要大量的评估工作。为了证明能够以降低成本的努力开始一个大型项目，就需要增加新的价值，而这也增加了项目的复杂性和成本。
然而，原有的服务体系是否架构了允许企业在无需重构整个实施框架的基础上替换某一组件的机制，以便企业实现后期的成本降低。最后，厂商锁定是一个实施问题。多年来许多架构模式(如n层客户端/服务器模型，面向服务模型，松散耦合模型等)都允许企业替换组件，但是由于缺乏体系性的远见和严密性，这个领域取得的突破很有限。
这些问题把我们带回到云计算中。当然，云计算提供了一种能够更加高效地迁移一体化技术的方式，比如电子邮件技术。但这其中仍然有很大程度的厂商锁定问题，因为从一个软件即服务(SaaS)厂商迁移到另一个SaaS厂商是一项巨大的工程。另一方面，试图使用基础设施即服务(IaaS)来解除对厂商的依赖将会导致令人失望的投资回报率。
换句话说，把一堆乱七八糟的东西从你的数据中心内迁移到云计算中心并不能使你从厂商锁定中解脱出来，反而会使你陷入更多的厂商锁定问题中。从厂商的专政中解脱的唯一方法是专注于敏捷架构，即在项目生命周期中支持技术的不断更新。