¿Qué es el vendor lock-in y cómo se puede evitar?

El vendor lock-in se produce cuando un cliente está tan vinculado con un proveedor que le resulta prácticamente imposible cambiar. Esto da lugar a que el cliente genere una gran dependencia del proveedor. Con los servicios Cloud conviene no perder de vista el efecto “lock-in” por el peligro que supone. En los siguientes apartados revelamos qué es exactamente lo que hay detrás del vendor lock-in y cómo se puede evitar.

En general, el efecto “lock-in” es la dependencia que tiene un cliente de un producto o tecnología. La dependencia se debe a que cambiar de ese producto o tecnología supone un coste elevado y, por lo tanto, es poco atractivo. Si la tecnología la ofrece un único proveedor (“vendor” en inglés), el cliente tiene una dependencia total de este, lo que resulta en un vendor lock-in.

El libre mercado ofrece una amplia gama de tecnologías y servicios entre los que el cliente puede elegir. Se ofrecen a diferentes precios y bajo diferentes condiciones. Cada relación comercial entre cliente y proveedor tiene sus propias ventajas e inconvenientes. La decisión del cliente de trabajar con varios o algunos proveedores genera tensiones económicas.

Desde el punto de vista administrativo, es preferible trabajar con pocos proveedores, lo que conduce a un entorno homogéneo que se asocia con una menor complejidad. Llevando este caso al extremo, puede que todos los productos y servicios se compren de un mismo proveedor. Esto supondría para el cliente una dependencia total del proveedor. En este caso, el cliente se encuentra entre la espada y la pared, con una posición negociadora débil frente al proveedor.

El ejemplo clásico de la dependencia de un proveedor en el sector del software es el caso del proveedor Microsoft. En varios sectores de la economía, los componentes principales proceden de la misma empresa: sistema operativo (Windows), software de aplicación (Office), base de datos (Access), etc. Esto significa que todos los componentes principales de software, desde los programas hasta las licencias, pasando por la fijación de precios y la asistencia técnica, están bajo el control de un único proveedor. El vendor lock-in se ha hecho efectivo.

La dependencia de un proveedor se debe a la inviabilidad de cambiar de proveedor. Incluso si el cambio es posible en teoría, en la realidad puede que solo sea posible con un enorme esfuerzo. Es decir, el cliente está atado al proveedor. Veamos el concepto con un ejemplo sencillo:

Muy a menudo los componentes tecnológicos suelen ser los llamados “bienes complementarios”. Existe una dependencia entre los componentes individuales. Por ejemplo, si tienes una Xbox o una PlayStation con su correspondiente colección de videojuegos, probablemente no cambiarás de consola, porque entonces tendrías que volver a comprar todos los juegos, ya que los que ya tienes no te funcionarían en la nueva consola.

Además de la incompatibilidad de las tecnologías competidoras descrita anteriormente, los obstáculos regulatorios y organizativos dificultan aún más el cambio de proveedor. Por un lado, puede que las condiciones de las licencias y otros acuerdos contractuales obliguen a un cliente a continuar con un proveedor. Por otro lado, también es posible que el cliente haya invertido mucho en la formación de los empleados para el uso de la tecnología específica de un proveedor. Si los conocimientos y formación no se pueden transferir al uso de otras tecnologías, entonces habría que comenzar el proceso de nuevo, así el statu quo se reafirma.

Todas las valoraciones llegan a la misma conclusión; que el todo es más que la suma de las partes. Es más, el todo (en nuestro caso un sistema) incluye:

• Las partes (componentes)
• Las interacciones y otras conexiones explícitas o implícitas, es decir, la compatibilidad entre las partes
• Las propiedades resultantes del sistema en su totalidad

Cuando se quiere realizar un cambio puede parecer que cada componente por separado puede reemplazarse con relativa facilidad. Sin embargo, es posible que haya reestablecer la compatibilidad entre las partes, lo cual puede suponer un gran coste. En un sistema con un vendor lock-in, la compatibilidad entre los componentes se da por hecho. En el caso de cambiar de proveedor, incluso de un único componente, será necesario reestructurar todo el sistema; el cambio se hace difícil o incluso imposible.

Un ejemplo concreto:

Imaginemos un sistema de base de datos integrado con la infraestructura de un proveedor. Los datos almacenados en él pueden migrar con relativa facilidad al cambiar de proveedor. Pero ¿qué pasa con los demás componentes y las compatibilidades entre sí? La configuración, los derechos de acceso, la distribución de la base de datos en varios servidores (sharding), etc. ¿Conocemos la complejidad que tiene el sistema en su conjunto y podemos llegar a entenderla? Si es así, ¿se podría reproducir todo el sistema de manera viable con la infraestructura de un nuevo proveedor? En muchos casos, la respuesta a al menos una de todas estas preguntas probablemente sea “no”.

Se puede usar una auditoría de seguridad para observar cómo las nuevas propiedades del sistema dificultan el cambio de proveedores. El uso de la auditoría de seguridad evalúa los requisitos técnicos, organizativos y legales del nuevo contrato. Se trata, pues, de un recurso vital del sistema. La interoperabilidad de un sistema se acredita mediante una certificación. La auditoría del sistema se realiza para un caso concreto; cuando se cambia de proveedor, el sistema se reestructura y debe, por ello, ser certificado de nuevo. El esfuerzo adicional que supone la certificación aumenta los costes de cambio y contribuye al efecto “lock-in”.

El uso de la nube ofrece muchas ventajas. Sin embargo, aquí también existe la posibilidad de que ocurra un vendor lock-in. Un ejemplo típico: los datos importantes se almacenan en un proveedor de la nube. Si queremos utilizar otro proveedor para procesar los datos, estos deben ser transferidos a través de la red, lo que supone unos costes de transferencia. Por ello, interesa no complicar el asunto y dejar que el primer proveedor sea el que procese esos datos. De esta manera, poco a poco se da pie a un efecto “lock-in”.

Cuantos más datos se almacenen y cuanto más longeva sea la relación comercial, más fuerte será el efecto “lock-in”. Si la propia lógica empresarial se basa en formatos, API (Interfaz de Programación de Aplicaciones) y configuraciones específicas del proveedor, será más difícil deshacer el entramado. Llevando el caso al extremo, todo puede venir de la mano de un único Managed Service Provider. También hay que tener cuidado cuando una system house ofrezca una solución a medida. Un alto grado de personalización da lugar a un fuerte vínculo entre el cliente y el proveedor.

Veamos primero qué capacidades tecnológicas conforman la nube. Podemos distinguir tres funcionalidades básicas:

• Gestión de redes por software (SDN): en lugar de configurar y utilizar routers y switches físicos, se utilizan redes y dispositivos de red virtuales.
• Software-Defined Storage (SDS): en lugar del almacenamiento masivo físico, se utilizan Object Stores como “Amazon S3” y Block Stores como “Azure Blob Storage” en un Software Defined Data Center.
• Soluciones de computación y sin servidor: con “Infrastructure-as-a-Service” (IaaS) y “Container-as-a-Service” (CaaS) se virtualizan los sistemas operativos y aplicaciones. Con “Function-as-a-Service” (FaaS) como “AWS Lambda” y “Microsoft Azure Functions” se facilitan funciones individuales para ser llamadas.

Un entorno de computación en nube incluye los aspectos técnicos de hosting, almacenamiento y aplicaciones. Además, están los aspectos organizativos de la configuración, el soporte técnico y la legislación. Las diferentes facetas de estos aspectos componen un entorno de nube específico. La cantidad de diferentes elementos puede servir para estimar lo compleja que suele ser la migración entre proveedores:

Para los llamados productos de la nube, como IaaS, PaaS, SaaS y CaaS se trata de servicios. El proveedor los presta a cambio de una tarifa, pero no pertenecen al cliente en ningún momento. Por lo tanto, corresponde al proveedor -respetando los contratos firmados- decidir si ofrecer estos servicios y en qué condiciones.

¿Qué ocurre si cambian los términos de un servicio? En el peor de los casos, supone una reducción de la calidad o del ámbito que cubre el servicio, o el proveedor aumenta el precio o cambia las condiciones en detrimento del cliente. En efecto, el proveedor está en el asiento del conductor, ya que el cliente depende del proveedor.

Las causas de la dependencia de un proveedor también surgen por el lado del cliente. Por ejemplo, cuando los empleados de una empresa están acostumbrados a trabajar con la tecnología proporcionada por el proveedor. Los expertos técnicos suelen estar especializados en determinadas tecnologías. Al cambiar de proveedor, puede ser necesario volver a formar al personal, un cambio puede incluso precisar la contratación de nuevo personal.

Para salir de un vendor lock-in, se deben migrar los datos y los procesos a un nuevo proveedor. Una migración de esta magnitud suele ser un proceso complejo. Dado que la satisfacción de la organización depende del éxito de la migración, ésta debe planificarse y probarse de antemano. Aunque se tenga mucho cuidado, es posible encontrarse con los errores a posteriori. Por lo tanto, una migración compleja siempre implica un alto riesgo, lo que hace que rápidamente surja la pregunta de si el esfuerzo para un cambio realmente vale la pena.

El mejor enfoque para evitar el vendor lock-in es combatirlo a nivel estratégico desde el principio. En lugar de confiar en un solo proveedor y transferirle así el poder, se recurre a varios puntos de apoyo. Los sistemas internos se construyen explícitamente con el objetivo de poder intercambiar componentes más adelante.

A continuación, hemos resumido las medidas estratégicas, organizativas y medidas técnicas que te ayudarán a evitar el vendor lock-in.

Si tienes en cuenta desde el principio el riesgo que supone el vendor lock-in, a la hora de elegir socios y tecnologías, puedes tomar mejores decisiones. Por ejemplo, si encuentras tecnologías comparables de dos proveedores con precios ligeramente diferentes, puede tener sentido optar por la oferta con el precio más alto. Al menos si se asume que esto reduce el riesgo de vendor lock-in.

En general, es necesario hacer un balance riguroso: lo más importante es comprender las propias necesidades en términos de tecnología y conocer las estructuras informáticas ya existentes. Partiendo del conocimiento de los propios sistemas y sus necesidades, se analiza el panorama informático. Es importante tener en cuenta las tendencias emergentes y no perder de vista el “end of life” de las tecnologías. Si, por ejemplo, se sigue usando un sistema heredado, puede ser recomendable un cambio.

Si una tecnología o un proveedor te parece un riesgo en términos de vendor lock-in, deberías definir una estrategia de salida desde el principio. De este modo, podrás reaccionar de forma rápida y decidida ante cambios desfavorables por parte del proveedor. Sabrás lo que tendrás que hacer de antemano y serás consciente de los costes y riesgos que conlleva esta acción.

El enfoque más obvio para evitar el vendor lock-in es no depender de un solo proveedor. En lugar de trasladar todos los procesos empresariales a la nube, puedes optar por un enfoque híbrido. De esta manera, además de los recursos de la nube de un proveedor tienes los de una nube privada de la empresa. Esto significa que los procesos primarios y los datos utilizados en ellos permanecen bajo el control de la empresa para preservar la soberanía de los datos.

Siguiendo el mismo criterio, puede ser una ventaja contratar servicios en la nube de varios proveedores en lugar de uno solo. El factor decisivo en este caso es que todos los servicios contratados dispongan de interfaces adecuadas. Solo así se puede montar un sistema integrado a partir de los componentes individuales. Además, son preferibles los servicios de los proveedores que soportan explícitamente la interoperabilidad mediante interfaces abiertas.

Estas medidas solo son efectivas si se aplican a las estructuras que realmente existen en la empresa. Si los procesos pasan desapercibidos, el vendor lock-in se produce a pesar de todos los esfuerzos. Esto resulta especialmente evidente en el caso de los llamados “datos oscuros”: se trata de datos desestructurados y almacenados que no se procesan ni usan para tomar decisiones. Es útil definir las dependencias de forma explícita y estandarizar en gran medida los procesos y sistemas.

La medida técnica más sencilla para evitar el vendor lock-in es no utilizar sistemas y formatos propietarios. Si utilizas sistemáticamente estándares abiertos y software libre, por definición no dependes de un solo proveedor. Sin embargo, incluso este método no te garantiza el éxito en el caso de usar la nube si has renunciado al control de los recursos hardware.

Afortunadamente, en los últimos años se han creado potentes herramientas de orquestación que abordan precisamente este asunto. Estos incluyen OpenShift y Terraform. Estas herramientas sirven de capa abstracta intermediaria que desvincula los requisitos propios de una infraestructura informática de la capa subyacente específica del proveedor. Esto te permite construir toda una infraestructura informática distribuida en varias nubes.

La palabra clave aquí es “Infrastructure-as-Code” (IaC). Ojo: “Code”, no “Service”. Mientras que un servicio se alquila, un código permanece bajo el control de uno mismo. Las estructuras deseadas se definen en el código. Estas incluyen los componentes individuales, así como las conexiones entre ellos. Además de la documentación explícita de los sistemas en el código, hay otras ventajas decisivas.

A partir de las estructuras definidas de forma abstracta en el código, el software de orquestación proporciona los sistemas informáticos correspondientes. Es posible distribuir los componentes individuales entre varias nubes. Esto sirve tanto para las infraestructuras en la nube de diferentes proveedores como para las nubes privadas de la propia empresa. La reducción en los costes de cambio de proveedor contribuye significativamente a la protección contra el vendor lock-in.