Cómo Kilimo construyó una red cloud híbrida sin partir la plataforma

Por qué construir híbrido en lugar de reconstruir

‍

Muchos founders asumen que multi-cloud significa rediseñar la plataforma. No es así — y no debería serlo. Las arquitecturas híbridas son comunes en empresas maduras; son raras en startups, porque es más fácil enseñarle a una startup en Serie A a optimizar para una sola nube que a gestionar dos. Pero cuando ya optimizaste para una, y el capital nuevo (en créditos) depende de usar otra, la ecuación cambia. Preservás lo que funciona, extendés lo que construiste y seguís adelante. En Renaiss ayudamos a los founders a tomar esa decisión de forma técnicamente sólida — y rentable.

‍

1. Asignación de IP

‍

Resolvé esto antes que cualquier otra cosa; es el error más barato de evitar y el más caro de arreglar después.

• Sin superposición de espacio de direcciones en ningún lado. Entre ambas nubes, on-prem y — algo crítico — los rangos de pods y servicios de Kubernetes, cada CIDR tiene que ser único a nivel global. La superposición te obliga a usar NAT o renumerar, y ambas opciones son un infierno.
• Asigná en bloques resumibles. Recortá una supernet grande y repartí rangos agregables por nube (por ejemplo, un /12 para AWS, otro /12 separado para Azure) para que las tablas de rutas y los anuncios BGP se mantengan compactos. Gobernalo con herramientas de IPAM reales, no con una planilla.
• Prestá atención al apetito de IP de Kubernetes. EKS con la VPC CNI le da a cada pod una IP de VPC ruteable y puede consumir decenas de miles de direcciones; AKS obliga a elegir el CNI desde el principio (Azure CNI pone los pods en la VNet y es ruteable cross-cloud, mientras que overlay/kubenet los esconde y no lo es).
• Hacé que los CIDRs de los pods sean ruteables y no se superpongan si los pods se comunican entre nubes. La conectividad directa pod a pod solo es posible cuando ambos lados usan rangos de pods ruteables y sin conflictos.

‍

2. Fabric de conectividad y appliances

‍

Dos decisiones en capas: cómo se conectan físicamente las dos nubes, y qué se ubica en el camino para rutear e inspeccionar el tráfico.

• Cómo se conectan las nubes. Una VPN IPsec sobre internet es barata y rápida de montar, pero tiene techos por túnel y la variabilidad propia de internet público; Direct Connect + ExpressRoute dedicados, unidos en un cloud exchange (Megaport, Equinix), compran latencia y throughput predecibles a mayor costo y plazo.
• Qué se ubica en el camino. El fabric cloud-native (Transit Gateway + Virtual WAN) escala automáticamente con mínima operación pero es solo L3; los firewalls administrados (AWS Network Firewall, Azure Firewall) suman inspección; las NVA de terceros (Palo Alto, Fortinet) dan inspección L7 consistente y un solo modelo de políticas entre ambas nubes, al costo del licenciamiento y de tener que sostener vos mismo la alta disponibilidad, el escalado y el patching.
• Ruteá de forma dinámica y simétrica. Usá BGP para el failover en lugar de rutas estáticas, y diseñá caminos simétricos — el ruteo asimétrico a través de un appliance stateful es la causa clásica y silenciosa de una caída híbrida.

Para Kilimo nos mantuvimos completamente cloud-native: una VPN IPsec entre AWS Transit Gateway y Azure Virtual WAN, sin appliances de terceros. Sus volúmenes de tráfico y sus necesidades de inspección no justificaban NVAs ni un circuito dedicado, y mantener el interconnect sobre appliances administrados significó no tener que cargar con alta disponibilidad, patching ni licenciamiento — eso queda del lado de los proveedores de nube.

‍

‍

3. DNS híbrido para zonas privadas

‍

Un workload en EKS tiene que resolver un nombre privado de Azure (y viceversa) sin filtrar la consulta al DNS público.

• Forwarding condicional en ambas direcciones. Usá Route 53 Private Zones con endpoints de Resolver de entrada/salida del lado de AWS, y Azure Private DNS con el DNS Private Resolver del otro lado, cada uno reenviando el subdominio de la nube par hacia el endpoint de entrada correspondiente.
• Dale a cada nube un subdominio distinto. Namespaces separados mantienen las reglas de forwarding limpias y evitan colisiones.
• Hacé que los endpoints de resolver tengan alta disponibilidad entre AZs. Un único endpoint de resolver es un punto único de falla para toda la resolución de nombres cross-cloud.
• No te olvides de la capa del cluster. CoreDNS en cada cluster necesita reglas forward para que los workloads dentro de EKS y AKS realmente lleguen al resolver correcto.

‍

4. PKI privada con una raíz de confianza compartida

‍

En una plataforma de microservicios cross-cloud, muchas veces vas a querer mTLS o TLS interno — lo que significa una jerarquía de confianza coherente, no un montón de certificados autofirmados sueltos.

• Una raíz, intermedios por nube. Distribuí el mismo bundle de raíz en ambas nubes para que un workload en EKS confíe en un certificado emitido en AKS.
• Preferí un emisor neutral a la nube. HashiCorp Vault te da un modelo consistente de emisión y rotación, en lugar de tener que combinar ACM PCA con una CA de Azure.
• Automatizá la distribución y la rotación. Apuntá cert-manager al emisor compartido en cada cluster para que los certificados sean de corta duración y se renueven solos.

Para Kilimo esto no aplicaba — sus requisitos cross-cloud no pedían mTLS servicio a servicio, así que dejamos deliberadamente una PKI privada fuera de alcance en lugar de construir algo que no se iba a usar. Lo incluimos acá porque la mayoría de las plataformas cross-cloud terminan necesitándolo tarde o temprano, y es mucho más barato planificar la jerarquía de confianza temprano que retrofitearla después.

‍

5. Comunicación entre clusters

‍

Esta es la pregunta que amarra todo el diseño: ¿cómo llega realmente un servicio en EKS a un servicio en AKS? Hay tres respuestas amplias, en orden ascendente de capacidad y peso operacional.

• Pod a pod directo (pods ruteables) — el camino de menor latencia y el más acoplado. Exige CIDRs de pods ruteables y sin superposición en ambos lados, y ata cada cluster al direccionamiento interno del otro, así que un cambio de un lado puede repercutir en todo el interconnect.
• Load balancers internos — cada cluster expone sus servicios cross-cloud con un LB interno (un NLB interno en AWS, un Standard Load Balancer interno en Azure) accesible por el interconnect privado. El cluster que llama apunta a un endpoint de LB estable en lugar de a pods individuales, así que los dos clusters se mantienen desacoplados de los detalles a nivel pod del otro.
• Service mesh multi-cluster — Istio, Cilium Cluster Mesh o Linkerd. La opción más completa (mTLS, traffic shifting, ruteo consciente de la localidad) y la más pesada de operar.

Para Kilimo elegimos load balancers internos. Solo un puñado de servicios necesitaba hablar entre nubes, y el modelo de LB interno nos dio el mejor balance entre simplicidad y control: los clusters se mantienen desacoplados, no necesitamos hacer que los CIDRs de pods sean mutuamente ruteables, y los endpoints de LB combinan naturalmente con el forwarding condicional de DNS del punto 3 — un servicio simplemente resuelve el nombre privado del par y obtiene una dirección estable en la otra nube. Las contrapartidas son un salto de red extra y tener que sostener nosotros mismos la salud y la configuración de endpoints del LB, ambas fáciles de asumir frente a levantar y operar un mesh cross-cloud para un puñado de flujos.

‍

Qué construimos para Kilimo

‍

La topología: un hub administrado en cada nube, un interconnect IPsec entre Transit Gateway y Virtual WAN que lleva BGP, forwarding condicional de DNS entre los dos resolvers, y load balancers internos como puntos de entrada de los servicios cross-cloud. Sin appliances de terceros, sin PKI privada.

Una llamada cross-cloud sigue las líneas punteadas y sólidas juntas: un pod en EKS resuelve el nombre del servicio de Azure (el forwarding condicional le entrega la dirección del LB interno), el tráfico cruza el link IPsec vía Transit Gateway y Virtual WAN, y llega al load balancer interno de Azure que expone AKS — y de forma simétrica en reversa.

‍

Qué aprendió Kilimo

‍

Kilimo hoy orquesta su inteligencia de gestión hídrica entre AWS y Azure sin fragmentar la plataforma. La latencia es predecible, los modos de falla están entendidos, y el costo por byte de datos que cruza el interconnect es conocido y aceptable. Los créditos de Azure, que llegaron como una obligación, se convirtieron en un activo estratégico.

La lección es más amplia: híbrido no significa compromiso. Significa decisiones deliberadas, tomadas temprano. Significa conocer tu espacio de IP antes de necesitarlo, rutear el tráfico de forma simétrica antes de tener una caída, y pensar en mTLS antes de estar en medio de una auditoría de cumplimiento.

Si estás construyendo climate tech, fintech o cualquier startup con infraestructura pesada y estás frente a la misma decisión — créditos en una nube, arquitectura en otra, una misión que no puede esperar — hablemos de cómo escalar sin partir la plataforma.

‍