Lock-in, portabilidad y cuándo vale pagar por lo gestionado
Evitar el lock-in tiene un precio que se paga todos los días, y el beneficio llega sólo si alguna vez se migra. La decisión honesta no es entre atarse y no atarse, sino qué tan caro sería salir y cuánto cuesta hoy dejar esa puerta abierta.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
“No quiero atarme a un proveedor” suena a prudencia y muchas veces es lo contrario: lleva a descartar servicios gestionados, a construir capas de abstracción propias y a operar uno mismo lo que la nube ya resolvía. Todo eso se paga cada mes, en tiempo del equipo.
La pregunta mejor formulada no es si atarse: es cuánto costaría salir de cada decisión, y cuánto cuesta hoy mantener abierta esa salida. Casi siempre la respuesta es distinta para cada capa del sistema.
No todo el lock-in es igual
| Tipo | Ejemplo | Costo de salir | Qué tan visible es |
|---|---|---|---|
| De datos | Terabytes en el almacenamiento de objetos | Alto: el tráfico de salida se cobra | Se subestima siempre |
| De servicio gestionado | Una base propietaria, una cola específica | Medio: reescribir integraciones | Visible |
| De arquitectura | Diseñar todo alrededor de funciones y eventos del proveedor | Alto: es rediseñar | Poco visible hasta que se intenta |
| Operativo | El equipo sabe una nube y sólo una | El más alto de todos | Invisible |
| Contractual | Compromisos plurianuales y descuentos por volumen | Conocido de antemano | Explícito |
El más caro es el que casi nunca se discute: el operativo. Un equipo que aprendió a operar bien una nube tiene ahí su conocimiento de incidentes, sus procedimientos, sus herramientas. Migrar no es sólo mover recursos: es volver a ser principiante en el peor momento posible.
Dónde conviene atarse y dónde no
La respuesta madura es por capas, y suele quedar así:
Cuatro decisiones típicas
- Lógica de negocio: portable siempre. Es lo más valioso y lo que no debería depender de ningún servicio. No cuesta nada mantenerla en código común.
- Cómputo: contenedores. Una imagen corre en cualquier nube y en una máquina propia. Es la portabilidad más barata que existe: se obtiene casi gratis.
- Datos: motores estándar donde se pueda. PostgreSQL o MySQL gestionados corren el mismo motor en todos lados. Las variantes propietarias dan rendimiento y conmutación mejor, y se justifican cuando el estándar deja de alcanzar de verdad.
- Lo periférico: atarse sin culpa. Colas, notificaciones, identidad, observabilidad. Reemplazarlos es trabajo acotado, y construir alternativas propias cuesta mucho más de lo que ahorra.
Antes de seguir, predecí
La capa de abstracción que sale más cara que el lock-in
El reflejo habitual es envolver todo en interfaces propias “por si cambiamos de proveedor”. Vale la pena mirar qué produce eso en la práctica.
Lo que pasa con la capa portable
- Queda en el mínimo común denominador: para funcionar en todas las nubes, sólo puede usar lo que todas tienen, así que se pierden las capacidades por las que se eligió el servicio.
- Hay que mantenerla, con sus propios errores, y sin la documentación ni la comunidad del servicio original.
- Casi nunca se ejerce: la mayoría de las organizaciones no migra, y la que migra descubre que la abstracción no cubría lo que hacía falta.
- Kubernetes es la variante grande de lo mismo: da portabilidad real del cómputo y trae su propio costo operativo, que es alto. Se justifica por sus propias razones, no como seguro contra el proveedor.
Una forma de decidir en cinco minutos
Las preguntas, en orden
- ¿Cuánto trabajo nos ahorra por mes? Si es sustancial, arranca ganando.
- ¿Qué pasaría si mañana hubiera que reemplazarlo? Semanas de trabajo es aceptable; rediseñar el sistema, no.
- ¿Qué parte es realmente propietaria? Una cola con una API específica se reemplaza; un modelo de datos diseñado alrededor de sus particularidades, no.
- ¿Existe un estándar con implementaciones múltiples? Si lo hay y el costo es parecido, se elige ese y el tema se termina.
- ¿Quién opera esto si no lo hace el proveedor? La respuesta sincera suele cerrar la discusión.
Más a fondo · nivel seniorMulti-nube: cuándo es una decisión y cuándo una consecuencia
Estar en dos nubes por diseño —cada carga en la que mejor le sirve— es una estrategia razonable, y muy distinta de correr la misma carga en dos nubes a la vez, que es lo que la gente imagina y casi nadie sostiene: duplica la operación, la identidad, el monitoreo y el conocimiento necesario, y agrega tráfico entre nubes que se cobra caro.
Hay tres motivos legítimos para multi-nube: requisito regulatorio o de cliente, que no se discute; capacidades específicas que una nube hace mucho mejor; y fusiones, donde no se eligió nada, se heredó. Lo que rara vez lo justifica es el poder de negociación, porque el descuento que se consigue suele ser menor que el costo permanente de operar dos plataformas.
La versión moderada que sí funciona: mantener el cómputo en contenedores, la lógica portable y los datos en motores estándar, y medir cada tanto qué costaría migrar el sistema principal. Ese número, actualizado, es la posición de negociación real —y a la vez el plan de contingencia—, sin pagar todos los meses por una mudanza que quizá nunca ocurra.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica