El problema fundamental que aborda esta arquitectura es la gestión de la complejidad y la fragmentación operacional en entornos de microservicios a escala. A medida que las organizaciones adoptan Kubernetes, la proliferación de clústeres autogestionados por equipos individuales conduce a un 'sprawl' operacional, duplicación de esfuerzos, inconsistencias en la gobernanza y una carga significativa en los equipos de infraestructura. Este escenario es una manifestación del desafío clásico de centralización vs. descentralización en la gestión de recursos computacionales, donde la descentralización inicial para la agilidad se convierte en un cuello de botella operacional a medida que la escala aumenta.
La solución propuesta por Equinix, una arquitectura de servicios compartidos sobre Amazon EKS, busca resolver este problema mediante la consolidación de la propiedad y la gestión de la infraestructura subyacente por un equipo centralizado. Esto permite estandarizar la capa de plataforma, aplicar políticas de gobernanza de manera consistente y ofrecer servicios comunes (CI/CD, observabilidad, datos) de forma centralizada. Al abstraer la complejidad de la gestión de Kubernetes de los equipos de aplicación, se busca mejorar la productividad del desarrollador y acelerar la entrega de valor, un objetivo recurrente en la ingeniería de plataformas.
Arquitectura del Sistema
La arquitectura de Equinix se basa en un modelo multi-cuenta en AWS, diseñado para separar responsabilidades y aislar dominios de seguridad y operacionales. Se definen tres cuentas principales: Workloads Account, Platform Account y Network Account.
La Workloads Account aloja los servicios de las aplicaciones en Amazon EKS, utilizando Application Load Balancer (ALB) con Kubernetes Gateway API para el ingreso de tráfico. Cilium se emplea como Container Network Interface (CNI) para la aplicación de políticas de red a nivel de pod y Hubble para la observabilidad de flujos de red. La Platform Account, gestionada por el equipo de operaciones, centraliza servicios de infraestructura compartidos como Amazon RDS, Amazon MSK, Amazon OpenSearch Service, Amazon MQ y Amazon S3, así como la infraestructura de CI/CD con GitHub Runners. El ingreso a estos servicios se realiza a través de Network Load Balancer (NLB), también con Cilium/Hubble. La Network Account actúa como un hub de conectividad, implementando una arquitectura de AWS Transit Gateway para la conectividad entre cuentas y regiones, y AWS Direct Connect Gateway para la conectividad híbrida con entornos on-premises. Amazon Route 53 Resolver gestiona la resolución DNS entre los entornos.
Esta segmentación de responsabilidades y el uso de servicios gestionados de AWS para componentes clave (EKS, RDS, MSK, OpenSearch, S3, Transit Gateway, Direct Connect, Route 53) permiten al equipo de operaciones enfocarse en la gobernanza y la estandarización, mientras que los equipos de aplicación consumen la plataforma como un servicio. La elección de Cilium para CNI y políticas de red es notable por su capacidad de aplicar reglas de seguridad granulares y su integración con Hubble para una observabilidad de red detallada, crucial en entornos multi-tenant.
Flujo de Despliegue de Aplicación
- 1 Desarrollador Push de código a repositorio de aplicación
- 2 GitHub Runners (Platform Account) Ejecuta pipeline CI/CD centralizado
- 3 Pipeline CI/CD Construye imagen de contenedor y la publica
- 4 Pipeline CI/CD Despliega recursos de Kubernetes (Deployment, Service, Gateway API) en Worklo...
- 5 Amazon EKS (Workloads Account) Orquesta el despliegue de pods de aplicación
- 6 Cilium (Workloads Account) Aplica políticas de red a nivel de pod
- 7 ALB (Workloads Account) Enruta tráfico externo a la aplicación
Flujo de Conectividad Inter-Cuenta/Híbrida
- 1 Workloads/Platform VPC Tráfico saliente hacia servicios compartidos o on-premises
- 2 AWS Transit Gateway (Network Account) Enrutamiento centralizado entre VPCs y regiones
- 3 Route 53 Resolver (Network Account) Resolución DNS para servicios internos y externos
- 4 Direct Connect Gateway (Network Account) Conectividad privada y segura a la red on-premises
- 5 Firewalls (On-premises) Inspección y filtrado de tráfico híbrido
- 6 Servicios On-premises Consumo de recursos o datos locales
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | Amazon EKS | Plataforma gestionada de Kubernetes para la orquestación de contenedores, eliminando la carga de gestión del control plane. vs Self-managed Kubernetes on EC2, Amazon ECS, Azure Kubernetes Service, Google Kubernetes Engine |
| networking | Cilium | Container Network Interface (CNI) para la red de pods y la aplicación de políticas de seguridad de red a nivel de capa 3/4 y 7. vs Calico, Flannel, AWS VPC CNI |
| observability | Hubble | Herramienta de observabilidad de red para Cilium, proporcionando visibilidad en tiempo real de los flujos de tráfico entre pods. vs Prometheus/Grafana con métricas de CNI genéricas |
| networking | AWS Transit Gateway | Hub de conectividad centralizado para interconectar VPCs de diferentes cuentas y regiones, y facilitar la conectividad híbrida. vs VPC Peering (escalabilidad limitada), VPN Site-to-Site |
| networking | Kubernetes Gateway API | API declarativa para gestionar el ingreso de tráfico a los clústeres de Kubernetes, ofreciendo más flexibilidad y control que Ingress. vs Kubernetes Ingress API |
| data-processing | Amazon RDS | Servicio de base de datos relacional gestionado, consumido por las aplicaciones desde la Platform Account. vs Self-managed databases on EC2, Amazon Aurora |
| messaging | Amazon MSK | Servicio gestionado de Apache Kafka para mensajería y streaming de datos, utilizado por las aplicaciones. vs Self-managed Kafka on EC2, Amazon Kinesis |
| observability | Amazon OpenSearch Service | Servicio gestionado para búsqueda y análisis de logs y métricas, parte de la pila de observabilidad compartida. vs Self-managed Elasticsearch/Kibana, Splunk |
Trade-offs
Ganancias
- ▲ Reducción de la sobrecarga operacional
- ▲ Aumento de la frecuencia de despliegues
- ▲ Gobernanza centralizada y estandarización
- ▲ Productividad del desarrollador
- ▲ Postura de seguridad
Costes
- △ Posible aumento de la complejidad inicial de la plataforma
- △ Dependencia de servicios gestionados de AWS
Fundamentos Teóricos
El problema de la gestión de recursos distribuidos y la coordinación entre equipos en sistemas complejos tiene raíces profundas en la informática. Conceptos como la 'separación de preocupaciones' (separation of concerns), popularizada por Edsger W. Dijkstra, son fundamentales para entender la división de responsabilidades entre las cuentas de Workloads, Platform y Network. La idea de una 'plataforma como servicio' (PaaS) o 'plataforma interna' (internal platform) es una evolución de la investigación en computación en la nube y la automatización de infraestructura, buscando abstraer la complejidad subyacente para los desarrolladores.
Aunque no hay un único paper que prediga directamente esta arquitectura específica, los principios de diseño de sistemas distribuidos, como la tolerancia a fallos, la escalabilidad y la consistencia, son omnipresentes. La gestión de la configuración y el despliegue a escala se relaciona con la investigación en 'Infrastructure as Code' y 'DevOps', que enfatizan la automatización y la colaboración. La elección de Kubernetes como orquestador se alinea con la investigación en sistemas de gestión de contenedores, que buscan optimizar la utilización de recursos y la resiliencia en entornos dinámicos. La adopción de un CNI como Cilium, con sus capacidades de eBPF, se conecta con la investigación en redes programables y la seguridad de microservicios, permitiendo una observabilidad y control de tráfico más granular a nivel de kernel.