CLOUD: Software para microservicios

El 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.

El uso de contenedores Docker, como una herramienta para la construcción de aplicaciones de software, se ha convertido en algo convencional. Mientras esto sucede en el terreno del software basado en la nube, no ha pasado lo mismo con las redes y las telecomunicaciones, aunque hay avancen como los siguientes:  AT&T, ha indicado que los microservicios desempeñarán un papel de gran importancia para alcanzar su objetivo de virtualizar el 75 % de su red para el año 2020. Asimismo  BT indicó que los contenedores desempeñarán un papel esencial en NFV. Y Ciena indicó que su software de virtualización y orquestación de redes, Blue Planet, ha evolucionado hacia la arquitectura de microservicios basados en contenedores.

La virtualización de redes y los microservicios

El enfoque utilizado para el desarrollo de software tradicional de la primera generación de controladores SDN y orquestadores NFV, fue desarrollar 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.

La 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.

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.

Software de virtualización de la red con una arquitectura basada en microservicio

Cuatro razones para implementarlo:
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.

Blue Planet de Ciena

La 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.
Ciena abrió el 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.