Para hacer realidad la Tercera Red, los proveedores de servicios de comunicaciones (CSP) necesitan aumentar su agilidad mediante la adopción de nuevas estrategias de negocio, procesos y tecnologías. De lo contrario, seguirán luchando contra la marea creciente de la competencia originada en la nube y proveedores OTT.
Durante este proceso es necesario tener un enfoque táctico. A menudo, los proveedores Cloud se basan en una o más plataformas para crear aplicaciones únicas que sus clientes perciben como simples servicios. Imitando este éxito, los CSP se beneficiarían al proyectar los servicios de red como aplicaciones que ofrecen al cliente una experiencia de marca, aunque utilizando en su infraestructura, en gran medida, plataformas abiertas. Impulsado por el MEF, la orquestación de servicios del ciclo de vida (LSO) ha emergido como una visión operativa crítica, que debería contribuir a definir estrategias de proveedor de plataforma abierta. Los líderes tendrán que fomentar un ecosistema de software abierto y ayudar a guiar la formación de una nueva cadena de valor, diseñando a la vez nuevas aplicaciones para aprovechar las plataformas clave.
Históricamente, los proveedores de servicios se han basado en gran medida en estándares formales para fomentar un ecosistema robusto. Los estándares han funcionado relativamente bien para la cadena de valor de hardware, desde los semiconductores a las arquitecturas de redes móviles, y han permitido a la mayoría de los proveedores elaborar redes multi-proveedor. Sin embargo, el inconveniente de los estándares son los prolongados plazos de entrega y una propensión a aumentar los costos inyectando requisitos que se desvían de los productos genéricos que sirven a un mercado más amplio. En la actualidad, las compañías se esfuerzan por mejorar la agilidad de su hardware con SDN y NFV – mediante la abstracción de software y virtualización para crear una infraestructura más flexible y dinámica.
A su vez, estas dos nuevas técnicas trasladan la complejidad al ámbito del software. Por su propia naturaleza, el software evoluciona rápidamente, reorganizando elementos internos para agregar nuevas características sobre la marcha. La buena ingeniería de software se basa en arquitecturas cuidadosamente estructuradas y organizadas en capas para manejar la complejidad. Al evitar los plazos de adopción de estándares – que contrastan con las ventajas que da la agilidad al innovar software – los operadores Cloud han sobresalido en el desarrollo de servicios innovadores, ya sea al basarlos en plataformas de software abierto o abriendo sus plataformas internas existentes.
Los operadores Cloud evitan la estandarización minuciosa. En lugar de ello, identifican funciones comunes, que utilizan como bloques de construcción para varias aplicaciones, encapsulándolas, y dándoles forma de API. Entonces, estas funciones pueden ser reutilizadas, combinadas, y anidadas para crear soluciones innovadoras. Aunque de ninguna manera constituye un ejemplo único, el ecosistema móvil Android probablemente sea el ejemplo más simple para el público general. Google ofrece el sistema operativo Android como una plataforma abierta, con APIs abiertas que habilitan funciones, incluidas aquellas funciones que dependen de hardware subyacente multi-proveedor. Para usted, y para su app de mensajería, es irrelevante quién fabricó la cámara de su teléfono, por lo que la plataforma Android permite la captura e intercambio de imágenes digitales a través de las API. Por tratarse de una plataforma, Android unifica todas las funciones del teléfono, evitando silos de información innecesarios.
Con un poco de imaginación, podemos establecer un paralelismo entre el ecosistema móvil Android y el ecosistema LSO. El MEF ha definido LSO como la orquestación de la gestión de servicios, junto con la gestión empresarial del servicio como un producto, incluyendo pedidos, facturación, y las relaciones con múltiples operadores.
La visión del MEF sobre LSO no restringe la implementación. Por lo tanto, somos libres para modelar el ecosistema LSO al estilo del ecosistema Android, como se muestra en la ilustración. La partición simplemente separa la “orquestación de servicios” de la “orquestación de ciclos de vida”. Al igual que la plataforma Android, una plataforma abierta de orquestación de servicios permitiría que “apps” de orquestación de ciclos de vida implementen transacciones comerciales automatizadas para agilizar las transacciones manuales que actualmente limitan la agilidad del negocio. La orquestación del ciclo de vida puede desarrollarse en sus propias plataformas, según proceda, pero un modelo de tipo apps permite la innovación y la diversidad.
En esta arquitectura, la plataforma de orquestación de servicios debe proporcionar APIs abiertas que permitan a diversas apps de ciclos de vida el acceso a la gestión de servicios neutrales; es decir, no vinculados a proveedores específicos. Los servicios de red, incluidos los servicios del MEF, son definidos por parámetros de flujo de tráfico que deben cumplirse a través del plano de datos de extremo a extremo – incluyendo elementos físicos y virtuales. Todas las funciones de orquestación de servicios, incluyendo el aprovisionamiento de servicios, su activación, y las garantías, se basan en la interacción con el plano de datos. El plano de datos CSP de hoy consta de equipos de múltiples proveedores. Los futuros equipos de redes podrán ser más abiertos, pero como un tema práctico, la inversión en esta infraestructura existente debería ser protegida. A menudo, los CSP utilizan sistemas de gestión de redes de múltiples proveedores (NMS) para federar estos sistemas. La plataforma de orquestación de servicios probablemente asumirá el papel de esta capa NMS, junto con sus funciones de gestión de servicios. En cualquier caso, el uso de una plataforma basada en APIs abiertos proporcionará una interfaz común independiente de la diversidad de los equipos subyacentes.
Esta arquitectura permite la optimización en paralelo de la experiencia del cliente y operaciones de red. Con la innovación de las apps de ciclo de vida, los CSP serán capaces de diferenciar su marca y la experiencia del cliente a través de interfaces sintonizadas, aunque conservando la eficacia operativa de una plataforma unificada. Por ejemplo, una app para pedidos, altamente flexible y preferida por un cliente corporativo multinacional, podría ser dramáticamente diferente de una app básica para pedidos de un cliente Pyme; aunque cada una se basa en la plataforma de orquestación de servicios para cumplir con los pedidos en las redes específicas del caso.
Este ejercicio esboza una dirección que podría tomar la implementación de LSO. Independientemente de la implementación, el uso de plataformas abiertas fortalecerá el ecosistema LSO y mejorará la agilidad del CSP. Por lo tanto, los CSP deben evaluar plataformas abiertas en la medida que van adoptando la visión LSO o la orquestación de otros servicios.
Por Prabhu Ramachandran, Director de WebNMS
