Costos de conmutación y bloqueo

No es de extrañar que las organizaciones estén preocupadas de estar encerrados en su proveedor de nube. Después de todo, la historia de la TI está llena de ejemplos de vendedores que aprovechan los elevados costos de conmutación para imponer términos de licencia restrictivos y aumentar los precios. Pero creo que la nube es diferente, y, de hecho, es cada vez más difícil para los proveedores de software, hardware y servicios de TI aprovechar el apalancamiento que han tenido en el pasado.

Este es un tema delicado, y como empleado de AWS, claramente tengo un poco que ver en el asunto. Pero me parece que mucha de la conversación sobre el bloqueo de proveedores está fuera de blanco, así que déjenme ver si puedo reencuadrar la discusión explicando cómo lo pensé cuando era un CIO, antes de unirme a AWS.

En primer lugar, estaba bastante claro por qué me estaba moviendo a la nube. Era principalmente ganar velocidad. Nuestros plazos de producción de nuevas capacidades de TI fueron demasiado largos; mi transformación no se trataba sólo de migrar a la nube, sino de acortar los plazos a través de DevOps, a través de la racionalización de nuestros procesos de gobernanza y supervisión, y mediante la creación de microservicios reutilizables que podrían ser rápidamente recombinados para desarrollar nuevas capacidades. Como el CIO de los servicios de ciudadanía e inmigración de los Estados Unidos (USCIS) supe que los cambios importantes en la política de inmigración podrían suceder en cualquier momento, y cuando sucedieron, nuestros largos plazos serían inaceptables. Tenía razones para creer que la nube reduciría significativamente nuestros costos (terminó cortando alrededor de 75% de nuestros costos de infraestructura directa), pero la velocidad era la primera en mi mente.

¿Cuáles fueron mis mayores obstáculos? El conjunto de habilidades de mis empleados, para uno. La mayoría de ellos nunca habían trabajado en la nube y eran nuevos en DevOps y microservicios también. Un segundo impedimento fue nuestro proceso de adquisiciones, con todo el trabajo legal y el proceso de selección de proveedores, procurando un servicio nos podría llevar a cualquier lugar de seis meses a tres años. Y hubo un impedimento cultural (OK, muchos, en realidad) en que teníamos una cultura de excepcionalidad — nuestras necesidades de TI del gobierno eran tan singulares que teníamos que hacer las cosas de manera diferente a lo que el resto de la industria consideraba que eran mejores prácticas.

Cuando consideré el uso de varios proveedores de nube para nuestra infraestructura y plataformas, rápidamente retrocedí de la idea. Temía que retrasara nuestra transformación, y la velocidad era el factor más importante para mí. Construir nuestros sistemas para desplegarse en múltiples nubes nos costaría tiempo, incluso si usábamos contenedores y herramientas independientes de la nube. Como estaba empujando a mis equipos a aprender a usar la infraestructura como código, no quería que las complejidades de la gestión de la infraestructura en diferentes nubes para ralentizar hacia abajo. Con un enfoque de varias nubes, también habría tenido que mantener el uso de servicios que eran específicos de un proveedor de nube en particular que de otra manera podría acelerarnos. Y como las habilidades eran un problema, no quería que mis empleados dedicaran tiempo a aprender diferentes plataformas en la nube y compatibilidad entre nubes. Finalmente, para superar nuestra cultura de «necesidades especiales» quería que mis empleados comenzaran con el camino más simple y sencillo que otras organizaciones estaban usando.

Por todas estas razones, sabía que cubrir mis apuestas en más de un proveedor de la nube tendría un gran costo para lo que intentaba lograr. Lo que quedaba era para mí considerar los riesgos de elegir un único proveedor de nube y encontrar maneras de mitigarlos.

Mi tren de pensamiento fue así: el término «lock-in» es engañoso. En realidad, estamos hablando de cambiar los costos. Los costos de cambio han existido a lo largo de la historia de TI. Tan pronto como te comprometes a una plataforma o a un proveedor, tendrás que cambiar los costos si más tarde decides cambiarte. Si elige Java y, a continuación, migra a Node.js, tendrá un costo. Si elige Maven y, a continuación, migrar a Gradle, tendrá un costo. Si decides en un mainframe y luego te mueves a un hardware de mercancía escalable horizontalmente, te costará algo. En ninguno de estos casos está realmente «bloqueado», simplemente tiene costos de conmutación, que pueden ser grandes o pequeños dependiendo de la situación.

Y siempre hemos factorizado estos costos en, al menos implícitamente, como hemos tomado decisiones. Si elegimos utilizar Oracle como base de datos para una aplicación determinada, normalmente no construimos la aplicación en SQL Server para asegurarnos de que no estamos bloqueados en Oracle. No lo hacemos simplemente porque creemos que los costos de tener dos bases de datos alternativas para la misma aplicación superan los beneficios en la gestión de riesgos.

Así que me pregunté: (1) ¿Cuáles serán mis costos de conmutación si tuviera que abandonar AWS? (2) ¿Cuál es la probabilidad de que ocurra? Y (3) ¿Cómo puedo reducir los riesgos de manera rentable? Con los servicios en la nube pagos bajo demanda (con algunas excepciones, como las instancias reservadas), por lo que no deja dinero en la mesa si decide cambiar de proveedor. Decidí que no tenía sentido en nuestro caso hacer todo el trabajo inicial de hacer nuestras aplicaciones multi-nube; como he dicho antes, que sería un costo muy grande y la probabilidad de que yo tendría que dejar AWS, juzgué, no era tan alta. En cambio, aceptaría que habría un costo de conmutación más adelante si, por alguna razón, decidimos dejar AWS, y que pudiéramos trabajar para mitigarlo.

La primera área que consideramos para reducir el riesgo de altos costos de conmutación fue arquitectónica. Usamos contenedores de Docker que esperábamos que serían desplegables prácticamente en cualquier lugar. Construimos microservicios, en parte con la idea de que más tarde podríamos decidir poner algunos servicios en una plataforma y otros en otra. También sabíamos que podríamos reducir el «radio de explosión» de los cambios a un único microservicio y probar cada uno independientemente por si necesitábamos empezar a cambiar a gran escala. Trabajamos activamente para acoplar nuestros servicios, especialmente cuando utilizamos un servicio específico de AWS, construyendo una fachada para cada servicio de AWS para que pudiéramos cambiarlo de la forma más transparente posible.

Una cosa que no hicimos, pero que es posible que desee considerar, es escribir un plan de “salida” o «reversión». Dependiendo del nivel de riesgo existente, puedes hacer que este plan sea más o menos detallado. En el plan, puede detallar cuáles serían los principales costos de conmutación si tuviera que abandonar AWS y qué pasos está tomando para administrarlos. También puede hacer un plan de proyecto de alto nivel para saber cómo se llevaría a cabo la salida, y puede estimar los costos. Con este plan en la mano, puede tomar decisiones informadas sobre el riesgo que está tomando comprometiéndose con un proveedor a la vez.

Como mencioné, la nube, DevOps y otros desarrollos contemporáneos están aflojando el asimiento que los vendedores tradicionales han tenido en usted. Si está haciendo las cosas que describí — acoplando sin apretar, creando fachadas, usando contenedores, etc. — no sólo está facilitando el cambio de proveedores de nube, sino que está facilitando el cambio de cualquier tipo de proveedor de plataforma. Al agregar el impacto del código abierto a los costos reducidos de desarrollar sus propias soluciones personalizadas, y a las ofertas de AWS en una base de «pago según demanda» (por ejemplo, RDS, DynamoDB y Aurora), sus riesgos (es decir, sus posibles costos de conmutación y la probabilidad de que desee cambiar) disminuyen rápidamente. Pero no es sólo riesgo, también se beneficia de la innovación que los vendedores traen cuando tienen que competir por su negocio.

Lo suficiente sobre mi proceso de toma de decisiones como un CIO, permítanme cambiar los sombreros y hablar desde mi perspectiva como un estratega de empresa en AWS por un momento. Al evaluar el riesgo de trabajar con AWS, tenga en cuenta que hemos construido deliberadamente nuestra plataforma en la nube en estándares abiertos como Xen, SQL y Linux, y cada vez somos más colaboradores en proyectos de código abierto. Hemos reducido los precios 67 veces ahora, en gran parte en ausencia de presiones competitivas para hacerlo. Nuestras herramientas que le ayudan a migrar a AWS también se pueden usar en reversa para ayudarlo a migrar. Hemos intentado hacerlo lo más fácil posible si opta por abandonar AWS. Para ser honesto, eso tiene sentido desde una perspectiva empresarial, porque también es en nuestro interés reducir el riesgo de trabajar con nosotros.

Nuestro ritmo de innovación debe garantizarle que pretendemos seguir ganando su negocio, con el conocimiento de que puede desplazarse a otro proveedor de la nube si decide hacerlo. 90 a 95 por ciento de nuestro roadmap está impulsado por lo que nuestros clientes nos dicen que quieren. Fue AWS el pionero en la nube y que sigue conduciendo el desarrollo de la nube.

Vale, llega de propaganda. Pero en serio, como estratega empresarial me gustaría hacer las siguientes sugerencias. En primer lugar, si usted cree que el riesgo de usar un solo proveedor supera los costos de usar más de un proveedor, seguir adelante y trabajar con varios proveedores. En ese caso, le sugiero que reduzca los costos de su decisión colocando algunas cargas de trabajo en nubes diferentes, en lugar de intentar hacer que una sola carga se pueda desplegar en varias nubes. Si está de acuerdo con mi razonamiento y decide ir con un solo proveedor, le sugiero que mitigue sus posibles costos de conmutación a través de una buena arquitectura, prácticas de implementación estándar y un poco de planificación previa.

Hay costos de cambio cuando se elige una plataforma en lugar de otra, y siempre ha habido. No existe tal cosa como «lock-in», excepto en la medida en que usted está de acuerdo con él contractualmente, pero los costos de cambio pueden ser altos o bajos. A través de un buen diseño y algún pensamiento anticipado, puede reducir sus costos de conmutación (desde software tradicional o desde un proveedor de nube). En lugar de pagar por adelantado esos costos de conmutación aceptando una penalización de velocidad y costos más altos ahora (en la nube de múltiples nubes), es posible que desee reducir sus costos de conmutación potenciales y ver si su proveedor sigue sirviendo bien.

–Mark

@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value
War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age

Mark Schwartz

Mark Schwartz es estratega empresarial en Amazon Web Services y el autor de “The Art of Business Value” y “A Seat at the Table: IT Leadership in the Age of Agility”. Antes de incorporarse a AWS, fue el CIO del servicio de ciudadanía e inmigración de los Estados Unidos (parte del Departamento de seguridad nacional), CIO de Intrax, y CEO de Auctiva. Tiene un MBA de Wharton, una licenciatura en Ciencias de la Computación de Yale, y una maestría en Filosofía de Yale.