Episode Transcript
[00:00:00] Speaker A: Todo falla todo el tiempo, al final es inevitable. Cada servidor, cada línea de código, cada sistema que montas, al final en algún momento va a caer. Los sistemas que perduran en el tiempo son aquellos que están alineados con los costes de negocio. Yo no puedo, o sea, me tengo que asegurar que la infraestructura que yo voy a desplegar se alinean con los ingresos y los objetivos. El que piense que yo diseño, soy un arquitecto de la leche y esto nunca va a caer, más vale que busque otro trabajo. No hay mejor alerta en mi monitorización que la factura. Si se dispara de repente de 1000 a 5000, oime, algo ha pasado. Está claro que si quieres ir rápido puedes ir solo, pero si quieres llegar lejos tienes que ir en equipo.
[00:00:42] Speaker B: ¿Qué tal?
[00:00:43] Speaker C: ¿Cuánto tiempo, Luna? Bueno, la verdad que bien, después de estar estos días en el Fin of Foundation Phoenix en Barcelona, contento, un poco cansado, pero la verdad que contento. Conocemos mucha gente de la comunidad y bueno, estamos acá con Guille.
[00:01:02] Speaker B: ¿Qué tal Guille? ¿Cómo estás?
[00:01:04] Speaker A: Buenas. Oye, muchas gracias por la invitación.
[00:01:07] Speaker B: Muy bien, un placer, un placer tenerte con nosotros.
Bueno, a Guille, para los que algunos no le conozcan, pues es Devrel de Amazon. Seguro que le habéis visto tanto en el podcast que tiene de charlas técnicas de WS, si estáis en eso, Ÿousand, como tanto en post y demás. Hace un montón de cosas por la comunidad de AWs aquí, sobre todo en España. ¿Así que bueno, Guille, cuéntanos un poco tu historia, en qué estás ahora y nada, cómo has acabado aquí?
[00:01:38] Speaker A: Bueno, cómo acaba aquí Damián y su hermano Ariel, que los conozco ya hace unos años, que siempre los he llamado los Munafo brothers o los Bros brothers. Pues aquí los tenemos. Me engañó para participar en vuestro podcast y charlar un poco de toda esta parte de Finops y venía muy a juego con cosas que estábamos haciendo del arquitecto Frugal, al final cómo diseñamos nuestros sistemas distribuidos, etc. Podía encajar en una charla agradable con vosotros. Y vengo del mundo de la infra, llevo muchos años en esto de la nube. Ya en su día me peleaba con aws cuando ni siquiera estaba creciendo. Y fíjate cómo hemos acabado, la de vueltas que da la vida. ¿Andamos de evangelistas enseñando, yo siempre me gusta decir enseñando el arte de lo posible, qué se puede hacer en la nube? Y ahora lo que estoy intentando es qué se puede hacer en la nube siendo eficientes y sostenibles.
[00:02:37] Speaker B: Eso es, eso es. Y bueno, para los que no lo conozcáis, Guille probablemente me dé una colección de shorts con sus quotes y con sus citas, probablemente que no tenga que hacer ningún tipo de trabajo o sea, que va a ser una auténtica maravilla editar este episodio. Y nada, Guille, pues te queríamos preguntar un poco la parte, lo que has comentado del tema del arquitecto frugal, de esta cultura que ves que está saliendo ahora. ¿En qué momento crees que hubo ese cambio? ŸOusand de la parte de infraestructura, porque tú y yo también somos de esa parte de infraestructura que nos centramos quizá más antes en otras cosas que en el coste. ¿Y en qué momento tú crees que eso ha cambiado y por qué crees que haya podido pasar?
[00:03:20] Speaker A: Yo creo que cada vez que ha habido una crisis, al final esto parece puertas abiertas al campo. Llega una burbuja, explota la burbuja y ya está. Todo el mundo ahorro de costes, a ser más eficientes. ¿Y llega un momento en el que te planteas de coño, por qué estar haciéndolo cada ciclo, que son cada ocho o 10 años que pasa un crash de este tipo, y no integrarlo ya para que el día que pase el impacto sea el mínimo posible? De hecho, fijaros que como vivimos en una sociedad completamente conectada, cada aspecto de lo que hacemos hoy en día en nuestra vida, desde lo más cotidiano, sacar un billete de avión o estamos todo el día viajando, los dispositivos que usamos, las transacciones que hacemos, todo, todo. Hay una serie de sistemas que operan en segundo plano. ¿Qué pasa cuando uno de estos falla? Empiezan a caer. Yo siempre me gusta hablar del caos, de como alguien desconecta el cable y de repente el mundo se viene abajo, todo se paraliza. Lo vimos con la pandemia, lo estábamos viendo ahora con las danas, lamentablemente con pérdidas humanas. Ÿ y estamos viendo que cada vez que ocurre una circunstancia de este estilo, todo se paraliza. Y a partir de ahí, cómo podemos realmente plantearnos te hace replantearte ciertas cosas.
[00:04:35] Speaker B: Eso es bueno y se te ha olvidado, aunque no, otros son este tipo de cosas son desastres naturales, no enfermedades. Pero también puede ser por un fallo técnico. Mira, cuando lo estabas diciendo me estaba acordando de el famoso incidente de Cloudstrike, que se paró el mundo.
[00:04:52] Speaker A: Yo no quería mencionarlos porque son amigos y de hecho a nosotros nos pilló estando en EE.UU. y volvíamos ese viernes de vuelta a mí, gracias a Dios, tenía el avión muy por la tarde, pero mis compañeros de por la mañana estuvieron 8 h atascados porque Delta no funcionaba. American Airlines creo que se salvó. Debe ser que no era cliente de esta gente. Pero sí, ahí te das cuenta que todo falla todo el tiempo. Al final es inevitable. Cada servidor, cada línea de código, cada sistema que montas, al final en algún momento va a caer. De hecho, hay una regla en hardware que es el Between Failures, ese tiempo de caída entre que el dispositivo se reinicia, porque tú no puedes controlar todo eso. Lo que sí es cómo me puedo preparar para cuando llegue ese momento, ÿousand cómo diseñamos y cómo hacemos para, lo que decíamos antes, minimizar ese impacto y hacerlo de una forma más eficiente.
[00:05:50] Speaker B: Sí, totalmente. Y al final que puedes tener un poco más control de qué puede pasar, cuándo pasa, cuánto tiempo me toca, todo el tema de en infra y en DevOps, la parte del disaster recovery que tenemos y demás. ¿Y bueno, yo te quería preguntar un poco en la parte de más de AWs, que al final por lo que sea es tu expertise, cómo crees que se está un poco gestionando el tema del Finops dentro de AWs?
¿Qué herramientas crees que pueden estar siendo las más útiles a ese nivel? Y en general, las prácticas que tú estás viendo en clientes o dentro de la compañía que puedan ser importantes en Finops.
[00:06:32] Speaker A: Bueno, es interesante porque Werner Vogels, nuestro CtO en el 2020 en Reinvent, hizo una keynote hablando justo del arquitecto Frugal, de cómo diseñábamos sistemas distribuidos que perduraran en el tiempo de una manera mucho más eficiente en cuanto a coste y sostenibilidad. Y vino con siete leyes. Y creo que esas siete leyes la verdad que encajan muy, muy bien a la hora, al menos lo que venimos de Infra, a la hora de cómo planificamos y diseñamos. ¿Y por ejemplo, hablaba de la primera, que era un tema de haz del coste un requisito no funcional, porque al final cuando piensas en el diseño siempre estamos enfocados a la disponibilidad, la seguridad, la escalabilidad, pero cuántas veces nos hemos parado a pensar en el coste? Al final un tema del CIO, el CTO y el CEO definen cómo va el negocio y todo lo demás y es un factor clave. Yo creo que a la hora del diseño hasta la parte de operación, desde la primera línea de código que pone el desarrollador hasta esa última instancia que tenemos en producción, todo impacto tiene un coste.
Y si a eso le añadimos ahora toda la parte de sostenibilidad, y mucha gente a lo mejor aquí dirá con esto está en lo de la agenda 2030, yo en esas cosas no creo porque creo que son chiringuitos y perdón, aquí sí lo puedo decir, a lo mejor me echan, no te preocupes.
Pero sí que es cierto que yo creo que hay que ser sostenible desde hace muchos años, cada vez estamos viendo como la inteligencia artificial requieren más recursos, más computación, más consumo. De hecho, se hablaba de esa fase de cerramos centrales nucleares y se están dando cuenta que para que la IA siga avanzando quizás hagan falta mini reactores para poder mantener toda esa capacidad.
¿Aquí hay un balance de compromiso hasta dónde queremos llegar y cómo queremos llegar? ¿Queremos que la inteligencia artificial siga evolucionando y consiga, como decía el Elon Musk, que acabe haciendo todo por nosotros y que nos paguen y podamos vivir todos de puta madre o realmente queremos limitarlo y hacerlo? Entonces dentro de eso, pues yo creo que el coste es un factor muy un factor muy clave para a la hora de diseñar y hacer cosas.
[00:08:49] Speaker B: Sí, y eso también te acuerdas que en la keynote que vimos el otro día se habla un poco de la dualidad, me parece un concepto súper interesante que es la dualidad de ai for finops, es decir, el finops, o sea la ia para el finops, es decir, para usar herramientas que se basen en ia, que generen optimización y finobs for ai, es decir, cómo aplicar el Finops al propio gestión de la AI. Y esa dualidad es como quizá uno de los temas más importantes que estamos viendo últimamente.
[00:09:21] Speaker A: Pero es interesante, es interesante este aspecto porque justo la gente muchas veces se pregunta oye, que es mejor que me gaste millones y cree mi propio modelo de lenguaje large LLM como decimos, o simplemente hago un rack que escojo un modelo fundacional que es genérico en base a datos entrenados y le doy mi contexto y en base a ese contexto el coste no va a ser el mismo. También es cierto que las limitaciones son mucho mayores simplemente en un contexto que realmente entrenar un modelo entero. Yo creo que ahí va también muy ese compromiso, ese trade off nos gastamos la pasta o vamos con esto que soluciona las necesidades de negocio que tengo a día de hoy lo que estoy.
[00:10:03] Speaker C: Viendo es que no solamente en cigars, pero nosotros como personas, trabajadores, querés ser más útil, tenés al aire. Hay que empezar a entender cómo utilizarla y cómo integrarla en el día a día para ser puede ser mucho más eficiente.
Bueno, en el synopsis lo vemos porque vas, pones datos, preguntas y cuando te acostumbras, empezás a manejar, dependes cómo funciona y lo integras en tus procesos mucho más eficaz en lo que vos podés hacer. Cuántos temas más podes tocar, en cuanto más eficaces, o sea, cuántas más reducciones puedes hacer de sit ups, [sos/eos] y estamos viendo que últimamente también, o sea, estamos hablando de todo este tema de la finos foundation ahora el día está en todo lado, todas las herramientas están hablando, tenemos todas las tienen ahí y la verdad que sería interesante ver a dónde va a llegar al final todo esto.
[00:11:07] Speaker A: Es cierto que hay mucho marketing detrás de todo esto, pero también también lo que estamos metidos en el día a día haciendo cosas. Todo el tema de orquestación de multiagentes, que creo que ya es una realidad a día de hoy, se ve el potencial, el potencial de cómo mejorar en la sociedad, de cómo mejorar la calidad de los servicios y sacar nuevos productos que realmente puedan tener un impacto real en la industria. Antes habéis mencionado herramientas, me has soltado la pregunta de porque en algún momento en esta conversación yo voy a empezar desde la parte de infra y llegaremos y ya nos juntaremos con la parte de negocio. De hecho, creo que es de lo que va todo el tema de Fino. Pero a nivel de infra, cuando nosotros en AWS una de las cosas que creo que hicimos muy muy bien fue una herramienta que liberamos open source que es Carpenter, que es un auto escalador de kubernetes que te permite optimizar las instancias en función ÿousand el tipo de carga de trabajo que estés desplegando. Funciona en AWS, pero también funciona en Azure y yo espero y deseo que esto acabe funcionando en todos los hiperescaladores porque creo que es una herramienta muy interesante a todo eso. Por un lado, con eso ya optimizas porque siempre te va a ajustar en base a la demanda el tipo de instancia que puedes utilizar. Y por instancias en AWS no va a ser. Tenemos un catálogo infinito que prácticamente para cualquier cosa puedes utilizar. Pero luego hay un concepto interesante que no mucha gente sabe, que solo en las instancias spot, que es capacidad que tenemos disponible en el datacenter y no estamos utilizando, se saca para que la puedas utilizar a un precio mucho más reducido. El único inconveniente que tiene es que en cualquier momento te la pueden quitar. En caso de que la compañía la necesite, te apaga la máquina, te la quita y la utiliza. Pero lo puedes utilizar para hacer cosas que no sean muy muy críticas, para hacer procesamiento de datos o cosas que tengas que hacer. Pues oye, te estás ahorrando un buen pellizco. Y ahora hablaremos de un ejemplo muy claro. 1 Tercera, que es a lo que vamos todos y que yo apuesto a futuro, son las Arquitecturas ARM. Lo siento por los amigos de Intel tal, pero sí creo que es mucho más eficiente. ¿Lo que pasa que aquí sí que hay un truco porque dices oye, la Arquitectura ARM es un 40 % más eficiente, más barato, me ahorro costes, tal, pero oye, cuál es el coste de migrar mis aplicaciones de xar? O sea, es que a lo mejor cuando empiezo a calcular el número de recursos que me hacen falta para recompilar la aplicación, las dependencias, etc. No me compensa. O quizás sí, si echas números dices oye, ahora me supone un gasto pero a largo plazo ahorramos. Esos son los tipos de compromisos que yo creo que la gente tiene que analizar a la hora de diseñar toda esta estrategia de crear sistemas distribuidos. ¿Como sé que te gustan las frases, te iba a soltar ya la primera, no? Porque si no consideras el coste en cada decisión, lo que estás poniendo en riesgo es la sostenibilidad de todo tu sistema.
[00:14:06] Speaker B: Bueno, pues nada, ya tenéis el clip chicos, no pasa nada, es uno de muchos.
[00:14:12] Speaker C: Gradual o anotarlo, imprimirlo.
[00:14:15] Speaker A: Tenemos siete leyes, o sea que espero, no sé si me saldrán siete frases para cada ley.
[00:14:20] Speaker C: Bueno, no, pero es interesante lo que dijiste porque la verdad que también cuando estás planeando ya podes identificar, no es solamente si estas personas. Hay una parte que la puedes tener así ok, cómo pasa todo esto del x a nada, compilar todas mis cosas. Pero hay recursos ya como los RDs que a veces lo puedes usar. ¿Por qué elegir desde un principio algo que te va a salir más caro? Somos el más barato, así que en eso hay que ya ponerlo en el principio cuando estás haciendo la arquitectura.
[00:14:59] Speaker A: Bueno, y de hecho creo que hoy anunciaron o ayer anunciaron que no sé si era Dinamodb, uno de nuestros servicios caía como 40 % mucho más barato que hace dos días. Al final esa evolución la vas a ir viendo cuanto más se utilice. Yo creo que es un ciclo Ÿousand. Al final nosotros experimentamos, creamos, en cuanto se adopta y cada vez hay más, pues al final se tienen que ir bajando el coste de cada cosa y eso repercute en el cliente final.
[00:15:26] Speaker C: Pero es que no conectaron con el de.
[00:15:30] Speaker A: Sí, o sea, si tú operas a día de hoy en AWS, tienes el explorador de costes que te va a sacar un desglose de qué servicios y de forma mensual tienes una gráfica ŸOusand de cómo verlo. Pero luego también tienes un advisor, tienes ahí un sistema que te va a decir oye, estás utilizando esta instancia que me he dado cuenta que los últimos 10 meses pues estás consumiendo un 30, %, vamos a pasar mejor a esta otra instancia que te va a salir mucho más barata, tal. También tiene ciertos peligros porque muchas veces estos advisors no tienen el contexto global. A lo mejor yo ese servidor lo tengo porque una vez al año tengo un pico y necesito toda la potencia para hacer una determinada función.
Si eres capaz de darle ese contexto a estos tipos de modelo y estas aplicaciones, pues evidentemente te van a venir bien. Otra de las recomendaciones que suelen hacer es oye, pásate de x arm porque vas a ahorrar, etc. Pero ya se empiezan a dar esas herramientas para que tú tengas la visual de qué es lo que gasto, cómo lo gasto. Y siempre hemos dicho Ÿousand al final no hay mejor alerta en mi monitorización que la factura. Si se dispara de repente de 1000 a 5000, Oime, algo ha pasado en todo esto.
[00:16:41] Speaker B: Sí, totalmente. Al final es lo que has mencionado de las alertas. Yo siempre lo veo que, por ejemplo, para gente que se esté iniciando, que pueda estar escuchando, es el tema de poner tu presupuesto y ponerte una alerta te va a salvar de más disgustos que muchísimas optimizaciones, muchísimas cosas que inventes. Es decir, te cierras tu presupuesto cuanto más o menos y cuando veas qué tal es el momento en el que ya tienes un poco de margen de actuar y saber que se te está yendo pronto, que tengas una delta del 50 % y te salte en el día dos, tú dices algo estamos haciendo mal. Cuanto antes lo que haces, mejor.
[00:17:22] Speaker A: Y de hecho, una conversación que tuve con Damián hace un tiempo justo él me decía claro, es que cuando estás en on prem no sabes el coste de lo que hay, porque al final yo hago una inversión, compro unos equipos, tengo mi datacenter y sé que en cinco años tengo que renovar equipos, licenciamiento y todo lo demás. Y mis cálculos van me gasto x millones en cinco años, esto es lo que voy a montar y así va mi negocio. Dentro de cinco años vuelvo a invertir. Cuando vas a la nube, desde el primer segundo sabes lo que estás gastando, tienes un mayor control de hacia dónde van las cosas. También es cierto que puedes crecer infinitamente cuanto más recursos tienes a disposición, pues al final es un control que hay que tener en consideración.
[00:18:02] Speaker B: Sí, dale, dale, Dami, perdón.
[00:18:07] Speaker C: Hablaste de todas las de las alertas y toda esta información que hay. No quería conectar con lo dijo Guillermo, que dice bueno, que recibiste al final del mes, no hay que justo lo que no hay que esperar. O sea, vamos, vamos a poner alertas para usar las anomalías, para estar nomás, para recibir las alertas y estas cosas lo más antes posible y no llegar a fin de mes de la factura.
[00:18:39] Speaker A: De hecho, esto me lleva a la segunda ley de Werner, que él hablaba que los sistemas que perduran en el tiempo son aquellos que están alineados con los costes de negocio. O sea, yo no puedo, o sea, me tengo que asegurar que la infraestructura que yo voy a desplegar se alinean con los ingresos y los objetivos. Y yo siempre pongo de ejemplo a Ryanair, la aerolínea de coste de bajo coste más grande de Europa, creo que es el lema o el logo que tienen y están muy orgullosos de ello. Es cierto que ellos lo que van es juegan con márgenes muy pequeños y van a la cantidad sobre la calidad te permite por €18 volar a otro país. Pero claro, no pueden escalar superando los ingresos que tienen. Entonces ellos por ejemplo, su estrategia es a instancias Spot. Creo que es uno de los clientes más grandes que utiliza instancias spot dentro de AWS. No lo usan para datos críticos pero sí para procesar cierto tipo de información. Es una forma de tener un balance en cuanto a ingresos, coste de infraestructura.
¿Aquí si quieres te digo también la segunda frase ÿ al final vas a tener que sacar camisetas, una con cada lema, no? Crecer por crecer no es suficiente.
Yo creo que lo que la gente tiene que quedarse con eso en la cabeza hay que hacerlo siempre alineado con los ingresos de mi negocio.
[00:20:00] Speaker B: La línea de camisetas estará disponible el año que viene, no os preocupéis chicos.
Pero y eso es una cosa que es muy interesante y que es una parte, a mí es una de las partes que quizá quizá más me gustan del Finops, que es la parte de las economías de unidad o Unit Economics y los KPIs.
Al final en Cloud y en el resto de gestión de infraestructuras es crítico saber, por ejemplo, algo tan simple como el coste por usuario. Es decir, cuánto es el valor que te da un usuario y cuánto te cuesta. Y eso es básico de negocio.
Primero de negocio, que en negocios tradicionales es muy relativamente sencillo de medir, pero cuando ya nos metemos en algo más complejo como puede ser el cloud y los costes son más variables y no es tan sencillo de calcular.
¿Es algo que no puedes perder porque al final lo que tú dices, no? Crecer por crecer, si tu coste de usuario es €1 y el beneficio que te da es 0,90, cada usuario que tienes te está hundiendo el negocio, entonces no estamos haciendo algo no está cuadrando. Entonces ese tema de saber qué metas y qué valores a ese nivel unitario me parece que es algo súper crítico y súper importante. Vimos varias charlas en el evento a ese nivel de ratios, de indicadores, de cómo calcularlo, porque al final sí que es verdad que es algo muy concreto de cada negocio. Es decir, por ejemplo, Ryanair pues tendrá mucho en cuenta los vuelos, el tiempo, las cancelaciones, etc. Que es muy del negocio Ÿousand pero un supermercado tendrá otras métricas, un banco tendrá otras métricas y eso es algo que me parece complicado de generalizar a nivel de pero por otra parte es muy importante tenerlo en cuenta. Es decir, esos KPIs, esas unidades económicas son fundamentales para que un negocio que esté en el cloud funcione bien, porque si no estás haciendo cosas totalmente a ciegas.
[00:22:02] Speaker A: Bueno, ahí viene la parte de monitorización. Cuántas veces hasta no hace mucho, hasta hace unos años nunca se había asociado los KPIs de negocio a la infra. Nadie llegaba al CIO y le decía Oye, estamos palmando €300000 al año por mala utilización de la infraestructura o porque tengo x entornos de desarrollo que parecen champiñones por todos lados y con poca utilización y mucho consumo. Cuando se han empezado a alinear esos costes, los de arriba han levantado las orejas y han dicho hay que ser mucho más eficientes en esto e ir a una estrategia en la que no haya tantos entornos de desarrollo, que tengas estos sandboxes ya limitados en cuanto a recursos, etc. Ya se le empieza a poner más foco para realmente ir mirando más cuánto gastamos y cuánto consumimos.
[00:22:49] Speaker C: Ahí también viene un tema un poco lo que tocaste antes, eso del spot. O sea, cuando estamos planeando, vamos a planear en donde podemos usar los cursos más tenemos un tenemos un sandbox, tratamos de usar cuanto más posible estos recursos que son como spot, sin más. Cuando no utilizamos todos estos recursos, apaguemoslo. Y ahí entran toda esta filosofía que tenemos en films de todas las automatizaciones.
¿Qué parte de eso empieza a ir cuando te estás monitoreando y sacando, aprendiendo bien tu negocio? Y también está el tema ese que cuando buscas optimización, una optimización no solamente lo que es una arquitectura o en los recursos, sino también en cómo usás la aplicación. Porque vemos a veces, por ejemplo, el otro día teníamos, escuché, estaba hablando con alguien en el Cielo Foundation, estaban cuidando los estaban haciendo save a los blogs diarios y cada vez que lo hacían eran $100. Pero vos al final no necesitas grabar los resultados cada $100, cada rato, eso lo podés hacer una vez al mes. No tocas todo el tiempo. Hay que buscar fijación, hay que buscar en varias formas y no solamente en las que estamos acostumbrados. También hay que fijarse en el usuario y el uso.
Estabas hablando también de Víctor, dema cuenta te cuesta un usuario Ÿousand.
[00:24:23] Speaker A: Pero mira, toca un tema importante que es el almacenamiento. Por ejemplo, en la monitorización y la observabilidad. Mucha gente tiende a cuanto más datos guardo, mejor análisis puedo hacer. Y al final te das cuenta que necesitas simplemente un porcentaje esa información, un muestreo para poder sacar conclusiones.
No puedes guardar todo porque al final es como no es el easy por sí, porque al final ese por sí te está llevando a mucho incremento, mucho mayor de costes que te pueden meter en un problema el día de mañana. Incluso aunque tengas distintas clasificaciones de almacenamiento. Lo meto en un call porque me da igual siempre si algún día tengo que tirar porque por regulación tengo que tener el dato cinco años, 10, depende de la industria en la que trabajes. Siempre sabes que para recuperar en la primera cabecera van a ser 4 h de restauración hasta que puedo leer el dato. Si puedes vivir con eso, guárdatelo. Pero hay que tener muy en cuenta. Pero también llega la parte de cuando yo estoy diseñando todo esto al final se trata de llegar a un compromiso entre por ejemplo, hay tres factores que siempre están en fricción que es el coste, la resiliencia y el rendimiento.
Todo falla todo el tiempo. Lo hemos dicho al principio.
¿Cuánto estoy dispuesto a sacrificar en rendimiento o coste para obtener esa resiliencia, para que no fallen las cosas? Y a mí esto me recuerda mucho a lo de las tres B bueno, bonito y barato. Puede ser bueno y bonito pero no te va a salir barato y cualquier combinación que hagas nunca vas a tener esas tres. ¿Cómo encuentras ese punto donde el sistema no sólo es rápido sino también tiene un coste eficiente y además es capaz de resistir a los fallos que se van a dar porque sí o sí se van a dar? Aquí el que piense que yo diseño soy un arquitecto de la leche y esto nunca va a caer ÿ más vale que busque otro trabajo.
[00:26:11] Speaker C: Eso exactamente la parte del chain, encontrar ese punto y cada uno lo tiene un punto diferente en que todas esas faltas segundas y dan lo más eficaz a una compañía no era era un.
[00:26:26] Speaker B: Poco eso, que al final es tener ese lo que lo que hablábamos de tener ese factor de coste en cuenta porque bueno, al final los DevOps que no hemos empezado, o sea que hemos empezado hace no mucho, siempre hemos estado con hemos recibido el mensaje de escalabilidad, arquitectura súper resiliente, súper escalables, no sé que sea lo más cutting edge posible y nadie mencionaba ni una sola palabra del coste. ¿Cuánto te cuesta tu querido cluster de Kubernetes? ¿Cuál es el coste base? Si tiene sentido, sino porque al final no mucha gente piensa que va a hacer un clúster de Kubernetes y que va a tener siempre, yo que sé, 200000 usuarios. Igual estás haciendo un clúster de Kubernetes para 20 o para dos. ¿Tiene sentido hacer un cluster de Kubernetes para eso? ¿Tiene sentido tener tus instancias súper grandes y tener toda esa arquitectura para una aplicación que igual es muy sencillita y que se podría hacer con una arquitectura mucho más eficiente en otros niveles? Es algo que creo que hasta hace poco no se tenía en cuenta y ahora cada vez se está teniendo más.
[00:27:38] Speaker A: Creo que ahí está el tema. Se trata de entender los compromisos a nuestro trabajo, igual que el del Finops, el que lleve todo el tema es encontrar ese equilibrio adecuado entre el coste, rendimiento y resiliencia que además se alinean con los objetivos del negocio.
[00:27:55] Speaker B: Totalmente. Y bueno, te quería preguntar un poco porque sí que hemos visto en AWS muchas herramientas que hemos mencionado antes y luego también tenemos la parte un poco de visualización, porque sí que es cierto que y bueno, Damián es un enamorado de los dashboards, yo creo que deberíais contratarle para hacer promoción. No he conocido a nadie que los venda mejor. Creo que estuvimos hablando con Ÿousand, con Yuri, que es como el encargado de los cursos dashboards y creo que se vio encantado con como Damián hablaba de sus queridos y amados dashboards. Le tenemos que invitar en cuanto cuando probablemente hagamos la versión en inglés porque creo que no va a estar más encantado con un entrevistador que con que con Damián. ¿Pero volviendo a quitando la parte de la broma no? ¿Cómo crees que que AWS está haciendo el trabajo en el tema de la visualización, de la agrupación de datos, de todas estas herramientas con Quicksight y demás? ¿Qué crees que es lo importante a ese nivel?
[00:29:01] Speaker A: Pues yo creo que como todo, la optimización no es el destino, es un proceso continuo y creo que en AWS se ha ido mejorando con el tiempo todo. Al principio tenías mucha monitorización de muchas cosas y a veces parecía que estaba desconectado. Ahora cuando se lo han traído todo al Hub Ÿousand han unificado, con lo cual puedo tener una visual de todos los costes, de todos los servicios y puedo filtrar por mensualidad, por tipo de servicio, por región donde lo tenga desplegado, etc. Y va asociado a un advisor, a un asistente que te va diciendo cómo puedo mejorar oye, pues esta instancia no la usas, usa una más pequeña, muévete a graviton. Yo creo que va mejorando y ahora con el tema de la ia encima, zweitausendein, cuando llegue un punto en el que yo le pueda preguntar oye, me gustaría saber dónde estoy gastando más en los últimos seis meses, que no me cuadra, que tengo aquí un delta de x y que de repente el sistema te diga oye pues por este proyecto que lleva estos recursos asociados y estos fts etc. Es donde se te está yendo la pasta. ¿Pero es interesante porque también lo hace desde el punto 501.º lo hacen los dashboards, pero al final la monitorización que tienes, tienes que tener dashboard para cada stakeholder dentro del end to end de tu servicio, de tu aplicación, está el de infra, que al de infra se la bufa estés gastando 2000 por encima, no, lo que quiero saber es si la aplicación está arriba, si lo gel check está todo en verde, si no tengo cuellos de botella, etc. Pero conforme va subiendo pues sí que va cambiando la perspectiva de son otros factores lo que me interesa y al cielo lo que le interesará será Oye, cuánto estamos metiendo en Capex, en Opex? ¿Cuál es mi retorno de inversión con todo lo que estamos haciendo, manteniendo ese 99,999999 de disponibilidad en mi servicio?
[00:30:47] Speaker C: Es que por eso exactamente el Quicksight y la infraestructura que crearon encima de eso, eso lo que dijo Víctor Conjuri, porque yo por ejemplo uso toda la instalación de los dashboards porque me da toda la infraestructura para mí empezar el bi bi y hacer el dashboard que quiero y encasarlo a cada personaje que tengo, a cada persona que tengo en la empresa para que le estoy ayudando, trabajando.
¿Qué quieres que te interesa más a zinfructura? Mira acá tenés todos los datos, ya tengo todo ahí casi hecho. Incluso también que estabas hablando, tocamos varias veces ahora otra vez lo de IA. Yo creo que las personas necesitan el IA y también para ser más efectivos y la forma que lo puedes hacer es por ejemplo, a mí menos me gusta hacer, viste todas esas presentaciones y hoy el chivo te puede dar un reporte y te lo puede crear. O sea, todavía creo que no llegó a lo que dijiste después de escribir y bueno encontrarme donde hay o cómo ser más eficaz en exactamente en este coste o en esta diferencia. Pero si te dan muchas cosas, si le puedes escribir, bueno haceme, dame los top 10 servicios, está como que en el crawl face, creo que esa día, pero creo que en un par de años llegaremos ahí.
[00:32:13] Speaker A: Tené en cuenta que esto está arrancando ahora mismo, o sea, realmente toda la funcionalidad que se puede sacar, tú imagínate de aquí a unos meses vendrá alguien seguro y te creará agentes de IA por cada función dentro del stack tecnológico que tengas. Tendré un agente que se dedicará solo a la monitorización de la infra Zweitausendein, otro al despliegue de releases de mis aplicaciones, otro a la parte financiera y orquestarás todo eso para que entre ellos se vayan hablando y que al final yo simplemente tenga que preguntar y tendrán un contexto 360 de mi negocio y eso llegará. Yo creo que al día de hoy lo de los multiagentes lo estamos viendo, habrá que ver a qué punto de eficacia y funcionalidad llegan. ¿Van a llegar porque me río el.
[00:33:00] Speaker C: Otro día y dije al final vamos a tener cada uno un día le iba a decir al mía bueno hablar con el día de Guillermo y contacto.
[00:33:09] Speaker B: Como cuando te enfadabas que tenías a una persona medio que le decías dile a no sé quién que me haga no sé cuánto, sabes?
¿Es un poco a ese nivel al que podemos llegar, no? ¿Pero la parte de multiagente creo que también lo hablábamos con con otra persona allí en el Finops ex que estaba montando cosas también de RA con multiagentes y que hablaran cada uno con lo suyo y cada uno tuviera un rol específico en el que al final es un poco, no? La teoría de la especialización que siempre se ha llevado, de que centrarte en una parte y ser el mejor ahí. Al final la IA te permite eso, que tengas un agente que hable con otro agente y que consiga feedback y que cada uno esté especializado en en una cosa y poder hacer sistemas bastante, bastante, bastante locos que hasta hace unos años no teníamos ni en mente que podrían pasar.
[00:34:01] Speaker A: Sí, pero para eso lo que hay que tener bien es toda la parte de monitorización. Aquí voy a decir una frase muy mundana y que me perdone la audiencia, pero cuando tienes datos de mierda, las respuestas son de mierda. Es la calidad del dato la que te va a permitir que realmente estos agentes de IA puedan contestar. Y volviendo a la parte de monitorización, porque creo que es crítica, lo que tú no ves, no puedes controlar. Teniendo visibilidad de todo lo que hay alrededor puedes reducir esos costes ocultos que muchas veces se dan y que no somos conscientes de ella. Entonces hay un trabajo ahí de base en el que creo que hay que poner mucho esfuerzo para llegar al punto donde queremos estar a la hora de que empieces a introducir IA y otros conceptos.
[00:34:43] Speaker C: Es un buen punto porque creo que en eso de los datos, los proveedores no están muy bien incluso. Sí, lo que sí está haciendo bien esta organización, si no se ve lo del Focus y que todos se le añaden atrás. O sea, hay cuatro proveedores que están atrás de eso y lo van organizando y lo van planeando. Ÿ Justo nos dijeron que iban a salir dos versiones por año, pero todavía estamos en una versión que también la ciudad oficial lo publicaron recién ahora y no hay suficiente los datos que hay personas, como dijiste, los datos no son buenos.
[00:35:27] Speaker A: ¿Luego la pregunta, porque tú has hablado antes de los dashboards, de business insights, business intelligence, etc. No? ¿Pero tú nunca le preguntas al cliente? ¿Porque a mí me ha pasado alguna vez de decir oye, estás activamente controlando tus costes o simplemente los estás observando y la gente te mira como con cara de loco, no? Digo, sí, puedes tener el dashboard y puedes estar viendo ahí el coste, pero si no tomas acción proactiva sobre lo que tienes delante, puedes tener un problema. Al final te vuelves reactivo que era lo que pasaba antiguamente en la monitorización ahora no en la observabilidad que ya es mucho más proactivo pero este es el mismo caso de uso.
[00:36:05] Speaker C: Pero es que eso que yo siempre me río porque tenés 140 y era 140 herramientas y todas hablando nosotros, nosotros, nosotros al final me arriba porque yo creo que la verdad por mi experiencia no sé, a lo mejor me equivoco, no sé pero aparte del feedback devons lo ven, el management lo ve una vez por semana en una presentación no va a entrar los dashboards a veces nervioso digo pero nadie usa el fino entonces estás haciendo una herramienta para el fin. ¿Entonces enfocate, le decía a uno de los enfocate en el fino porque todos los demás no lo ven y me hiciste acordar de eso ahora pero yo creo que tenés razón, lo observan y no hacen nada y por eso sabes por qué estoy contento? Porque siempre van a necesitar un fino que siempre iba a tener tonos al.
[00:36:52] Speaker B: Final, al final lidiar con con tantos agentes de la cultura de la empresa implica que vas a estar tú ahí en el centro un poco del foco y que vas a tener te va a venir un poco el trabajo de decir bueno voy a tener que intentar concienciar a todo el mundo, ayudar a todo el mundo y tener un poco esa parte.
[00:37:10] Speaker A: No es sencillo, no es sencillo porque son demasiadas unidades de negocio, depende del tamaño de tu empresa también, pero si hablamos de multinacionales etc. Demasiados actores en juego a los que hay que convencer ÿ o alinear muchas veces y siempre tienes que tener una estrategia de win win quick wins que decimos oye cuál es la Low Hanging fruit, la primera que puedo ejecutar para que el resto de la compañía vea el valor que tiene el ser más eficientes, tener mejor impacto. ¿Pues muchas veces en esto de infra que contaba antes de estar palmando €300000 le decíamos al CIO oye que estos 300000 los podías tener de valle para seguir desarrollando o ampliando la arquitectura no? Otras cosas cuando dices coño que esto la pasta no nos sobra pero ya que ya que me lo estás contando vamos a optimizar y vamos a reinvertir todo esto en otras áreas.
[00:38:03] Speaker B: Y hay algo que yo creo que se ignora un poco y que creo que puede ayudar bastante a implicar al resto de actores sobre todo más el leadership quizá en el Finops es el tema de las personas. Es decir, si tú lo que dices estás ahorrando €300000, tienes una factura excesiva por €300000 de cloud, esos €300000 pueden ser no sé cuatro personas, cinco personas en tu equipo que igual necesitas para desarrollar tu sistema o el bono para.
[00:38:37] Speaker A: El CIO, yo que sé.
[00:38:38] Speaker B: Sí, sí, sí. Bueno, el motivador que quieres meterle.
[00:38:42] Speaker A: Yo creo que hay que tener un ÿousand control muy granular porque al final eso es lo que sí que te permite optimizar tanto los costes como la experiencia de usuario. ¿Ahora uno de los temas también que surgen es hasta qué punto quiero esa granularidad? Porque muchos datos al final te puedes ahogar en el éxito y realmente no ser capaz de ser proactivo en determinadas acciones. Y volvemos a toda la parte de compromisos que hemos hablado antes o el tema de coste resiliencia. ¿Aquí también pasa a la hora del control de gastos de Oye, hasta qué punto necesito saber todo? El de infra está claro que sólo quiere saber cuánto le cuesta su infra, pero el CIO tendrá otra visual y tendrá otra dimensión sobre la que trabajar en los datos para sacar él sus propias conclusiones.
[00:39:26] Speaker B: Sí, totalmente y al final es un poco lo que decías, que al final cada uno tiene su contexto, cada uno quiere ver una parte de lo que le importa pero sí que es verdad que Ÿousand qué es eso que nos olvidamos un poco de no, sí, queremos reducir la factura del cloud y demás. Y luego creo que el fino puede ser algo muy relevante a nivel de personas, que al final es un poco lo que hemos dicho de que se centra en la cultura de la empresa, de tener cosas en cuenta, de implicar a todo el mundo y de y de que impacte positivamente tanto al negocio y a las personas que forman parte de él. Creo que es algo muy importante.
[00:40:09] Speaker C: ¿El fino tiene que tener un soporte de algún lado y tiene que ver cuál es el interés de cada uno y ver cómo lo hace funcionar todos juntos y es una de las responsabilidades que tenemos como fino, eso es lo que tenemos que hacer y eso junta muchas cosas, no solamente la visualidad sino también ver cuál es el pain de la otra persona y ver cómo cómo se lo da, cómo se lo simplificas con datos y todo viste? Junto con todo lo que hablamos antes, usar los datos, tener los datos, agarrarlos y dárselos y ahí va a ver el beneficio que tiene porque no todos van a pensar, van a ver el beneficio de gastos. Los beneficios pueden ser cómo hacemos en tu aplicación, en si caso cómo hago yo tu trabajo como DevOps mejor con datos y ahí es cuando vas a tener que cambiar también el lenguaje. Por eso viste todo hablando de cultura o de crear un lenguaje. Entonces el clima tiene que saber hablar el lenguaje de cada uno y ver cómo le ayuda a cada uno en su rol y ahí cuando vamos a tener más acceso que al final todo eso va a llevar a lo que queremos sea un coste normal para cada business y todo lo que lo que decimos encontrar ese lugar es el costumes, que es lo más eficaz, lo más beneficiario para ese business.
[00:41:29] Speaker A: Es que está claro que si quieres ir rápido puedes ir solo, pero si quieres llegar lejos tienes que ir en equipo y ahí tienes que poner de acuerdo a todas las unidades de negocio dentro de la casa, porque al final no se trata de ti o de mí, se trata de la compañía. Hay una marca, hay una imagen que hay que empujar y entre todos tiene que salir. Hay veces que ves esas tensiones, esas fricciones entre unidades, porque al final hay mucho ego en la industria.
Yo muchas veces digo yo como este videojuego ya me lo he pasado, a mí me la sopla.
¿Yo ya he tenido que hacer lo que tenía que hacer en esta vida y lo que hago es intentar, oye, cuál es tu problema? ¿Cómo mejoramos tu problema? Y pensar en cómo vamos evolucionando en conjunto. Pero bueno, yo supongo que la gente que nos oye habrá encontrado casos de todo tipo.
[00:42:13] Speaker B: Sí, al final, bueno, dependiendo del tipo de empresa y de la situación, del rol que puedas tener, de los recursos que tengas, depende de muchos factores.
Puede ser mejor o peor. Pero bueno, yo creo que hemos tocado cosas muy interesantes hoy. Sobre todo me parece que la conversación tanto al principio como al final ha dado muchas perlas para que la gente pueda reflexionar sobre sobre la cultura del fino, sobre sobre lo que se puede hacer.
Creo que deberíamos mandar este este podcast a Yuri para que este contexto se lo subtitulamos en inglés para que lo lea traducido primero. Eso es eso.
¿Le pongo los subtítulos en inglés para entiendes? Y nada, creo que nos has dado muchos tips, Guille, de cómo cómo hacer las cosas de aparte de infraest aws y nada, muchas, muchas gracias por venir. Ha sido ha sido un auténtico placer.
[00:43:07] Speaker A: A vosotros por invitarnos.
[00:43:10] Speaker C: Siempre un placer y ojalá te tengamos otra vez acá.
[00:43:14] Speaker A: Gracias.
[00:43:14] Speaker B: Nos vemos en la próxima, chicos. Un saludo.
[00:43:18] Speaker A: Ÿousand.
