A pesar de que el tema de los microservicios basados en contenedores parece haberse convertido, de la noche a la mañana, en un tema de gran actualidad dentro del entorno de las redes y las telecomunicaciones, en realidad, este concepto ha estado vigente desde hace algún tiempo. La estrategia del desarrollo de software para microservicios tuvo su origen en el mundo de la TIs, impulsado por grandes empresas web 2.0 como Netflix, que estaban en la búsqueda de mecanismos más flexibles para cambiar, adaptar, probar y escalar sus aplicaciones en la nube, la cual contrasta con el enfoque monolítico legado.
Si avanzamos un par de años hasta llegar a nuestros días, vemos que el uso de contenedores Docker, como una herramienta fundamental para la construcción de aplicaciones de software, se ha convertido en algo convencional. Mientras así sucede en el terreno del software basado en la nube, desafortunadamente no ha pasado lo mismo con las redes y las telecomunicaciones, hasta ahora.
Para poner un ejemplo, veamos lo publicado en el blog de AT&T, donde destacan el hecho de que los microservicios desempeñarán un papel de gran importancia para alcanzar su objetivo de virtualizar el 75 por ciento de su red para el año 2020. A esto se suma el anuncio hecho por BT hace algunas semanas, en el sentido de que los contenedores desempeñarán un papel esencial en NFV. Y por último, Ciena también anunció recientemente que nuestro galardonado software de virtualización y orquestación de redes, Blue Planet, también había evolucionado hacia la arquitectura de microservicios basados en contenedores.
Entonces, la pregunta es: ¿qué son los microservicios y por qué esta estrategia resulta tan importante dentro del ámbito de la virtualización de redes?
Para explicar los microservicios, primero tenemos que analizar el enfoque utilizado para el desarrollo de software tradicional de la primera generación de controladores SDN y orquestadores NFV. Estos fueron desarrollados como aplicaciones de software monolíticas y no modulares. Aunque este enfoque permitió a los proveedores aportar una solución al mercado, la arquitectura de estos sistemas de software no permitía escalar de manera fácil para administrar grandes redes, tampoco fue diseñada para proporcionar un esquema de módulos que hiciera posible realizar las actualizaciones sin interrupciones. Y lo más importante es que estas plataformas monolíticas no permitían ninguna personalización para poder añadir nuevas funciones sin que requirieran reconstruir la pila de software por completo.
Las limitaciones de este enfoque de software son cada vez más evidentes, especialmente a medida que se implementan más aplicaciones para la nube. Incluso los pequeños cambios y las mejoras en las funciones requieren de un esfuerzo considerable como la reconstrucción del código, la recopilación, el volver a activar pruebas de regresiones y nuevamente a implementar el software. Además, la actualización del software puede provocar la interrupción del servicio de un operador. Debido a los riesgos de interrupción de los servicios, así como al esfuerzo necesario para reparar todo el código, las arquitecturas monolíticas tienden a retardar la adopción de nuevas funciones. Esto resulta totalmente inconveniente, en especial cuando se tiene la intención de adoptar más conceptos de las TIs en las telecomunicaciones, donde un software ágil, así como las actualizaciones y mejoras frecuentes son cruciales para mantenerse competitivo.
La escalabilidad es otro desafío que enfrentan las aplicaciones de software basadas en arquitecturas monolíticas. Al escalar una aplicación monolítica, debe escalarse toda la aplicación, en lugar de solo aquellas partes que requieren más recursos. Por ejemplo, si se agregan más servidores al conjunto global de computación que los que un orquestador NFV puede utilizar para prestar servicios, solo las partes del orquestador relacionadas con la gestión de la infraestructura tendrían que escalarse para hacer frente al aumento del número de recursos. La interfaz gráfica de usuario (GUI), el analizador sintáctico, el controlador VNF no tienen que escalarse, ya que no están relacionados con estos cambios. Sin embargo, una aplicación monolítica no tiene un módulo separado que esté diseñado para controlar solo los recursos de infraestructura. Por consiguiente, todo el sistema de software necesitaría escalarse, lo que daría como resultado un consumo de recursos considerablemente mayor a los que realmente necesita.
¿Qué es lo mejor de una arquitectura basada en microservicios?
Una arquitectura basada en microservicios elimina los desafíos asociados con las aplicaciones monolíticas, ofreciendo a los operadores de redes la capacidad de implementar y beneficiarse de las tecnologías más modernas a escala web, reducir la utilización de recursos, añadir rápidamente nuevas funciones sin interrumpir el servicio, e integrar fácilmente las soluciones desarrolladas por terceros. He aquí cómo se logra.
Los microservicios son servicios relativamente pequeños y autónomos que funcionan juntos. Cada servicio se centra en hacer muy bien solo una cosa y es autónomo, es decir, trabaja como una entidad independiente. Un microservicio podría implementarse como un servicio aislado o conjuntamente con otros servicios. En general, estos servicios aislados, en contenedores, se comunican entre sí mediante APIs independientes del lenguaje. Por ejemplo, un módulo podría proporcionar solo la GUI, otro módulo podría proporcionar solo la capacidad de hablar con un enrutador, y otro módulo podría centrarse en la comunicación con la OSS y así sucesivamente.
Una aplicación de software monolítico incluye y vincula estrechamente todas las funciones en un solo código. En una arquitectura basada en microservicios, cada servicio proporciona una funcionalidad específica y está vinculado a otros servicios a través de las APIs.
La arquitectura de Blue Planet se rediseñó para constituir una plataforma de microservicios basada en contenedores.
La recientemente relanzada plataforma Blue Planet de Ciena está construida en torno al concepto de los microservicios, en donde cada uno funciona dentro de su propio contenedor. Este esfuerzo comenzó hace un año y se inició a partir de las solicitudes de los clientes de tener una mayor programabilidad, apertura y modularidad.
El resultado ha sido que hemos abierto esencialmente la capota de Blue Planet para que puedan hacer uso de sus recursos y conocimientos tipo DevOps (si así lo desean) para modificar rápidamente la plataforma, agregar nuevos microservicios y programar la plataforma para construir servicios diferenciados. Por ejemplo, un nuevo dispositivo virtual o físico se puede agregar a Blue Planet con sólo añadir un microservicio que hable con ese dispositivo específico, sin necesidad de cambiar por completo, incluso ni de reiniciar la plataforma. O, en lugar de utilizar los elementos analíticos y la política de encendido del microservicio que viene instalado de manera estándar con Blue Planet, los clientes pueden fácilmente conectar una aplicación alternativa, desarrollada por un proveedor externo. Por supuesto, la nueva arquitectura también hace que sea muy fácil integrar soluciones de código abierto, beneficiándose de la mejora continua que provee la comunidad Open Source.
Muy bien, seamos específicos, ¿cuáles son esas cuatro razones por las que usted desea implementar el software de virtualización de la red con una arquitectura basada en microservicio?
- Fácil personalización y las mejores soluciones en su clase: Puesto que cada servicio se separa a través de llamadas a la API, el operador de la red o el integrador del sistema puede personalizar fácilmente y adaptar la plataforma mediante la elección del mejor software para llevar a cabo una tarea específica, beneficiándose de la mejor solución en su clase, ya sea a través de la utilización de las tecnologías más modernas, las opciones de código abierto o soluciones desarrolladas por terceros.
- Resistencia: Una gran disponibilidad y resistencia son elementos muy importantes. Con este tipo de arquitectura, si fallara uno de los componentes de un sistema, dicho fallo no provocaría la caída de toda la plataforma ni afectará el servicio que se presta. Independientemente de la causa raíz, los problemas son aislados y el resto de la plataforma sigue funcionando sin interrumpir el servicio general que se esté prestando.
- Escalamiento simplificado: A medida que aumenta la demanda sobre la plataforma, en lugar de escalar todos los componentes, la escalada se puede centrar en los micro servicios problemáticos que necesitan crecer con mayor asignación de recursos. El resultado es un uso frugal de los recursos existentes y, por consiguiente, una reducción en el nivel de gastos y un mejor rendimiento de la inversión (ROI).
- Facilidad de implementación: Puesto que cada servicio se desacopla, los servicios pueden actualizarse, pueden añadirse nuevas funciones e implementarse de forma independiente al resto de la plataforma, sin tiempo de inactividad o interrupción del negocio total.
Los microservicios basados en contenedores logran desagregar la pila de software tal y como SDN y NFV han desagregado los dispositivos de red tradicionales basados en hardware. Con esta nueva arquitectura, Blue Planet brinda una verdadera plataforma de virtualización y orquestación de red de última generación que ofrece un nivel de programabilidad, agilidad y modularidad de servicio antes inalcanzable.
