Adoptar los servicios nativos de un proveedor cloud puede ser, en muchos sentidos, una decisión lógica. Las herramientas están integradas y la productividad se dispara desde el primer día. AWS Lambda, Google BigQuery, Azure Cognitive Services: cada uno de estos servicios resuelve problemas reales con una eficacia difícil de ignorar. Sin embargo, cada línea de código que los invoca es también un ladrillo en la pared de una dependencia que pocos calculan.
El vendor lock-in en cloud no es un error de planificación puntual; es el resultado acumulado de muchas pequeñas decisiones razonables. Un equipo elige DynamoDB porque resuelve sus problemas de latencia. Otro integra Step Functions porque simplifica su orquestación. Un tercero adopta Cloud Spanner porque nada más ofrece coherencia global a esa escala. Cada decisión es justificable de manera individual. El problema emerge cuando se examina el conjunto.
Migrar de un proveedor cloud no es un proyecto de semanas. Para la mayoría de empresas maduras, es una reescritura parcial de su arquitectura
MOISÉS CAMARERO AGUILAR, COMPUSOF
Índice de temas
Los costes del vendor lock-in
Los costes son de tres naturalezas: la primera es económica; sin la posibilidad real de cambiar de proveedor, la capacidad de negociar precios desaparece. El proveedor puede mantener su margen sabiendo que la migración costaría mucho más de lo que se ahorraría el cliente. La segunda, es operativa; los equipos desarrollan competencias en servicios propietarios que no son transferibles. Un especialista en servicios cognitivos de Azure no es, por defecto, un experto en Vertex AI de Google. La tercera, y más frecuentemente subestimada, es estratégica; cuando el roadmap de tu producto depende del roadmap del proveedor, pierdes la capacidad de diferenciarte.
La respuesta no es, como a veces se plantea, el fundamentalismo. Insistir en que todo servicio debe poder migrar en 48 horas es tanto una utopía como una señal de que el equipo no ha evaluado cuándo la especialización crea ventaja competitiva. La pregunta correcta no es si usar estos servicios, sino cuáles. Por poner un ejemplo, construir una capa de interfaz sobre los servicios de almacenamiento cuesta tiempo; no construirla puede costar el futuro de la empresa.
Valoración del vendor lock-in
Las organizaciones que gestionan mejor este riesgo no evitan los servicios propietarios: los usan de forma deliberada. Definen qué capacidades son commodities —donde la portabilidad importa— y cuáles son fuentes de ventaja diferencial —donde la integración profunda tiene sentido—.
El vendor lock-in no es bueno ni malo per se; es un vector de riesgo que requiere gestión activa. Las empresas que mejor lo manejan no son las que lo evitan, sino las que lo miden, lo documentan y toman decisiones conscientes sobre cuánto están dispuestas a aceptar a cambio de qué beneficio concreto.
El precio que en ocasiones se paga por esa democratización es la soberanía técnica. Decidir cuánta se está dispuesto a ceder es, probablemente, una de las decisiones de arquitectura más importantes que puede tomar cualquier CTO en los próximos años.
