Presentamos Network as a Service (NaaS), ahora con SunVizion

Basta con una mirada al pasado de la telecomunicación y las tecnologías de TI para que quede clara la dirección de las oscilaciones pendulares de los conceptos a escala macro, incluida la oscilación entre la modularización/fragmentación y la consolidación/arquitecturas monolíticas. Carey tiene razón al señalar que muchos proveedores (y operadores) se están enfocando en los servicios administrados y en la abstracción. De hecho, está ocurriendo un cambio macro: desde el desarrollo de sistemas de telecomunicaciones subcontratados —outsourced— hacia modelos internos. Es algo que provoca las grandes empresas de telecomunicaciones a contratar desarrolladores e integradores para crear soluciones personalizadas y supone un cambio radical a favor de la "softwareización": las firmas siguen el ejemplo de los híper escaladores, brindando una mayor capacidad de programación a los paquetes infraestructurales.

Esta forma de pensar ha generado muchos beneficios para los proveedores de servicios, p.ej. el aumento en las entregas Agile ocurrió en paralelo con una mayor modularidad y control interno de lo que se estaba desarrollando. Además, las técnicas avanzadas de integración permitieron abstraer las redes, lo que, en definitiva, facilitó la construcción de paquetes de software altamente flexibles sobre muchos equipos poco adaptables (y a menudo heredados) que las empresas de telecomunicaciones están obligadas a mantener e integrar.

La filosofía de priorizar los servicios permitió que las redes, tanto las antiguas como las nuevas, estén envueltas en el API estándar con patrones de exposición a servicios más comunes, como aquellos propuestos para la red como servicio (Network as a Service, NaaS).

Cómo lanzar la red como servicio

Es un concepto donde o estamos dentro del límite, o fuera de él. "El límite" está representado por la capa común de API. Todo lo que está por encima del límite de API es software muy flexible. Dentro del límite está tanto el hardware como el software, pero generalmente es menos maleable que el software como tal, hasta si tenemos en cuenta las tendencias de redes virtualizadas y definidas a nivel de programación, los cambios dentro de dicho límite —tanto en las redes como en los dominios de su orquestación— no suelen ocurrir al ritmo tan rápido. Esto no significa que no cambia nada, sino que fuera del límite el ritmo de cambios —dentro del catálogo de productos y dominios de orquestación de servicios— es mucho más elevado.

En el artículo de Carey también podemos leer la famosa opinión de Ray Ozzie (de Lotus Notes y Microsoft): “La complejidad mata. Les quita la vida a los desarrolladores, dificulta la planificación, construcción y pruebas de productos, despierta las dudas de su seguridad y es frustrante tanto para el usuario como para el administrador”. Tengamos en cuenta que lo decía en 2005. Con la proliferación de opciones disponibles en la época de "la nube nativa", el nivel de complejidad con el que se enfrentan los desarrolladores es mucho mayor que entonces. Dentro del OSS y BSS, en aquellos tiempos de monolitos, los desarrolladores seguramente tenían menos posibilidades.

 

En cierto modo la complejidad disminuyó, debido a que los desarrolladores ahora pueden aprovechar las bibliotecas y la "contenedorización" y así abstraer la complejidad, algo que, sin embargo, no debe confundirse con una menor complejidad en los stacks top-to-bottom, como lo puso recientemente en relieve la vulnerabilidad log4j. Los desarrolladores se enfrentan con las decisiones difíciles: entre la variedad de opciones tecnológicas disponibles en el momento del diseño, no solo para el desarrollo inicial, sino hasta para los ciclos de vida completos de DevSecOps. El artículo de Carey destaca que “cada uno de los tres grandes proveedores de la nube (Amazon Web Services, Microsoft Azure y Google Cloud) ofrece alrededor de 200 servicios únicos a los clientes: entre la computación, almacenamiento, bases de datos, análisis, redes, dispositivos móviles, herramientas para desarrolladores, herramientas de gestión, IoT, seguridad y aplicaciones empresariales."

Estos días, siguiendo la metáfora del péndulo de tecnología, nos preguntamos igual como Carey si va a haber un cambio a favor de una mayor consolidación de los marcos de trabajo. En lugar de cientos o hasta miles de servicios únicos, ¿acaso veamos una mayor consolidación a través de combinaciones empaquetadas de estos servicios? Mirando esto desde una perspectiva más local, ¿se podría facilitar el trabajo de los desarrolladores mediante la consolidación, especialmente dentro del llamado límite?

Las herramientas SunVizion combinan varios servicios únicos y proporcionan una capa común de servicios/API que permite la abstracción de complejidad de la red para que la aprovechen los desarrolladores de aplicaciones fuera del límite. De este modo, los desarrolladores reciben lo mejor de ambos mundos: la capacidad de evolucionar rápidamente para cualquier necesidad de cara al cliente (fuera del límite), conservando la consistencia de la exposición del servicio (el límite), pero con un registro fiable de seguridad y adaptación a toda tendencia en las redes (dentro del límite). Por lo tanto, le proponemos la aplicación de las siguientes herramientas SunVizion:

• Service Fulfillment: el cumplimiento de servicios es una solución que consolida el inventario, el catálogo, la orden impulsada por flujo de trabajo y orquestación, la gestión de recursos, la mano de obra y la gestión de materiales.
• Network Inventory: el inventario de red es una solución completa para gestionar las redes multitecnológicas, sus conexiones y, continuamente, su capacidad.
• Smart Service Designer: el diseño de servicios inteligente es una solución basada en catálogos para descomponer los pedidos a planes de orquestación dinámicos, listos para insertar en la red.

Si desea reducir la complejidad para sus equipos de DevSecOps, reserve una consulta con nosotros para descubrir cómo le podrá ayudar la gama de soluciones SunVizion.