La evaluación de una solución tecnológica siempre implica dos aspectos principales: el técnico y el comercial.
Mientras que en el aspecto técnico la comparación entre varias alternativas suele ser sencilla en función de las especificaciones y capacidades de cada solución, el aspecto comercial requiere una perspectiva más amplia, que abarque todos los costos y beneficios vinculados con cada solución. Dicha perspectiva debe tener en cuenta no sólo los costos directos de la solución, sino también los indirectos y crear un análisis del Costo Total de Propiedad (TCO – Total Cost of Ownership, por sus siglas en Inglés).
El análisis del TCO cubre el costo de la solución y otros costos, como por ejemplo, los inmobiliarios —superficie útil o espacio de racks— energía, aire acondicionado, mano de obra, integración con la infraestructura existente, cursos de instrucción y muchos otros costos derivados, que normalmente no se pagan al proveedor de la solución, por lo que se trata de costos indirectos.
Este tipo de análisis requiere una inversión importante, ya que exige conocer los detalles técnicos de cada solución, junto con una revisión detallada de la estructura global de costos del operador.
Otro método para evaluar los costos de cada alternativa es el Costo por Puerto. Se puede ver en este método una referencia «rápida e informal», que sólo tiene en cuenta el componente básico principal de una arquitectura —por ejemplo, un puerto de 100 GbE— que asume una dependencia lineal entre el costo global y la cantidad de puertos en cada configuración. Suele incluir solo costos directos y es una herramienta muy práctica para comparar soluciones alternativas.
Tanto el TCO como el costo por puerto incluyen defectos inherentes, que se agudizan al comparar dos tipos distintos de soluciones tecnológicas con los mismos requisitos. Esto ocurre al comparar una solución de red monolítica basada en racks con otra desagregada, nativa de la nube.
Por ejemplo, ¿acaso hoy en día, en los ámbitos de la tecnología de la información y de la nube, un proveedor de servicios o una compañía hiperescaladora consideraría la posibilidad de agregar un nuevo servicio a su cartera basado en un servidor dedicado específico del proveedor, frente a la opción de disponer de una nueva aplicación virtual que funcione en un servidor estándar de gama alta? Incluso si el servidor único tradicional pudiera ofrecer mejores gastos de capital, ¿podría realmente compararse en un modelo de TCO con los inmensos beneficios de gastos operativos del modelo de recursos compartidos en la nube?
La tecnología ha cambiado. Los centros de datos se convirtieron en nubes. Hoy en día, los proveedores de servicios ponen en práctica las ventajas de la nube en sus redes, al comenzar a crear redes como la nube y alejarse de un modelo de enrutador de servicio único y específico del proveedor, para pasar a un modelo de recurso de red ágil y compartido. Las redes están evolucionando, de la tradicional función de red física (PNF), pasando por funciones de red virtuales y en la nube (VNF y CNF), hasta un nuevo modelo de función de red en la nube (NCNF- Network Cloud Network Function) con el que es posible aprovechar todas las ventajas de la nube de red con un TCO más bajo.
El TCO tiene defectos. Exige muchos esfuerzos de análisis en áreas en las que las diferencias entre las soluciones son pequeñas. El hecho de que implique muchos datos también hace que sea muy fácil de distorsionar.
Más importante aún, el análisis de TCO (al igual que el de Costo por Puerto) deja de lado la medición de la funcionalidad de la solución. O sea, contar solo el costo total de una infraestructura —en función de una capacidad y una arquitectura determinadas y de un recuento de puertos específico— sin evaluar el rendimiento de esta infraestructura por solución, como su funcionalidad, capacidad, etc,
Estos defectos inherentes son aceptables al evaluar soluciones que se basan en conceptos tecnológicos y arquitectónicos idénticos. Pero al introducir una nueva tecnología de nube de red como DriveNets Network Cloud y evaluarla en estas antiguas herramientas, se podría llegar a una conclusión errónea y causar pérdidas significativas al proveedor de servicios de comunicaciones.
La solución obvia para el problema antes mencionado es llevar a cabo el análisis de TCO basándose en el Servicio o la función de red y no en una arquitectura predefinida.
Podrían parecer similares, pero se debe tener en cuenta que, en una solución desagregada y nativa de la nube, la misma infraestructura de hardware y software puede servir para más de una función de red.
Por lo tanto, al cotejar un enrutador con otro o, en nuestro caso, un enrutador con un clúster, la comparación debe tener en cuenta que el clúster de la nube de red puede ser equivalente a un enrutador único o a varios enrutadores, y asumir diversas funciones de conexión en red.
Esto se definirá mediante una instancia de software agregada al clúster, con un cambio mínimo del TCO y del Costo por Puerto. Por lo tanto, dos configuraciones casi idénticas de una nube de red se deben cotejar con dos configuraciones totalmente diferentes de una arquitectura de enrutador monolítico, lo que lleva a obtener distintos resultados de la misma herramienta de TCO.
Por otro lado, si se agrega el servicio —o la función de red— como entrada a este análisis, éste proveerá un resultado mucho más preciso.
Para evaluar con precisión el Costo Total del Servicio, se deben tener presentes varios aspectos.
Sin embargo, en la arquitectura de DriveNets Network Cloud, todos los recursos de hardware se extraen y se colocan en un repositorio de recursos que cualquier función de red que resida en el clúster puede utilizar de manera dinámica, por lo que el total de recursos necesarios se puede reducir significativamente. Esto se debe a las sinergias entre los diversos servicios, ya que éstos requieren un conjunto diferente de recursos de hardware —como CPU, NPU, TCAM, Calidad de servicio (QoS), etc.Las redes monolíticas basadas en racks suelen emplazarse en silos, donde cada dominio —por ejemplo, VPN, banda ancha, móvil, etc.— tiene sus propios recursos de hardware dedicados. Estos recursos no se pueden compartir ni transferir entre diferentes dominios.
Uso de racks y de matriz de conmutación
Al analizar el uso de ranuras, puertos y recursos de matriz de conmutación en una red monolítica basada en racks, se suele concluir que hay una subutilización significativa. Esto se debe a que el rack y la matriz de conmutación se suelen adquirir el primer día, mientras que las futuras tarjetas de línea suelen introducir una mayor densidad de capacidad y hacen que el rack se bloquee antes de estar completamente ocupado.
La alternativa de DriveNets Network Cloud no está sujeta a la limitación del rack o de la matriz de conmutación y crece en función de las necesidades, así como de la tecnología disponible en cada etapa.
Esto refleja los cálculos de energía, aire acondicionado y superficie útil o espacio de racks.
Hardware sin enrutamiento
Una arquitectura de red típica incluye, además de enrutadores, algunas funciones de red no vinculadas con el enrutamiento. Entre otras, cabe mencionar firewalls (FW), inspección a fondo de paquetes (DPI) y mitigación de ataques de denegación de servicio (DDoS).
Estas funciones utilizan dispositivos creados específicamente o servidores estándar basados en x86, que suponen tanto costos directos —el propio hardware— como indirectos, (por ejemplo, espacio de racks y energía). Ambas funciones podrían ser importantes a medida que la red se amplíe y que el volumen de tráfico que debe pasar por esas funciones aumente.
Sin embargo, en la arquitectura de DriveNets Network Cloud, dichas funciones se agregan a la infraestructura de clústers existente como Instancias de Servicio (SI). Los contenedores adicionales se agregan por medio del software, pero en la mayoría de los casos, no se requiere hardware adicional.
En este caso, los costos marginales consisten únicamente en el costo del propio software.
Amplitud de números de parte
En una arquitectura basada en racks, se utilizan diversos tipos de hardware para distintas funciones de red. Enrutadores, diversos dispositivos, servidores y tarjetas crean una larga lista de números de parte que se utilizan en la red. Esto complica los procedimientos de planificación y operación de la red y aumenta el costo de las piezas de repuesto almacenadas en los depósitos del proveedor de servicios de comunicaciones para ofrecer la sustitución inmediata de cualquier elemento de hardware esencial de la red.
Sin embargo, la arquitectura de DriveNets Network Cloud se crea a partir de un par de elementos fundamentales básicos. Dichos elementos fundamentales son comunes a todos los tipos de sitios —desde un sitio de 4 Tbps hasta uno de 768 Tbps— y a todas las funciones de la red, desde enrutadores hasta firewalls. El resultado es que el costo de las piezas de repuesto en una red basada en la arquitectura de DriveNets Network Cloud es muy inferior al de la arquitectura basada en racks.
Los cuatro ejemplos citados llevan a una evidente reducción de gastos de capital. Esto también conduce a la reducción de gastos operativos. La consistencia de la infraestructura física reduce los gastos operativos, dada la menor cantidad de variaciones de hardware, de versiones de software y de procedimientos de mantenimiento. Dado que muchas operaciones se basan en software, se requieren menos visitas “in situ” y procesos operativos como la identificación y solución de problemas resultan más eficientes con una mayor visibilidad del sistema —por ejemplo, la matriz de conmutación, que por lo demás es una “caja negra” que no se puede analizar.
Además de la reducción de costos, hay otros aspectos relacionados con la generación de ingresos, ya que un análisis más rápido de la causa raíz y menores tiempos de mantenimiento conducen a una mejor calidad de la experiencia del cliente, factor que puede reducir también la pérdida de clientes. El mismo efecto se consigue con una respuesta más rápida a cambios en los patrones de tráfico basada en la asignación dinámica de recursos a cada dominio de la red.
La generación de ingresos adicionales se hace posible gracias a la innovación sincronizada con software, lo que posibilita la rápida introducción de servicios de red, sin visitas “in situ”, lo que conduce a nuevas fuentes de ingresos.
Conclusión
La introducción de la tecnología de nube de red DriveNets Network Cloud no solo transforma la manera de estructurar redes, sino que encierra un enorme potencial de ahorro de dinero y de aumento de los ingresos, sin costos ocultos. Las comparaciones artificialmente forzadas entre soluciones basadas en la nube y soluciones heredadas basadas en racks son cada vez más irrelevantes. La verdadera comparación debería basarse en la eficiencia de los recursos de la red. En una solución basada en la nube, la eficiencia y el valor se basan en la extracción de todos los recursos de hardware. Dicha extracción eleva la utilización del hardware a un nuevo nivel. Para reconocer este potencial, es necesario adoptar un nuevo enfoque con respecto a la evaluación del TCO, uno que tenga en cuenta el Costo Total de Servicio en la red y no solo el costo por elemento de red.
