En arquitectura cloud, el lock-in es una restricción que condiciona cómo diseñas, mueves y evolucionas tu aplicación. Entender sus tipos te ayuda a tomar decisiones de arquitectura más conscientes y a evitar juicios apresurados sobre por qué un sistema está construido de cierta manera.

Antes de elegir un proveedor, un producto o una versión, conviene preguntarte cuál es tu lock-in aceptable. Esa pregunta desbloquea casi todas las decisiones técnicas que vienen después.

¿Qué es el lock-in en arquitectura cloud y por qué importa?

El lock-in es un bloqueo o restricción que limita tu capacidad de cambiar de proveedor, producto, versión o plataforma sin asumir un costo o riesgo alto. No es algo malo por defecto: es una variable que debes evaluar.

¿Qué es el lock-in en la nube? Es una restricción que dificulta mover tu aplicación de un proveedor, producto o tecnología a otro. Aparece por contratos, integraciones, customizaciones o decisiones técnicas que ya tomaste.

La idea central es simple: cada decisión que tomas hoy puede convertirse mañana en un bloqueo. Por eso conviene anticipar qué tipo de lock-in estás dispuesto a aceptar [00:36].

¿Cuáles son los tipos de lock-in que afectan tu arquitectura?

Existen ocho tipos de lock-in que pueden cambiar la forma en que diseñas tu aplicación. Cada uno aparece en un nivel distinto: desde el contrato comercial hasta la mentalidad del equipo.

Vendor, product y version lock-in

El vendor lock-in es la dificultad de moverte entre cloud providers. Si Platzi Wallet corre en Azure y firmaste un acuerdo comercial con integraciones específicas, llevarla a AWS implica un costo enorme. Es el bloqueo más común y el que más se menciona en el mercado [01:21].

El product lock-in aparece cuando customizas tanto un producto que ya no puedes reemplazarlo. Imagina que montaste todo en Kubernetes sobre Google Kubernetes Engine, con integraciones nativas. Si llega la directiva de migrar a Elastic Container Service de AWS, el riesgo de mover esas integraciones puede ser inaceptable [02:18].

El version lock-in ocurre cuando una versión específica de un producto te ata. Pasó con Apache Airflow al saltar a la versión 2: muchas customizaciones dependían de la versión anterior y actualizar implicaba romper integraciones. Incluso Google Cloud sufrió un kernel panic al actualizar Google Kubernetes Engine, afectando a clientes que no estaban listos [03:30].

Architecture y platform lock-in

El architecture lock-in es el bloqueo por una arquitectura muy customizada. Si construiste Platzi Wallet completamente en contenedores y ahora quieres pasar a funciones serverless, básicamente tienes que rehacerla [04:50].

El platform lock-in aparece cuando tus políticas, roles y permisos están profundamente acoplados a los servicios de una plataforma. Migrar de Amazon a Azure significa reconstruir toda esa capa de configuración, no solo mover el código [05:15].

Skills, legal y mental lock-in

El skills lock-in es uno de los más subestimados. Si tu equipo de backend, DevOps y cloud solo domina AWS, proponer Azure no tiene sentido aunque técnicamente sea viable. Lo mismo aplica si tu equipo de data trabaja en Google Cloud Platform: forzar Azure te obliga a capacitar o contratar, y eso cuesta tiempo y dinero [06:00].

¿Cómo supero el skills lock-in? Aprendiendo. Es el único tipo de bloqueo que se resuelve con formación continua del equipo o con nuevas contrataciones estratégicas.

El legal lock-in lo determina la legislación. Si una norma del país prohíbe sacar cierta información del territorio y tu proveedor actual, como Oracle, tiene región local pero Alibaba Cloud no tiene data center en Colombia, tu arquitectura queda atada por razones legales, no técnicas [07:00].

Y llegamos al más peligroso: el mental lock-in. Es una suposición inconsciente que frena decisiones. Frases como "la nube es más cara", "la nube es insegura" o "la nube no escala" suelen venir de una mala experiencia ajena, no de datos propios. Cambiar mentalidad es más complicado que cambiar tecnología [08:10].

¿Cómo usar el lock-in para tomar mejores decisiones de arquitectura?

La recomendación práctica es no juzgar una arquitectura como mal hecha sin conocer su contexto. Detrás de cada decisión hay restricciones, acuerdos comerciales, equipos con habilidades específicas y marcos legales que tú no ves desde afuera.

Cuando diseñes tu propia aplicación, hazte estas preguntas en orden:

• ¿Qué proveedor estoy eligiendo y qué tan fácil sería salir de él?
• ¿Qué productos o tecnologías estoy customizando hasta el punto de no retorno?
• ¿Qué versiones críticas pueden bloquearme en el futuro?
• ¿Qué sabe realmente mi equipo y qué tendría que aprender?
• ¿Hay alguna restricción legal que limite dónde pueden vivir mis datos?
• ¿Estoy tomando decisiones por miedo o por evidencia?

¿Cuál es el lock-in más peligroso? El mental, porque te impide siquiera probar la nube. Se combate con experimentación directa: probar, medir y comparar antes de juzgar.

El skills lock-in se vence aprendiendo. El mental se vence probando. Los demás se gestionan diseñando con intención desde el primer día.

¿Qué tipo de lock-in has visto en tu empresa o proyecto? Cuéntame tu caso en los comentarios.