Commodity Cloud: Estrategia Multi-Cloud para evitar el vendor lock-in

Las nubes públicas también tienen downtime

Si trabajás en IT, seguramente recordás alguno de esos días en que uno de los grandes proveedores de nube pública decidió tomarse un descanso. Estas interrupciones parecen volverse cada vez más frecuentes; ya no nos sorprenden. La mayoría de nosotros hemos sido afectados de alguna forma: aplicaciones caídas en todo el mundo, equipos en pánico, temas en tendencia en redes sociales, y ese incómodo mensaje en el dashboard de la nube: «servicio degradado». Mientras todos preguntan cuándo van a volver los servicios, nos preguntamos: ¿por qué dependemos tanto de un solo proveedor?

La respuesta siempre fue «porque es más fácil», «porque todos usan ese proveedor», o la clásica «porque lo decidió alguien que ya no trabaja más en la empresa». Pero hoy, entre muchos SREs e ingenieros DevOps, crece una filosofía de tratar a los proveedores de nube como lo que se denomina «commodity compute»: proveedores de infraestructura básica e intercambiable.

Esto no significa que todas las nubes sean iguales, pero la idea es que deberías poder mover tus aplicaciones de una a otra sin necesidad de refactorizar la mitad del código o la infraestructura. Tiene sentido, ¿no? Pero requiere estrategia, disciplina y las herramientas adecuadas para lograrlo.

Commodity Compute — qué significa ?

Imaginá que tu infraestructura en la nube es como la electricidad: no te importa si viene de plantas solares, eólicas o hidroeléctricas — solo querés que llegue de forma consistente y poder cambiar de proveedor si uno falla o te cobra de más. Eso es el commodity compute.

En términos técnicos, significa construir tus sistemas de modo que no dependan de servicios propietarios específicos de AWS, GCP o Azure. En lugar de usar AWS Lambda, DynamoDB o S3 directamente en tu código, construís capas de abstracción que puedan funcionar con cualquier proveedor. Si mañana Google Cloud ofrece mejor relación precio-rendimiento, o Azure tiene datacenters más cerca de tus usuarios, deberías poder migrar sin reescribir toda tu aplicación.

Esto es especialmente relevante cuando recordamos que:

Las nubes han experimentado múltiples cortes, cada vez más frecuentes.
Los precios de los proveedores varían entre sí y entre regiones.
Existen costos ocultos o difíciles de estimar, como los cargos por transferencia de datos.
Ciertas regulaciones exigen que determinados datos permanezcan en ciertas regiones o países.
El vendor lock-in (quedar atado a un proveedor) elimina tu poder de negociación.

Vendor lock-in

Es como firmar una hipoteca sin leer la letra chica. Los proveedores de nube saben cómo venderte conveniencia: configuraciones rápidas, servicios integrados y ejemplos de código que «simplemente funcionan». Pero esa conveniencia tiene un precio oculto: una dependencia de servicios propietarios que no existen fuera de ese ecosistema. Después descubrís que:

Tu código está atado a servicios propietarios. Si usaste AWS Lambda con API Gateway y DynamoDB, migrar a otra nube significa reescribir una parte enorme de tu aplicación. Ese «ahorro de tiempo» inicial se convierte en deuda técnica extremadamente cara.
Perdés tu poder de negociación. El proveedor puede ofrecerte descuentos por compromiso o volumen, pero no tenés la opción de irte a la competencia sin una inversión significativa. Cuando cambiar de proveedor implica reescribir tu app, estás negociando desde una posición de debilidad. El proveedor fija precios unilateralmente y tu única alternativa es aceptarlos o embarcarte en meses de migración costosa.
La resiliencia puede ser más frágil de lo que pensás. Sí, AWS tiene múltiples zonas de disponibilidad. Pero cuando toda la región us-east-1 tiene problemas (como ya ha ocurrido), tu «99.9% de disponibilidad» se evapora. Esto no significa que estar en más de una nube garantice mágicamente el uptime, pero hay buenas prácticas que apuntan en esa dirección.

Filosofía multi-cloud: soberanía, no caos

Acá es donde entra la estrategia multi-cloud. No se trata de duplicar todo en n nubes distintas — eso sería increíblemente caro y complejo — sino de diseñar sistemas que puedan ejecutarse en distintos proveedores sin cambios mayores.

La clave está en usar tecnologías y herramientas cloud-agnostic; es decir, herramientas que funcionan igual sin importar si estás en AWS, GCP o Azure. Esto se logra principalmente a través de:

1. Kubernetes

Kubernetes se ha convertido en el gran unificador; es el estándar de oro de la infraestructura en la nube: todos los grandes proveedores lo soportan (EKS en AWS, GKE en Google, AKS en Azure), y una vez que tu aplicación corre en Kubernetes, puede — en teoría — correr en cualquier lugar.

¿Por qué es tan poderoso? Porque abstrae las diferencias entre nubes. Tu aplicación se comunica con la API de Kubernetes, no directamente con AWS o Google. Los contenedores son portables por diseño.

Ojo: también existen características específicas de cada proveedor de Kubernetes, como Auto EKS o AKS Virtual Nodes, que añaden fricción al paradigma multi-cloud. Pero no entres en pánico: existe un ecosistema masivo de herramientas open source construidas para Kubernetes que funcionan perfectamente en cualquier nube.

2. Infrastructure as Code (IaC)

Escribir infraestructura como código no es nuevo, pero hacerlo de forma agnóstica requiere disciplina. Terraform y su fork open source, OpenTofu, son los estándares de facto: permiten definir la infraestructura (servidores, redes, bases de datos) en archivos de configuración que funcionan en múltiples proveedores.

En lugar de usar CloudFormation (AWS) o Azure Resource Manager, Terraform y OpenTofu ofrecen una sintaxis y flujo de trabajo comunes. Una advertencia: cambiar de proveedor no es trivial — los recursos de AWS no son intercambiables con los de Azure — pero al menos usás el mismo lenguaje de IaC. No tenés que aprender CloudFormation, ARM Templates ni Google Deployment Manager.

Lo más importante: podés gestionar infraestructura en múltiples nubes desde un único stack, habilitando verdaderas arquitecturas multi-cloud.

3. CI/CD neutral

Este es un error común: usar AWS CodePipeline o Azure DevOps parece conveniente al principio, pero te ata. En cambio, plataformas como Jenkins, GitLab CI o GitHub Actions con runners self-hosted te dan flexibilidad total.

ArgoCD y Flux son particularmente interesantes para despliegues en Kubernetes: implementan GitOps (donde tu repositorio Git es la «única fuente de verdad»), y funcionan de manera idéntica en cualquier cluster de Kubernetes, independientemente de en qué nube esté.

Mejores prácticas para lograr independencia

1. Usá herramientas open source y estándares abiertos

En lugar de CloudWatch (AWS), usá Prometheus para métricas y Grafana para visualización. En lugar de AWS Secrets Manager, usá HashiCorp Vault. En lugar de servicios propietarios de service mesh, podés optar por Istio o Linkerd.

Estas herramientas funcionan exactamente igual en cualquier cluster de Kubernetes, en cualquier nube. Sí, requieren más configuración inicial, pero te dan libertad y portabilidad.

2. Abstraé los servicios de almacenamiento

Los buckets de almacenamiento (S3, Cloud Storage, Blob Storage) son similares pero tienen APIs diferentes. Usá bibliotecas que abstraigan esas diferencias — como s3fs, que puede trabajar con múltiples backends compatibles con S3 — o implementá tu propia capa de abstracción.

Para bases de datos, optá por soluciones que puedas ejecutar en cualquier lugar: PostgreSQL, MySQL, MariaDB o Valkey. Si bien las versiones gestionadas de los proveedores son convenientes, correr las versiones open source en Kubernetes te da portabilidad total.

3. Implementá observabilidad cloud-agnostic

La observabilidad (logs, métricas, trazas) es crítica, pero evitá las soluciones propietarias. OpenTelemetry es el estándar emergente que permite recolectar telemetría de forma unificada, independiente del proveedor.

Tu stack de observabilidad podría verse así:

OpenTelemetry para recolectar métricas y trazas.
Fluentd o Loki para logs.
Prometheus para almacenar métricas.
Grafana para visualización.
Jaeger o Tempo para trazabilidad distribuida.

Este setup funciona en cualquier nube, e incluso on-premises si fuera necesario.

4. Diseñá SLIs y SLOs neutros

En SRE, definís Service Level Indicators (SLIs) y Objectives (SLOs) para medir la confiabilidad. Estos deben ser independientes del proveedor: «99.9% de solicitudes exitosas» o «latencia p95 menor a 200ms» son métricas universales.

Al medir desde fuera del proveedor de nube (usando tus propias herramientas de monitoreo), podés comparar objetivamente el rendimiento entre proveedores. Esto no solo te da los datos para decidir dónde correr cada workload, sino también evidencia concreta si necesitás negociar precios o cambiar de proveedor.

5. Automatizá, automatizá, automatizá

El multi-cloud solo es viable si está altamente automatizado. Desplegar manualmente en tres nubes distintas sería una pesadilla; por eso necesitás:

IaC para toda la infraestructura.
GitOps para deployments (ArgoCD, Flux).
Automatización de backups cloud-agnostic (por ejemplo, Velero para Kubernetes).
Planes de Migración, DRP (Plan de Recuperación ante Desastres) y BCP (Plan de Continuidad de Negocio) regularmente testeados.
Policy as Code con herramientas como OPA (Open Policy Agent) o Kyverno.

El objetivo SRE aquí es reducir el «toil» (trabajo manual repetitivo). Si cambiar de nube requiere semanas de esfuerzo manual, no es verdaderamente portable.

Kubernetes Federation: cómo dominar entornos multi-cluster

Cuando operás en múltiples nubes, probablemente tenés varios clusters de Kubernetes. Gestionarlos uno por uno sería un caos. Acá entran las herramientas de orquestación y federación multi-cluster:

Crossplane te permite gestionar infraestructura cloud usando la API de Kubernetes, bajo licencia Apache 2.0. Básicamente, definís recursos de AWS, GCP o Azure como objetos de Kubernetes, y Crossplane los provisiona. Es IaC «a la manera de Kubernetes», completamente open source.
Karmada es un sistema de orquestación multi-cloud que permite desplegar aplicaciones en múltiples clusters simultáneamente, con políticas de distribución y failover automático. También bajo licencia Apache 2.0.
Open Cluster Management es un plano de control centralizado para gestionar clusters de Kubernetes existentes y crear nuevos. Usa el modelo hub-spoke para controlar los clusters y aprovecha herramientas como Argo CD y Open Policy Agent para orquestar políticas, deployments, recuperación ante desastres y más. Es extensible con add-ons y su licencia es Apache 2.0.

La clave es tener un plano de control unificado sin depender de soluciones propietarias como Google Anthos o Azure Arc — que, irónicamente, crean lock-in mientras prometen libertad multi-cloud.

Seguridad y Compliance en multi-cloud

En entornos multi-cloud, la seguridad requiere consistencia. No podés tener políticas distintas para cada nube, porque los errores de configuración están entre las principales causas de incidentes de seguridad según el OWASP Top 10 2025.

Para prevenirlo, debemos usar Policy as Code para definir reglas una vez y aplicarlas en todos lados. Algunas herramientas disponibles:

OPA Gatekeeper o Kyverno para políticas de Kubernetes.
Falco para detección de amenazas en runtime.
Trivy o Grype para escaneo de vulnerabilidades en contenedores.

Para Identity and Access Management (IAM), deberías implementar OIDC (OpenID Connect) con proveedores como Keycloak que podés correr en cualquier lugar, en lugar de depender completamente del IAM nativo de cada nube.

Estrategias de Migración y Recuperación ante Desastres

Una de las ventajas menos obvias del multi-cloud es la resiliencia ante desastres. Si diseñaste tu arquitectura correctamente, podés lograr:

Failover automático: ante una interrupción o degradación en una región de AWS, el tráfico se redirige automáticamente a GCP. Esto se logra mediante DNS con health checks, balanceadores de carga globales y replicación de datos entre proveedores.
Migraciones graduales: no necesitás migrar todo de una vez. Podés mover workloads específicos a distintas nubes según tus necesidades: cargas pesadas donde sean más baratas, APIs de baja latencia cerca de los usuarios, y datos sensibles en nubes con compliance certificado que cumpla las leyes locales.
Testing continuo: una parte central de la filosofía SRE es testear regularmente tus runbooks de DR. Simulá que AWS desapareció y validá que podés levantar todo en GCP en minutos, no en días.

Trade-offs: porque no todo es color de rosa

Seamos honestos: el multi-cloud no es gratis ni trivial. Hay que reconocer varios desafíos clave:

Complejidad operativa: gestionar múltiples nubes es significativamente más complejo que quedarse en una. Requiere expertise en distintos proveedores, monitorear más piezas en movimiento y mantener una huella de infraestructura más grande.
Costos iniciales: la implementación requiere una inversión real: tiempo de ingeniería, tooling especializado y automatización pesada. Es una apuesta a mediano-largo plazo, no una victoria rápida.
Networking: mover datos entre nubes es caro — muy caro. Los proveedores cobran altos egress fees, y también hay que considerar la latencia. Necesitás una arquitectura inteligente para minimizar transferencias entre nubes y reducir la latencia donde el rendimiento del servicio es crítico.
No siempre es necesario: una startup en etapa temprana probablemente no necesite multi-cloud. El enfoque «commodity» tiene más sentido para organizaciones que tienen:
Workloads críticos con tolerancia cero al downtime.
Requerimientos regulatorios complejos.
Escala suficiente para que el vendor lock-in sea un riesgo material.
El presupuesto para invertir en portabilidad.

El futuro es portable

Tratar a los proveedores de nube como commodity compute es más que una decisión técnica; es una postura estratégica sobre control, resiliencia y costos. En un mundo donde la dependencia de un único proveedor puede costarte millones en una negociación contractual desfavorable — o donde una sola interrupción puede paralizar todo tu negocio — la portabilidad es una póliza de seguro valiosa.

Los estándares abiertos y el ecosistema CNCF son maduros hoy. La parte difícil no son las herramientas. Es operarlas en producción, a escala empresarial, en múltiples nubes, sin que el toil consuma vivo a tu equipo.

No necesitás estar en tres nubes simultáneamente desde el día uno, pero sí necesitás diseñar como si pudieras estarlo mañana. Usá abstracciones, evitá servicios específicos del proveedor — especialmente cuando existen alternativas open source viables — automatizá todo y mantené tus opciones abiertas.

Porque al final del día, cuando AWS, GCP o Azure caigan (y va a pasar), vas a querer un Plan B — y será mucho más fácil de ejecutar si lo diseñaste desde el principio.

El camino hacia la independencia en la nube es largo, pero cada paso que das para reducir el vendor lock-in es un paso hacia mayor control, mejor resiliencia y una arquitectura más sostenible a largo plazo.

Recursos recomendados y referencias

Plural.sh – Mastering Multi-Cloud Kubernetes: A Practical Guide
DevOps.com – Designing Your DevOps Ecosystem for Multi-Cloud
McKinsey Digital – SRE: Boosting Cloud Resiliency and Value
Google SRE Book — La guía definitiva sobre indicadores de servicio, SLOs y reducción de toil.

Software	Sitio oficial
Kubernetes	https://kubernetes.io
OpenTofu	https://opentofu.org
Prometheus	https://prometheus.io
Grafana	https://grafana.com
OpenTelemetry	https://opentelemetry.io
Crossplane	https://www.crossplane.io
Karmada	https://karmada.io
Plural	https://www.plural.sh
Istio	https://istio.io
Linkerd	https://linkerd.io
Vault (HashiCorp)	https://developer.hashicorp.com/vault
OPA Gatekeeper	https://open-policy-agent.github.io/gatekeeper/website
Kyverno	https://kyverno.io
Falco	https://falco.org
Trivy	https://trivy.dev