En el episodio 65 de The AI Forecast, "La responsabilidad de Vibecoding: cómo una IA sin control puede acabar con el ROI de la nube", David Linthicum se une al presentador Paul Muller para revelar los costes ocultos de los entornos híbridos y multinube y explicar por qué el gobierno y la resiliencia de la nube se han convertido en prioridades en la sala de juntas.
A medida que las interrupciones de alto perfil en la nube exponen dependencias ocultas y puntos únicos de fallo, los líderes de TI deben replantearse la resiliencia, la gestión de datos y la rendición de cuentas en entornos de nube híbrida.
Esto es lo que destacó de la conversación entre Paul y David:
El principal diferenciador: la fiabilidad frente a la resiliencia
Paul: El término "resiliencia" es curioso, porque la gente suele equiparar la resiliencia con la fiabilidad, y hay una diferencia muy grande, ¿no?
David: Sí que la hay. La resiliencia es tu capacidad para evitar que estos desastres interrumpan tus procesos y tu actividad empresarial. En otras palabras, ¿cuáles son el plan A, el plan B y el plan C? ¿Qué grado de resiliencia y tolerancia a fallos va a tener? La fiabilidad se refiere básicamente a un componente: cómo se mantendrá por sí mismo y cómo se recuperará de un fallo. La resiliencia es tu responsabilidad; la fiabilidad, no. Normalmente, si se trata de un proveedor de servicios en la nube, es su responsabilidad, pero tú seguirás viéndote afectado. Tú vas a pagar la factura. No vas a obtener ningún crédito de estos proveedores de servicios en la nube cuando se caigan.
Paul: La resiliencia es un elemento arquitectónico, no una consecuencia de un componente, ¿no es así? Depende de cómo diseñes tu sistema. Todo se remonta a esa arquitectura empresarial.
David: Todo es arquitectura, y está en las capas de aplicación y empresarial. Hay que trabajar y planificar para lograr la resiliencia. No es algo que surja por sí solo, ni se encuentra en la nube. Ahí es donde la gente se sorprendió. Pensaban que serían completamente resilientes a cualquier problema que tuvieran, pero ahora se dan cuenta de que son falibles como todos los demás. Parte de construir un sistema de IA, una arquitectura empresarial o cualquier tipo de planificación arquitectónica se centra en la resiliencia. Es igual de importante, si no más, que la seguridad, la gobernanza y el resto de aspectos que debemos abordar. Debe ser operacionalizado para poder demostrar, con métricas, que esto no detendrá el procesamiento del negocio si pasa lo peor. Hay que invertir tiempo y dinero para resolverlo.
Si no tienes resiliencia, no podrás superar este tipo de situaciones.
Responsabilidad y observabilidad en un mundo híbrido
Paul: Ahora, mucha gente habla sobre las nubes híbridas, pero parece ser, en algunos aspectos, una combinación de los mejores y peores atributos de los mundos locales y de la nube. ¿Cómo construimos una responsabilidad y observabilidad claras en lo que en última instancia será un mundo híbrido?
David: Si está construyendo soluciones híbridas y multinube, básicamente tiene que gestionar la complejidad que forma parte de las soluciones, y la resiliencia será un plano de control común que atraviese todo eso. La gente piensa: "Bueno, voy a montar esto de forma híbrida, de modo que pueda realizar una conmutación por error a mis sistemas locales, o incluso a otra nube". Eso está muy bien, y funciona, pero no va a ser barato. Creo que la capacidad de comprender esos costes y recursos, y de gestionarlos, es el principal punto de discordia.
La multinube es fantástica porque permite utilizar la mejor tecnología para crear sistemas más eficientes, pero la resiliencia y la fiabilidad van a ser un problema en esas arquitecturas. Siempre digo que se puede tener resiliencia o eficiencia, pero no ambas cosas a la vez. O creamos una arquitectura resiliente, o tendremos que lidiar con interrupciones del servicio tres o cuatro veces al año que le costarán miles de millones a la empresa.
El aumento de los costes de la nube y la tendencia a la repatriación
Paul: Teniendo en cuenta cuestiones como los cortes de suministro catastróficos, los sobrecostes y las complejas responsabilidades, no es de extrañar que muchas empresas estén planteándose repatriar sus cargas de trabajo. ¿Cuál es la situación actual al respecto y cuáles son algunas de las dificultades a las que se enfrenta la gente al intentar volver a trasladar parte de esas cargas de trabajo a su entorno local?
David: Lo más importante sería el coste de hacerlo. Ahí hay dos capas. En primer lugar, ya has gastado alrededor de medio millón de dólares en aplicaciones y en migrarlo todo a la nube, y ahora tendrías que gastar una cantidad similar para volver a trasladarlo. En segundo lugar, tendrías que acudir al consejo de administración y explicar esa decisión y el camino a seguir. Es una conversación difícil, porque implica reconocer que la transición a la nube, que en un principio se esperaba que fuera más valiosa y fiable, no ha dado los resultados previstos. Alguien tendrá que ir a pedir perdón y dar explicaciones para que, en consecuencia, la organización vuelva a un entorno en el que tenga más control sobre el hardware.
Por lo general, recurrir a proveedores de coubicación y de servicios gestionados resulta mucho más eficiente, pero estos se están viendo afectados por el coste de la nube. Y ahora que están analizando las cargas de trabajo de la IA, están intentando hacer ese movimiento aún más rápido porque no pueden permitirse la nube. Aunque la nube va a ser la solución más sencilla para la IA, es la vía más fácil para desarrollar estos sistemas. Se dispone de todo un ecosistema listo para usar bajo demanda, pero resulta demasiado caro para la mayoría de las empresas. Si vamos a volver allí por razones económicas, entonces tenemos que poner algunos recursos en marcha para asegurarnos de que lo hacemos de manera efectiva.
Paul: ¿Cuántos otros desarrolladores de cuántas empresas han puesto en marcha un pequeño proyecto paralelo en una aplicación de programación que haya generado unas cargas de trabajo de computación o de almacenamiento increíbles que provoquen sobrecostes?
David: Estás codificando cuando le indicas al sistema de IA cuál es tu interpretación y qué es lo que tiene que codificar. El problema es que no capta los matices. No sabe gestionar la eficiencia y acabas gastando más dinero. Y ese tipo de cosas, lo de la codificación intuitiva, ya sabes, es divertido, pero la cuestión es que tenemos que recuperar cierto control humano sobre todo esto. Y, cuanto más veo los sistemas de codificación que salen al mercado (ya sabes que la mayoría de mis clientes los están probando), más me doy cuenta de que fracasan porque no son capaces de alcanzar la eficiencia necesaria.
No te pierdas la conversación completa con Adam Skotnicky en The AI Forecast en Spotify, Apple Podcasts, y YouTube.
