前不久的Cloud Native World大会颇受关注，通信服务提供商（CSP）更是引人注目。来自沃达丰的Johanna Newman介绍了该公司的“云原生之旅”，给大家敲响了一些很常见陷阱的警钟，也带来了一些新的启示。

她描述了从虚拟化到云原生的发展过程。在看到敏捷开发过程被采用的速度有多快之后，许多人认为云原生驱动的转换也会同样迅速。大多数人认为云原生的好处是如此透明，那么迁移将是“非常简单的”。

众所周知，事实并非如此。虽然供应商能够交付一些云原生应用程序，但在确保应用程序级别的互操作性方面仍然存在问题。这意味着需要新的整合，会使得运营成本飙升。

Newman承认了“云就绪”和“云原生”之间的区别。在早期，许多人认为如果一个功能被虚拟化并可以使用OpenStack进行管理，那么这段旅程就结束了。

然而，很快就清楚了，将这些功能分解为容器化的微服务对于CSP快速部署功能、自动化管理、实现云所承诺的可伸缩性、灵活性和最重要的敏捷性至关重要。Newman表示从虚拟化到云计算的飞跃对于硬件和软件供应商来说太大了。

重新构建VNF以将其容器化并使其成为云原生的过程并不简单，传统的VNF供应商并没有以CSP希望看到的速度这样做。这是一个鸡和蛋的问题：如果没有网络可供部署，供应商不会花费大量的成本和精力来重新构建他们的软件；同样地，如果没有软件可以在CSP上运行，CSP也不会花费大量的成本和精力来部署新的云网络。当然，一些像Rakuten这样的新进入者已经能够云原生，这表明在合适的情况下，这个承诺是可以实现的。

Newman还讨论了集成挑战——当然，这些挑战并不是电信行业独有的，但在其复杂的多供应商环境中更为突出。在笔者担任云基础设施分析师期间，在一次又一次的调查中，当被问及加快采用云原生架构的最大障碍是什么时，CSP始终将集成列为最大的障碍。

Newman还讨论了Common NFVi Telco Taskforce（CNTT）的工作，该工作组负责开发一些供应商可以设计的参考架构。这些架构将有助于缓解集成挑战，更不用说VNF/CNF生命周期管理（LCM）和正在进行的运维。

沃达丰要求所有新的软件都是云原生的，称之为“云原生黄金法则”。这并不奇怪，因为许多CSP都有类似的策略。令人有点惊讶的是，软件即服务（SaaS）被视为使用电信功能的一种可行的替代方案。虽然提供SaaS服务的供应商本身可能不是云原生的（例如，它可能仍然依赖于硬件），但从沃达丰的角度来看，考虑到SaaS模式的较低运维和维护成本以及灵活性，它是一个不错的选择。

在笔者担任分析师期间，CSP是否会使用这种模型中的网络功能的问题尚未解决。因此，听说一家1级CSP认为这可能是一种可行的方法，对笔者来说很有趣。（需要说明的是：Newman并没有特别提到SaaS是一种使用网络功能的方式，而是更一般地说是一种实现云原生优势的方法。）

她指出，沃达丰的网络方面比公司的IT部门“更不成熟”，后者已经具备云原生能力，但只有在完全替代了现有系统的某些情况下，沃达丰才是真正的云原生公司。除了上面提到的重新构建VNFs的问题之外，标准也是一个值得关注的问题。由于电信市场对集成性和互操作性的要求，而大公司通常不需要遵守这些要求，因此标准在基础设施开发和管理中一直扮演着重要的角色。

虽然开源方法可以满足一些需求，但电信公司仍然需要需求标准。纽曼明确表示，沃达丰正在采取一种基于标准的方法来实现云原生转换。CNTT和电信基础设施项目（TIP）认识到对开源和标准的需求，并正在相应地开发解决方案。当一些人想知道为什么电信公司的发展速度不如他们的公有云同行快时，标准问题常常被忽视。笔者认为这是双方——开源和标准——都取得了进展，不再试图控制局面，而是合作朝着共同的目标努力。

与AT&T和Verizon等同行相比，沃达丰似乎对云原生转型采取了更为慎重和谨慎的态度。纽曼指出，这些公司与公有云提供商的合作关系，将其定性为“探索性的”，并表示沃达丰正饶有兴趣地观察他们可能想要复制什么。

笔者很好奇是否有证据表明沃达丰确实在考虑用SaaS模式使用CNF。显然，CSP网络改造没有唯一的正确的方法。

原文链接：

https://www.lightreading.com/cloud-native-nfv/vodafones-cloud-native-journey-a-mix-of-old-school-and-new/a/d-id/762163