网络是由一组设备组成的，它使用一个网络管理系统以确保网络的互联性，而服务管理系统则为其增加了必要的“服务至网络”意识。
这是一个伟大的模式——这一模式已历经数十年而不衰——但是，由于虚拟化的出现，这一模式也开始变得过时了。
基于抽象和实例化，虚拟化也拥有它自身的管理模式。从希望部署的抽象服务或设备开始入手——可能是一个路由器或者一组路由器，也可能是一个基于一组路由器而开发的VPN服务。然后，就可以部署那些抽象的虚拟资源——计算能力、应用程序、数据存储、虚拟连接等等，总之不管是什么吧——来实现它。即便是使用最简单的描述，虚拟化的两个事实也是越来越明显的。首先一点，虚拟化应跳过服务和资源之间所有的低层次步骤，这就意味着通常在这个阶段都要跳过所有那些看上去很美的管理程序。但是，如果虚拟网络能够让云计算供应商通过直接操作虚拟设备而新建虚拟网络服务，那么我们就有理由认为，虚拟设备并不知道关于他们整体服务属性的任何信息，同样它们也不知道它们之间的相互关系。迷失在这样的管理环境中——也就是说将一个服务的各个部分与服务整体相联系的能力，反之亦然。
因此，虚拟网络管理要求供应商保留一个当服务创建时所建立关系的记录，这样一来，他们就能够在以后必要的时候执行恢复管理环境的操作。这是非常重要的一个步骤，但却几乎总是在云计算网络实施中被忽略，即通常只是开发服务，而软件叠加与网络设备并不存在任何特殊的链接。你可以使用这种方法开发出最佳服务，但它却不是基于SLA、合同承诺的托管服务。
关于虚拟化的第二个发现就是，虚拟化创建的抽象资源是不同于它们的物理资源的。不必使用真实的物理设备开发虚拟交换机、路由器或防火墙;相反，你可以使用托管的、基于软件的功能。这就使管理条线变得更为复杂了。例如，一个虚拟防火墙可能实际上是由若干托管进程以及一对网络连接组成的。如果这个防火墙是一个物理设备，那么我们就可以发送一个用于读取其管理信息库(MIB)的SNMP命令，以便于检查防火墙的状态。但是，由于在我们的虚拟网络服务中并不存在任何的物理防火墙组件，因此也就没有可供读取的MIB。即便每个组件都存在一个MIB，那MIB数据又是如何与虚拟防火墙功能相关联的呢?我们还必须考虑组件之间网络连接的状态，因为在物理世界中连接性是根本不存在的。
除了上述两个与虚拟网络管理相关的战略问题以外，还有一个很现实的问题。请设想以下的应用场景，在几个不同的数据中心中有几十台物理服务器上运行着虚拟机，而数据中心之间只是通过主干光纤相连。现在，则可以想象一下，虚拟网络服务是如何跨这个复杂平台进行工作的。可能有一千个客户和两千个服务，以及十二台服务器和一个跨数据中心的链接。为了发现任意一个服务的状态，我们就必须检查该服务所使用的资源的管理接口，从而导致成千上万的服务向有限的资源发出这样的服务请求。这就对网络流量管理提出了极高的要求，单单为响应管理请求就会对资源造成了极大的应用负载压力。
针对虚拟网络服务而新兴的管理模式
整个行业还没有对虚拟管理给出全部的答案，但是我们已经在管理模式的定义和管理流量的控制方面取得了一些进展。这两方面都随着虚拟管理经验的增长而将逐渐得到完善。
在管理模式方面，我们看到了两个方向的发展趋势。一个就是虚拟设备模式，其软件定义或虚拟网络功能包括了一个可代表它们所创建的虚拟设备的管理组件。你可以在无论哪个最方便的功能集合中进行管理组件开发，这一模式为创建基于方便管理而不是严格功能性的虚拟设备提供了潜力。
另一种模式就是服务驱动的运行模式，其功能集合都是为创建服务而定义的。例如，云计算供应商使用TM论坛的信息构架(SID)GB922 服务域模式就可以在他们定义服务组合的同时给出管理关系的定义。因此，一个泛化的过程能够在任意一点提供一个管理试图——从而完全地消除了每个服务的管理单元。
尽管市场上对目前的OSS/BSS系统是否不适合新的基于虚拟化的服务还存有疑虑，但是运营商们在很大程度上是继续发展这些系统而不是取代它们也非常说明问题。统一数据模式和衍生服务运行模式的组合似乎与运营商们在虚拟服务管理上的未来目标是相当一致的，同时它还保留了与目前OSS/BSS软件和实践的联系。事实上，运营商们希望这些组合能够适合TM论坛和他们自己OSS/BSS系统的发展，从而为运营商迎来一个全新的、云计算驱动的、基于虚拟化的美好未来。
