Oportunidades y desafíos de la evolución tecnológica en Cloud Native

Hoy en día, Cloud Native se está volviendo cada vez más popular, y la CNCF define Cloud Native como:

• Basado en un entorno moderno y dinámico, también conocido como entorno en la nube.
• Con la contenerización como tecnología fundamental, incluyendo Service Mesh, infraestructura inmutable, API declarativa, etc.
• Las características clave incluyen escalado automático, capacidad de gestión, observabilidad, automatización, cambios frecuentes, etc.

Según la encuesta de CNCF 2021, hay un número muy significativo (más de 62,000) de contribuyentes en la comunidad de Kubernetes. Con la tendencia actual de la tecnología, cada vez más empresas están invirtiendo más costos en Cloud Native y uniéndose tempranamente a la pista para implementaciones activas en la nube. ¿Por qué las empresas están adoptando Cloud Native mientras desarrollan, y qué significa Cloud Native para ellas?

Ventajas Técnicas de Cloud Native

La popularidad de Cloud Native proviene de sus ventajas a nivel técnico. Hay dos aspectos principales de la tecnología Cloud Native, incluyendo la contenerización liderada por Docker y la orquestación de contenedores liderada por Kubernetes.

Docker introdujo las imágenes de contenedores al mundo tecnológico, convirtiendo las imágenes de contenedores en una unidad de entrega estandarizada. De hecho, antes de Docker, la tecnología de contenerización ya existía. Hablemos de una tecnología más reciente, LXC (Linux Containers) en 2008. En comparación con Docker, LXC es menos popular ya que Docker proporciona imágenes de contenedores, que pueden ser más estandarizadas y más convenientes de migrar. Además, Docker creó el servicio público DockerHub, que se ha convertido en el repositorio de imágenes de contenedores más grande del mundo. Además, la tecnología de contenerización también puede lograr un cierto grado de aislamiento de recursos, incluyendo no solo el aislamiento de CPU, memoria y otros recursos, sino también el aislamiento de la pila de red, lo que facilita la implementación de múltiples copias de aplicaciones en la misma máquina.

Kubernetes se hizo popular debido al auge de Docker. La tecnología de orquestación de contenedores, liderada por Kubernetes, proporciona varias capacidades importantes, como la autocuración de fallos, la programación de recursos y la orquestación de servicios. Kubernetes tiene un mecanismo de descubrimiento de servicios basado en DNS incorporado, y gracias a su arquitectura de programación, puede escalar muy rápidamente para lograr la orquestación de servicios.

Ahora, cada vez más empresas están adoptando activamente Kubernetes y transformando sus aplicaciones para embarcarse en la implementación de Kubernetes. Y el Cloud Native del que hablamos en realidad se basa en la premisa de Kubernetes, la piedra angular de la tecnología Cloud Native.

Ventajas de la Contenerización

1. Entrega Estandarizada

Las imágenes de contenedores se han convertido en una unidad de entrega estandarizada. Mediante la tecnología de contenerización, los usuarios pueden completar directamente la entrega a través de una imagen de contenedor en lugar de binarios o código fuente. Dependiendo del mecanismo de empaquetado de la imagen del contenedor, puedes usar la misma imagen para iniciar un servicio y producir el mismo comportamiento en cualquier entorno de ejecución de contenedores.

2. Portabilidad y Ligereza, Ahorro de Costos

La tecnología de contenerización logra cierto aislamiento mediante las capacidades del kernel de Linux, lo que a su vez facilita la migración. Además, la tecnología de contenerización puede ejecutar aplicaciones directamente, lo que es más ligero en implementación técnica en comparación con la tecnología de virtualización, sin la necesidad de un sistema operativo en la máquina virtual.

Todas las aplicaciones pueden compartir el kernel, lo que ahorra costos. Y cuanto más grande sea la aplicación, mayor será el ahorro de costos.

3. Conveniencia de la Gestión de Recursos

Al iniciar un contenedor, puedes establecer las propiedades de CPU, memoria o E/S de disco que pueden usarse para el servicio del contenedor, lo que permite una mejor planificación y despliegue de recursos al iniciar instancias de aplicaciones a través de contenedores.

Ventajas de la Orquestación de Contenedores

1. Simplifica el Flujo de Trabajo

En Kubernetes, el despliegue de aplicaciones es más fácil de gestionar que en Docker, ya que Kubernetes utiliza configuraciones declarativas. Por ejemplo, un usuario puede simplemente declarar en un archivo de configuración qué imagen de contenedor usará la aplicación y qué puertos de servicio se expondrán sin necesidad de gestión adicional. Las operaciones correspondientes a la configuración declarativa simplifican enormemente el flujo de trabajo.

2. Mejora la Eficiencia y Ahorra Costos

Otra característica ventajosa de Kubernetes es la conmutación por error. Cuando un nodo en Kubernetes falla, Kubernetes programa automáticamente las aplicaciones en él a otros nodos normales y las pone en funcionamiento. Todo el proceso de recuperación no requiere intervención y operación humana, por lo que no solo mejora la eficiencia operativa a nivel operativo, sino que también ahorra tiempo y costos.

Con el auge de Docker y Kubernetes, verás que su aparición ha traído una gran innovación y oportunidad a la entrega de aplicaciones. Las imágenes de contenedores, como unidades de entrega estándar, acortan el proceso de entrega y facilitan la integración con sistemas CI/CD.

Considerando que la entrega de aplicaciones se está volviendo más rápida, ¿cómo está siguiendo la arquitectura de aplicaciones la tendencia de Cloud Native?

Evolución de la Arquitectura de Aplicaciones: de Monolíticas, Microservicios a Service Mesh

El punto de partida de la evolución de la arquitectura de aplicaciones sigue siendo la arquitectura monolítica. A medida que el tamaño y los requisitos de las aplicaciones aumentaron, la arquitectura monolítica ya no satisfacía las necesidades del desarrollo colaborativo en equipo, por lo que gradualmente se introdujeron arquitecturas distribuidas.

Entre las arquitecturas distribuidas, la más popular es la arquitectura de microservicios. La arquitectura de microservicios puede dividir los servicios en múltiples módulos, que se comunican entre sí, completan el registro y descubrimiento de servicios, y logran capacidades comunes como la limitación de flujo y el corte de circuito.

Además, hay varios patrones incluidos en una arquitectura de microservicios. Por ejemplo, el patrón de base de datos por servicio, que representa cada microservicio con una base de datos individual, es un patrón que evita el impacto a nivel de base de datos en la aplicación, pero puede introducir más instancias de bases de datos.

Otro es el patrón de API Gateway, que recibe el tráfico de entrada del clúster o de toda la arquitectura de microservicios a través de una puerta de enlace y completa la distribución del tráfico a través de APIs. Este es uno de los patrones más utilizados, y productos de puerta de enlace como Spring Cloud Gateway o Apache APISIX pueden aplicarse.

Las arquitecturas populares se están extendiendo gradualmente a arquitecturas Cloud Native. ¿Puede una arquitectura de microservicios bajo Cloud Native simplemente construir el microservicio original como una imagen de contenedor y migrarlo directamente a Kubernetes?

En teoría, parece posible, pero en la práctica hay algunos desafíos. En una arquitectura de microservicios Cloud Native, estos componentes necesitan ejecutarse no solo en contenedores, sino también incluir otros aspectos como el registro, descubrimiento y configuración de servicios.

El proceso de migración también implica transformación y adaptación a nivel de negocio, requiriendo la migración de lógica común como autenticación, autorización y capacidades relacionadas con la observabilidad (registros, monitoreo, etc.) a K8s. Por lo tanto, la migración desde el despliegue original en máquinas físicas a la plataforma K8s es mucho más compleja de lo que parece.

En este caso, podemos usar el modelo Sidecar para abstraer y simplificar el escenario anterior.

Normalmente, el modelo Sidecar viene en forma de un Sidecar Proxy, que evoluciona del lado izquierdo del diagrama siguiente al lado derecho al sumergir algunas capacidades genéricas (como autenticación, autorización, seguridad, etc.) en Sidecar. Como se puede ver en el diagrama, este modelo se ha adaptado de requerir el mantenimiento de múltiples componentes a requerir solo dos cosas (aplicación + Sidecar) para mantener. Al mismo tiempo, el modelo Sidecar en sí contiene algunos componentes comunes, por lo que no necesita ser mantenido por el lado del negocio, resolviendo fácilmente el problema de la comunicación de microservicios.

Para evitar las escenas complejas de configuración separada y construcción repetida de ruedas al introducir un Sidecar para cada microservicio, el proceso puede implementarse introduciendo un plano de control o mediante inyección del plano de control, lo que gradualmente forma el actual Service Mesh.

Service Mesh generalmente requiere dos componentes, es decir, plano de control + plano de datos. El plano de control completa la distribución de la configuración y la ejecución de la lógica relacionada, como Istio, que es actualmente el más popular. En el plano de datos, puedes elegir una puerta de enlace API como Apache APISIX para el reenvío de tráfico y la comunicación de servicios. Gracias al alto rendimiento y escalabilidad de APISIX, también es posible realizar algunos requisitos de personalización y lógica personalizada. A continuación se muestra la arquitectura de la solución Service Mesh con Istio+APISIX.

La ventaja de esta solución es que cuando deseas migrar de la arquitectura de microservicios anterior a una arquitectura Cloud Native, puedes evitar cambios masivos en el lado del negocio utilizando directamente una solución Service Mesh.

Desafíos Técnicos de Cloud Native

El artículo anterior mencionó algunas de las ventajas de la tendencia actual de Cloud Native en términos técnicos. Sin embargo, cada moneda tiene dos caras. Aunque pueden traer algunos elementos frescos y oportunidades, también surgirán desafíos debido a la participación de ciertas tecnologías.

Problemas Causados por la Contenerización y K8s

En la parte inicial del artículo, mencionamos que la tecnología de contenerización utiliza un kernel compartido, y el kernel compartido trae ligereza pero crea una falta de aislamiento. Si ocurre un escape de contenedor, el host correspondiente puede ser atacado. Por lo tanto, para enfrentar estos desafíos de seguridad, se han introducido tecnologías como los contenedores seguros.

Además, aunque las imágenes de contenedores proporcionan un método de entrega estandarizado, son propensas a ser atacadas, como los ataques a la cadena de suministro.

De manera similar, la introducción de K8s también ha traído desafíos en la seguridad de los componentes. El aumento en los componentes ha llevado a un aumento en la superficie de ataque, así como vulnerabilidades adicionales relacionadas con los componentes subyacentes y niveles de dependencia. A nivel de infraestructura, migrar de máquinas físicas o virtuales tradicionales a K8s implica costos de transformación de infraestructura y más costos laborales para realizar copias de seguridad de datos del clúster, actualizaciones periódicas y renovaciones de certificados.

Además, en la arquitectura de Kubernetes, el apiserver es el componente central del clúster y necesita manejar todo el tráfico interno y externo. Por lo tanto, para evitar problemas de seguridad en la frontera, cómo proteger el apiserver también se convierte en una pregunta clave. Por ejemplo, podemos usar Apache APISIX para protegerlo.

Seguridad

El uso de nuevas tecnologías requiere atención adicional a nivel de seguridad:

• A nivel de seguridad de red, se puede implementar un control granular del tráfico mediante Network Policy, u otros métodos de cifrado de conexiones como mTLS para formar una red de confianza cero.

• A nivel de seguridad de datos, K8s proporciona el recurso secret para manejar datos confidenciales, pero en realidad, no es seguro. Los contenidos del recurso secret están codificados en Base64, lo que significa que puedes acceder a los contenidos mediante decodificación Base64, especialmente si se colocan en etcd, que puede leerse directamente si tienes acceso a etcd.

• A nivel de seguridad de permisos, también hay una situación en la que los ajustes de RBAC no son razonables, lo que lleva a un atacante a usar el Token relevante para comunicarse con el apiserver para lograr el propósito del ataque. Este tipo de configuración de permisos se ve principalmente en escenarios de controlador y operador.

Observabilidad

La mayoría de los escenarios de Cloud Native involucran algunas operaciones relacionadas con la observabilidad, como el registro, monitoreo, etc.

En K8s, si deseas recopilar registros de varias maneras, necesitas recopilarlos directamente en cada nodo de K8s mediante agregación. Si los registros se recopilaran de esta manera, la aplicación necesitaría exportarse a la salida estándar o errores estándar.

Sin embargo, si el negocio no realiza cambios relevantes y aún elige escribir todos los registros de la aplicación en un archivo en el contenedor, significa que se necesita un Sidecar para la recopilación de registros en cada instancia, lo que hace que la arquitectura de despliegue sea extremadamente compleja.

Volviendo al nivel de gobernanza de la arquitectura, la selección de soluciones de monitoreo en el entorno Cloud Native también plantea algunos desafíos. Una vez que la selección de la solución es incorrecta, el costo de uso posterior es muy alto, y la pérdida puede ser enorme si la dirección es incorrecta.

Además, hay problemas de capacidad involucrados a nivel de monitoreo. Al desplegar una aplicación en K8s, puedes simplemente configurar su limitación de tasa para limitar los detalles de recursos que la aplicación puede usar. Sin embargo, en un entorno de K8s, todavía es bastante fácil sobrevender recursos, sobreutilizar recursos y desbordar la memoria debido a estas condiciones.

Además, otra situación en un clúster de K8s donde todo el clúster o nodo se queda sin recursos llevará a la expulsión de recursos, lo que significa que los recursos ya en ejecución en un nodo son expulsados a otros nodos. Si los recursos de un clúster son limitados, una tormenta de nodos puede fácilmente hacer que todo el clúster colapse.

Evolución de la Aplicación y Patrón de Multi-clúster

A nivel de evolución de la arquitectura de aplicaciones, el problema central es el descubrimiento de servicios.

K8s proporciona un mecanismo de descubrimiento de servicios basado en DNS por defecto, pero si el negocio incluye la coexistencia de negocios en la nube y negocios existentes, será más complicado usar un mecanismo de descubrimiento de servicios DNS para manejar la situación.

Mientras tanto, si las empresas eligen la tecnología Cloud Native, con la expansión de la escala del negocio, gradualmente considerarán la dirección del procesamiento de múltiples nodos, lo que luego involucrará problemas de multi-clúster.

Por ejemplo, queremos proporcionar a los clientes un modelo de mayor disponibilidad a través de múltiples clústeres, y esta vez involucrará la orquestación de servicios entre múltiples clústeres, la distribución de carga multi-clúster y la sincronización de configuración, y cómo manejar y desplegar estrategias para clústeres en escenarios de multi-nube y nube híbrida. Estos son algunos de los desafíos que se enfrentarán.

Cómo APISIX Habilita la Transformación Digital

Apache APISIX es una puerta de enlace API Cloud Native bajo la Apache Software Foundation, que es dinámica, en tiempo real y de alto rendimiento, proporcionando ricas características de gestión de tráfico como equilibrio de carga, upstream dinámico, lanzamiento canario, corte de circuito, autenticación, observabilidad, etc. Puedes usar Apache APISIX para manejar tráfico tradicional norte-sur, así como tráfico este-oeste entre servicios.

Actualmente, basado en la evolución arquitectónica y los cambios de aplicación descritos anteriormente, también se han derivado soluciones de controlador Ingress y Service Mesh basadas en APISIX en Apache APISIX para ayudar a las empresas a llevar a cabo mejor la transformación digital.

Solución APISIX Ingress

Apache APISIX Ingress Controller es una implementación de Kubernetes Ingress Controller que sirve principalmente como una puerta de enlace de tráfico para manejar el tráfico norte-sur de Kubernetes.

La arquitectura de APISIX Ingress Controller es similar a APISIX en que es una arquitectura separada para el plano de control y el plano de datos. En este caso, APISIX se utiliza como el plano de datos para el procesamiento real del tráfico.

Actualmente, APISIX Ingress Controller admite los siguientes tres métodos de configuración y es compatible con todos los complementos de APISIX de inmediato:

• Soporte para recursos Ingress nativos de K8s. Este enfoque permite que APISIX Ingress Controller tenga un mayor nivel de adaptabilidad. Hasta ahora, APISIX Ingress Controller es la versión más soportada de cualquier producto de controlador Ingress de código abierto e influyente.

• Soporte para usar recursos personalizados. Los recursos personalizados actuales de APISIX Ingress Controller son un conjunto de especificaciones CRD diseñadas según la semántica de APISIX. Usar recursos personalizados facilita la integración con APISIX y es más nativo.

• Soporte para Gateway API. Como la próxima generación del estándar Ingress, APISIX Ingress Controller ha comenzado a soportar Gateway API (etapa Beta). A medida que evoluciona Gateway API, es probable que se convierta en un recurso incorporado para K8s directamente.

APISIX Ingress Controller tiene las siguientes ventajas sobre Ingress NGINX:

• Separación arquitectónica. En APISIX Ingress, la arquitectura del plano de datos y el plano de control están separados. Cuando la presión del procesamiento de tráfico es alta y deseas expandir la capacidad, simplemente puedes hacer la expansión del plano de datos, lo que permite que más planos de datos sean servidos externamente sin necesidad de hacer ajustes en el plano de control.

• Alta escalabilidad y soporte para complementos personalizados.

• Como elección del plano de datos, con alto rendimiento y características completamente dinámicas. Gracias a la característica completamente dinámica de APISIX, es posible proteger el tráfico del negocio tanto como sea posible con el uso de APISIX Ingress.

Actualmente, APISIX Ingress Controller es utilizado por muchas empresas en todo el mundo, como China Mobile Cloud Open Platform (un producto de API abierta y IDE en la nube), Upyun y Copernicus (parte de Europe's Eyes on Earth).

APISIX Ingress Controller sigue en iteración continua, y planeamos mejorar más funciones de las siguientes maneras:

1. Completar el soporte para Gateway API para habilitar más configuraciones de escenarios.
2. Soporte para proxy de servicios externos.
3. Soporte nativo para múltiples registros para hacer que APISIX Ingress Controller sea más versátil.
4. Actualizaciones arquitectónicas para crear un nuevo modelo arquitectónico;
5. Integración con Argo CD/Flux y otras herramientas GitOps para crear un ecosistema rico.

Si estás interesado en la solución APISIX Ingress, no dudes en seguir las actualizaciones de la comunidad para iteraciones de productos y tendencias de la comunidad.

Solución APISIX Service Mesh

Actualmente, además de la puerta de enlace API y la solución Ingress, la solución Service Mesh basada en APISIX también está en iteración activa.

La solución Service Mesh basada en APISIX consta de dos componentes principales, a saber, el plano de control y el plano de datos. Istio fue elegido para el plano de control ya que es un líder de la industria con una comunidad activa y es soportado por múltiples proveedores. APISIX fue elegido para reemplazar a Envoy en el lado de los datos, permitiendo que el alto rendimiento y escalabilidad de APISIX entren en juego.

El Service Mesh de APISIX todavía se está persiguiendo activamente, con iteraciones posteriores planificadas en las siguientes direcciones:

• Realizar aceleración eBPF para mejorar la efectividad general.

• Realizar integración de capacidades de complementos para permitir un mejor uso de las capacidades de APISIX Ingress dentro de la arquitectura Service Mesh.

• Crear una herramienta de migración sin problemas para proporcionar herramientas más fáciles y simplificar el proceso para los usuarios.

En general, la evolución de la arquitectura y la tecnología en la era de Cloud Native nos trae tanto oportunidades como desafíos. Apache APISIX como una puerta de enlace Cloud Native se ha comprometido a más adaptaciones e integraciones técnicas para la tendencia de Cloud Native. Varias soluciones basadas en APISIX también han comenzado a ayudar a los usuarios empresariales a llevar a cabo la transformación digital y ayudar a las empresas a transicionar a la pista de Cloud Native más suavemente.