El “vendor lock-in” ha sido un riesgo citado a menudo desde mitades de los años 90.
Miedo de que, al invertir demasiado en un vendor, una organización reduce sus opciones en el futuro.
¿Fue esta una preocupación válida? ¿Lo es todavía hoy?
El Riesgo
Las organizaciones caminan en una línea fina con sus vendors de tecnología. Idealmente, se selecciona un conjunto de tecnologías que no solamente cumplen con sus necesidades actuales, pero que se alinean con su visión a futuro también.
De esta forma, coforme maduran las herramientas del vendor, estas continúan soportando su negocio.
El riesgo es que, si se tienen todos los huevos en una sola canasta, perderá todo el poder en la relación con su vendor.
Si el vendor cambia de dirección, Incrementa sus precios de forma significativa, retira una oferta crítica, baja la calidad del producto o sucede cualquier otro escenario, usted está en un problema.
El “lock-in” con un vendor significa que el costo de cambiarse con otro o cambiar de tecnología puede ser prohibitivo o muy caro.
Todos estos escenarios han sucedido y sucederán de nuevo, por lo que es natural que las organizaciones estén preocupadas por el lock-in.
La Madurez de la Nube
Cuando la nube comenzó a volverse prominente, el espectro del lock-in resurgió. CIOs alrededor del mundo pensaban que migrar la mayoría de su infraestructura hacia AWS, Azure o Google Cloud los ataría a ese vendor en el futuro.
Tratando de mitigar este riesgo, las organizaciones regularmente adoptaron un enfoque “neutral de la nube”. Esto significa que sólo usaban servicios “genéricos” ofrecidos por los proveedores. A menudo disfrazado como una estrategia “multi–nube”, en realidad era una apuesta para no perder el poder en la relación proveedor/cliente.
Por sí solo, es un movimiento inteligente.
Dar un paso hacia atrás y ver el panorama completo puede mostrarnos algunos de los problemas con este enfoque.
Automatización
El primer problema es que el uso rudo de la automatización en los despliegues en la nube significa que el lock-in no es un riesgo tan importante como lo era en épocas pasadas. El esfuerzo manual requerido para hacer que un vendor cambie para su red de almacenamiento solía ser monumental.
¿Ahora? Es un par de APIs y una cuenta basada en consumo ajustada por megabytes. Este patrón se repite a lo largo de otros tipos de recursos.
La automatización reduce de forma importante el costo de cambiar proveedores, lo cual reduce el riesgo de lock-in.
Perderse de algo
Cuando su organización establece el mandato de solamente usar los servicios básicos (cómputo basado en servidores, bases de datos, redes, etc.) de un proveedor de servicios en la nube, está perdiéndose de una de las ventajas más importantes de migrar hacia la nube; hacer menos.
La meta de una migración hacia la nube es eliminar las cargas pesadas de sus equipos.
Usted quiere que sus equipos entreguen valor de negocio directamente el mayor tiempo posible. Una de las formas más directas de lograrlo es potenciando cada vez más servicios gestionados.
Usando AWS como ejemplo, usted no quiere correr sus propios servidores de base de datos en Amazon EC2 o incluso en RDS estándar si puede evitarlo. Amazon Aurora y DynamoDB usualmente ofrecen menos impactos en la operación, un mejor desempeño y menores costos.
Cuando las organizaciones están preocupadas por el lock-in, típicamente se pierden del verdadero valor de la nube: un enfoque especializado en entregar mayor valor de negocio.
Pero la multi-nube…
En este nuevo enfoque, una estrategia multi–nube tiene un objetivo diferente. Sus equipos deberían estar intentando maximizar el valor del negocio (lo cual incluye costo, carga operativa, esfuerzo de desarrollo y otros aspectos) a donde sea que esta tarea los lleve.
Conforme las organizaciones maduran en el uso de su nube y la implementación de filosofías DevOps, generalmente comienzan a elegir cuidadosamente servicios que los proveedores de la nube complementan mejor su visión de negocio y ayudan a resolver problemas.
Ellos usan la automatización para reducir el impacto si es que tienen que cambiar de proveedores en algún punto en el futuro.
Esto lleva a una división multi–nube que típicamente se distribuye en 80% en una nube y 10% en otras dos. Esto puede variar dependiendo de la situación, pero la premisa es la misma; las organizaciones que prosperan tienen una nube primaria y otros servicios cuando y donde hace sentido.
Herramientas de Spanning para la Nube
Hay algunas herramientas que son más efectivas cuando puedan trabajar en todas las nubes que está utilizando la organización. Estas herramientas van desde productos de software (como herramientas de seguridad y de implementación) hasta métricas en playbooks operativos.
Siguiendo los principios de enfocarnos en entregar valor al negocio, es necesario evitar activamente duplicar un conjunto de herramientas a menos de que sea absolutamente necesario.
La madurez de las herramientas en las operaciones en la nube ha alcanzado el punto en el que puede entregar soporte a múltiples nubes sin reducir su efectividad.
Esto significa que los playbooks de automatización puedan soportar fácilmente multi–nube (por ejemplo, Terraform). Las herramientas de seguridad puedan soportar fácilmente multi–nube (por ejemplo, Trend Micro Cloud One™). Las herramientas de observación pueden fácilmente soportar multi-nube (por ejemplo, Honeycomb.io).
El principio guía para una estrategia multi–nube es maximizar la cantidad de valor que el equipo puede ofrecer al negocio. Usted puede lograr esto al volverse más eficiente (usando el servicio correcto y la herramienta correcta en el momento correcto) y eliminando trabajo que no contribuye a lograr ese objetivo.
En la era de la nube, el lock-in de vendors debe de estar al final de su lista de preocupaciones. No permita que un miedo antiguo impida el progreso de sus equipos.
[hr toptext=”” size=”” custom_size=”2″ hide_mobile_hr=”false”]
También puede interesarle:
| » | 8 Mitos de la nube |
| » | Explorando las amenazas comunes a la seguridad en la nube: |
| » | ¿Es más seguro el Cómputo en la Nube ante Hackers Maliciosos? |
Leave a Reply