Módulo 14 · Multinube: AWS y Google Cloud/Lección 93
Portabilidad y dependencia del proveedor
Qué se puede mover con cambios menores, qué tiene un equivalente y qué es propietario a propósito. Por qué Kubernetes no hace portable una solución por sí solo.
⏱ 12 min
Al terminar podrás
- →Clasificar cada componente según su portabilidad
- →Estimar el costo de salida de un proveedor
- →Explicar qué cubre y qué no cubre Kubernetes
Toda decisión técnica te ata a algo: a un lenguaje, a una base de datos, a un proveedor. La dependencia del proveedor (vendor lock-in) es lo que costaría cambiar después. No es un pecado: es un intercambio. Aceptas un costo futuro a cambio de un beneficio hoy. El error es aceptarlo sin saberlo.
Tres categorías para cada componente
La tercera categoría no es mala. Es la que más valor suele dar: menos operación, más velocidad. Solo tiene que ser una decisión consciente, escrita y revisada.
La matriz, capacidad por capacidad
| Criterio | En AWS | Categoría habitual | Qué cuidar para poder salir |
|---|---|---|---|
| Plataforma de cómputo | Contenedores en ECS o EKS; funciones en Lambda | Contenedores: portable. Lambda: dependencia elegida | Separa la lógica del handler; los disparadores, permisos y formatos de evento son de AWS |
| Registro de imágenes | Amazon ECR | Portable | Las imágenes siguen el estándar OCI; cambia solo la URL y la autenticación |
| Base relacional | RDS o Aurora con PostgreSQL | Portable si usas PostgreSQL estándar | Funciones propias de Aurora (Global Database, su capa de almacenamiento) no existen fuera |
| Almacenamiento de objetos | Amazon S3 | Con equivalente | La API de S3 es un estándar de facto; las políticas, eventos y clases de almacenamiento no viajan |
| Mensajería | SQS, SNS, EventBridge; o Kafka (Amazon MSK) y RabbitMQ (Amazon MQ) | SQS/SNS/EventBridge: con equivalente. Kafka y RabbitMQ: portables | Las reglas de EventBridge y los filtros de SNS hay que reescribirlos |
| Caché | ElastiCache con Valkey o Redis OSS | Portable | El protocolo es el mismo; la configuración del clúster cambia |
| Red | VPC, subredes, security groups, Transit Gateway | Con equivalente | Los conceptos existen en todas las nubes; la configuración se rehace completa |
| Balanceo de carga | ALB y NLB | Con equivalente | HTTP y TLS son estándar; reglas, anotaciones y certificados no |
| DNS | Route 53 | Con equivalente | Los registros estándar se exportan; los alias y las políticas de enrutamiento son propios |
| Identidad | IAM, IAM Identity Center, Cognito | IAM: dependencia elegida. Federación OIDC o SAML: portable | El modelo de permisos de IAM no tiene traducción directa |
| Observabilidad | CloudWatch y X-Ray | Con equivalente | Instrumenta con OpenTelemetry: el código no cambia si cambias el destino |
| Infraestructura como código | CloudFormation y CDK; o Terraform u OpenTofu | CloudFormation: dependencia elegida. Terraform/OpenTofu: herramienta portable | La herramienta viaja; los recursos descritos siguen siendo de AWS y se reescriben |
Lo de Terraform se malinterpreta seguido: usar una herramienta multiproveedor no hace portable lo que describes con ella. Un módulo que crea un ALB y una tabla de DynamoDB hay que reescribirlo para otra nube. Más en infraestructura como código.
El costo de salida
Para estimar lo que costaría irte, suma cinco partes:
- 1
Egreso de datos
Sacar terabytes de una nube se cobra por GB. Calcula el volumen total y el tiempo de copia. Ve costos de datos. - 2
Reescritura
Cada integración propietaria (disparadores, políticas, reglas de eventos) son horas de ingeniería y pruebas. - 3
Recapacitación
El equipo, los runbooks, las alarmas y las guardias se rehacen para la nueva plataforma. - 4
Contratos
Compromisos de uso vigentes (Savings Plans, instancias reservadas, licencias) que sigues pagando aunque te vayas. - 5
Doble operación
Durante la migración pagas y operas los dos lados. Suele ser la parte que más se subestima.
Por qué Kubernetes solo no te hace portable
Un Deployment de Kubernetes corre en cualquier clúster compatible. Eso es real y valioso. Pero el clúster es solo el centro; lo que lo rodea casi nunca viaja:
- Bases de datos administradas: el pod habla con RDS o DynamoDB, que se quedan en AWS.
- Identidad: IRSA y EKS Pod Identity conectan pods con roles de IAM. En otra nube, el mecanismo es otro.
- Balanceadores: el AWS Load Balancer Controller se configura con anotaciones
alb.ingress.kubernetes.io/...que nadie más entiende. - Almacenamiento: las
StorageClassapuntan al driver de EBS (ebs.csi.aws.com). - Red: el Amazon VPC CNI da a cada pod una IP de la VPC; otros CNI funcionan distinto.
- Secretos, DNS y observabilidad: integrados con Secrets Manager, Route 53 y CloudWatch.
- Complementos administrados: los add-ons de EKS se reemplazan por los de otro proveedor.
- Y sobre todo, los datos: volúmenes, bases y buckets no se mueven con un
kubectl apply.
Kubernetes te da un lenguaje portable para describir cargas. La portabilidad de la solución depende de todo lo que conectas a él. Si no tienes otra razón para Kubernetes, ECS suele ser más simple; lo comparas en contenedores.
Técnicas de portabilidad que sí pagan
- Interfaces estándar y protocolos abiertos: SQL de PostgreSQL, HTTP, OIDC y SAML, imágenes OCI, la API de S3, OpenTelemetry, Kafka o AMQP. Cambiar de proveedor se vuelve cambiar una configuración.
- Una abstracción solo donde paga: envuelve las dos o tres piezas que de verdad podrían cambiar (por ejemplo, el envío de eventos). Envolver cada SDK agrega código, bugs y ningún beneficio.
- Datos exportables: formatos abiertos como Parquet, CSV o JSON; replicación lógica de PostgreSQL hacia cualquier otro PostgreSQL; exportaciones periódicas de DynamoDB a S3.
- Ensaya la salida: restaura un respaldo en otro entorno, fuera de AWS si el riesgo lo justifica. Mide cuánto tardas. Igual que un simulacro de DR.
- Escribe la decisión: cada dependencia elegida merece un registro con su costo de salida. Lo ves en documentar una arquitectura.
Quiz
Pon a prueba lo que aprendiste
0 de 5 correctas · 5 sin responder
1.Una aplicación usa Aurora PostgreSQL con SQL estándar, sin funciones propias de Aurora. ¿Cómo clasificas ese componente?
2.Un equipo dice: «usamos Terraform, así que somos portables entre nubes». ¿Qué es lo más preciso?
3.Una empresa migra a EKS para «no depender de AWS». Sus pods usan RDS, Pod Identity, el AWS Load Balancer Controller y volúmenes EBS. ¿Qué falta considerar?
4.Al estimar el costo de salida de un proveedor, ¿qué parte se suele subestimar más?
5.¿Cuál de estas prácticas mejora la portabilidad sin renunciar a los servicios administrados?