Cómo diseñar una arquitectura de nube híbrida

En el pasado reciente, un enfoque de nube híbrida generalmente implicaba migrar algunos servicios de la infraestructura on premises a una nube pública o nube privada, y estos servicios se comunicaban entre sí. Incluso si una nueva aplicación se creó para alojarse en una nube pública, se adhirió a una arquitectura tradicional orientada a servicios (SOA).

Pero, hoy en día, la arquitectura basada en microservicios está en el núcleo del modelo de nube híbrida. Los microservicios son un enfoque en el que una aplicación se divide en componentes o servicios más pequeños para facilitar el despliegue. Estos microservicios se diferencian de los servicios de SOA en que tienen su propia pila tecnológica y se despliegan en contenedores, que son ejecutables ligeros que contienen el microservicio y sus bibliotecas dependientes.

Los contenedores son ligeros porque comparten el kernel del sistema operativo (SO) de la máquina, lo que significa que cada contenedor contiene solo el microservicio y sus dependencias. Cualquier dependencia del sistema operativo se comparte desde el hardware en el que reside el contenedor. Esta virtualización permite que los microservicios se desplieguen de forma independiente en cualquier entorno on premises o en la nube. Y la autosuficiencia hace que los microservicios sean muy diferentes de la SOA y más adecuados para el despliegue en la nube, donde la necesidad de elasticidad y flexibilidad para optimizar los recursos de la nube es primordial.

La contenerización como modelo de empaquetado para aislar procesos en cualquier entorno no es un concepto nuevo, pero la aparición de Docker en 2013 como motor de contenedores creó una estructura de empaquetado universal. Además, una plataforma de orquestación de contenedores como Kubernetes automatiza el despliegue de Docker, o cualquier otro contenedor que cumpla con los estándares de Open Container Initiative (OCI), en entornos de nube híbrida.

La aparición de la contenerización ha ayudado a aprovechar realmente los beneficios de las nubes híbridas, con el enfoque cambiando a una fácil portabilidad de las cargas de trabajo y el despliegue automático de servicios en el entorno de nube de su elección.

Hace unos años, las preguntas clave en un debate sobre la arquitectura de nube híbrida se centraban en qué nube o entorno on premises cada carga de trabajo debería ejecutar y cómo hacer que estos diferentes entornos se comuniquen entre sí. Esencialmente, la ubicación de alojamiento y la conectividad física siguieron siendo las principales consideraciones.

Por ejemplo, una aplicación que tratara con datos confidenciales se alojaría en una nube privada. O una aplicación heredada/existente que es difícil de modernizar Continuaría existiendo on premises. Mientras tanto, las organizaciones trasladarían las aplicaciones que necesitan escalabilidad a entornos de nube pública. Luego, establecerían canales como túneles de red privada virtual (VPN) o flujos de mensajes para facilitar la comunicación entre entornos.

Estos siguen siendo factores importantes a considerar, pero con el paradigma de la contenerización, el enfoque ha cambiado de la ubicación física y la conectividad a la flexibilidad para mover cargas de trabajo perfectamente de un entorno a otro. Por lo tanto, alojar una aplicación en una nube privada o en una nube pública no tiene por qué ser una decisión rígida. Si la estrategia no funciona, es fácil mover cargas de trabajo empaquetadas como contenedores entre entornos, escalar hacia arriba y hacia abajo e incluso ejecutar instancias del mismo servicio en diferentes entornos.

Todo esto ha llevado a una arquitectura moderna, altamente disponible y flexible que ofrece alto rendimiento, eficiencia de recursos y ahorro de costos.

El diseño y la implementación de una nube híbrida deben tener en cuenta muchos factores, incluidos los objetivos comerciales de una empresa, su ámbito tecnológico actual, los objetivos de transformación digital y las consideraciones de seguridad. Dado que una arquitectura de este tipo con múltiples soluciones de nube híbrida podría volverse compleja muy rápidamente, es importante aprovechar las herramientas de operaciones para una gestión de la nube centralizada, fluida y escalable. Estos son algunos factores que deben tenerse en cuenta al crear la estrategia de nube híbrida.

Estrategia de modernización

Para la mayoría de las organizaciones, la idea de la computación en la nube híbrida comienza con la modernización o el traslado de sus aplicaciones del entorno on premises a la nube, y hay algunas maneras de ejecutar esto:

• Lift-and-shift: una de las formas más comunes de impulsar la modernización, el lift-and-shift, es trasladar la aplicación completa fuera de las instalaciones al entorno de la nube. Esto implica cambiar el hardware subyacente para benficiarse de los recursos y servicios de infraestructura de computación en la nube escalable y seguros. Es una opción conveniente cuando no hay tiempo suficiente para refactorizar o rediseñar.
• Refactorizar: en lugar de trasladar la aplicación monolítica completa a la nube, lo que no solo lleva mucho tiempo sino que también puede ser innecesario, es mejor identificar uno o dos servicios (algo que no tiene necesidades urgentes de mejora del rendimiento o cumplimiento), refactorizarlos (por ejemplo, agregue código adhesivo para exponer las API REST, ya que las interfaces de servicio anteriores podrían estar estrechamente acopladas a la plataforma específica) y desplegar en la nube. Esta mudanza por fases da la oportunidad de dirigir una cantidad menor de tráfico a nuevas instancias en la nube para oportunidades de prueba y aprendizaje y, finalmente, mover todas las instancias del servicio a la nube.
• Rearquitectura: finalmente, existe el enfoque más sofisticado de dividir todos los componentes del sistema en microservicios de responsabilidad única que son modulares y tienen una ruta independiente hacia la producción y contenerlos. Esto implica una reescritura completa y es un proceso costoso, pero también maximiza los rendimientos.

Plano de control unificado

Los equipos de operaciones empresariales gestionan su entorno de nube a través de un plano de control unificado que proporciona una experiencia de operaciones en la nube cohesiva y coherente en todos los entornos. Admite capacidades básicas de gestión de clústeres, como programación y orquestación de cargas de trabajo, canalizaciones de integración y despliegue continuos (CI/CD), registro, telemetría y seguridad federada.

El objetivo es abstraer las complejidades subyacentes de los proveedores de servicios en la nube (CSP) individuales y los tiempos de ejecución de los equipos de aplicaciones y proporcionar una interfaz común para que los equipos de operaciones gestionen las cargas de trabajo en la empresa. 

Estas son algunas de las ventajas de un plano de control unificado:

• Emplee estrategias de asignación dinámica de carga de trabajo en máquinas virtuales, contenedores o despliegues sin servidor .
• Disfrute de la capacidad de incorporar proveedores adicionales o ubicaciones perimetrales con un esfuerzo mínimo.
• Cree capacidades de PaaS como la función como servicio (FaaS) que estén altamente disponibles y funcionen en diferentes implementaciones en la nube.
• Centralice la gestión del cumplimiento.

Puerta de enlace de API y malla de servicios

Los patrones de arquitectura, como las puertas de enlace de API centralizadas y la malla de servicios, permiten una gestión transparente de las capacidades de la nube, como el enrutamiento, la comunicación de servicio a servicio, la seguridad, la limitación de velocidad y la Observabilidad.

La puerta de enlace de API actúa como una puerta de entrada unificada en todas las regiones y es responsable de manejar las funciones de tráfico "norte-sur", incluidas las siguientes:

• Autenticación y autorización de usuarios
• Regulación y limitación de velocidad
• Gestión del tráfico
• Gestión del ciclo de vida de las API
• Barreras de seguridad en la nube
• Análisis de borde

La malla de servicios, por otro lado, maneja el tráfico "este-oeste" entre dependencias de servicios:

• Comunicación segura de servicio a servicio en un clúster
• Gestión del tráfico con equilibrio de carga, reglas de enrutamiento, reintentar, conmutación por error, recuperación ante desastres e inyección de fallas
• Telemetría con métricas, registros y rastreos para todo el tráfico dentro de un clúster, incluida la salida y la entrada del clúster
• Trazabilidad distribuida para instrumentar el flujo de una solicitud a través de las Boundary
• Descubrimiento automatizado de servicios

Istio, por ejemplo, es una capa de malla de servicios de código abierto que dirige la comunicación entre servicios de acuerdo con una configuración predefinida proporcionada por los administradores de la nube. Actúa como complemento de la capa de orquestación de Kubernetes y funciona con contenedores, invisibles para programadores y administradores.

Seguridad

La complejidad de la arquitectura de nube híbrida requiere un enfoque de varios niveles en diferentes capas para garantizar la seguridad y la protección de extremo a extremo. 

Los CSP como IBM Cloud, Amazon Web Services (AWS), Microsoft Azure y Google Cloud tienen la responsabilidad, según los acuerdos de nivel de servicio (SLA), de autenticar y autorizar cualquier llamada en la capa perimetral, construyendo un cortafuegos alrededor de las aplicaciones empresariales. Esto incluye la protección contra la denegación del servicio y el cumplimiento de las regulaciones de privacidad, como el Reglamento General de Protección de Datos (RGPD) y la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA).

En una infraestructura on premises, la seguridad perimetral se puede lograr mediante API Gateway, que protegen todos los endpoint. Cualquier llamada desde un servicio web o una aplicación móvil que resida fuera de un centro de datos debe validarse y enrutarse a través de API Gateway.

Un entorno de computación en la nube contiene una capa adicional de seguridad en forma de políticas de control definidas en la malla de servicios y API expuestas por la plataforma de orquestación. Estas políticas garantizan que solo las llamadas seguras se reenvíen a los nodos de Kubernetes y, de ahí, a los microservicios.

Además, el concepto de microsegmentación (dividir el entorno en diferentes segmentos de seguridad lógicos para definir políticas de control de acceso para cada servicio y carga de trabajo) se puede utilizar para crear y demarcar niveles de seguridad entre los servicios que se ejecutan dentro de un entorno. Y, por último, las políticas de cifrado sirven como una capa adicional de protección de datos.

Conectividad de red

En una sola región de nube, las zonas de disponibilidad tienen una red de fibra dedicada que conecta todos los nodos de una red, lo que permite a las empresas crear arquitecturas de alta disponibilidad donde el ancho de banda es ilimitado y las latencias de red son bajas. Sin embargo, la comunicación entre regiones y múltiples proveedores de la nube se enruta a través de Internet pública y tiene el costo de latencia elevada y posibles fallas.

En una arquitectura de nube híbrida, existen tres patrones para el intercambio de datos entre los proveedores subyacentes:

• Direcciones IP públicas a través de Internet (latencia elevada debido a la dirección compartida)
• Servicios gestionados como VPN (latencia más predecible con mayor seguridad)
• Interconexión dedicada a través de puntos de presencia comunes (POPs) (opción costosa ofrecida por los CSP pero con menor latencia y máxima seguridad)

Dado que estas opciones difieren en términos de velocidad de transferencia, latencia, confiabilidad, SLA, complejidad y precios, es importante sopesar las limitaciones y los beneficios antes de diseñar la capa de conectividad de red.

Sesgo por el código abierto en las plataformas de desarrollo

Una nube híbrida significa la capacidad de cambiar cargas de trabajo de un entorno a otro y tener una plataforma de desarrollo de aplicaciones que se ejecuta en cualquier nube. Para ser verdaderamente nativo de la nube, no debe haber una dependencia estrecha de ninguna tecnología, plataforma o incluso CSP específicos, y las empresas deben ser ágiles a los cambios del mercado.

Una arquitectura de código abierto permite este enfoque unificado del desarrollo en el que los desarrolladores pueden gestionar su infraestructura subyacente independientemente de la tecnología utilizada para su implementación. El código abierto ya no está en la periferia con una audiencia especializada y exclusiva que lo utiliza por rentabilidad; ahora es convencional y ha ocupado un lugar central debido a sus características ricas, calidad y desarrollo basado en la comunidad.

Incluso en un área sensible como la seguridad, el software de código abierto ahora se percibe como una gran opción, según lo informado por el Informe de Red Hat sobre el Estado del código abierto empresarial. La seguridad, la calidad y el soporte para la arquitectura nativa de la nube son las principales razones por las que las empresas están mostrando un sesgo consciente por el código abierto.

Consulte el artículo de JJ Asghar “Cultivating Careers, Communities and Companies with Open Source” para obtener más información.

Las soluciones de nube híbrida de IBM Cloud ofrecen flexibilidad y portabilidad tanto para aplicaciones como para datos. Linux, Kubernetes y contenedores admiten la pila de nube híbrida y se combinan con Red Hat OpenShift para crear una plataforma común que conecte recursos locales y en la nube.

Aprenda más sobre las soluciones de nube híbrida construidas con IBM Cloud.

Para comenzar a crear sus propias soluciones de nube híbrida, regístrese para obtener un IBMid y cree su cuenta de IBM Cloud.