¿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á­c­ti­ca­me­n­te imposible cambiar. Esto da lugar a que el cliente genere una gran de­pe­n­de­n­cia del proveedor. Con los servicios Cloud conviene no perder de vista el efecto “lock-in” por el peligro que supone. En los si­guie­n­tes apartados revelamos qué es exac­ta­me­n­te lo que hay detrás del vendor lock-in y cómo se puede evitar.

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

El libre mercado ofrece una amplia gama de te­c­no­lo­gías y servicios entre los que el cliente puede elegir. Se ofrecen a di­fe­re­n­tes precios y bajo di­fe­re­n­tes co­n­di­cio­nes. Cada relación comercial entre cliente y proveedor tiene sus propias ventajas e in­co­n­ve­nie­n­tes. La decisión del cliente de trabajar con varios o algunos pro­vee­do­res genera tensiones eco­nó­mi­cas.

Desde el punto de vista ad­mi­ni­s­tra­ti­vo, es pre­fe­ri­ble trabajar con pocos pro­vee­do­res, lo que conduce a un entorno homogéneo que se asocia con una menor co­m­ple­ji­dad. 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 de­pe­n­de­n­cia total del proveedor. En este caso, el cliente se encuentra entre la espada y la pared, con una posición ne­go­cia­do­ra débil frente al proveedor.

El ejemplo clásico de la de­pe­n­de­n­cia de un proveedor en el sector del software es el caso del proveedor Microsoft. En varios sectores de la economía, los co­m­po­ne­n­tes pri­n­ci­pa­les proceden de la misma empresa: sistema operativo (Windows), software de apli­ca­ción (Office), base de datos (Access), etc. Esto significa que todos los co­m­po­ne­n­tes pri­n­ci­pa­les de software, desde los programas hasta las licencias, pasando por la fijación de precios y la asi­s­te­n­cia técnica, están bajo el control de un único proveedor. El vendor lock-in se ha hecho efectivo.

La de­pe­n­de­n­cia de un proveedor se debe a la in­via­bi­li­dad 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 co­m­po­ne­n­tes te­c­no­ló­gi­cos suelen ser los llamados “bienes co­m­ple­me­n­ta­rios”. Existe una de­pe­n­de­n­cia entre los co­m­po­ne­n­tes in­di­vi­dua­les. Por ejemplo, si tienes una Xbox o una Pla­y­S­ta­tion con su co­rre­s­po­n­die­n­te colección de vi­deo­jue­gos, pro­ba­ble­me­n­te no cambiarás de consola, porque entonces tendrías que volver a comprar todos los juegos, ya que los que ya tienes no te fu­n­cio­na­rían en la nueva consola.

Además de la in­co­m­pa­ti­bi­li­dad de las te­c­no­lo­gías co­m­pe­ti­do­ras descrita an­te­rio­r­me­n­te, los ob­s­tácu­los re­gu­la­to­rios y or­ga­ni­za­ti­vos di­fi­cu­l­tan aún más el cambio de proveedor. Por un lado, puede que las co­n­di­cio­nes de las licencias y otros acuerdos co­n­tra­c­tua­les 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 te­c­no­lo­gía es­pe­cí­fi­ca de un proveedor. Si los co­no­ci­mie­n­tos y formación no se pueden tra­n­s­fe­rir al uso de otras te­c­no­lo­gías, entonces habría que comenzar el proceso de nuevo, así el statu quo se reafirma.

Todas las va­lo­ra­cio­nes llegan a la misma co­n­clu­sió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 (co­m­po­ne­n­tes)
• Las in­ter­ac­cio­nes y otras co­ne­xio­nes ex­plí­ci­tas o im­plí­ci­tas, es decir, la co­m­pa­ti­bi­li­dad entre las partes
• Las pro­pie­da­des re­su­l­ta­n­tes del sistema en su totalidad

Cuando se quiere realizar un cambio puede parecer que cada co­m­po­ne­n­te por separado puede re­em­pla­zar­se con relativa facilidad. Sin embargo, es posible que haya re­es­ta­ble­cer la co­m­pa­ti­bi­li­dad entre las partes, lo cual puede suponer un gran coste. En un sistema con un vendor lock-in, la co­m­pa­ti­bi­li­dad entre los co­m­po­ne­n­tes se da por hecho. En el caso de cambiar de proveedor, incluso de un único co­m­po­ne­n­te, será necesario re­es­tru­c­tu­rar todo el sistema; el cambio se hace difícil o incluso imposible.

Un ejemplo concreto:

Ima­gi­ne­mos un sistema de base de datos integrado con la in­frae­s­tru­c­tu­ra de un proveedor. Los datos al­ma­ce­na­dos en él pueden migrar con relativa facilidad al cambiar de proveedor. Pero ¿qué pasa con los demás co­m­po­ne­n­tes y las co­m­pa­ti­bi­li­da­des entre sí? La co­n­fi­gu­ra­ción, los derechos de acceso, la di­s­tri­bu­ción de la base de datos en varios se­r­vi­do­res (sharding), etc. ¿Conocemos la co­m­ple­ji­dad que tiene el sistema en su conjunto y podemos llegar a en­te­n­de­r­la? Si es así, ¿se podría re­pro­du­cir todo el sistema de manera viable con la in­frae­s­tru­c­tu­ra de un nuevo proveedor? En muchos casos, la respuesta a al menos una de todas estas preguntas pro­ba­ble­me­n­te sea “no”.

Se puede usar una auditoría de seguridad para observar cómo las nuevas pro­pie­da­des del sistema di­fi­cu­l­tan el cambio de pro­vee­do­res. El uso de la auditoría de seguridad evalúa los re­qui­si­tos técnicos, or­ga­ni­za­ti­vos y legales del nuevo contrato. Se trata, pues, de un recurso vital del sistema. La in­te­ro­pe­ra­bi­li­dad de un sistema se acredita mediante una ce­r­ti­fi­ca­ción. La auditoría del sistema se realiza para un caso concreto; cuando se cambia de proveedor, el sistema se re­es­tru­c­tu­ra y debe, por ello, ser ce­r­ti­fi­ca­do de nuevo. El esfuerzo adicional que supone la ce­r­ti­fi­ca­ción aumenta los costes de cambio y co­n­tri­bu­ye al efecto “lock-in”.

El uso de la nube ofrece muchas ventajas. Sin embargo, aquí también existe la po­si­bi­li­dad de que ocurra un vendor lock-in. Un ejemplo típico: los datos im­po­r­ta­n­tes se almacenan en un proveedor de la nube. Si queremos utilizar otro proveedor para procesar los datos, estos deben ser tra­n­s­fe­ri­dos a través de la red, lo que supone unos costes de tra­n­s­fe­re­n­cia. 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 em­pre­sa­rial se basa en formatos, API (Interfaz de Pro­gra­ma­ción de Apli­ca­cio­nes) y co­n­fi­gu­ra­cio­nes es­pe­cí­fi­cas 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 pe­r­so­na­li­za­ción da lugar a un fuerte vínculo entre el cliente y el proveedor.

Veamos primero qué ca­pa­ci­da­des te­c­no­ló­gi­cas conforman la nube. Podemos di­s­ti­n­guir tres fu­n­cio­na­li­da­des básicas:

• Gestión de redes por software (SDN): en lugar de co­n­fi­gu­rar y utilizar routers y switches físicos, se utilizan redes y di­s­po­si­ti­vos de red virtuales.
• Software-Defined Storage (SDS): en lugar del al­ma­ce­na­mie­n­to masivo físico, se utilizan Object Stores como “Amazon S3” y Block Stores como “Azure Blob Storage” en un Software Defined Data Center.
• So­lu­cio­nes de co­mpu­tación y sin servidor: con “In­fra­s­tru­c­tu­re-as-a-Service” (IaaS) y “Container-as-a-Service” (CaaS) se vi­r­tua­li­zan los sistemas ope­ra­ti­vos y apli­ca­cio­nes. Con “Function-as-a-Service” (FaaS) como “AWS Lambda” y “Microsoft Azure Functions” se facilitan funciones in­di­vi­dua­les para ser llamadas.

Un entorno de co­mpu­tación en nube incluye los aspectos técnicos de hosting, al­ma­ce­na­mie­n­to y apli­ca­cio­nes. Además, están los aspectos or­ga­ni­za­ti­vos de la co­n­fi­gu­ra­ción, el soporte técnico y la le­gi­s­la­ción. Las di­fe­re­n­tes facetas de estos aspectos componen un entorno de nube es­pe­cí­fi­co. La cantidad de di­fe­re­n­tes elementos puede servir para estimar lo compleja que suele ser la migración entre pro­vee­do­res:

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 pe­r­te­ne­cen al cliente en ningún momento. Por lo tanto, co­rre­s­po­n­de al proveedor -re­s­pe­ta­n­do los contratos firmados- decidir si ofrecer estos servicios y en qué co­n­di­cio­nes.

¿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 co­n­di­cio­nes en de­tri­me­n­to del cliente. En efecto, el proveedor está en el asiento del conductor, ya que el cliente depende del proveedor.

Las causas de la de­pe­n­de­n­cia de un proveedor también surgen por el lado del cliente. Por ejemplo, cuando los empleados de una empresa están aco­s­tu­m­bra­dos a trabajar con la te­c­no­lo­gía pro­po­r­cio­na­da por el proveedor. Los expertos técnicos suelen estar es­pe­cia­li­za­dos en de­te­r­mi­na­das te­c­no­lo­gías. Al cambiar de proveedor, puede ser necesario volver a formar al personal, un cambio puede incluso precisar la co­n­tra­ta­ció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 sa­ti­s­fa­c­ción de la or­ga­ni­za­ción depende del éxito de la migración, ésta debe pla­ni­fi­car­se y probarse de antemano. Aunque se tenga mucho cuidado, es posible en­co­n­trar­se con los errores a po­s­te­rio­ri. Por lo tanto, una migración compleja siempre implica un alto riesgo, lo que hace que rá­pi­da­me­n­te surja la pregunta de si el esfuerzo para un cambio realmente vale la pena.

El mejor enfoque para evitar el vendor lock-in es co­m­ba­ti­r­lo a nivel es­tra­té­gi­co desde el principio. En lugar de confiar en un solo proveedor y tra­n­s­fe­ri­r­le así el poder, se recurre a varios puntos de apoyo. Los sistemas internos se co­n­s­tru­yen ex­plí­ci­ta­me­n­te con el objetivo de poder in­te­r­ca­m­biar co­m­po­ne­n­tes más adelante.

A co­n­ti­nua­ción, hemos resumido las medidas es­tra­té­gi­cas, or­ga­ni­za­ti­vas 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 te­c­no­lo­gías, puedes tomar mejores de­ci­sio­nes. Por ejemplo, si en­cue­n­tras te­c­no­lo­gías co­m­pa­ra­bles de dos pro­vee­do­res con precios li­ge­ra­me­n­te di­fe­re­n­tes, 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 im­po­r­ta­n­te es co­m­pre­n­der las propias ne­ce­si­da­des en términos de te­c­no­lo­gía y conocer las es­tru­c­tu­ras in­fo­r­má­ti­cas ya exi­s­te­n­tes. Partiendo del co­no­ci­mie­n­to de los propios sistemas y sus ne­ce­si­da­des, se analiza el panorama in­fo­r­má­ti­co. Es im­po­r­ta­n­te tener en cuenta las te­n­de­n­cias eme­r­ge­n­tes y no perder de vista el “end of life” de las te­c­no­lo­gías. Si, por ejemplo, se sigue usando un sistema heredado, puede ser re­co­me­n­da­ble un cambio.

Si una te­c­no­lo­gía o un proveedor te parece un riesgo en términos de vendor lock-in, deberías definir una es­tra­te­gia de salida desde el principio. De este modo, podrás reac­cio­nar de forma rápida y decidida ante cambios de­s­fa­vo­ra­bles por parte del proveedor. Sabrás lo que tendrás que hacer de antemano y serás co­n­s­cie­n­te 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 em­pre­sa­ria­les 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 uti­li­za­dos en ellos pe­r­ma­ne­cen 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 pro­vee­do­res en lugar de uno solo. El factor decisivo en este caso es que todos los servicios co­n­tra­ta­dos dispongan de in­te­r­fa­ces adecuadas. Solo así se puede montar un sistema integrado a partir de los co­m­po­ne­n­tes in­di­vi­dua­les. Además, son pre­fe­ri­bles los servicios de los pro­vee­do­res que soportan ex­plí­ci­ta­me­n­te la in­te­ro­pe­ra­bi­li­dad mediante in­te­r­fa­ces abiertas.

Estas medidas solo son efectivas si se aplican a las es­tru­c­tu­ras que realmente existen en la empresa. Si los procesos pasan des­ape­r­ci­bi­dos, el vendor lock-in se produce a pesar de todos los esfuerzos. Esto resulta es­pe­cia­l­me­n­te evidente en el caso de los llamados “datos oscuros”: se trata de datos des­es­tru­c­tu­ra­dos y al­ma­ce­na­dos que no se procesan ni usan para tomar de­ci­sio­nes. Es útil definir las de­pe­n­de­n­cias de forma explícita y es­ta­n­da­ri­zar 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 pro­pie­ta­rios. Si utilizas si­s­te­má­ti­ca­me­n­te es­tá­n­da­res abiertos y software libre, por de­fi­ni­ció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 re­nu­n­cia­do al control de los recursos hardware.

Afo­r­tu­na­da­me­n­te, en los últimos años se han creado potentes he­rra­mie­n­tas de or­que­s­ta­ción que abordan pre­ci­sa­me­n­te este asunto. Estos incluyen OpenShift y Terraform. Estas he­rra­mie­n­tas sirven de capa abstracta in­te­r­me­dia­ria que de­s­vi­n­cu­la los re­qui­si­tos propios de una in­frae­s­tru­c­tu­ra in­fo­r­má­ti­ca de la capa su­b­ya­ce­n­te es­pe­cí­fi­ca del proveedor. Esto te permite construir toda una in­frae­s­tru­c­tu­ra in­fo­r­má­ti­ca di­s­tri­bui­da en varias nubes.

La palabra clave aquí es “In­fra­s­tru­c­tu­re-as-Code” (IaC). Ojo: “Code”, no “Service”. Mientras que un servicio se alquila, un código permanece bajo el control de uno mismo. Las es­tru­c­tu­ras deseadas se definen en el código. Estas incluyen los co­m­po­ne­n­tes in­di­vi­dua­les, así como las co­ne­xio­nes entre ellos. Además de la do­cu­me­n­ta­ción explícita de los sistemas en el código, hay otras ventajas decisivas.

A partir de las es­tru­c­tu­ras definidas de forma abstracta en el código, el software de or­que­s­ta­ción pro­po­r­cio­na los sistemas in­fo­r­má­ti­cos co­rre­s­po­n­die­n­tes. Es posible di­s­tri­buir los co­m­po­ne­n­tes in­di­vi­dua­les entre varias nubes. Esto sirve tanto para las in­frae­s­tru­c­tu­ras en la nube de di­fe­re­n­tes pro­vee­do­res como para las nubes privadas de la propia empresa. La reducción en los costes de cambio de proveedor co­n­tri­bu­ye si­g­ni­fi­ca­ti­va­me­n­te a la pro­te­c­ción contra el vendor lock-in.