Editar

Soluciones multinube con Serverless Framework

Azure Functions

En este artículo, se describe la forma en que el equipo de ingeniería de software comercial (CSE) de Microsoft se ha asociado con un minorista global para implementar una solución sin servidor de alta disponibilidad en las plataformas en la nube de Azure y Amazon Web Services (AWS) con Serverless Framework.

Architecture

Diagrama que muestra la arquitectura sin servidor multinube.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

  • La aplicación de usuario puede proceder de cualquier origen capaz de iniciar sesión en la nube. En esta implementación, el usuario inicia sesión en una aplicación de puerta de enlace que equilibra la carga de solicitudes 50-50 entre las nubes de Azure y AWS.
  • Cualquier respuesta también se redirige mediante la puerta de enlace de API Manager, que, a continuación, la envía a la aplicación solicitante.

Componentes

Serverless Framework

Esta solución usa Serverless Framework, disponible en Serverless, Inc. La versión gratuita de Serverless Framework incluye una CLI, más complementos y servicios de supervisión limitados. La edición Pro incluye funcionalidades operativas entre nubes, como la supervisión y las alertas mejoradas. El marco admite los lenguajes Node.js y Python, así como con los hosts de nube de AWS y Azure.

Para usar Azure con Serverless Framework, necesita:

  • Node.js, para empaquetar microservicios;
  • Azure Functions, para proporcionar funcionalidad comparable a otras plataformas en la nube;
  • Serverless Framework, para admitir la implementación y supervisión multinube;
  • La biblioteca multinube sin servidor, para proporcionar API en tiempo de ejecución normalizadas para desarrolladores;
  • El complemento sin servidor de Azure Functions, para admitir la implementación multinube. Este complemento no estaba inicialmente en paridad con el complemento Lambda de AWS y se amplió para este proyecto.

En la siguiente figura se muestra la canalización de procesamiento. Los niveles de middleware representan cualquier funcionalidad intermedia necesaria antes de llegar al controlador.

Diagrama que muestra una canalización de procesamiento multinube.

API independientes de la nube

La implementación sin servidor en cada plataforma admite funciones individuales como microservicios, una para cada nodo de VM funcional, y ejecuta el procesamiento según sea necesario. Cada función Lambda de AWS tiene una función de Azure Functions correspondiente. La biblioteca multinube sin servidor crea microservicios análogos desde cualquier nube en una API REST normalizada independiente de la nube que las aplicaciones cliente pueden usar para interactuar con cualquier plataforma. Dado que el nivel de API abstracta proporciona código para abordar los microservicios correspondientes para cada plataforma, las transacciones no necesitan traducción. La interfaz independiente de la nube permite que las aplicaciones de usuario interactúen con la nube sin saber a qué plataforma en la nube acceden y sin que importe.

En el siguiente diagrama se ilustra este concepto:

Diagrama que muestra una API independiente de la nube.

CI/CD con GitOps

Un trabajo principal de Serverless Framework es abstraer todos los problemas de infraestructura de la implementación de una aplicación en la nube. Con un enfoque basado en manifiestos, Serverless Framework puede tratar con todos los problemas de implementación, lo que permite automatizar la implementación según sea necesario para admitir GitOps.

Aunque este proyecto inicial usaba implementaciones manuales, es realista implementar compilaciones, pruebas e implementaciones sin servidor basadas en manifiestos en una nube o en varias. Este proceso puede usar un flujo de trabajo para desarrolladores de GitOps: compilación desde GIT, uso de puertas de calidad para pruebas y evaluación, e inserción de soluciones sin servidor en ambos proveedores en la nube. Realizar todas las implementaciones mediante Serverless Framework desde el principio del proyecto es la manera más eficaz de continuar.

Administrador de API

El administrador de API puede ser una aplicación existente o personalizada. El administrador de API Apigee™ de esta implementación solo actuaba como enrutador para equilibrar la carga de las transacciones a 50-50 en las dos plataformas en la nube y sus funcionalidades estaban infrautilizadas.

El administrador de API debe ser capaz de:

  • implementarse dentro o fuera de una plataforma en la nube según sea necesario;
  • enrutar mensajes hacia y desde ambas plataformas en la nube;
  • registrar solicitudes de tráfico para coordinar el tráfico de mensajes asincrónicos;
  • retransmitir solicitudes y respuestas mediante la API REST desde y a la aplicación de usuario;
  • supervisar el estado de las implementaciones de marco sin servidor en la nube para validar su capacidad de recibir solicitudes;
  • realizar comprobaciones automatizadas de mantenimiento y disponibilidad en cada plataforma en la nube para admitir el enrutamiento y la alta disponibilidad.

Alternativas

  • Otros lenguajes, como Python, podrían implementar la solución, siempre que sean compatibles con las implementaciones sin servidor de las plataformas en la nube, AWS Lambda y Azure Functions en este caso. En este proyecto se usó Node.js para empaquetar los microservicios, ya que el cliente estaba familiarizado con Node.js y tanto la plataforma de AWS como la de Azure lo admiten.

  • La solución puede usar cualquier plataforma en la nube que admita Serverless Framework, no solo Azure y AWS. Actualmente, Serverless Framework es compatible con ocho proveedores en la nube diferentes. La única advertencia es que es necesario asegurarse de que los elementos que admiten la arquitectura multinube o su equivalente están disponibles en las plataformas en la nube de destino.

  • En esta implementación inicial, el administrador de API solo actuaba como enrutador para proporcionar un equilibrio de carga de las transacciones de 50-50 a las dos plataformas en la nube. El administrador de API podría incorporar otra lógica de negocios para escenarios específicos.

Detalles del escenario

En la informática sin servidor, el proveedor en la nube asigna dinámicamente recursos de microservicios para ejecutar código y solo cobra por los recursos que se usan. La informática sin servidor abstrae el código de la aplicación de la implementación de la infraestructura y el código y de los aspectos operativos, como la planeación y el mantenimiento.

Al igual que con otros servicios, cada proveedor de servicios en la nube tiene su propia implementación sin servidor y es difícil para los clientes usar un proveedor diferente sin un importante impacto operativo y aumento de costos. Los clientes potenciales pueden considerar que esta situación debilita su posición y agilidad de negociación. La dependencia del proveedor es uno de los mayores obstáculos para la adopción de la nube empresarial.

El marco de código abierto Serverless Framework es una interfaz en la nube universal para desarrollar e implementar soluciones informáticas sin servidor en distintos proveedores en la nube. Las API comunes y de código abierto para funciones sin servidor ayudan a proveedores, clientes y asociados a crear soluciones entre nubes para ofrecer servicios avanzados. Serverless Framework reduce las barreras para la adopción de la nube, ya que soluciona los problemas de dependencia del proveedor y redundancia del proveedor entre nubes. Los clientes pueden optimizar sus soluciones en función del costo, la agilidad y otras consideraciones.

CSE y el equipo de producto de Azure reescribieron colectivamente la CLI sin servidor para admitir nuevas características de Azure Functions, como funciones prémium, API Management y Key Vault. Ahora, la CLI sin servidor proporciona una interfaz estándar para la implementación de GitOps en Azure y AWS. El equipo también desarrolló la biblioteca multinube sin servidor, que proporciona una API en tiempo de ejecución normalizada para implementar aplicaciones sin servidor en AWS y Azure.

Este diseño proporciona alta disponibilidad con conmutación por error activa-activa entre varias plataformas en la nube, en lugar de conmutación por error activa-pasiva. Si el servicio de un proveedor en la nube deja de estar en buen estado o disponible, esta solución puede volver a enrutar las solicitudes a otra plataforma en la nube.

Este proyecto cumple los siguientes objetivos técnicos:

  • Crear una solución entre sectores.
  • Usar la biblioteca sin servidor multinube para admitir una API independiente de la nube que interactúe con microservicios dondequiera que se implementen.
  • Admitir un flujo de trabajo de proceso de CI/CD de GitOps para desarrollo, pruebas e implementación en todas las plataformas en la nube admitidas.
  • Use el acceso basado en API mediante una puerta de enlace en la nube autenticada y el equilibrio de carga entre las plataformas en la nube mediante el uso de la puerta de enlace como enrutador.

Otras posibles ventajas de usar Serverless Framework son las siguientes:

  • Prevención o reducción de la dependencia del proveedor
  • Reducción de entre el 40 y más del 60 % durante el desarrollo mediante la biblioteca sin servidor multinube
  • Desarrollo de soluciones avanzadas que combinan los servicios de diferentes proveedores en la nube
  • Eliminación de la mayoría de los requisitos de mantenimiento y complejidad de la plataforma y la infraestructura
  • Uso compartido de datos más sencillo, comparaciones de rendimiento y costos, y capacidad de aprovechar ofertas especiales
  • Alta disponibilidad activa-activa

Posibles casos de uso

  • Escriba aplicaciones del lado cliente para varias plataformas mediante una API independiente de la nube de la biblioteca multinube sin servidor.
  • Implemente una colección de microservicios funcionales en un marco sin servidor para varias plataformas en la nube.
  • Use una aplicación independiente de la nube en todas las plataformas en la nube sin conocer ni preocuparse de qué plataforma la hospeda.

Consideraciones

  • En este artículo no se describen las soluciones de seguridad, aunque la implementación inicial las incluía. Hay muchas soluciones de seguridad posibles, algunas de las cuales dependen de la plataforma y este marco debe admitir cualquier solución razonable. La autenticación de usuario es la seguridad mínima que se supone.

  • Dado que es difícil articular las diferencias entre las ofertas funcionales sin servidor de AWS y Azure, los primeros esfuerzos deben centrarse en asignar las funciones disponibles en cada plataforma en la nube y en identificar los requisitos de transformación necesarios. Puede desarrollar una API independiente de la plataforma a partir de esta información.

  • El uso de una solución de código abierto puede presentar riesgos debido a los desafíos de mantenimiento y soporte técnico a largo plazo de cualquier software de código abierto.

  • En la instancia gratuita de Serverless Framework, la supervisión se limita principalmente al panel administrativo. La supervisión está disponible en la oferta empresarial de pago. Actualmente, el complemento sin servidor de Azure Functions no incluye disposiciones para la observación o supervisión, y sería necesario modificarlo para implementar estas funcionalidades.

  • Esta solución podría usar métricas para comparar el rendimiento y los costos entre plataformas en la nube, lo que permite a los clientes optimizar sin problemas el uso en todas las plataformas en la nube.

Implementación de este escenario

Una implementación azul-verde tradicional desarrolla e implementa una aplicación en dos entornos independientes, pero idénticos, azul y verde, lo que aumenta la disponibilidad y reduce el riesgo. Normalmente, el entorno azul es el de producción y es el que suele controlar el tráfico en directo, mientras que el entorno verde es una implementación de conmutación por error ajustada a las necesidades. Normalmente, la canalización de CI/CD implementa automáticamente los entornos azul y verde dentro de la misma plataforma en la nube. Esta configuración se considera una configuración activa-pasiva.

En la solución multinube, la implementación azul-verde se implementa en ambas plataformas en la nube. En el caso sin servidor, se implementan dos conjuntos duplicados de microservicios para cada plataforma en la nube, uno como entorno de producción y otro como entorno de conmutación por error. Esta configuración activa-pasiva dentro de cada plataforma en la nube reduce el riesgo de que esta plataforma esté inactiva, aumenta su disponibilidad y habilita la alta disponibilidad activa-activa multinube.

Diagrama que muestra una implementación azul-verde activo-activo.

Una ventaja secundaria de la implementación azul-verde es la posibilidad de usar la implementación de conmutación por error en cada plataforma en la nube como entorno de prueba para las actualizaciones de microservicios antes de lanzarlas en la implementación de producción.

Pasos siguientes