Episode Transcript
[00:00:00] Speaker A: Para mí uno de los costes que veo muchos más clientes y que genera mucho desasosiego es el de la red. Es decir, muchos clientes no entienden que por llevarse costes al cloud haya tránsito, haya costes de red dentro del propio cloud. Si un Dropbox hubiese nacido teniendo que comprar toda esa capacidad de cabinas y servidores, no hubiese nacido nunca. Si no sabes explicárselo a un niño de seis años, es que realmente no eres capaz de haber entendido ese concepto. Gastando una pasta en la monitorización del proveedor. Oye, que te estás gastando una pasta en la red. Oye, que te estás balanchando una pasta en estos servicios de seguridad. Esos directores que han pasado notas de gasto astronómicas de consumos de servicios de un proveedor y que eso nunca aparecía en los libros contables de la empresa.
[00:00:45] Speaker B: ¿Muy bien, Damián, qué tal? ¿Cómo estás? Aquí me traes.
[00:00:48] Speaker C: Bien. Bueno, un gran amigo de hace tiempo, Alex, creo que creo que creo que fue una de las primeras personas que hablé con él de Phoenix. Hace mucho tiempo. Estábamos en la comunidad de Spain Clouds y Alex hace mucho contenido.
[00:01:07] Speaker A: Pues mira, cinco o seis años, porque fue recién llegado yo a Oracle, recuerdo. Y eso debió ser por el 2000 por ahí. Y ya hablando de phenops, [sos/eos] algo más de tiempo. O sea que ya por el 2015, 16 en telefónica ya empezamos a escribir sobre esas cosas porque estaba preocuparse la.
[00:01:30] Speaker C: Gente no es un seguro, nos dicen.
[00:01:33] Speaker A: Que es shock para que todo tenga contexto, más allá de ya empezaban a.
[00:01:40] Speaker B: Doler los costes de ando, cuando pasamos.
[00:01:41] Speaker A: Bien las pruebas de concepto y los pilotos y empezamos a meter muchas cosas importantes allí, pues ya nos empezaba a preocupar el coste de la nube.
[00:01:49] Speaker B: Normal, normal. Y nos cuentas un poco en plan cuál ha sido un poco tu trayectoria, sobre todo dentro del sector de cloud, cómo se puede ver en tu camiseta. Creo que está clara la medida que trabajas. Y nos cuentas un poco cómo.
[00:02:06] Speaker C: Pensé.
[00:02:07] Speaker A: Que te refería a esta red, unos chavales a los que ayudamos, una empresa pequeña, ahora creo que les vamos a ayudar con el fútbol que habían anunciado hace poco, que se metían también en ese ver el final. Bueno, pues os cuento. Yo la verdad es que he tenido la suerte de vivir y de disfrutar esto del Claude desde que era un niño, desde que era yo un niño profesionalmente y desde que Claude era un niño. Es decir, yo empecé, estaba en varios fabricantes, Gilbert, Packardell, más siempre desde el lado del on premise, porque por aquella época lo único que se empezaba a escuchar era el VMware, la virtualización, los nodos SX. Ahí yo creo que y ahora en el momento que estamos del Hive, de la IA generativa, yo creo que todas las innovaciones tecnológicas siempre pasa lo mismo. Primero empezamos evangelizando, luego esto para pruebas pilotos en tonos de desarrollo, luego lo llevo a producción y luego ya me preocupo de qué grande se ha hecho esta tecnología en mi presupuesto y tengo que optimizar, que es parte de lo que va el Finops. Entonces, ya os digo, desde hace ya cerca de 20 años en el mundo hardware, luego tuve una época de un pequeño integrador y luego tener el mundo del outsourcing, que la verdad es que si lo pones en perspectiva, el outsourcing y el cloud realmente es esa mezcla del hardware más la parte de servicios que hacía un outsourcer. Y el cloud vino para romper todo eso, vino para cargarse la parte de operaciones y externalización de servicios con la industrialización y la creación de estándares, como ha pasado en la industria tecnológica alrededor del cloud. Y luego por otro lado, la del hardware. Primero ya Vmware se cargó un poco este mercado, es decir, ya los fabricantes no tenían que ven, no es que no tuviesen, es que no podían vender tanto hardware porque no había escucha. Yo recuerdo un de él que muchas veces despachábamos, enviamos un servidor para el correo, enviamos servidor para una oficina nueva que ha abierto y tengo que montar el director activo en el servidor de impresión. Entonces, siempre que había una carga de trabajo nueva, había un servidor, vmware llegó y se lo cargó y era un pool de recursos y cada carga de trabajo me iba consumiendo recursos de ese pool de recursos. Y luego ya llegó el cloud que ya lo puso todo, todo patas arriba. Entonces, ya os decía, estuve en Siemens en la parte de outsourcing, Siemens it solution and services, cerca de siete años. Otros cerca de siete años ÿ en Telefónica, ahí cambié un poco la gorra, me quité la gorra de preventa y me puse la gorra de producto, desarrollo y negocio, donde empezamos a hablar ya de los primeros servicios cloud que había en España, el Virtual Data Center, algún otro experimento que hicimos con tecnologías como Jogin en su momento, que aparecía por allá en 2012 como uno de los líderes en el cuadrante de Gartner en cuanto a innovación y se quedó en nada, en un bluff. Y luego me tocó la parte ÿousand de contar eso internamente en Telefónica, tanto al consejo como a los diferentes stakeholders internos y externamente a los analistas y a los países de Telefónica para extender ese negocio de cloud que era muy saludable y rentable en España, al resto de países de Telefónica. Y esa parte fue muy bonita también aprendí un montón de cosas y sobre todo me dio una perspectiva un poco de ÿousand de lo difícil que es hacer este negocio rentable.
Ahí lo decíamos, Jojen es un ejemplo, pero es que si te pones una de las últimas presentaciones que hicimos al consejo en Telefónica era eso. Yo cogía los cuadrantes de Gartner de los 2010, lo plasmaba contra los del 2017 y veías que al principio había 60,70 proveedores de nombres impronunciables, muchos de ellos únicamente americanos y muchas Telcos por ahí metidas o empresas que habían comprado Telcos. Y luego, pues eso, si lo miras en perspectiva, en las últimas épocas de Telefónica el número era ya muy reducido, ocho o 10 participantes. Y si te fijas hoy en los cuadrantes de cloud pública, pues creo que no llega ni a los dedos de la mano el número de proveedores que tienes. Además ves dos vertientes, como ves en la tecnología en general a día de hoy, la vertiente americana, los cinco proveedores principales americanos y los tres chinos. Los tres chinos únicamente están ahí por representatividad de su mercado, es decir, como nadie puede entrar, pues tienen entre un mercado muy grande. Entonces es fácil que salgan si tienes en cuenta cuáles son los criterios de Gartner, que es digamos, tamaño del mercado, clientes e innovación que aportas. Así que bueno, es entretenido. Yo creo que este mundo todavía tiene ÿousand, tiene mucho que decir en las empresas. Y bueno, ahora con la IA generativa nos han dado una segunda juventud al cloud, porque ahora todo el mundo quiere meter esto de la IA generativa en sus aplicaciones que mayoritariamente están en el cloud y ahí los Finox sí que van a tener muchísimo decir que hacer, porque el modelo cuando lo cambias únicamente del hardware a consumir algo, en muchas ocasiones a través de una API, pues todavía es mucho más preocupante.
[00:07:24] Speaker C: ¿Cuánto empezaste con el sino?
[00:07:27] Speaker A: Bueno, pues empecé a hablar de ello, ya te digo, cuando las primeras conversaciones con clientes iban en la línea de he creado este monstruo, este gremlin, que era un osito de peluche fabuloso y súper cookie, se ha convertido en un montón de lagartos que no paran de consumirme recursos y necesito empezar a controlar. Entonces yo empecé a investigar y a meterlo en el discurso ya en telefónica porque era una oportunidad de por lo menos tener una iteración con el cliente. Es decir, no podías atacar a un gigante como era Aws o Azure en ese momento únicamente hablando de innovación, tenías que buscar otras palancas, ya sea la residencia, el dato, la soberanía, etc. Etc. Pero la parte del synopsis era súper importante, sobre todo muchas veces porque ni los clientes mismos sabían dónde se les estaban yendo los puertos. Es decir, muchas veces sabían que estaba esa factura. Y luego también, no sé si lo recordáis, pero había un término muy, muy curioso que era el saudo it, es decir, todo lo que estaba gastando la empresa que realmente no estaba bajo el perímetro del presupuesto oficial, sino que de forma oficiosa habían Amex, visas por ahí purnando en diferentes club proveedores de cloud, que luego muchos directores, conozco muchos directores que han pasado notas de gasto astronómicas de consumos de servicios de un proveedor y que eso nunca aparecía en los libros contables de la empresa como presupuesto de IT. Entonces, yo creo que esa mezcla de esa situación versus el desconocimiento general y el control y el gobierno hizo que esto del Finox pues una realidad. Además, si miras el origen y el libro que rige todos los principios del fino de estos australianos, pues pasó como ni till, un proyecto que desgraciadamente no funcionó todo bien, que tenía que funcionar y alguien tuvo que pensar cómo ponerle puertas al campo. Entonces, bueno, yo creo que esos comienzos a nivel de discurso están muy bien, pero luego a mí personalmente, con el paso del tiempo me ha ayudado para seguir iterando con muchos clientes y ayudarles a optimizar su infraestructura.
[00:09:45] Speaker B: Sí, al final es eso, que no tampoco los proveedores, sobre todo al principio, ahora ya hay más herramientas, tampoco lo podían excesivamente fácil para entender todo el coste. Aparte que es un sistema complejo que no deja de ser el cloud, al final, sobre todo en otros proveedores más grandes, tantos servicios, es difícil controlar y tenerlo todo, todo junto, pero no lo ponían fácil. Y encima sí, ya había desconocimiento del propio cloud, la gestión de costes era como bueno, pues paso la factura y esto es lo que nos hemos gastado, punto. Y ahora ya como todo es más complejo, todo está ahí, ahora hay que separar a ver quién gasta, quién no gasta. Estas cosas vienen a tener bastante utilidad.
[00:10:26] Speaker A: Y yo creo que también ahora en el mercado se confunde un poco. Todo lo que es Finops, yo veo que la gente lo está metiendo en una caja que llama Landing Sun y esos pilares y principios de actuación de cómo van a empezar a utilizar la nube, pues en fino está ahí embebido y nadie es consciente de ellos. Es decir, las políticas, los grupos, lo has dicho tú, los usuarios, quién tiene acceso a qué, qué presupuestos asignamos a cada compartimento que montamos en el cloud, pues eso no deja de ser fino. Lo que pasa es que explícitamente nadie lo comenta porque parece que siempre el Finobs está pensado desde el ahorro y más desde un lado a lo mejor económico, financiero, de compras, pero yo creo que es una barrera que el mercado también tiene que romper y los departamentos de TI tienen que empezar un poco a a esclarecer.
[00:11:13] Speaker C: Ese es excelente show y varios Daniels y ni una palabra decir nada.
[00:11:20] Speaker B: Nada.
[00:11:22] Speaker C: Que quería decir sobre Víctores es que si hablas, hablamos de las facturas. Yo estaba hablando el otro día con alguien, entonces me dice, explícame la factura. Entonces, claro, está. ¿Imagínate esta gente que estaba acostumbrada a recibir una letra, viste? Compré un server, una letra, ahora reciben una cosa así que tienen servicios y servicios y servicios y cosas así y te lo dan de manera diferente y no lo entiendes porque es mucho. Y creo que es algo que se asustan también, porque cuando ya entendés un poquito cada cosa es muy. Para mí es fácil leer, bueno, pero empecé a pensar cómo es difícil para ellos. Entonces ahí me cayó, claro, antes tenía una factura de dos o tres cosas y no tenías ni 1 millón de cosas. Entonces o se asustan o no entienden o no son tecnológicos.
[00:12:15] Speaker A: ¿Y ya no solo eso, es decir, cuánto de lo que viene en esa factura estoy utilizando? Que esa es otra derivada. Es decir, que zombies en el cloud hay muchos proyectos que surgen, blockbunners que se crean eternamente, elementos en el object storage o en el archive que han sido parte de un proyecto, backups, etc. Información que has subido que podrías eliminar. Hay un montón de deficiencias que puedes aplicar. Pero ya no solo eso, otra de las componentes que nos habla del finops y que creo que casi el más importante es entender qué aportación tiene en el desarrollo de producto. Es decir, yo si fuese una startups y estuviese desarrollando un producto en mi pipeline de lo que sería mi backlog de características, de features que voy a meter en la aplicación, yo si estuviese haciendo esa gestión económica financiera, me interesaría o querría ver cuánto me va a costar esa nueva funcionalidad, qué carga de trabajo adicional requiere, ese tipo de cosas que en ese infinito del DevOps que todos siempre pintamos, queda muy bonito. Deberíamos también en algún momento insertar esa reflexión de cuánto cuesta, porque a lo mejor esa feature que pasados seis meses está utilizando únicamente un 10 % de mis clientes, pues me está costando más de lo que estoy ganando. Entonces, bueno, eso yo siempre rompo esa lanza del fino de no solo desde ahorro y control de costes, sino de cómo también puede ayudar a la organización a ser mucho más rentable.
[00:13:45] Speaker B: Sí, o sea, al final todo el. Yo a mí me gusta mucho como llevarlo al tema del ROI, del Return over Investment, o sea, es decir, eso me quedó muy claro como desde el principio de la idea es sacar el máximo provecho de cada dólar o euro que metas en el cloud. Y eso tiene que ser como la llave de todo lo que hagas. ¿Porque también lo hablaba con otra persona cuando empecé a hablar de fimos, que era en plan de si es muy fácil ahorrar costes, tú apagas todo y te cuesta cero, sabes?
Y ya está, ya has ahorrado, ya has hecho finos.
Pero no, es decir, tú intentas sacar cada euro lo máximo que puedas. Es decir, si tú puedes tener un margen de un 90, %, pues inténtalo, en lugar de tener un 20, un 30, si solo optimizando, consíguelo. O sea, que con la misma cantidad de dinero invertido ganes mucho más. Esa es totalmente la idea. Estoy totalmente de acuerdo con.
[00:14:41] Speaker A: Pero ya no solo eso, sino el, digamos, establecer la cultura de seguimiento y de control de las cosas que están en el cloud. Porque también me encuentro muchas veces que tienes únicamente la factura, pero la factura es una pista de lo que está pasando en mi presupuesto. ¿La otra es lo que te da la monitorización, es decir, estos recursos, realmente cuántos estoy utilizando? Porque, bueno, yo aquí hago un poco apología de mi empleador, pero una de las cosas que como Oracle tenemos de ventaja de haber llegado tarde en todo esto es haber intentado atacar ese dolor del cliente. Porque el tema de la complejidad, esto es como lo que decía Richard Feynman, que si no sabes explicárselo a un niño de seis años, es que realmente no eres capaz de haber entendido ese concepto. Pues aquí es lo mismo. El tema de la complejidad del finobs es una complejidad establecida por los proveedores, porque es mucho más fácil a ti. ¿Está construido desde qué me es fácil a mí como proveedor? ¿Qué me es lo más fácil? Pues en cada región tengo una serie de costes de energía, de datacenter, de recursos.
Mi escandallo de precios, botón up, es decir, me cuesta tanto y en esta región el precio es tanto, versus la aproximación que vimos desde el iclick es a lot of down. Es decir, con qué dinero gano yo suficientemente dinero para establecer una lista de precios global, hago el top down y sé que en algunas regiones ganaré más y en otras ganaré menos margen por los costes operativos que yo tengo de gestionar esa infraestructura y ese negocio. Entonces, con ese cambio únicamente le estás dando al cliente la ventaja de quitarle ese dolor. Es decir, yo me he encontrado además muchísimos proyectos, esta realidad del multicloud se ve frustrada ÿ porque allá donde estás consumiendo determinados servicios de determinados proveedores, primero no están en otras regiones, que ese es un punto de dolor importante también y segundo, me costaba más el collar que el galgo. Es decir, cambiar de región me salía un x por 100 más caro por el hecho, aunque tuviese ahorros, de conectarme en el mismo datacenter con otro cloud provider. Entonces, yo creo que es una complejidad infundada por los proveedores, por su facilidad y no pensando en el cliente. Y luego, por otro lado, lo que decís, es decir, la complejidad en la que se ha construido la mayoría de los servicios que utilizan nuestros clientes. Es decir, estoy seguro por conversaciones que en su momento tuve con muchos analistas, el 60, el 80 % de los ingresos de los grandes hiperscalar sigue siendo compute y almacenamiento en gran medida. Entonces, esa variable que decíamos de sé lo que me estoy gastando, pero no sé cuánto estoy consumiendo de cada uno de los mismos. La estructura de las saves fijas en la nube es otra forma también de planificar o de ejecutar de manera mucho más sencilla tus operaciones en el cloud. Es decir, venga un cliente y le asigno esta save y ya sé que esto lo voy a cobrar sí o sí, no tengo problema ninguno. Es decir, puedo tener otros modelos que son más flexibles, pero el básico, el que va a consumir todo el mundo, es súper sencillo. Es decir, tengo tanta capacidad de cómputo, tengo tanta sobresuscripción, sé que voy a ganar tanto. Entonces, al cliente no le estás poniendo facilidad ninguna porque él es el que se tiene que buscar luego las tortillas, buscar estas estrategias de Finox, todo el tema de terraformar recursos, Continuous delivery, Continuous integration, para, oye, es que estoy viendo que está. Y lo que decíamos, Finops no es solo únicamente esa gestión financiera, oye, estos recursos están infrautilizados, voy a bajar una Save, voy a cambiar por otro recurso que sea mucho más óptimo o voy a bajar el performance que tiene que tener este almacenamiento, esa segunda parte todavía yo creo que cuesta muchísimo más por la mayoría de las organizaciones. Es decir, la parte sencilla, lo que dice Damián, me bajo el CSV del proveedor, me lo subo a un cuadro de mandos que me he pintado con cualquier herramienta analítica y tengo una foto clara de dónde se me está yendo el dinero. Claro, eso tiene una segunda derivada, es todo eso lo estás utilizando. Es decir, son proyectos activos que tienes, son proyectos o infraestructura que puedes optimizar y apagar automáticamente. ¿Y por otro lado, de todo eso que te queda en ese primer ejercicio, cuánto de eso estás utilizando? Es decir, podrías coger otra seis mucho más óptima para ejecutar esas carreras de trabajo o cambiar de tecnología, Zweitausendein, paso de Intel, AMD, que normalmente suele ser más barato. Los proveedores, bueno, hay clientes que se hacen esas reflexiones, pero yo creo que mayoritariamente, la mayoría de los clientes es algo que no obvian por el día a día en el que nos vemos todos sumergidos. Tienes tantas cosas que hacer que de estas que a lo mejor son importantes no te preocupas. Y veo que todavía a día de hoy muchos clientes afrontan los proyectos de cloud como lo hacían en On Premise y al igual que instalaba un servidor el software y lo ponían en marcha, el cloud sigue siendo lo mismo, lo monto, lo dejo ahí, 5 años después no sé ni cómo está, ni si está desactualizado, si estoy utilizándolo.
[00:19:56] Speaker B: Entonces bueno, y al final es eso, con una, o sea, porque si haces una estructura fija que no tenga tanta complejidad con los cambios de región, etc. Al final sí que es un poco más parecida a lo que había antes en On premise. Es decir, te costaba tanto, pues tú calculas un mes a mes una amortización o lo que sea y dices vale, pues al mes o al año me cuesta tanto x, pero es que ahora con este eso sí que es verdad que el modelo es muy flexible, entonces te permite escalar de cualquier manera, pero también tiene mucha complejidad de si tienes que controlar, no sé, 100 servicios, pues es un poco infierno. Y lo que tú dices, que al final la gran mayoría y por eso casi toda la optimización está ahí, se centra en optimización de la capacidad de computación, ya sea con máquinas virtuales, containers, etc. Etc. El storage y red y que al final es por ejemplo el 90 % junto con permisos de lo que te pedirían en un examen de cloud. Es decir, que al final el resto de casos sí que es verdad que si lo ofrecen es porque a ellos les saldrá rentable y porque alguien lo usará, pero el 90 % es eso y poco más. O sea, contando que las bases de datos, contando bases de datos, data, etc. Como computación, storage, pero al final es como si te centras en eso y tienes claro cómo se gestiona eso, tampoco necesitas como tanta tanta historia para gestionar.
[00:21:22] Speaker A: Ha sacado un punto importante que yo me encuentro en muchas conversaciones con clientes y en muchos proyectos, muchos de ellos te dicen es que yo hice el presupuesto y estoy corriendo en tal proveedor y lo que era 100 en el presupuesto ahora son 180, vamos a echarle un ojo. Y te pones a echarle un ojo y dices oye que te estás gastando una pasta de la monitorización del proveedor, oye que te estás gastando una pasta en la red, oye que te estás gastando una pasta en estos services de seguridad y todos los clientes acaban pasando por el mismo flujo. Es decir, se fijan en la infra, esto que hubiese montado así en mi casa, lo monto así en el cloud. Y no se olvidan que en su casa normalmente tienen todos esos servicios accesorios, la mayoría de ellos ya tienen un sistema de monitorización, un sistema de backup, que me refiero que no era un costo importante del proyecto.
Hacen la misma aproximación al cloud, sobre todo en estas primeras iteraciones de muchas empresas de ese puro leaf and seed. Y luego se dan cuenta que requieren de otros servicios. ¿Es decir, qué hago? ¿El servicio que tenía en On premise me lo monto igual en la nube? Es decir, me monto un backup, ser un Symantec, un convolt para hacer mis backups, ya que estoy utilizando el del proveedor, me monto una moneda ya que estoy utilizando. Entonces, esos costes que nadie los había contemplado a priori, aparecen con el running de servicios. Y luego, para mí, uno de los costes que veo muchos más clientes y que genera mucho desasosiego es el de la red. Es decir, muchos clientes no entienden que por llevarse cosas al cloud haya tránsito, haya costes de red dentro del propio cloud. Y aquí vuelvo a hacer otra vez apología de mi empleado. En Oracle no la cobramos, cobramos únicamente el tránsito de bajada, los 10 tierras al mes gratuitos. Entonces, eso es muy fácil en la conversación de cliente, es decir, oye, todo esto que está aquí, si te vienes conmigo, es cero. No, es que yo tengo un kubernetes en tal proveedor y cada vez que va de una zona de red a otra zona de red, ese microservicio me genera una llamada, me genera coste de ingreso y de salida. ¿Y dices tú, pero cómo puede ser eso? Tú en tu casa te va a costar más en una LAN poner tus cubermetes y que estén hablando entre diferentes servidores, pues porque se lo vas a pagar alguien en la nube. Entonces, muchas de esas cosas los clientes no son conscientes o no se dan cuenta hasta el momento en el que tienen la explotación implementada. Y ahí es donde empiezan a pensar en el Finops y cómo trabajar este tipo de cosas a posteriori siempre. Es como la medicina que tenemos hoy en día, que curas únicamente la enfermedad. Pues yo creo que finox es como la medicina occidental. La oriental tiene otro foco más de personas sanas, la occidental estamos centrados en curar a las personas enfermas. Pues aquí es la misma aproximación la que estoy viendo en el flote. Es decir, ya a posteriori es cuando nos preocupamos de estas cosas.
[00:24:14] Speaker C: Yo también lo que veo es que tenés razón, a mucha gente también empieza como bueno, yo hago ese en list and shit y después lo voy a.
[00:24:22] Speaker A: Cambiar y luego nunca cambia.
[00:24:25] Speaker C: Exactamente, conando y subiendo y subiendo y nunca van a tener tiempo para cambiarlo después. Y ahí es un punto que sí hay que tocarlo. Y el fin opciones.
[00:24:38] Speaker A: También yo veo mucha diferencia en las tipologías de las empresas y la primera unidad de empresas que empezaron a utilizar o que realmente sacaron ÿousand un gran partido del cloud fueron las startups, es decir, una bicoca. Es decir, tengo recursos, solo pago por lo que uso, estoy validando mi dedo del negocio. Es fácil preverlo.
Si un Dropbox hubiese nacido teniendo que comprar toda esa capacidad de cabinas y servidores, no hubiese nacido nunca.
Bueno, netflix a lo mejor hubiese sido otro cantar, pero bueno, te encuentras esas casuísticas que fue una gran palanca para muchas empresas emergentes. Pero la empresa, digamos, establecida, tradicional, gran cliente del Ibex 35, del Nasdaq, del Fortune 500, ese tipo de empresas, el 80 90 % de su catálogo de cargas de trabajo son aplicaciones comerciales. Es decir, que ahí la reingeniería o la refactorización de esa aplicación viene muy condicionada a lo que el fabricante te permita o no te permita, que como mucho va a ser que ya lo puedes correr en un contenedor, la capa de aplicaciones.
Entonces, bueno, es algo que también me encuentro en el día a día. ¿Hay eficiencias? Pues tienes realmente pocas de arquitectura, son más eficiencias de operación.
[00:25:59] Speaker B: Sí, sí, totalmente.
Y yo te quería preguntar una cosa que has dicho antes sobre los cuadrantes de Gartner y tengo curiosidad por saber tu opinión.
Ahora en Finops salen muchos reportes, hay muchas herramientas, etc. Etc. Etc. Entonces esos cuadrantes están llenos y que es verdad que hay proveedores más grandes, más pequeños y tal. ¿Tú crees que puede pasar algo similar en este campo? ¿O cómo crees que puede evolucionar el Finops a nivel de herramientas y proveedores de servicios? Tengo curiosidad por.
[00:26:34] Speaker A: Mira, sinceramente con el Finops tengo una sensación agridulce como en su momento tenía con el tema del multicloud. En su momento, hace seis o ocho años, algo más, 10 años, el mercado sin control de brokers de cloud, herramientas que te permitían mover cartas de trabajo, tener esa parte de Finox también súper afinada y realmente no existe ninguna que haya progresado de forma significativa. De hecho, casi todas a día de hoy he visto que han quedado un poco difuminadas. Entonces no veo que haya un mercado excesivamente bollante, creo que es más un poco las buenas prácticas que cada compañía sea capaz de implementar, porque veo que es más un tema de cultura en sí que de herramientas.
Es igual que muchos marcos metodológicos.
Mucha gente quería implementar etil y compraba herramientas tipo remedy o las que vendía milésimo 100.º para implementar Itil y hacer seguimiento de Itil en su casa. Creo que muchas veces la herramienta es la excusa para ponerte el sellito o ponerte el market, el gol que tienes como director de infraestructura dentro de tu casa, pero que es más un tema de cultura que de herramienta.
[00:27:50] Speaker C: Eso es un punto excelente, porque la herramienta tiene que ayudar al fin off, decir, ah, tengo una herramienta y ya está listo, como dijiste, tengo no un buen filo. Tiene que hacer la cultura, usar herramientas que hayan ahí y seguir haciendo el trabajo. O sea, la cultura y todo lo que hay que hacer, los costes y todas esas cosas, pero decir, ah, tengo la herramienta, la herramienta va a ser trabajo de finos.
[00:28:16] Speaker A: Y ahí la ventaja que ve la herramienta a día de hoy es lo que decíamos, el tema de muchas empresas ya están utilizando, tengo muchos clientes, la mayoría de los clientes que tengo con proyectos en OCI están utilizando OCI 1, dos o tres proveedores más. Es decir, hay muchos clientes que están utilizando los cuatro grandes, más IBM, más algo que tienen algún otro lado en modelos SaaS. Entonces, desde ese punto de vista, creo que una herramienta es importante para centralizar y, digamos, sobre todo, normalizar toda esa información. Cada proveedor te la presenta en un formato con su nomenclatura. Es difícilmente comparable. Yo sí tuviese una herramienta donde, y sobre todo sacase, no lo conozco porque a día de hoy no es parte de mi día a día, pero yo si tuviese que sentarme con un CEO y proponerle un plan de implantación de cultura, finos y herramientas, buscaría algo que fuese capaz de traducirme qué es cada cosa en cada proveedor. Porque yo creo que es también la dificultad a día de hoy y muchos de los retos que tienen los arquitectos ahora de cloud en las empresas. Es decir, este producto o este servicio del proveedor a hace exactamente lo mismo que el b y que el c. Porque claro, digo, me voy a Kubernetes. Cada Kubernetes en la nube es totalmente diferente. Ya si empezamos a hablar de servicios de gestionados tipo Openshift, pues todavía mucho más. Entonces, hablamos de contenedores y todo el mundo lo deja un poco en la nebulosa. Pero ya no solo es el hecho de qué voy a hacer, sino qué voy a perder o qué voy a ganar en ese estudio. También desde la parte del finops a nivel de arquitectura, qué voy a ganar o qué voy a perder y que tengo que tener en cuenta que a lo mejor yo tengo que hacer de manera diferente a como lo hacía, o manual o porque me voy a ahorrar cosas, que eso también es parte del fino, cambiar un modelo por otro y ahorrarme una operación de infraestructura. Yo creo que muchos clientes, solo por el hecho, fijaros, de pasar a un modelo de continuous delivery, continuous integration en sus aplicaciones y tenerlo todo terraformado, gestionado con un ansible para los despliegues, ganarían en eficiencias operativas un montón. Lo que pasa que eso es como todo. Cuando hablaba y evangelizaba el cloud pasa ahora un poco lo mismo. Es decir, yo siempre hacía la misma broma, mala broma de cuñado, pero era la que hacía el cliente. ¿Digo, sabes por qué el dios no hizo el mundo en siete días? Hizo el mundo en siete días porque no tenía legacy. Digo, así de fácil. El problema de las empresas sigue siendo el legacy en gran medida. Y claro, combatir o intentar revertir desde cero una tendencia que en el mundo de la informática puede llevar 20, 30,40 años en algunas empresas, pues es prácticamente imposible. Es como creerse atlas y llevar el mundo a tus espaldas, literal.
[00:31:13] Speaker B: Y además el coste añadido que eso te supone, porque no es lo mismo montar la aplicación desde cero, como puede hacer una startup o lo que sea, que esté más abierta a cambios, que lo que tú has dicho, una empresa comercial grande donde todo lleva su proceso, donde cada cambio está revisado y reconocimiento dependencia del fabricante. Sí, claro, o sea, al final te has hecho ahí un. Que es un poco lo que hay que tener cuidado también en la nube, que si dependes de un servicio y tienes todo muy implementado para un servicio muy concreto, como luego quieras migrar porque el proveedor, o en este caso el fabricante, te ha dado lo que está pasando ahora con Vmware, con la subida brutal de costes, pues a ver qué haces. Es el caso tan famoso que está viendo ahora entre At Tfünf y VMware.
¿No sé, al final luego si te quieres migrar de Vmware y toda tu virtualización a VMware, hasta qué punto, no?
[00:32:10] Speaker A: Ese debate problem está hoy en día en, yo creo que prácticamente una de cada dos reuniones con clientes. Y te puedes encontrar alternativas de todo caso y de todos los colores.
Las dos más fáciles es, o sigo con VMware en el servicio, un proveedor, por lo menos yo ya no soy el que tenga que lidiar con VMware, se carga el proveedor. O la otra es, hago un big bang y todo lo que tengo en máquinas virtuales de Vmware lo paso a máquinas nativas en un proveedor de cloud. Eso yo creo que es sencillo, digamos, el camino es sencillo, pero claro, luego te empiezas a dar cuenta que ya hay muchas empresas que no es 100 % su carga de trabajo, toda la granja de Vmware, sino que ya tiene cosas en Kubernetes, algunos lo tendrán en tanzu, otros habrá hecho sus implementaciones van y la desde cero, otros estarán utilizando pensive. Entonces ya empieza a complicarse mucho más esa discusión de me enfado con este proveedor y me lo llevo 100 % al cloud. Tienes que revisar diferente tipo de cosas y sobre todo herramientas como Pensive, que están súper implementadas a nivel de contenedores y muchos clientes, pues bueno, es muy sencillo hacer ese drag and drone así de configuración. Eso es genial.
[00:33:27] Speaker B: Pues la verdad es que era muy interesante por saber un poco tu opinión, porque cuando has dicho lo de Gartner, es que me has saltado la larga.
[00:33:34] Speaker A: De hecho, un cuadrante de Gartner donde estaban empresas como Raidscape, esta empresa que emitía un informe de la adopción del cloud.
Sí, yo creo que sí, no sé quién la compró, pero desapareció de Ÿousand del mercado hace tres o cuatro años. Y George sumamente telefónica. Hicimos muchos análisis de herramientas de lo que llamamos brokers de cloud rate scale, estaba en el radar. Creo que en España había otra de una startup de Marcelona, si no recuerdo mal, Aptio One o por el estilo, que de hecho luego compró la computadora telefónica o la celero telefónica a través.
[00:34:13] Speaker B: De Wire up, vamos, aptio ahora sí es la misma, ahora es DM, básicamente.
[00:34:20] Speaker C: La Xaman, ahora IPM.
[00:34:23] Speaker A: Bueno, eran esos brokers de cloud que te iban agrupando esa información de costes principalmente y tenían la promesa únicamente de mover cargas de trabajo de forma nativa entre un proveedor y otro, que yo nunca lo he visto nada fácil, sobre todo teniendo herramientas, digamos, en source y nativas como era Terraform.
[00:34:46] Speaker B: Sí, literal. ¿Yo como persona que se ha comido ese trabajo haciendo el terraform y demás, no es fácil ni ahora, incluso con la IA que te permite, digamos, generar código y te quita un poco ese trabajo más manual, no? Más pesado de escribirte todo el código, etc.
[00:35:07] Speaker A: El problema es que está construido para cada nube, es la marca, pero tienes un proveedor para cada nube y cada nube tiene sus nomenclaturas, sus servicios y.
[00:35:18] Speaker B: Es un problema total, o sea, imposible de solucionar. Es decir, en el momento que intentes generalizar, como aviso, no es posible template.
[00:35:31] Speaker A: Que vayas amoldando para cada despliegue dinube.
[00:35:35] Speaker B: Y es que, o sea, el proveedor te lo va a joder, así de claro. O sea, le apetece cambiar un parámetro de no sé qué, ya tienes que hacer una arquitectura entera, o sea, es creo que es algo que ha inventado mucha gente.
[00:35:47] Speaker A: ¿De hecho fue comprada por IBM, no? Si no recuerdo mal.
[00:35:52] Speaker B: Sí, compraron Hasicorp y hace hace poco. La verdad es que no sé, el presupuesto IBM, no sé. Luego ya lo comenté una vez en la newsletter de las sinergias, luego yo ya he visto mucho compra de empresas y luego empiezan las sinergias, a ver las sinergias de IBM con todo lo que está comprando en en Cloud, habrá que ver cómo va, pero bueno, esperemos porque al final sí que Terraform tuvo un momento crítico con el tema del cambio de licencia, de que ya no iba a ser pública, ahí las pasó, no fue el mejor momento, estuvieron listos comprarla ahí, la verdad.
[00:36:32] Speaker A: Yo creo que era algo del proceso de venta.
[00:36:35] Speaker B: ¿Sí, yo creo que algo así, pero.
[00:36:38] Speaker A: Le salió la salida de Hashimoto, no? Era el fundador.
¿Bueno, pues el fundador, que era un americano de origen japonés, salió seis meses antes de cambiar el modelo comercial y a los tres, 4 meses les compró IBM, no? Parece que estaba un poco todo orquestado en esa línea.
[00:36:55] Speaker B: Sí, no sé, pero ahí lo vieron un poco, creo que vieron cómo se dio la vuelta a la conversión al.
[00:37:00] Speaker A: Final con Docker, creo que al que pase que se queda un poco ahí.
[00:37:05] Speaker B: En si Docker, o sea, al final yo por ejemplo me acuerdo en tema de Docker que dije es que es imposible, o sea, que seáis rentables, es decir, esto tiene que estar quemando dinero a punta pala. Me acuerdo en los principios era no estáis generando nada, o sea, simplemente estáis dando y no estáis generando nada para vosotros, es decir, tenéis que monetizar de alguna manera porque si no esa empresa se moría y se iba todo al garete. Entonces al final Ÿousand entre las cosas y otras luego con el container D, todas estas iniciativas y luego todo el ecosistema que se ha formado alrededor de Docker, porque no hay que olvidarse que al final todo parte un poco de ahí surgen otros temas comerciales que al final las compañías tienen que vivir de algo, es decir, queremos Docker que funcione gracias a la divina voluntad de no.
[00:37:56] Speaker A: Sé, pero es como casi todos los las iniciativas open source se ha visto con Docker, se vio con terraza luego, pero ya no habíamos vivido con Linux en general, es decir, las empresas, las grandes compañías, llegado el momento tenían sus contratos con Red Hat, con Suse, con Onacle, con el que le estaba proporcionando o el que habían elegido como su proveedor de plataforma de Linux. ¿Entonces lo pensé, está muy bien, yo creo que es ha sido un poco el que ha hecho que realmente la informática y ya no tanto la informática, el cloud haya crecido de forma exponencial, porque si te pones a ver, muchos de los proyectos que hay detrás de un montón de servicios de los proveedores, originalmente fueron servicios open source, no? Entonces, o proyectos open source. Entonces le daba esa gasolina que necesitaba el cloud, pero como bien dices, hay que hacerlos que sean rentables.
[00:38:47] Speaker B: Claro, así es. ¿Y ahí es un poco el modelo, no? Porque al final muchas empresas, mira, MongoDB y demás, empiezan por ofrecerte una herramienta que es súper útil, open source y luego ya los servicios pues te lo gestiono yo. Bueno, que si totalmente establecido ya funciona.
[00:39:06] Speaker A: Efectivamente, ahí con el open source. Las licencias también hay que tener mucho cuidado en el cloud.
[00:39:12] Speaker B: Sí, creo que tenemos que traer a alguien del tema licencias porque ese es un melón bastante importante en fino en general, porque porque hay mucho dinero puesto ahí. ¿Y cómo se negocia? A mí me interesa mucho saber cómo negocias.
[00:39:31] Speaker A: Muchos de los clientes cuando van al cloud. Es decir, a ver, soy juez y parte en esto porque parte del revenido de Raquel todavía sigue viniendo de la parte de licencias y el cloud no ha ido más rápido porque muchos de los ISVs han podido, han puesto trabas a que esa portabilidad de licencia se ejecutase entre el on premise y la nube. Pero es una de las cuestiones que todavía a muchísimos clientes con los que hablo les preocupa. ¿Es decir, qué pasa con biggest de Windows? ¿Me los puedo llevar? ¿No los puedo llevar? ¿Qué pasa? Además es distinto si me la llevo a máquina nativa del proveedor que si me la llevo sobre un Vmware. ¿Qué pasa con las licencias de Vmware de Red Hat? Pues yo en mi casa licencio la granja, yo cuando monté rehab sobre máquina virtual tuya, como lo tengo que hacer, pues esas preguntas no son, al fin y al cabo no deberían ser preguntas técnicas. Yo a mí, desde mi punto de vista, no debería preocuparse ningún departamento de TI de tener que lidiar con esas cuestiones, pero sigue siendo gran parte del día a día de las organizaciones.
[00:40:41] Speaker B: Sí, sí, definitivamente. Me lo apunto ahí.
Dime, Damián.
[00:40:46] Speaker C: No, no, eso quería agregar también el tema de SAS, que es casi tienen algo en común y no, también, pero también eso, porque la gente no entiende hasta el final.
¿También ahí tenés licencia y también ahí tenés gastos, no solamente del proveedor, sino también el proveedor de la nube y cómo va todo ahí también es un.
[00:41:10] Speaker A: Tema que hay que.
[00:41:13] Speaker C: Desde el punto.
[00:41:13] Speaker A: De vista del phinops en general, el SaaS suele ser mucho más sencillo porque te lo acaban licenciando la gran mayoría de los proveedores por usuario, no?
[00:41:21] Speaker C: Entonces sí, pero cuando llegas al tema este del procurement, que están haciendo todo en la negociación y todo el tema, eso no siempre saben o no conocen todo o al final no saben también esos gastos que traen en las letras chiquitas, como decimos, no todos saben. No todos saben. Lo vimos, lo vi últimamente con unos cuantos clientes que pidieron que esté un phenox ahí que les ayude a entender. Viste todo lo que. Porque al final si tenés un proveedor, te da, te ofrece un servicio, te pone ahí, al final le ponen también, te cambian los puntos, por ejemplo, te dan un dbu, data visual, te dan como un precio por una unidad, que eso te cida, pero esa unidad al final se viste, se parte en varios servicios de cada nube y diferente de cada nube. Entonces ahí está todo eso. Y también encima hay parte que está en tu nube, o sea, estás pagando más por los servicios que no solamente que ellos te están ofreciendo, sino a otras cosas que ellos te ponen en tu nube. Entonces todo eso no siempre se entiende. Eso es lo que yo vivo.
[00:42:43] Speaker B: Sí que también puedes tener complejidad en un servicio SaaS, si no coger un modelo de tanto al mes o tanto por usuario, ahí se te puede, poco.
[00:42:53] Speaker A: Más os puede ayudar. Porque esa parte del SaaS para mí, más allá de entender el precio por usuario u otros otras cosas que quedan también un poco en esa neurosa del SaaS, pues los servicios de productividad, los office 365, acaba siendo casi el mismo modelo, usuario o sid o usuario y ya te doy acceso a mis diferentes paquetes comerciales, pues con este paquete tienes a, b y c, en el siguiente tienes no sé cuántos más y en el otro no sé cuántos más. Bueno, ahí es más sencillo, ÿousand, pero.
[00:43:28] Speaker C: Ahí también tenés también otro tema, aparte del lío de lo que se usa, sino también de que a veces la gente compra de más.
Y cómo ves, y ahí es lo difícil, cómo identificás qué usuario, si está contento o no está contento, por qué lo usa, por qué no lo usa.
[00:43:47] Speaker A: Bueno, ese es el rop del customer success, que sobre todo en la parte del SaaS siempre ha tenido mucha más importancia. Es decir, un cliente que no está utilizando, el ejemplo es más sencillo, Netflix. Es decir, si tú dejas de entrar a netflix todos los días y no ves películas, pues a lo mejor ese hábito que no has generado, pues va a hacer que cuando pasen tres o cuatro meses digas me voy de Netflix. En el SaaS pasa lo mismo, es decir, si tú haces un proyecto, si tú lo compras y tus usuarios no lo usan, a lo mejor cuando vaya a llegar la renovación si no hay un una persona de tu organización que está persiguiendo al cliente, incentivándolo a utilizarlo y ver las ventajas, pues llegará y el mes de antes cuando le envíen la oferta de renovación, tú dirá bueno, pues nada, encantado, hasta la próxima.
[00:44:36] Speaker C: Eso sí, pero eso si el cliente identifique eso y ahí creo que es donde está el filo que tiene que.
[00:44:42] Speaker A: Sí, sí, sí, efectivamente. A lo mejor habría que tener a alguien dentro de ese tipo de organizaciones que se [sos/eos] que me las en vigilar el uso y en los dos.
[00:44:52] Speaker C: Nada clave, interesante el punto porque tiene que estar de los dos lados.
[00:44:57] Speaker B: Claro, literalmente, creo que eso ya es una idea para un podcast futuro porque da para un episodio entero.
¿Me gustaría saber literalmente a mí como una negociación de licencias de un Enterprise deal desde dentro, en plan de y cómo te tuviste que pegar y tal? Aunque sea sin números porque tiene que haber una guerra.
Sí, sí, sí, sí, sí, me lo apunto totalmente. Lo quiero de los dos lados, de el que da el servicio y el que lo compra. Y ver cómo se negocia de cada parte.
[00:45:32] Speaker A: No solo eso, tienes grandes proveedores de cloud que tienen unos commitment.
[00:45:36] Speaker B: Sí, sí, sí, sí, sí. Por eso esa parte, eso también nunca.
[00:45:39] Speaker A: Lo he entendido, porque siempre que voy a los clientes te dicen que no son capaces de llegar al commitment que les ha marcado el proveedor y van con la lengua afuera y van a tener penalizaciones ÿousand y dices te has comprometido a un dinero que has utilizado 10 y encima le vas a tener que pagar una penalización de x porque no has sido capaz de gastar todo. Yo nunca lo entendí. Yo mira, ahí lo cuento también de otra manera. Ese es mi día a día con muchos clientes. Ya tengo tal comienza con tal proveedor. ¿Digo, esto de llegar tarde al cloud, el problema que tenemos es eso, no? Es cuando te toca la novia que te gusta el colegio y has dado besos con todos y a ti te dice que ir despacio porque tú le gustas, pues dices bueno, qué suerte he tenido yo, qué suerte he tenido yo. Pues es como saber que están pasando negociaciones cuando te encuentras un cliente que hay con un regalo de esos firmados con tercera que le inhabilita hacer nada con nadie más porque ya hipotecado tecnológicamente su desarrollo tecnológico.
[00:46:37] Speaker B: Ahí está el objetivo.
Pues nada, Alex, la verdad es que creo que ha sido una conversación súper interesante sobre un montón de sobre un montón de cosas y nada, un placer porque hayas venido. La verdad es que creo que hemos aprendido un montón.
[00:46:51] Speaker A: A vosotros por dejarme pasar este rato tan entretenido y discutir de estas cosas tan frikis que no es fácil hablar con todo el mundo así que nada, Damián, Víctor, un placer y cuando queráis volvemos a hablar.
[00:47:06] Speaker B: Ok, genial. Pues nada chicos, nos vemos en la próxima.
