No notas el bloqueo cuando el tablero está en verde y el ingeniero de ventas sigue respondiendo en menos de cinco minutos.
Lo notas cuando una interrupción se alarga porque las únicas personas que pueden arreglarla son un equipo de escalado del proveedor en otra zona horaria,
y tu «exportación estándar» resulta ser una nota de rehenes con formato educado.
El bloqueo raramente es una única mala decisión. Es el interés compuesto de pequeñas comodidades: APIs propietarias, add-ons gestionados,
controladores especiales, facturación opaca y contratos escritos como si los diseñara un entusiasta de los laberintos.
Qué es realmente el bloqueo por proveedor (y qué no es)
El bloqueo por proveedor no es «usamos un producto». Es «no podemos irnos sin sufrir una caída material, un golpe financiero o un incumplimiento de cumplimiento».
La diferencia importa porque todo sistema serio depende de proveedores. La meta no es pureza. La meta es apalancamiento.
Los tres tipos de bloqueo (y cómo reconocer cada uno)
-
Bloqueo técnico: APIs propietarias, formatos, controladores o planos de control que se incrustan en tu app y operaciones.
Lo reconoces cuando “migrar” significa “reescribir”. -
Bloqueo económico: tarifas de egress, compromisos a largo plazo o modelos de precios que castigan la portabilidad.
Lo reconoces cuando el CFO aparece de repente en tus reuniones de arquitectura. -
Bloqueo operativo: solo el personal del proveedor puede depurar ciertos modos de fallo, o tu equipo deja de entender el sistema porque el proveedor lo oculta.
Lo reconoces cuando tu canal de incidentes contiene la frase «esperando al proveedor».
El bloqueo no siempre es malvado. A menudo es deuda no pagada.
Parte del bloqueo es un intercambio explícito: «Aceptamos funciones propietarias porque la velocidad importa más que la portabilidad».
Eso puede ser racional—si valoras la salida por adelantado, mantienes tus datos portables y conservas una ruta de escape que no sea imaginaria.
La mayoría de los equipos no hace nada de eso. Tratan «podemos migrar siempre más tarde» como si fuera una característica, no un proyecto.
Una heurística práctica: si no puedes explicar tu plan de salida en diez minutos, no tienes un plan de salida. Tienes esperanza.
Hechos y contexto histórico que puedes usar en reuniones
Un poco de historia ayuda porque el bloqueo no es una invención moderna de la nube. Es un patrón antiguo con sudadera.
Aquí tienes puntos concretos que puedes usar para dirigir decisiones sin sonar como alguien que teme el cambio.
-
1960s–1970s: el “bundling” de IBM modeló la industria. El desempaquetado del software del hardware creó un ecosistema,
pero también enseñó a los proveedores que los planos de control y las interfaces propietarias son poder. -
1980s: proliferaron variantes de Unix propietarias. La portabilidad existía, pero “portable” a menudo significaba
“recompilar y rezar”, con herramientas específicas del proveedor que se colaban. -
1990s: los arrays de almacenamiento empresariales se volvieron ecosistemas. No solo comprabas discos; comprabas software de gestión,
funciones de replicación y firmware especial—más la idea de que irse sería desagradable. -
Inicios de 2000: la virtualización redujo algunos bloqueos y creó otros nuevos. Fue más fácil mover cargas como “VMs”,
pero los ecosistemas de hipervisores (plugins de backup, drivers, orquestación) se volvieron pegajosos. -
2010s: la nube hizo que la portabilidad pareciera fácil—hasta que llegó la gravedad de los datos. Mover compute suele ser un fin de semana. Mover muchos petabytes
es una temporada, a veces un año fiscal. -
Los contenedores revivieron el sueño de la portabilidad. Pero el lock-in real a menudo se trasladó a planos de control gestionados
(IAM, bases de datos gestionadas, add-ons de Kubernetes gestionados, observabilidad propietaria). -
La API de S3 se volvió un estándar de facto. Eso ayudó la portabilidad para almacenamiento de objetos, pero no para las políticas de ciclo de vida,
integración de identidad, eventos y ataduras analíticas alrededor. -
“Open source” no es automáticamente “portable”. Los servicios gestionados de código abierto aún pueden bloquearte mediante
extensiones propietarias, modelos de facturación y dependencia operativa del proveedor.
Idea parafraseada, atribuida a Werner Vogels (CTO de Amazon): Todo falla, todo el tiempo—así que diseña para la falla como estado por defecto.
El bloqueo es lo que ocurre cuando diseñas solo para el éxito.
Modos de fallo por lock-in: dónde muerde primero en ops
1) Tus datos son “exportables” pero no “utilizables”
A los proveedores les encanta la palabra “exportar”. ¿Exportar en qué formato? ¿Con qué metadatos? ¿Con qué checksums? ¿Con qué garantías de ordenamiento?
¿Preserva ACLs, timestamps, versiones de objetos, locks de retención, retenciones legales, contexto de KMS y trazas de auditoría?
Si tu historia de cumplimiento depende de eso, “exportar” sin fidelidad es una infracción esperando ocurrir.
2) El plano de control se convierte en punto único de fallo
Muchos servicios gestionados son operativamente sólidos hasta el día en que el plano de control titubea.
Si no puedes rotar credenciales, no puedes crear volúmenes, no puedes reprogramar nodos, no puedes ver métricas, no puedes abrir casos de soporte por problemas de SSO—felicidades,
tu respuesta a incidentes ahora depende de una interfaz web.
3) “Gestionado” significa “no tienes los mandos que necesitas durante un incidente”
En un incidente de almacenamiento quieres límites de IOPS, control de profundidad de cola, throttling por inquilino, visibilidad del lag de replicación
y la capacidad de aislar vecinos ruidosos. En un servicio gestionado, esos mandos pueden existir solo como “contacta soporte”.
Eso no es un mando. Eso es un ticket.
4) La facturación es el riesgo de disponibilidad oculto
El egress y el precio por solicitudes pueden alterar decisiones de arquitectura bajo presión. Los equipos empiezan a hacer cosas inseguras—como desactivar replicación,
comprimir logs “más tarde” o estirar ventanas de retención—porque alguien se asustó por una factura inesperada.
Cuando el costo es una sorpresa, la fiabilidad se vuelve negociable.
Broma #1: El bloqueo por proveedor es como el minibar de un hotel—no notas los precios hasta que ya tienes sed y te quedaste sin opciones.
5) La habilidad se atrofia: tu equipo deja de saber cómo funciona el sistema
El bloqueo no es solo tecnología. Es cognición. Si la caja negra del proveedor funciona “bien” por dos años, el equipo olvida
cómo ejecutar el equivalente por sí mismo. Luego el proveedor cambia términos, descontinúa una función o tiene un evento regional. De repente estás migrando
con un equipo que ya no tiene la memoria muscular.
6) Tu línea de tiempo de incidentes incluye “compras/procurement”
En el momento en que tu plan de DR necesita una licencia de último minuto, una renegociación o la aprobación de un gestor de cuenta del proveedor, no tienes un plan de DR.
Tienes un póster motivacional.
Tres mini-historias desde las trincheras corporativas
Mini-historia #1: La interrupción causada por una suposición errónea (la trampa del “API estándar”)
Una fintech de tamaño mediano reconstruyó una canalización de documentos alrededor de almacenamiento de objetos “compatible con S3”, provisto por un proveedor especializado que prometía
baja latencia y funciones de cumplimiento integradas. El equipo de desarrollo fue cuidadoso: usaron el SDK de S3, evitaron endpoints específicos del proveedor
e incluso escribieron pruebas de integración contra un emulador S3 local. Lo consideraron portable.
Entonces legal pidió una exportación completa de un subconjunto de objetos con prueba de retención inmutable—versiones de objetos, modo de retención y logs de acceso—por una auditoría.
El equipo supuso que podrían extraer eso vía APIs estándar de S3. El proveedor sí soportaba las APIs básicas de objetos, claro. Pero la cadena de pruebas de cumplimiento
vivía en servicios de metadatos propietarios y en una canalización de logs de auditoría propietaria.
Exportar “los datos” fue fácil. Exportar “los datos más la evidencia” no lo fue. Pasaron días ensamblando una cadena de custodia manualmente,
parseando dump CSV proporcionados por el proveedor y discutiendo sobre la precisión de timestamps. Mientras tanto, un release quedó bloqueado porque cumplimiento no podía aprobar.
El fallo no fue incompetencia técnica. Fue una suposición: “Si la API de datos es estándar, la semántica operacional también lo es.”
No lo son. La compatibilidad con S3 puede cubrir lecturas y escrituras mientras todo lo que importa en entornos regulados—retención, legal hold, trazas de auditoría, gestión de claves—permanece propietario.
La corrección fue dolorosa pero esclarecedora: definieron un “contrato de portabilidad” para almacenamiento, incluyendo qué metadatos deben ser extractables, en qué formato
y cómo se validarán. También empezaron a replicar logs de cumplimiento en un sistema independiente que controlaban, incluso si el proveedor almacenaba los objetos.
Más coste. Mucho más apalancamiento.
Mini-historia #2: La optimización que salió mal (el incidente del “vamos a usar la función mágica del proveedor”)
Una compañía de e-commerce tenía una flota PostgreSQL muy ocupada y mucho tráfico de lectura. Migraron a una oferta de base de datos gestionada y se enamoraron inmediatamente
de una función del proveedor: escalado de lectura casi sin configuración con réplicas de lectura propietarias y una capa de enrutamiento transparente.
El rendimiento mejoró. El equipo celebró. Luego se pusieron ambiciosos: canalizaron cargas de trabajo intensivas en lectura, consultas analíticas y algunos endpoints críticos
a través del router del proveedor. Era conveniente. También era una nueva dependencia que no era visible en el código de la aplicación.
Durante un evento de red regional, la capa de enrutamiento degradó de una forma que no parecía problema de base de datos. Las conexiones se aceptaban y luego se quedaban atascadas.
Los timeouts se multiplicaron. La aplicación escaló automáticamente, empeorando la situación. Su runbook decía “fallar a réplicas autogestionadas”. Excepto que la aplicación
ya no tenía una cadena de conexión sencilla para hacerlo. El router era ahora el contrato.
Escaparon añadiendo una capa explícita de acceso a la base de datos en su plataforma: los endpoints de conexión se abstrajeron detrás de DNS interno,
y el router del proveedor se convirtió en una implementación, no en la implementación. También añadieron una ruta de emergencia “directa-al-primary” y la probaron trimestralmente.
La lección: las optimizaciones que te quitan mandos no son optimizaciones. Son externalizar tu capacidad de improvisar.
Mini-historia #3: La práctica aburrida pero correcta que salvó el día (la victoria del “simulacro de salida”)
Una empresa SaaS del sector salud ejecutaba una mezcla de servicios cloud y almacenamiento on-prem, y tenían una regla profundamente poco sexy: cada trimestre,
hacían un “simulacro de salida” para una dependencia crítica. No una migración completa. Un ensayo. El objetivo era demostrar que podían mover una porción representativa de datos de producción,
validarlos y ejecutar una carga de trabajo clave en otro entorno.
Mantenían una segunda configuración de proveedor de identidad en “standby frío”, conservaban módulos Terraform agnósticos al proveedor cuando era posible,
y almacenaban su material de claves de encriptación de forma que pudiera rehidratarse fuera de un único KMS de nube. También documentaron las partes molestas:
qué cuotas de servicio necesitaban aprobación previa, qué cambios DNS eran necesarios y qué equipos debían firmar.
Un año, su proveedor de nube primario tuvo un incidente de plano de control que bloqueó el aprovisionamiento y rompió partes de su pipeline CI/CD.
No catastrófico, pero se alargó durante horas de negocio, que en salud es mucho tiempo para estar “algo caído”.
Su respuesta no fue heroica. Fue procedural. Cambiaron un subconjunto de cargas de clientes al entorno alternativo usando pesos DNS preplanificados,
restauraron desde backups replicados continuamente y mantuvieron los servicios. Nadie escribió un postmortem viral. Ese es el punto.
La práctica aburrida que los salvó fue un ejercicio trimestral que los ejecutivos una vez cuestionaron. Tras ese incidente, nadie lo volvió a cuestionar.
Guía de diagnóstico rápido: encuentra el cuello de botella antes de culpar al proveedor
Cuando las cosas se tuercen, el bloqueo por proveedor amplifica el pánico porque reduce tus opciones. Tu trabajo es separar
“el sistema está lento” de “estamos atrapados”. Aquí está el orden de triaje rápido que uso en producción.
Primero: confirma el radio de explosión y si es plano de control o plano de datos
- Síntomas del plano de control: no se pueden crear recursos, no se puede cambiar la configuración, auth/SSO roto, paneles caídos, llamadas API fallando rápido.
- Síntomas del plano de datos: lecturas/escrituras con timeout, picos de latencia, lag de replicación creciente, colapso de throughput.
Segundo: identifica la clase de cuello de botella
- Red: pérdida de paquetes, mismatch de MTU, problemas TLS, enrutamiento cross-region raro, enlaces saturados.
- Almacenamiento: límites de IOPS/throughput, profundidad de cola, throttling, vecino ruidoso, contrapresión de replicación.
- Cómputo: CPU steal, presión de memoria, pausas de GC, agotamiento de pools de hilos, límites del kernel.
- Límites de servicio: cuotas, límites de tasa, caps de conexión, throttling de API.
- Comportamiento de la app: tormentas de retry, thundering herd, rollout malo, consultas ineficientes.
Tercero: decide si necesitas una vía de escape ahora
Una vía de escape no es “migrar todo”. Es “reducir la dependencia rápidamente”. Ejemplos:
cambiar el tráfico de lectura a respuestas cacheadas, fallar a un endpoint DB más simple, detener temporalmente escrituras no críticas,
o enrutar descargas de objetos a través de un CDN que controles en lugar del endpoint del proveedor.
Broma #2: El mejor momento para diseñar una estrategia de salida fue el año pasado. El segundo mejor momento es antes de que tu pager empiece a componer poesía.
Manos a la obra: 14 tareas reales para medir el lock-in y planear una salida
Estas son intencionalmente prácticas. Cada tarea incluye: un comando, salida realista, qué significa y la decisión que tomas.
Ejecútalas en un host representativo (o en CI) y pega resultados en tus notas de arquitectura.
Tarea 1: Inventario de agentes propietarios y daemons del proveedor
cr0x@server:~$ systemctl list-units --type=service --state=running | egrep -i 'agent|vendor|backup|snap|replic|monitor' | head
vendorx-agent.service loaded active running VendorX Node Agent
backup-appliance-connector.service loaded active running Backup Appliance Connector
node-exporter.service loaded active running Prometheus Node Exporter
Qué significa: Tienes al menos un agente específico del proveedor en la ruta crítica. Eso no es automáticamente malo, pero es una dependencia.
Decisión: Para cada servicio propietario, documenta: qué falla si para, cómo eliminarlo y qué reemplaza su función.
Tarea 2: Identificar módulos/driver del kernel que te atan a una plataforma
cr0x@server:~$ lsmod | egrep -i 'nvme|virtio|vendor|mlx|zfs' | head
nvme 57344 2
virtio_net 45056 0
mlx5_core 942080 0
zfs 4157440 3
Qué significa: Los módulos estándar están bien. Un módulo de kernel específico del proveedor es un riesgo de migración (diferentes kernels, firmado, soporte).
Decisión: Si ves un driver del proveedor, planifica un arranque de prueba sin él en staging y valida rendimiento/funcionalidad.
Tarea 3: Cuantificar la gravedad de los datos (cuánto tendrías que mover)
cr0x@server:~$ df -hT | egrep -v 'tmpfs|overlay'
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p2 ext4 1.8T 1.2T 530G 70% /
/dev/nvme1n1 ext4 7.0T 6.6T 110G 99% /data
Qué significa: 6.6T de datos calientes no es “simplemente copiarlos”. Es tiempo, ancho de banda y validación. A 200 MB/s efectivo, eso son ~9.2 horas mínimo, antes de verificación y reintentos.
Decisión: Clasifica datasets en: debe-migrar, puede-reconstruirse, puede-expirar. Los planes de salida se ganan eliminando datos, no copiándolos.
Tarea 4: Medir rendimiento real del disco vs expectativas
cr0x@server:~$ fio --name=randread --filename=/data/fio.test --size=8G --direct=1 --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=30 --time_based --group_reporting
randread: (groupid=0, jobs=4): err= 0: pid=2213: Tue Feb 4 10:21:31 2026
read: IOPS=58.2k, BW=227MiB/s (238MB/s)(6815MiB/30001msec)
slat (usec): min=3, max=612, avg=12.1, stdev=6.3
clat (usec): min=121, max=48912, avg=2188.4, stdev=1330.2
lat (usec): min=138, max=48926, avg=2200.9, stdev=1330.5
Qué significa: Ahora puedes comparar los IOPS/latencias medidos con las afirmaciones del proveedor y con tus SLOs. La latencia en cola alta (max ~49ms) puede dañar bases de datos.
Decisión: Si la latencia tail es alta, no adoptes una característica de plataforma que asuma latencia de almacenamiento predecible (algunos tiers de DB gestionada lo hacen).
Tarea 5: Detectar throttling de almacenamiento o IO wait bajo carga
cr0x@server:~$ iostat -xz 1 5
avg-cpu: %user %nice %system %iowait %steal %idle
12.30 0.00 3.10 24.80 0.00 59.80
Device r/s w/s rkB/s wkB/s await svctm %util
nvme1n1 820.0 410.0 98000 42000 18.4 0.9 98.7
Qué significa: %util alto y await alto sugieren que el dispositivo está saturado o throttled. Si este dispositivo es “gestionado”, puede que no tengas mandos.
Decisión: Si la saturación es frecuente, planifica una ruta de migración a almacenamiento donde puedas escalar IOPS de forma independiente o añadir cache.
Tarea 6: Comprobar opciones de filesystem y montaje que pueden bloquear la portabilidad
cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /data
/data /dev/nvme1n1 ext4 rw,noatime,nodiratime,discard
Qué significa: Opciones de montaje como discard, noatime son portables; pero algunos filesystems (o funciones como reflinks, compresión) pueden cambiar los requisitos de la herramienta de migración.
Decisión: Estandariza en funciones de filesystem portables para datos “movibles”; reserva las funciones avanzadas para datos que puedas regenerar.
Tarea 7: Validar que puedes exportar y restaurar una base de datos lógicamente
cr0x@server:~$ pg_dump --format=custom --file=/tmp/appdb.dump --dbname=postgresql://app@db01/appdb
pg_dump: dumping contents of database "appdb" ...
pg_dump: finished
Qué significa: Los dumps lógicos son portables entre muchos entornos (con matices). Si pg_dump es demasiado lento o demasiado grande, dependes de snapshots físicos—a menudo atados al proveedor.
Decisión: Si no puedes completar un dump lógico en tu ventana RTO/RPO, invierte en replicación lógica o patrones de doble escritura antes de que te obliguen a migrar.
Tarea 8: Comprobar si tu infraestructura está pegada a un proveedor vía Terraform state y providers
cr0x@server:~$ terraform providers
Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/aws] ~> 5.0
├── provider[registry.terraform.io/hashicorp/kubernetes] ~> 2.0
└── provider[registry.terraform.io/hashicorp/helm] ~> 2.0
Providers required by state:
provider[registry.terraform.io/hashicorp/aws]
Qué significa: Si el state está dominado por un proveedor, la migración requiere importar a un nuevo state o reconstruir—ambas riesgosas bajo presión de tiempo.
Decisión: Introduce un límite de abstracción: módulos que puedan apuntar a múltiples backends y estados separados por entorno y clase de dependencia.
Tarea 9: Identificar imágenes de contenedor ligadas a un registro del proveedor o imagen base
cr0x@server:~$ crictl images | head
IMAGE TAG IMAGE ID SIZE
vendor.registry.local/platform/app 1.42.0 9b1d0c4a2f3e 312MB
docker.io/library/nginx 1.25 e34f3c9c7b7a 187MB
Qué significa: La dependencia de un registro de proveedor puede convertirse en una interrupción de producción si falla la autenticación o el registro cae.
Decisión: Refleja imágenes críticas en un registro que controles y fija por digest para reproducibilidad.
Tarea 10: Confirmar que tu clúster Kubernetes no depende de CRDs/controladores específicos del proveedor
cr0x@server:~$ kubectl get crd | egrep -i 'vendor|ingress|certificate|backup' | head
backups.vendorx.io
snapshots.vendorx.io
certificaterequests.cert-manager.io
Qué significa: Los CRDs del proveedor implican que tus workloads y backups pueden no ser portables tal cual.
Decisión: Prefiere APIs upstream (CSI snapshots, Ingress estándar) cuando sea posible; para CRDs del proveedor, documenta un mapeo de equivalencias.
Tarea 11: Inspeccionar drivers CSI y storage classes para portabilidad
cr0x@server:~$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION
fast-ssd csi.vendorx.io Delete WaitForFirstConsumer true
standard kubernetes.io/no-provisioner Delete Immediate false
Qué significa: Un provisioner CSI del proveedor puede bloquear el ciclo de vida de tus PVs y la mecánica de snapshot/restore.
Decisión: Asegúrate de poder restaurar datos de PV fuera del clúster (backups a nivel de archivos) y de haber probado mover una carga stateful a otro backend CSI.
Tarea 12: Verificar que los backups son realmente restaurables sin el appliance del proveedor
cr0x@server:~$ borg list /backup/borg::appdb-2026-02-04
appdb-2026-02-04 Tue, 2026-02-04 02:00:02 [d2d84c4c7b3a] 18.42 GB
Qué significa: Este es un formato de backup independiente y basado en archivos que puedes restaurar donde puedas ejecutar borg. Si tus backups sólo restauran vía una UI del proveedor, estás bloqueado.
Decisión: Requiere al menos una ruta de backup independiente del proveedor y probada vía restore por CLI.
Tarea 13: Estimar exposición a egress midiendo tráfico saliente
cr0x@server:~$ sar -n DEV 1 3 | egrep 'IFACE|eth0'
IFACE rxpck/s txpck/s rxkB/s txkB/s
eth0 1420.00 1890.00 9820.50 21540.25
eth0 1411.00 1922.00 9750.10 21910.80
eth0 1468.00 1855.00 10020.90 21010.40
Qué significa: Tu tasa de salida sostenida es ~21 MB/s (txkB/s). Multiplica por horas/día y puedes estimar el egress mensual si tuvieras que mover datos o servir tráfico cross-zone.
Decisión: Si el egress es una partida presupuestaria material, añade caching/CDN, comprime respuestas y arquitecta para localidad antes de necesitar una salida.
Tarea 14: Encontrar endpoints específicos del proveedor codificados en configuraciones
cr0x@server:~$ grep -R --line-number -E 'vendorx|\\.cloudprovider\\.internal|kms|s3-' /etc /opt/app 2>/dev/null | head
/opt/app/config.yaml:17: endpoint: https://s3-us-east-1.cloudprovider.internal
/opt/app/config.yaml:22: kms_key_id: arn:cloud:kms:us-east-1:acct:key/1234abcd
/etc/systemd/system/vendorx-agent.service:5:ExecStart=/usr/local/bin/vendorx-agent --region us-east-1
Qué significa: Endpoints codificados y identificadores KMS son minas de migración. Garantizan sorpresas.
Decisión: Mueve esto a una capa de indirección: nombres DNS que poseas, variables de configuración con overrides por entorno y un sistema de secretos que pueda cambiar backends.
Errores comunes: síntomas → causa raíz → solución
1) Síntoma: “No podemos fallar porque el servicio gestionado no nos deja cambiar X”
Causa raíz: Diseñaste alrededor de un plano de control que no controlas (IAM, routing, aprovisionamiento) y no mantuviste una ruta manual.
Solución: Mantén una ruta de emergencia documentada: credenciales estáticas almacenadas de forma segura, endpoints alternativos y un procedimiento probado para ejecutar cargas críticas con menos funcionalidades.
2) Síntoma: “La exportación tuvo éxito, pero el sistema restaurado carece de permisos/historial de versiones”
Causa raíz: Exportaste objetos/filas pero no las semánticas (ACLs, retención, logs de auditoría, extensiones de esquema, triggers, usuarios).
Solución: Define un manifiesto de exportación: datos + metadatos + verificación. Ejecuta simulacros de restauración que validen la postura de seguridad, no solo checksums.
3) Síntoma: “Las estimaciones de migración siguen retrasándose; seguimos descubriendo dependencias ocultas”
Causa raíz: No hay grafo de dependencias. Los equipos usaron comodidades de SDK y funciones de plataforma informalmente.
Solución: Construye un inventario: SDKs, APIs, CRDs, políticas IAM, claves KMS, nombres DNS, dependencias de red y runbooks operativos. Hazlo parte de la revisión de cambios.
4) Síntoma: “Los costes se disparan durante incidentes; liderazgo exige recortes riesgosos”
Causa raíz: El modelo de precios está acoplado a acciones de fiabilidad (egress para DR, replicación cross-region, logs extra, lecturas extra).
Solución: Preaprueba una partida presupuestaria para fiabilidad. Trata el tráfico de DR como una reserva de capacidad, no como una sorpresa.
5) Síntoma: “Soporte dice que es culpa nuestra, nosotros decimos que es de ellos, nada se mueve”
Causa raíz: No hay observabilidad compartida. No puedes aportar evidencia porque la telemetría está atrapada en su plataforma.
Solución: Exporta métricas/logs/trazas a un sistema que controles (o al menos dualízalos). Durante un incidente, la evidencia gana discusiones.
6) Síntoma: “No podemos cambiar de proveedor porque nuestro IaC es específico del proveedor”
Causa raíz: Los módulos Terraform reflejan los primitivos de un proveedor, no la intención de tu plataforma.
Solución: Reescribe módulos alrededor de la intención (“network”, “cluster”, “db”, “object store”) y deja las implementaciones del proveedor detrás de interfaces. Separa archivos de state.
7) Síntoma: “Los backups están verdes, pero las restauraciones son aterradoras”
Causa raíz: Los backups dependen de formatos de snapshot propietarios o appliances sin herramientas de restauración independientes.
Solución: Añade al menos un backup portátil: a nivel de archivos, dumps lógicos o formatos abiertos, y programa restauraciones con regularidad. Trata el tiempo de restauración como un SLO.
8) Síntoma: “Nuestra app no puede ejecutarse fuera de esta nube por supuestos de IAM/KMS”
Causa raíz: Identidad y cifrado se implementaron con constructos específicos del proveedor, referenciados directamente en código/config.
Solución: Introduce una abstracción de identidad interna (límites OIDC/SAML) y abstracción de claves (envelope encryption con capacidad de rewrap). Usa indirección para identificadores.
Listas de verificación / plan paso a paso: cómo escapar limpiamente
Paso 1: Admitir a qué estás atado (inventario + clasificación)
- Capa de datos: bases de datos, almacenamiento de objetos, block storage, sistemas de backup, colas.
- Plano de control: IAM, KMS, DNS, secretos, CI/CD, gestión de Kubernetes.
- Capa de ops: observabilidad, herramientas de incidente, flujos de on-call, runbooks, contratos de soporte.
Haz una tabla simple para cada dependencia:
Qué hace, qué depende de ello, cómo operar sin ello por 24 horas,
cómo luce la salida, qué datos deben moverse.
Paso 2: Definir estándares “portables por diseño”
- Protocolos: prefiere protocolos y APIs estándar (PostgreSQL wire protocol, S3 core API, CSI, OIDC).
- Formatos: usa formatos exportables (Parquet/CSV cuando corresponda, dumps lógicos de DB, formatos de backup abiertos).
- Identificadores: evita codificar ARNs/IDs del proveedor en configs; usa capas de indirección.
- Secretos y claves: diseña para rewrap de claves y cambios de backend de secretos.
Paso 3: Construir un “presupuesto de salida” y conseguir aprobación
Las salidas cuestan dinero: almacenamiento extra para doble escritura, ancho de banda extra para replicación, entornos adicionales para simulacros.
Trátalo como un seguro. Si el liderazgo quiere portabilidad, el liderazgo financia la portabilidad.
Paso 4: Elegir un patrón de arquitectura de salida (elige uno, no los mezcles)
-
Cold standby: recursos mínimos en otro sitio; restaurar desde backups.
Barato, RTO más lento. Ideal para servicios poco críticos. -
Warm standby: datos replicados + workloads probados periódicamente.
Balance entre coste y rapidez. A menudo el mejor por defecto. -
Active-active: ejecución dual entre proveedores/regiones.
Caro y operacionalmente complejo. Vale la pena para un pequeño número de sistemas críticos.
Paso 5: Hacer la portabilidad testeable
No puedes gestionar lo que no puedes probar. Añade checks en CI que fallen builds cuando alguien introduce un endpoint codificado,
una función SDK propietaria o una dependencia CRD no portable sin una excepción explícita.
Paso 6: Ejecutar una migración por etapas (la forma limpia)
- Ensayar en non-prod: prueba la mecánica de restore y cutover.
- Migrar primero la ruta de lectura: replica datos, sirve lecturas, valida la corrección.
- Introducir doble escritura o change-data-capture: mantiene los sistemas sincronizados un periodo controlado.
- Hacer el cutover de escrituras: ventana de freeze corta si hace falta; mantener plan de rollback.
- Ejecutar validación paralela: comparar conteos, checksums, muestreo y métricas de negocio.
- Descomisionar deliberadamente: mantener una ventana de retención definida, luego eliminar acceso y costos.
Paso 7: Institucionalizar las prácticas aburridas
- Simulacros de salida trimestrales para una dependencia.
- Pruebas de restauración con RTO/RPO medidos.
- Inventario de dependencias como parte de la revisión de arquitectura.
- Lista de verificación de contratos: asistencia en terminación, formatos y plazos de exportación, respuesta de soporte durante terminación, cláusulas de cambio de precios.
Preguntas frecuentes
1) ¿Es multi-cloud lo mismo que evitar el lock-in?
No. Multi-cloud puede reducir algún bloqueo, pero también puede duplicar tu complejidad operativa y crear “bloqueo a tu propio desastre”.
La mejor meta es estar capaz de salir: poder irte dentro de un sobre de tiempo/coste acordado.
2) ¿Cuál es la manera más rápida de saber si estamos atados a una base de datos gestionada?
Intenta responder tres preguntas con evidencia: ¿Puedes hacer una exportación/importación lógica a la escala requerida? ¿Puedes ejecutar el mismo motor en otro lado sin pérdida de funciones?
¿Puedes operarlo (monitoring, backups, failover) sin la consola del proveedor?
3) ¿Los “servicios gestionados de código abierto” están a salvo del lock-in?
Más seguros, no seguros. Aún puedes quedar atado por extensiones propietarias, dependencias operativas u facturación opaca. “Open source” reduce una categoría de riesgo:
la disponibilidad del código. No te da automáticamente portabilidad de operaciones.
4) ¿Qué términos contractuales importan realmente para el lock-in?
Asistencia en la terminación, formatos y plazos de exportación de datos, respuesta de soporte durante la terminación, cláusulas de cambio de precios, previsibilidad de costes de egress
y qué ocurre con claves/logs/trazas tras la terminación. También: qué tan rápido puedes aumentar límites y si eso requiere aprobación humana.
5) ¿Cuál es la mayor trampa técnica de lock-in en Kubernetes?
CRDs específicas del proveedor para flujos de trabajo core (ingress, backups, políticas, networking) y snapshots de almacenamiento propietarios. Se filtran en manifests y runbooks.
Usa APIs upstream cuando sea posible y trata los CRDs como código que deberás migrar después.
6) ¿Cómo reduzco el dolor del egress sin reescribir todo?
Cachea agresivamente, comprime respuestas, mantiene datos locales al cómputo, evita tráfico cross-region parlanchín y usa estrategias de replicación que minimicen relecturas completas.
Además: mide el tráfico saliente ahora, para que puedas negociar precios desde una posición de hechos.
7) ¿Cuál es un plazo realista para una “salida limpia”?
Para sistemas moderados: semanas a meses. Para patrimonios de múltiples petabytes y con requisitos de cumplimiento: trimestres. El factor limitante suele ser la validación de datos y la paridad operativa,
no copiar bytes.
8) ¿Cómo evitamos que los ingenieros usen funciones propietarias?
No confíes en buenas vibras. Crea una política de portabilidad: qué funciones están permitidas, cuáles requieren aprobación explícita y cuál es el plan de salida.
Añade checks en CI que detecten endpoints codificados y APIs específicas del proveedor, y haz visibles las excepciones.
9) ¿Cuál es la estrategia mínima viable de salida para un equipo pequeño?
Un backup portable que puedas restaurar sin el proveedor, indirección DNS para endpoints, definiciones de infraestructura en control de versiones
y un simulacro de restauración trimestral. Puedes ser pequeño y aun así difícil de atrapar.
Conclusión: próximos pasos que puedes hacer esta semana
El bloqueo por proveedor no es un fallo moral. Es un resultado predecible cuando la conveniencia se compone y nadie valora la salida.
La solución no es “nunca usar servicios gestionados”. La solución es mantener apalancamiento: datos portables, operaciones portables y contratos que no te castiguen por irte.
Haz estos pasos en orden
- Ejecuta las tareas de inventario arriba en un host de producción representativo y en un clúster. Crea una lista de dependencias que puedas defender.
- Elige una dependencia crítica (base de datos, almacenamiento de objetos, identidad, backups) y programa un simulacro de salida dentro de 30 días.
- Añade una ruta de backup portable si no la tienes, y restaúrala en un entorno limpio.
- Introduce indirección: nombres DNS que controles, endpoints controlados por configuración y un procedimiento de acceso de emergencia.
- Escribe el SLO de salida: “Podemos dejar a este proveedor en X días por Y coste con Z downtime.” Luego haz que sea cierto.
Si no haces nada más: haz que tus datos sean restaurables de forma independiente y practica hacerlo. Todo lo demás es negociable.