长期以来，DriveNets一直支持一个容器化的软件框架，它被托管在一个由白盒设备组成的集群中。实际上，这是一个属于自己的小云，该公司甚至称其为 "网络云"。他们还支持控制平面分离，这个架构可以用来将IP控制平面直接与CDN、5G甚至物联网等事物绑定。总之，网络云的概念有很大的潜力，现在他们可能刚刚开始这样做。
DriveNets不是没有说过他们的架构会支持第三方元素；他们在最近发布的题为《NCNF：从 "云上网络 "到 "网络云"。网络虚拟化的演变"。他们想说的是，对运营商来说，功能托管的概念已经从特定于虚拟机（最初的NFV虚拟网络功能模型）发展到通过使用容器而更具有云效率。最终的目标是什么？在DriveNets的网络云中托管容器。
NFV及其VNF仅仅通过在容器中运行就能成为云原生的概念当然有很多问题，"云原生网络功能 "作为VNFs的继承者的概念应该被命名为 "容器化网络功能"，因为无论你怎么称呼它们，这个倡议都不可能创造真正的云原生元素。NFV的管理和协调方法有太多的包袱，NFV ISG的CNF工作没有解决关于使用容器或虚拟机来托管服务功能/特性的三个大问题。
大问题一是单靠容器是否真的能提供云原生行为的好处。一个应用程序不是因为你在容器中运行它而无状态的，它是无状态的，因为它被写成了无状态，而且无论它是如何被托管的，它都会有这个属性。就状态而言，容器属于无状态和有状态之间的一种灰色地带。一方面，容器应该是可重新部署的，这是在无状态设计中寻求的属性。另一方面，容器并不强制执行这一点，它们只是假装该属性存在。在大多数商业应用中，这已经很好了，因为容器化的应用可以从失败和重新部署中恢复。在基于事件的应用中，比如网络中的几乎所有东西，这还远远不够。
大问题二是容器的模式是否适合虚拟功能。很多关于容器与虚拟机的讨论都集中在一台服务器可以支持的每个数量上（容器胜出是因为操作系统没有为每个重复，而每个虚拟机看起来像裸机）。应该更多地关注这样一个事实，即容器系统都是在软件组织阶段解决配置的可变性和依赖性，而不是在部署时手动（或用DevOps工具）解决。
我们的最后一个大问题是，容器或任何云托管策略是否能够满足许多基于托管功能的应用程序的延迟要求。例如，O-RAN有近实时和非实时的RAN智能控制器，其描述使它们听起来包括某种形式的协调，这是容器系统用于部署和重新部署的东西。以一种任意的方式在云上传播对延迟敏感的东西，延迟的积累是不可避免的。
那么，DriveNets是如何解决这些大问题的？
首先，DriveNets的模型是一个集群云，目的是在其内部部署服务功能，那里的延迟很低，而且有可用的一般计算和网络处理器资产的混合物。虽然这没有提供云计算所特有的广泛的资源池，但正如问题三所指出的那样，大的资源池可能被浪费在那些延迟问题决定了要把东西部署在彼此之间的应用上。DriveNets显然解决了问题三。
下一点是，DriveNets使用了容器模型，但不是标准的容器编排，看来DriveNets的编排器（DNOS）对应用程序的约束使它们以更有序的云原生兼容的方式行事。然而，我们必须认识到，标准的的VNF/CNFs在DriveNets中要么表现得同样糟糕，要么就不会运行。这并不是对他们方法的批评；你不可能真的将物理网络功能，即网络设备内的代码，在不重新编码的情况下转换为最佳的云原生实现。只是我们不能说DriveNets解决了CNF的问题；它提供了另一种模式，如果遵循该模式，就能避免这些问题，但我们没有该模式的细节，所以我们无法判断按照该模式开发是否实用。在问题一和问题二上，我们都不能给DriveNets肯定。
不过，对我来说，这些问题对DriveNets的愿望并不像另一个问题那样重要，这个问题与整个PNF/VNF/CNF进化的争论无关。这个问题就是在网络云内设立第三方 "NCNF "的好处。这个问题的正确答案可以完全验证NCNF的方法，但同样，我们无法从材料中坚定地回答这个问题。