去 Cloud-率先加速 WAN 转型

对于网络架构师和工程师来说， WAN 体验通常是通过电信运营商关系来看待的。 在许多情况下，这种经历不一定是积极的。 与电信运营商合作设计的过程 ENTerp上升 WAN 需要谈判合同和费率、配置和安装新电路、解决性能问题和中断以及管理服务级别协议（SLAs） 在现有基础上。 至少可以说，这一切都具有挑战性。 当您包括运营商必须维护才能交​​付的复杂对等关系时 全球连通性 事实上，在描述电信行业时，您不会立即想到“敏捷”一词，您可能会得出这样的结论：整体体验并不好。

Cloud-第一 WAN 架构
与上面定义的电信运营商关系不同， cloud-第一 WAN 经验改变了这种范式。 我们谈论的不仅仅是公众 clouds。 这是一种基于业务敏捷性、操作简单性和一致的多重体验的整体体验。cloud 部署。 它在完成所有这一切的同时，利用了 cloud 消费模式。

可以这样想：计算是从实体模型演变而来的。erp将拥有、运营和维护其本地数据中心的应用程序和基础设施提升为 cloud 消费模式。 同样， cloud-第一 WAN 经验将传统网络模型演变为网络消费模型，其中实体erp的崛起和网络提供商分担责任 WAN 应用程序和基础设施。

图 1：采用平台方法 cloud-第一 WAN

更重要的是，消费模型简化了服务交付，将其从需要大量培训的手动流程转变为许多人称之为“意图驱动”的自动化流程。

A cloud-第一 WAN 体验应该提供“即服务”消耗的可预测的端到端性能，这应该带来卓越的用户和应用程序体验。

Cloud-第一 WAN应该提高业务敏捷性。 在上市时间以分钟、小时和天来衡量的时代，组织需要 WAN 使用一个 cloud 消费模式，特别是基于运营支出的产品，具有灵活的计费和易于服务集成的特点。 正是这种新的网络消费模式推动了敏捷性，使 IT 和基础设施团队能够快速适应业务需求。 这包括快速变化的业务优先事项、集成的供应链和全球化需求。 Cloud-第一 WAN应该提供操作简单性，以最佳的托管服务为特色，使企业能够erp大大简化了复杂性。 这 cloud-第一 WAN 提出了对 WAN 通过提供技术的消费模式（SD-WAN）和托管服务。 真的，这就像两全其美。

Cloud-第一 WANs 应该提供一个多cloud-就绪架构，提供将任何应用程序带到任何地方的选择 cloud 通过连接公众 cloud 提供商、软件即服务（SaaS) 提供商和合作伙伴 clouds——在完成这一切的同时提供一致的用户体验。 正是这种能力才是 cloud- 首次提供服务。 它是一种具有可扩展性的产品，可以连接到任何基础设施即服务（IaaS）、平台即服务（PaaS），或 SaaS 任何地区的提供商只需付出很少的努力。 使用这种方法，IT 部门应该可以灵活地在任何地方部署任何应用程序，并且任何员工可以在任何地点、任何时间访问。

简而言之，您的 WAN 应提供与连接到 LAN 的用户体验相同的用户体验。

相对于 DIY 的优势 SD-WAN
在后多协议标签交换中（MPLS）世界中，IT 规划人员通常可以选择构建或使用其 WAN.

耳鼻喉科erp上升到 wan自己做所有事情通常都是从盒子供应商那里获取技术，然后增加安全性， cloud、优化和编排组件。

这种自己动手的方法并不像听起来那么简单，尤其是在我们看到专业知识存在巨大差距的时代。 结果，恩erp由于成本、复杂性或时间安排，上升常常会走到尽头。 事实上，高达 20% 的 DIY 部署以失败或无法完成而告终erp性能。

与 DIY 方法相关的一些挑战 SD-WAN 包括：

叉车升级
自己做 SD-WAN 推出通常涉及硬件更改、库存管理、版本控制、补丁问题等。 即使当 SD-WAN 是作为软件升级完成的，当额外的硬件升级时，旧硬件的性能会下降 SD-WAN 功能混合在一起，这可能会导致 技术债务, 搁浅的资产 以及购买升级硬件的需要。

安保行业
跨边缘实施一致的安全性 cloud （例如，提供加密所有流量的能力）可能很困难，因为所有的移动部件。

SLAs
SLAs 它们只有被定义、理解和执行才有效。 大多数供应商无法保证端到端 SLA 因为他们在服务交付价值链中没有拥有足够的组件。 正因为如此，传统 SD-WAN 盒子供应商无法保证网络 SLAs。 对于全球部署或涉及最后一英里电路时，情况可能会变得更加复杂。 大多数供应商提供的报价令人费解 SLAs 而且，由于他们无法端到端地控制它们，因此实际上无法提供服务正常运行时间。 因此，他们提供的后端信用具有复杂的计算，这不能充分反映失败的业务影响 SLA.

Cloud 敏捷
数字耳鼻喉科erp崛起需要敏捷的环境。 引进新 cloud 应用程序、踢出或迁移遗留应用程序以及开设和关闭分支机构和卫星办事处都需要对 WAN.

部署时间

与多个最后一英里和中间一英里服务提供商的设备交付周期、配置、测试和合同修改可能会严重延迟部署。

应用程序性能缓慢
缺乏直接入口匝道 cloud 服务提供商可以显着减少 cloud 应用性能。 波动的延迟和数据丢失可能会影响实时、低延迟的应用程序，例如 UCaaS。 缺乏内置 WAN 优化或应用程序加速技术也会降低用户体验。

叠加问题
当底层的功能配置（MPLS）之前 SD-WAN 必须重新配置以适应某些人创建的覆盖 SD-WANs。 这会导致损坏 QoS、路由和其他相关问题。

更重要的是，端到端的控制减少了。 SLAs 由于覆盖层和底层的可见性是分开的，因此可以跨越 DIY 全局骨干网。 因此，关联故障以及在覆盖层和底层之间提供最小关联甚至没有关联变得更加困难。

复杂的操作和多重概念验证 (POC)
建立一个 WAN 需要与多个原始设备制造商 (OEM) 和服务提供商签订合同。 这可能会导致复杂性增加。 问题解决通常涉及多个 POC 以及用于第一英里和中英里连接的单独联系人列表。 这种方法不符合 cloud 的消费模式 CIOs更喜欢他们的应用程序。

相对于服务提供商的优势
除了自己动手的方法 WANs，有些人选择消费 WAN 来自服务提供商。 然后，提供商从盒子供应商处获取技术。 不幸的是，由于服务提供商和技术供应商之间存在所有移动部件，这并不能带来真正的无缝体验。 提供商的底层网络和运营商之间可能会出现问题 SD-WAN 技术供应商的覆盖。 采用服务提供商方法面临的挑战包括：

最后一英里锁定
运营商喜欢将客户锁定在最后一英里的解决方案中，而不是让他们选择市场上的最佳选择。 最后一英里服务有可能造成糟糕的整体用户体验，并削弱企业的敏捷性。 SD-WAN 的方法。

缓慢推出
与 OEM 签订的合同中的设备交付周期、配置、测试和修改可能会出现延迟。

不好 cloud 托管
运营商并不总是与 cloud 服务提供商，例如 Amazon Web Services (AWS)、Microsoft Azure 或 Google Cloud。 这使得确保 cloud 应用程序性能和优化的区域连接。

不敏捷
正如我们之前提到的，数字化实体erpRise 在需要敏捷性的环境中运行。 需要更改的事件 WAN 包括推出新产品 cloud 应用程序、删除或迁移遗留应用程序以及打开和关闭分支机构和远程位置。 遗产 WAN我们无法跟上快速变化的步伐。

安保行业
提供商可能未与企业首选的安全供应商合作erp上升。 提供商也可能没有给定安全供应商的第一手经验和深入支持。

不符 SLAs

运营商在特定的服务区域内运营，例如单个国家或地区。 对于国际连接，与多个服务提供商进行对等安排，这使得难以保证端到端 SLAs。 因此，所提供的服务只能与众多提供商之间的最小公分母一样好。

不灵活的定价
运营商网络通常涉及多个服务提供商之间的协议。 这导致了一种旨在补偿价值链中每个人的定价模式，这使得它们变得不灵活且昂贵。

净推荐值低（NPS)
调查普遍对运营商评价不佳 NPS 调查。 他们的低分是由于众多的挑战：成为消费者而不是技术的创造者； 对各种原始设备制造商的依赖； 需要复杂的运营商间协议； 保护遗留投资的任务 MPLS; 以及将客户锁定在第一英里和最后一英里产品等方面的趋势。

创作者与消费者
SD-WAN 不是单盒即插即用解决方案。 综合的 SD-WAN 解决方案需要各个元素之间的相互作用。 由于运营商是消费者而不是技术的创造者，因此他们提供一流服务的能力受到限制。

图 2：DIY 比较 SD-WAN、MSP/电信公司，以及 Cloud-第一 WAN 途径

评估平台方法
回顾一下，传统 SD-WAN 供应商采取以盒子为中心的观点，对端到端的全球体验几乎不负责，而传统服务提供商只是将多个供应商的技术产品拼凑在一起，最终会损害他们提供无缝体验的能力。

最合乎逻辑的前进道路是评估一种平台方法，该方法能够利用可扩展且端到端的统一服务架构。 该平台需要提供复杂的服务来实现连接套件， cloud、安全和优化服务。 具体来说，这些服务部署在 SaaS 面向所有客户的模型，并且可以轻松增强。

无论是区域部署还是全球部署，采用平台方法还应该利用编排引擎，为端到端部署或第一英里、中间和最后一英里提供可见性和控制。 你可以拥有世界上最好的硬件，但如果 SD-WAN 以零碎的运营模式提供成果。

总之，端到端责任消除了与 DIY 相关的问题以及与无法控制自己的端到端运营商合作的问题 WAN 技术。

这篇文章最初发表于 pipelinepub.com