Episode Transcript
[00:00:00] Speaker A: Phenops al final está poniéndose muy de moda recientemente, pero bueno, hace unos años nadie hablaba de él.
[00:00:05] Speaker B: Pasamos al club donde todo el mundo tiene que saber todos los servicios, las líneas de coste, los cost drivers en rate per usage, o sea, es mucho nivel y parece que todo el mundo sabe mucho de abre la calculadora y te explota la cabeza porque dices que si la licencia de tal, que si el disco es premium, SSD estándar, SSD pull stable, que si pongo una gravitron, o sea, yo quiero una máquina virtual Linux, qué fecha, cuanto estoy pagando esto porque quiero, o sea, no estoy pagándolo porque esté poco eficiente, es que no estoy pagando porque quiero, para llegar rápido a mi destino.
[00:00:39] Speaker C: Creo que Fineops es general a toda una compañía, desde el SEO hasta el último de los desarrolladores, legal, producto.
[00:00:48] Speaker B: Lo que me encanta de nuestro trabajo es que es un trabajo muy creativo, no es cada día Zweitausendein hacer lo mismo como un mono.
[00:00:54] Speaker A: Buenas a todos y bienvenidos a un nuevo episodio de Phoenix más que costes. Hoy somos más que tres por primera vez, así que hoy tenemos dos invitados bastante, bastante especiales. Creo que va a vamos a tener una conversación bastante, bastante interesante. Son Alfonso San Miguel, que es Cloud Architect Lead y tenemos a Dani, que es responsable de datos y de arquitectura de datos en. Hola Luz. ¿Qué tal, Dani? ¿Qué tal, Alfonso?
[00:01:26] Speaker C: Muy bien, buenos días. Gracias.
[00:01:30] Speaker A: Bueno, y cómo no, nuestro querido copresentador, Damián.
[00:01:33] Speaker C: ¿Qué tal?
[00:01:33] Speaker A: ¿Cómo estás?
[00:01:34] Speaker D: Gracias, de verdad, muy entusiasmado por esto. Somos cuatro y también creo que vamos a tratar temas interesantes hoy, así que.
Sí, sí, eso es.
[00:01:46] Speaker A: Vamos a ello. Pues nada, bueno, para los que no conozcáis, Alfonso y Dani estuvieron trabajando hace un poco de tiempo en un libro llamado Cloud Efficient, Cloud Finops, si no recuerdo mal, es que siempre confundo las palabras. Un libro muy interesante, lo recomiendo a todo el mundo que se lo lea, aprendes mucho, sobre todo si sois ingenieros y si sois de otras partes del sector también, porque os va a dar mucho detalle de cosas que implementar y que no y cómo hacerlo de verdad, o sea, un ejemplo de cosas que hacer, cómo se hacen con casos reales. Está súper bueno, a mí me encanta.
No es porque estén aquí, no por nada antes de conocerlos, o sea que o sea, que genial. Así que nada chicos, Ÿousand yo quería preguntar un poco para que os ubique la gente cómo surgió la idea, porque bueno, esto no fue hace dos días, esto fue hace un poco de tiempo y el Finops al final está poniéndose como muy de moda recientemente, pero bueno, hace unos años pues nadie hablaba de él. Entonces para que se ocurriera hacer una idea de un libro. Contanos un poco cómo surgió todo esto.
[00:02:59] Speaker B: Bueno, pues si os parece empiezo yo, que fui un poco el que el que bueno, Dani estaba más o menos por esa época también por allí, pero la semilla un poco cuando nací o yo estaba acababa de entrar en Habanade, Accentum y bueno, venía de arquitectura cloud, etc. Etc. Gobernanza es un poco siempre esa parte de la arquitectura cloud siempre me ha encantado. Y bueno, pues empezamos un proyecto en Santander, en el banco Santander, precisamente para montar lo que sería un CCOo Philops.
Entonces estuvimos colaborando con dos arquitectos allí, increíbles personas y y compañeros, Sonia y Daniel, si nos escuchan por aquí, un saludo enorme.
Entonces nada, pues conmigo se empezó a hacer lo que sería la semilla de este proyecto Finox en Santander, en la parte, digamos, desde cb, desde Central, no desde ninguna entidad concreta. Y ahí nos juntaron a Dani y a mí y entonces me dijeron Dani está en Alfonso, Alfonso, este Dali.
¿Y fue así un poco extraño a.
[00:04:08] Speaker C: Primera vista también esta parte, vale?
Yo también venía, siempre he venido al mundo de los datos, de las arquitecturas. Sí, pero lo más importante, cuando conocimos a Alfonso, nos quedamos mirando, nos conocimos y dijimos bueno, tú pinups, no es lo que eres ahora. ¿Y también agradecer a Sonia y a Dani, vale? Pero nos costaba mucho. Pero esto como siempre sale mejor pues conociéndonos, trabajando mucho, sufriendo juntos. Y primero éramos compañeros de trabajo, ahora somos amigos. 1 día de cervezas pues salió la idea del libro y eso sí, de Alfonso, vale, que con sus contactos.
[00:04:54] Speaker A: ¿Sí, sí, al final de dónde salen las mejores ideas, no?
[00:04:57] Speaker C: En el bar, en el bar.
[00:05:00] Speaker B: Pensad que claro, en esa época, estamos hablando como hace ya dos años o por ahí, no había la Feel of Foundation, si existía, estaba en pañales todavía. Yo recuerdo haber leído el libro y el libro de O'Reilly me encantó, el de Jr me encantó, un contenido increíble, me abrió la cabeza, me estalló la cabeza totalmente, pero echaba de menos un paco en la parte práctica. ¿Vale, todo esto está genial, pero cómo llevo yo esto ahora? ¿Ÿ a la realidad de una nube o de otra? Y recuerdo que en esa época inicial había muchísimo trabajo de Dani, yo y de también la gente de Santander, o sea, Daniel, historia de brainstorming porque no había nada, no había documentación. Entonces primero teníamos que crear toda esa documentación, digamos, oficial de cómo se deben hacer las cosas a nivel de optimización de costes, máquinas virtuales, tagging, dashboards, ÿ, capaz, todo de cero. ¿Y es eso, y era como qué hacemos?
Pero es que ese trabajo tan creativo fue súper divertido. Empecemos, sacar dato, vamos a ver qué nos sale, vamos a ver.
Y bueno, eventualmente, yo creo Dani esa etapa se acabó. Cada uno siguió su camino profesional que teníamos delante, se deshizo ese equipo que acabamos siendo unas cuantas personas.
Ismael Increíble el equipo, la verdad. Óscar un equipazo de 10. Pero al final se acabó desmantelando 1 poco. Joder, yo me quedé detrás de la cabeza con esa idea de decir hemos creado muchísimas cosas de cero, que sí, obviamente las tenemos ahí en la cabeza y todo, pero bueno, teníamos una idea de que habíamos creado como una especie de nuestro framework propio, por así decirlo, o teníamos algo cercano a ello. Entonces, un poco más, avanzamos un poco más en el tiempo, unos meses después, directamente me escribe Packet, la editorial de Ÿousand, y me dice oye, hemos visto que sabes de phenops en terimarios, ha escribido un libro. Y yo digo sí, venga, y a quién se preocupe decirme algo a este elemento de aquí, a Dani ahí está.
[00:07:04] Speaker C: Ahí empieza el problema.
[00:07:06] Speaker B: Me pareció perfecto para poner colofón a estos dos años de trabajo, de creatividad y de cosas que luego, viendo un poco lo que se plantea ahora, pues llegamos a muchas de las mismas conclusiones que se han llegado en la industria Zweitausendein. Pero la idea era plasmar en un libro pues nuestra versión de este framework, que realmente todo se basa en los pilares de siempre, de Jr y de O'Reilly y todo esto, o sea, toda nuestra idea. Obviamente lo primero que hicimos fue leer ese libro. O sea, que no estamos inventando una rueda, pero sí que intentamos construir algo sobre esa base, sobre esos pilares. Y esa era un poco la idea. Y también cumplir eso que os decía al principio, es decir, vamos a dar algo práctico, algo que a los frikis o a los ingenieros les sirva para empezar a dar sus primeros pasos, pero algo también y este era un reto muy difícil que le valga también a un financiero. Obviamente hay ciertos capítulos en el libro que no recomiendo a nadie no técnico que se lea porque va a explotar la cabeza, pero el resto del libro es bastante accesible para gente no técnica, para proyectarlas. Entonces hemos intentado un poco aunar todo eso. Es difícil, pero creo que más o menos lo conseguimos. Y así un poco nació. Nos tiramos a la piscina y ya está.
[00:08:17] Speaker C: Ÿ y con la premisa de que no todas las compañías son iguales o rail marca es el marco, el framework general, pero la madurez de una compañía no es la misma. La A, la B, la c, en algunas ni siquiera tienen un protocolo de costes. ¿Todavía seguimos pensando en la amortización ese cambio cultural que yo lo vi con Alfonso fue muy muy grande, vale? Es oye, vamos a poder, es una gran oportunidad, no nos engañemos, con todas las nubes, con todos los servicios que puede tener una entidad como Santander, entender a bajo nivel el cos driver de un servicio fue increíble. ¿Oye, y ahora cómo hacemos guardarraíles para esto?
[00:09:07] Speaker B: Y además, aparte de una parte friki, que efectivamente, entender qué problemas hay, qué cosas provocan ineficiencias en costes, la parte personal y la parte de las personas en sí, qué dificultades hay para esto, qué temas burocráticos te encuentras, qué stopes hay, quién es quien más te apoya y quién más te puede aportar. O sea, esto es oro. Las cosas técnicas, mira, los servicios cloud sabemos cómo son Vienner y Van, hoy hay este, mañana hay este y estas son las herramientas para utilizar cada uno. Pero esa parte cultural fue brutal, fue un aprendizaje brutal.
[00:09:41] Speaker D: Claro, también no cada protocolo, no cada proceso le viene bien a cualquier empresa. Hay que hacer esa conexión que tiene que ser justo para, muy justo creo yo, para que salga todo esto, lo que es el fin ofiel en una empresa y ser muy justo para las personas que están trabajando en esa empresa, si no, tampoco va a funcionar. Entonces, muy interesante. Y la verdad que ya quiero ir.
[00:10:12] Speaker B: A comprar invierno porque quiero también hay que comprarlo.
[00:10:16] Speaker C: Una de las cosas que también es es darles el ownership, no me recordaba la palabra.
[00:10:23] Speaker A: Empoderar.
[00:10:24] Speaker C: Empoderarles, eso es, el ownership a los equipos que realmente que el coste de la infraestructura también depende de ellos. Es decir, que sean conscientes de que levantar ciertos recursos en cloud tiene consecuencias.
Oye, nosotros es lo de si un departamento que ya iremos al gaming, bueno, hemos tenido discusiones de todo con el Alfonso, pero es que si dos equipos saben, no todos siempre tienen la misma infraestructura, no pueden competir, pero que sean responsables de Oye Ÿousand, este servicio que utilizo está optimizado, puede valer para una carrera pad, puede valer para una revisión salarial y tal. Y es una de las cosas que también queríamos poner en el libro, de que también tiene que estar muy relacionado como un objetivo de tecnología el ahorro de costes, que a veces no lo está, que solo está en la capa estratégica, que capex, Opex, que esos capítulos son durísimos para un técnico, pero creo que es muy importante diferenciar el paradigma anterior con el de ahora.
Es una oportunidad para técnicos, para PMs, para EMS. Es un libro ligero, no tan pesado, pero no es un framework cerrado. Y creo que también tiene muchos ejemplos que puedes comenzar a hacerlos. Es decir, oye, reducción de costes, discos, lo típico.
Bueno, una experiencia a mí respecto a.
[00:11:53] Speaker B: Ese tema Perdona Víctor que te interrumpa.
Justo me encanta lo que estaba diciendo Dani, porque parece que todo el mundo, o sea, ya sabéis que en Ite está postureo, por así decirlo, parece que todo el mundo está haciendo Hinai, todo el mundo está haciendo fino, todo el mundo cloud, son hombres avanzados, son multicloud. O sea, la realidad es que la gente va mucho más lenta de lo que parece y solo hay unas cuantas compañías punteras, pero la realidad es que la gente va como puede que bastantes retos hay. Entonces, el libro empieza tratando un tema que es precisamente el cambio de paradigma que supone el cloud. Esto que dice eran y no, es decir, cost accountability. Hasta yo, por ejemplo, arquitecto de infraestructura, yo en mi pasado, cuando trabajaba en cosas no cloud, ni me preocupaba en los costes, sabía que se compraba un servidor pensado para cinco años, que la capacidad se estimaba previamente, vamos a crecer un 40. %. Entonces tú ya comprabas con suficiente disco y cpu para que tuvieras años y años de meterle cosas ahí. Y pasamos al cloud, donde todo el mundo tiene que saber todos los servicios, las líneas de coste, los costdrivers en Repair, usage. O sea, es mucho nivel y parece que todo el mundo sabe mucho de Cloud. Ahora ya obviamente han pasado años, ya la gente va controlando más, pero ese es uno de los puntos, es decir, los equipos Cloud saben de Cloud, hacer cosas en Cloud, pero no se han parado a pensar el paradigma, el cambio de paradigma y cómo le influye esto al equipo financiero, por ejemplo, cómo pierde el control. Porque antes ellos decían te apruebo este presupuesto de cinco años, el equipo financiero pide el control y la responsabilidad pasa claramente a los técnicos, a los equipos técnicos y los de ingeniería. Entonces ese es el punto perfecto para empezar a hablar de Philops y de hecho es lo primero que tratamos en el libro. Incluso otro de los temas muy interesantes es el iceberg en los ÿousand costes on Prem. Nadie sabe lo que cuestan las cosas, nadie se pone nunca a pensar cuánto cuesta electricidad, cuánto cuesta tener un site por si es de can data center, cuánto cuesta tener a una persona que hace seguridad. Y nadie se ha pensado a parar eso. ¿Cuando hacen unas business case de cloud, de migración al cloud, se cuenta solo el soporte, la infraestructura y los discos y estas cosas? No, no cuenta todo, si no, no está haciendo ejercicio.
[00:14:06] Speaker D: ¿Ahora estábamos hablando de eso en un capítulo creo que con mi hermano, no, Víctor? La gente habla mucho del coste en la nube, en el cloud, pero lo más interesante es que por lo menos sabes lo que estás pagando, pero no sabe lo que están pagando. Alguien pensaba que era el que sabía, pero exactamente no sabía a dónde va todo el coste. Como decís, es electricidad, el lugar. Hay muchas cosas que como como un empresario, como un financiero, no lo sabes y la nube sí te da todo eso.
Todo esto es una de las cosas más buenas que tiene la nube. Tú puedes saber claramente lo que tienes.
Bueno, claramente eso es otro tema. Depende de cómo se las cosas.
[00:14:54] Speaker C: Eso nos da para otros tres libros. Vale.
[00:14:56] Speaker A: Lo que es la claridad, porque cuando, o sea, al final es lo que el cambio de paradigma es que comentas, Alfonso, que al final yo me acuerdo de cuando empecé, que yo ya empecé como toqué hacer cloud con el tema de infraestructura y ya veía, nosotros trabajábamos ONPREM, pero al final yo trabajaba en una startup que éramos literalmente cinco. Entonces, para hacer recursos para todo, ya empezabas en el cloud y tú llegabas y ya configuraba una estancia tuya. ¿Decías, vale, y esto cuánto va a costar? Que si el disco, que si el propio, qué modelo, en base a qué, coge un modelo u otro para una persona totalmente nueva. O sea, no tienes ni idea de. Pero necesitas ese recurso porque si no, no despliegas a ningún lado. O sea, no tienes un servidor que digas, mira, aquí todo ese tema para al final eso desde un principio. El primer paso es que al final el primer paso que tienes que hacer, aparte de hacer tu código, es pedir una máquina virtual, por ejemplo, y dices, vale, esta decisión tiene un coste. ¿Dice, cómo voy a saber yo que si esto es tanto, cuál? El dato de la vpc, de si cuánto cuesta el egress data, en qué región lo pongo.
[00:16:08] Speaker B: Una reflexión muy interesante. Imagínate que tú te acabas de sacar tu en azure o el audio certified practitioner, el inicial, o en azure essentials y es así. Bueno, vamos a ver la calculadora, voy a explicar una máquina virtual. Abres la calculadora y te explota la cabeza porque dices que si la licencia de tal, que si el disco es premium, ssd estándar, ssd push table, que si pongo una gravitron. O sea, yo quiero una máquina virtual Linux. ¿Qué fecha?
[00:16:37] Speaker A: Contando un servidor.
[00:16:43] Speaker D: Entre regiones o no pasan.
[00:16:44] Speaker B: Eso es. Quieres Crossregion, perdonad.
[00:16:50] Speaker C: Ahí es. ¿Imaginemos cómo desarrollábamos antes también proyecto todos, creo que ya, bueno, yo ya tengo una edad y es a ver, qué necesitamos? Cuatro servidores, tres, cinco, tal, memoria, pues cuatro, cinco, tal. Eso estaba todo amortizado porque ya tenías la infraestructura. Uno más, uno menos, tú ya tienes el CPD. Claro, cambias al paradigma y lo que funciona mal en Primize, en Cloud, el error puede ser exponencial.
Siempre contaré una anécdota que vi cuando en las primeras ocasiones a nivel de datos en OnPrime se tenía un demonio porque no tenía ni siquiera una arquitectura de eventos que estaba atacando la base de datos para ver si se actualizaba eso. ¿En OnPrimate, el de seguridad, todos tranquilos, se subió a Cloud la misma base de datos con el mismo proceso y las operaciones se dispararon y llegaron la gente, oye, oye, a mí me dijiste que esto me valía $1000 y aún me ha salido 8000. Qué ha pasado? Es que tus procesos también tienen que cambiar la forma de generar tus infraestructuras y software.
Es un ecosistema como la Amazonía, tiene que estar lo más, más protegido porque cualquier cosa puede romperlo. Entonces, oye, una mala decisión. Por eso siempre los guardarraíles, toda la gente técnica tiene que ser consciente de las consecuencias que en la factura final tiene.
[00:18:22] Speaker B: Vale, pero, por ejemplo, es un tema muy interesante ese que dices, Dani, porque cuando haces una migración a Cloud, bueno, esto me ha pasado en mi actual empresa, Bact, precisamente me ha pasado una falta de veces ya. ¿Zweitausendein se hace una migración, vale? ¿Cuándo se triggerea una migración? ¿Cuándo quieres hacer una migración y de verdad te corre prisa? Cuando, por ejemplo, se acaba el soporte de un servidor o tienes máquinas sin licenciar, historias de estas, ahí de repente hay muchísima prisa y hay que moverlo en la nube. Imaginaos, te curras un business case, todo, y claro, una de las cosas es lo que dice, lo primero que hacen para hacer todo rápido es lift and shift. Y lift and shift significa llevarte los problemas que tienes ya a la nube, incluso se van a grabar. ¿Entonces, hasta qué punto lift and ship es una buena decisión? Yo, mira, internamente una de las cosas que hago es decir, ahí de hecho tengo esta presentación de destinada porque me encantan estos, está Free Queens. Factores para una migración al cloud que te pueden decidir si haces cualquiera de las seis r's, el lift a shift, ambifactor, nepurpost, retire, ya sabéis, en la charla. Factores, por ejemplo, una es el coste, pero es una. El resto hay muchísimas. Technical expertise del equipo es otra. El impacto que puede tener un usuario. Si vas a estar downb, envigado una aplicación, en lo que la mueves al cloud y la vas a tener cerrada, te va a decir management que no, ni de coña.
Entonces, hay muchas cosas que tener en cuenta. El coste es solo una de ellas. Parece que el coste es lo más importante al principio, pero puedes causar mucho más problemas llevándote algo no utilizado. Por eso yo intento no dejar nunca que no se optimice la o sea, todo tiene que estar optimizado antes del plot porque lo vas a ver en tu cara. O sea, lo que antes no te importaba, como dice Dani, ese problemita que no te importaba te va a hacer en tu cara, toma, este es tu problema y lo que no has enfrentado en los cinco últimos años porque lo has ido dejando, lo vas a tener que enfrentar ahora y además te va a costar mucho más que cuando lo tenías. Onprem y bueno, ya no hablamos de rain, soy single prem, nadie encerra en starsing onprem porque como tienes tus máquinas ahí tienen vaquillas sin uso ninguno, etc. O sea, que esto es un tema que también da para un libro inops enfocado migraciones cloud, de emprender cloud. Ahí hay un trabajo.
[00:20:39] Speaker A: Bueno, eso es un melón tremendo con el instance es un melón tremendo porque hacen luego todos. O sea, lo hablamos también en otro que era no sé cuánto por 100, ahora se quiere volver. Y digo sí, no sé, vuelve ahora. Ahora estás empantanado hasta el fin del mundo y ahora quieres volver. Sí, con lo que el tiempo que has perdido, lo que te ha costado y ahora resulta que antes era más barato.
Mis dudas.
[00:21:11] Speaker B: Pero yo creo que como un mundo, perdón, iba a decir, hay como un mundo oculto de synops cuando pensamos en phenops y todos nos imaginamos máquinas virtuales, right size, las típicas cosas autoescalin. Yo veo que hay como ciertos mundos ocultos de de los que no se habla mucho. La migración es cloud, es uno optimizado antes de migrar. Esto no se trata mucho.
Y otra muy interesante que estoy viendo yo es temas de costes que no están relacionados con infraestructura. Por ejemplo, licencias. Yo estoy haciendo ahora mismo un proyecto de optimización de licencias de power bi.
Nada que ver con infraestructura como código, nada con nada de auto scaling, nada de bitesizing, pero es un pastizal.
Entonces ese es un mundo en el que hay mucho también por descubrir y el framework todavía no está muy cubierto.
[00:21:58] Speaker D: Me han salido existe acordar que me hicieron alguna vez cuando entra el fino, mientras antes mejor.
¿Estás planeando una migración? Bueno, Metal Side que te ayude a ver cosas que no pensaba. ¿También me hiciste acordar el tema de SAS, todo lo que estás por las liceas, donde hay lugar de costes y tecnología, pone finos, por qué no? Que te ayude a ver y ver cosas que una persona financiera no lo puede ver o una persona que está haciendo DevOps y no le interesa, no lo puede ver.
Ponen un proceso por esa función ahí también que hay mucho, mucho, mucho para hacer. Víctor, creo que le dimos una idea más, pero nos cuento un libro.
[00:22:52] Speaker A: Vais a seguir trabajando más vosotros que nosotros, sabes de este episodio. Y quería hablar un poco del tema de las licencias, porque al final yo creo que eso beneficia también mucho a la parte menos técnica quizá de que está más acostumbrado a generar, a la gestión de contratos, todo el ITAM, todo este el procurement, todo este aprovisionado de cosas y negociado de contratos y reservas y tal, que ahí sí que es verdad como que todo lo que nosotros, por ejemplo yo por mí y este, vemos como más técnico y demás, pero ahí, aparte de que te estás jugando un pastizal, o sea, en empresas en cuanto se ponen un poco grandes las licencias de cualquier SaaS o de cualquier infraestructura, es una barbaridad de dinero más que ajustar una v, una vm de e a n porque ha cambiado la familia o lo que sea, eso son $20, lo otro igual son 20 millones.
Entonces, ahí sí que es verdad que yo creo que los financieros o la parte de aproximamiento tiene un rol que si se adaptan rápido van a estar muy bien posicionados. Yo creo, la verdad. Esa es mi impresión. No sé qué pensáis.
[00:24:03] Speaker B: Yo creo que totalmente. Yo por el ejemplo que mira, un ejemplo que estamos trabajando, estamos contratando un firewall.
Cuando estás en estos procesos, lo primero que haces es evaluar diferentes vendors.
Primero evalúas cómo lo vas a comprar. Lo vas a comprar directo a través de un partner.
Evalúas diferentes vendors para ver cómo lo pagas. ¿Lo vas a pagar a un año, lo vas a pagar a tres, lo vas a pagar en el marketplace de un cloud, lo vas a pagar directamente con Brigger on Isis?
Todo esto tiene implicaciones en los costes. Vas a coger una máquina pequeña y vas a aumentar luego poco a poco, por ejemplo, un firewall pequeñito y luego según vayas necesitando, vas a comprar algo grande.
Es que es un mundo. Pero yo veo que muchas veces esto parece que es un tema de IT, no es un tema de finance.
[00:24:51] Speaker A: Yeah. Es un poco mezcla. No sé, qué pena.
[00:24:55] Speaker C: Yo ahí, perdonad que lo diga. Yo creo que ese es uno de los grandes problemas, que Finance no piensa que es un problema de ellos. Ÿousand. Es decir, yo sé el coste, pero vuelvo a decir lo mismo, el amortizado y tal lo tienen muy claro. Pero yo una de las cosas que creo que ahora es nosotros antes los proyectos, tú decías tengo 1 millón y me gasto 1 millón. Ahora vas a un proyecto y le dices es que no sé cuánto me voy a gastar. Claro, a Peina le dicen a ver, quieto un momento, explícame.
[00:25:22] Speaker A: Literal.
[00:25:23] Speaker C: Entonces, es que no lo sé, digo, porque me estás pidiendo que haga algo de que si vienen 10 personas más, si tengo más request y tal, ya no, no, no, no. Pues yo creo que esa es una de las cosas. Y en licencias es lo que pasa es cuántas personas tengo. Tiene una regla de tres. Es decir, yo tengo tanta máquina, tanto core, compro tantas. ¿Oye, pero tenemos entornos que no están apagados, qué tal? Porque el manager de las licencias solo cuentas los activos, dónde están. Entonces se puede hacer muchas cosas allí. Y con Alphon, pues imaginaros, en Santander, el licenciamiento que teníamos nos dio para Alphon en esta parte más en Assure de que estábamos, o sea, nos dio tiempo a escribir otro libro de las licencias.
[00:26:12] Speaker A: Vale, ya vamos por el quinto, creo, me parece. Por el sexto, no sé cuánto lleváis ya.
[00:26:16] Speaker D: No, pero es verdad, porque al final han terminado comprando licencias que no se usan o terminando a veces productos que la gente no está tan contenta de lo que está usando porque solamente unos participaron en la decisión. Y bueno, está el tema, como dijo Danik Alfie, uno no sabe lo que. A veces puede llegar a una ocasión que no sabe lo que está pagando o lo que va a pagar, lo que va a pasar.
[00:26:41] Speaker B: Entonces, sí, yo creo que además, yo creo que además el equipo financiero tiene que aprender. O sea, no vamos a enseñar ahora nada al equipo financiero, pero tiene que adaptarse a la flexibilidad en la realidad. Por ejemplo, nosotros estamos ahora en un programa de migración a cloud y tenemos que migrar, en mi empresa actual, bank, tenemos que migrar tropecientos países a cloud. A mí me piden que no piden, digamos, que nos metamos en budget. ¿Eso, cómo metes en budget una migración que ni siquiera te han metido a analizar lo que hay? No puedes. O sea, tienes que meter, televisar, hacer el business case y luego pedir en ese momento ese aumento de budget. Pero es que es que la naturaleza incluso en sí es flexible. Entonces tiene que cambiar cómo se. Esa parte de provisioning y de procurement y todo eso tiene que cambiar. Y las licencias que decía Dani también, pero en cualquier proyecto, en cualquier cosa, en que cada día. Es que mañana me dice negocio que tenemos que hacer una aplicación prioritaria o siete y de repente sale un pastizal en cosas cloud a lo mejor es eso y no, y está bien hecho porque una de las cosas es decir, oye, es que estoy pagando esto porque quiero. O sea, no estoy pagándolo porque esté poco eficiente, es que no estoy pagando porque quiero para llegar rápido a mi destino. ¿Quieres conseguir esta información o estos KPIs? Claro, lo pago con gusto. Es que eso también es otra cosa. ¿En la que parece que todo es reducir costes, no? ¿Hay veces que quiere expandarte a pensar también, me entendéis? Así que no pate, el tema de galletines es difícil, desde luego.
[00:28:08] Speaker C: ¿Si me permitís, ahí una de las cosas que estamos implantando nosotros, que ya lo teníamos también, es lo del ROI, es decir, qué aplicación, cuánto ROI nos va a dar, cuánto nos da ahora y cuánto nos va a dar el coste que lo vamos a implementar?
Porque hay aplicaciones, todas. No, no, esta aplicación es buenísima, esto es core para la empresa.
¿Vemos los accesos, dos personas, es el SEO y alguien más, y él dice, pero cuánto nos cuesta esto? $2 millones. ¿Pues muy bien, o sea, esto es eficiencia en el cloud, vale? Es los access. ¿Entonces eso sí que nos permite el cloud, o sea, nos permite esa flexibilidad de Oye, quieres ver esto? Lo levanto solo el día que lo vayas a ver. Es on demand. La licencia de los, en este caso, pues de los grandes visuales y tal, se ha reducido. Antes comprabas licencias para tener, ahora hay el, en la parte visual hay las licencias por uso también, es decir, por sesión que hayas abierto. No es lo mismo pagar como un máximo de x dinero, 1 rate por sesión de cero con algo, oye, si yo entro una vez al mes son cero 30. Pero antes se compraba la licencia, se tenía toda la infraestructura levantada. Entonces, todas estas cosas nos tienen que hacer, que han venido a cambiar el paradigma de todos, de todos financieros, ya también lo legal, porque hay muchos acuerdos comerciales, o sea, es un ecosistema desde el desarrollo hasta la publicación. ¿Pero yo para finalizar, hay que ser conscientes de, también hay un capítulo de que tiene que tener un business unit, tenemos que saber medir esto, cómo? ¿Cada cuánto es el coste medio de mi storage? ¿Algo muy sencillo, bueno, no es sencillo porque hay que hacer muchas cosas, pero tienes que saber si al siguiente mes te has desviado, cómo lo vas haciendo, por qué? Porque los proyectos pueden entrar, pero tienen que tener una justificación. Y ahí siempre lo decimos con alcohol, tiene que tener un ROI. ¿Es decir, me tienes que decir, si mi empresa ahora mismo le digo, gasto 10 millones de infraestructura, 1 facturación de 1000 millones, no se preocupe Dani, esta es la buena, vale? Pero claro, el problema es cuando hay aplicaciones que tienen altísimo coste y no tienen ese retorno a la inversión que estamos usando.
[00:30:31] Speaker B: Nosotros en nuestro mini framework Phinops teníamos una idea que estaba muy bien, que era, nosotros analizamos una infraestructura o una serie de aplicaciones en la nube y lo que hacemos es plantear diferentes planes. Teníamos quick wins, todo el mundo sabe lo que es un quick win, lo puedes hacer rápido, sin impacto prácticamente y consigues ahorritos rápidos. Genial.
Short Term Initiatives, que son cositas que puedes hacer y que llevan un cierto ahorro y que relativamente llevan poco esfuerzo. Y Long Term, imaginemos por Long Term, por ejemplo, contabilizar una solución, cositas pasando a ser vendes. Estamos hablando de cosas. Y a series. Todo esto son proyectos.
En Athylos Foundation hablan de mini business cases. ¿Para cada uno de estos proyectos nosotros usamos la idea de potencial savings, que es decir, cuántos ahorros voy a conseguir si aplico esto? Y si le añadimos la variable esfuerzo, aunque sea esfuerzo, una variable abstracta, un número del un al cinco, un número del un al 10, qué esfuerzo percibes que le puede costar esto el equipo de ingeniería con los potential savings y con este esfuerzo puedes ordenar. Claro, quick wins, esfuerzo cero, potencial savings, pocos. Pero es que con esfuerzo cero lo primero que hago. Entonces, eres capaz de ordenar tus iniciativas a ejecutar en syrups y ver las que más valor tienen para ti, las que haciendo menos consigues más. Esto es muy interesante y lo hacíamos así. Entonces, esta es una de las ideas que la priorización de las iniciativas Phinops es un tema muy interesante. Entonces, puede ser lo que decías tú, si el ROI de tirarte seis meses refactorizando una aplicación es brutal, adelante, pero tienes que haberte currado muy bien los números y en análisis.
[00:32:13] Speaker D: Bueno, creo que Víctor, llegamos al momento de las preguntas.
[00:32:16] Speaker A: Sí, sí, ha sido espectacular, la verdad. El tema del ROI es una locura, así que vamos a terminar con todavía más valor en el tema de las preguntitas. Sí, sí.
[00:32:26] Speaker D: Bueno, entonces llegamos al momento que al auxiliar de nosotros, a todas que vienen a nuestro programa, hacemos unas preguntas cortitas. Así que empecemos.
¿La primera es, bueno, si pudieran crear una herramienta de Things mágica, cuál sería?
[00:32:44] Speaker A: Mágica, mágica, sí. ¿O sea, que dijeras quiero tener x, cuál sería tu herramienta?
[00:32:52] Speaker C: Nosotros teníamos ya un simulador. No, eso no.
[00:32:56] Speaker B: Date por dónde vas. Yo tenería, por ejemplo, esta idea de no potencial savings, si la multiplicas a nuto ciencia ficción.
¿Es decir, cómo se verían mis costes si yo, imagínate un dashboard de evolución de costes en la nube, vale? Esto es lo que gasto por mes, va aumentando, va viviendo. ¿Y eres capaz de si aplico esto, cómo se ve mi gráfica? ¿Si aplico esto, cómo se ve mi gráfica? ¿Si aplico esto, cómo se ve mi gráfica? Ÿousand. Eso sí, si fuera de verdad, yo eso no firmo.
[00:33:26] Speaker C: Claro, nosotros ya por otra cosa empezamos ya. Estos simuladores los llamamos simuladores porque los equipos financieros de Santander necesitaba marcar una cosa muy importante, que son distintos escenarios, escenarios de expansión, de retrocesión. Y ellos ya más o menos les dimos, no está perfecta porque ya no sé cómo está, pero sí que les damos esa herramienta mágica de intentar predecir algo que a ellos les da mucho miedo, que es decir, oye, en el peor de los casos es honesto, en el mejor de los casos y tengo un milésimo noveno.
Pero eso, eso, cuidado porque lleva mucho dato, lleva mucha. No es lo mismo.
[00:34:10] Speaker B: Pero aquí tenemos la manita mágica, Denny, no te preocupes de eso, tiene que ser mágica.
[00:34:15] Speaker D: ¿Me hacía acordar, yo tenía una idea de que ŸOusand, como si pudieras hacer un TGP, da de lo que, de todo el todo tu operación cloud, agarras.
[00:34:24] Speaker B: Una arquitectura y la ponés así, cuánto sería el costo?
[00:34:28] Speaker D: ¿Eso sería bueno?
[00:34:30] Speaker B: Sí, sí, increíble.
Bueno, vamos a crear, vamos a ver.
[00:34:33] Speaker D: Cómo la creamos, a lo mejor vamos una vez con ellas y tomar fenómenos.
¿Bueno, la próxima pregunta es cuál es el mayor mal entendido sobre Finox?
[00:34:49] Speaker C: ¿Yo creo, desde mi punto de vista, creo que es que esto solo es del equipo de financieros y de desarrolladores, vale? Creo que FineUps es general a toda una compañía, desde el SEO hasta el último de los desarrolladores, legal, producto.
Entonces yo creo que eso es una de las cosas que yo sí creo que hay que trabajar más. Para eso también hemos creado este libro, para que no solo sea para financiero, es mucho también de gestión, hay mucho de Okrs, hay mucho de Cap, que no están relacionados con el desarrollo del software, pero que simplícitamente cuando creas un producto, yo creo que es eso, sale el lado friki, es decir, tener un framework único para controlarlos a todos. Es decir, como ha salido el poder del anillo, pues es esto. O sea, a mí lo que eso es una de las cosas que yo creo que deberíamos hacer participar más a la gente, que todavía esto, hay un vertical sliding todavía de, oye, esto es Finops y es solo, no, tiene que ser, tiene que ser transversal.
[00:36:04] Speaker B: Para mí la mayor diría que es que Phenops es reducción de costes, no es eso, es control, punto.
Aprende a control, sé capaz de controlar lo que dice Dani, totalmente de acuerdo. Parece que Phenops es un tema de IT, de arquitectura Cloud, del equipo Cloud Operations. No, no es así. Pero lo otro también es control, es sacarle el máximo partido a tu budget, no es reducirlo.
Reducirlo no resiste los milagros con la varita básica. Ojalá estuviéramos, pero es una de las cosas que parece que la gente no entiende. Yo no digo que muchos en mi empresa actúan, te vas a gastar una pasta yendo al Knop en la navidad, ahora controla nada, ya está.
[00:36:47] Speaker D: ¿Bueno, la última pregunta es cuál es la referencia de ustedes en este mundo?
[00:36:51] Speaker B: ¿Decimos, de personas, de qué?
[00:36:55] Speaker A: Y Alfonso, sí, sí, Alfonso, vale, no seas tan bueno.
[00:37:00] Speaker B: Es que no sé, yo tenemos una cosa en común Dani y yo, y ninguno de los dos nos consideramos, diría yo, perfiles Phoenix puramente. Nos encantan muchas cosas fuera de sol.
Entonces, creo que con eso, creo que por nuestro tipo de perfil tenemos muchísimos referentes. Yo, por ejemplo, desde que empecé a meterme un poco más la Fill of foundation, me parece increíble el trabajo que está haciendo. Y en la parte de optimización de Koster me parece el referente. ¿Claro, vamos, no hace star, como dicen otros, no? Que tenemos que un poco seguir todos y tener la cabeza. Pero yo tengo muchísimos referentes también de temas de infraestructura, como código de DevOps, scripts, no sé.
[00:37:43] Speaker C: Sí, yo sí también me permite Alfons.
¿Yo creo que Fine Ops es un framework muy, muy grande y es, necesitas acompasar muchas cosas y muy bien, como relojito suizo para esa contención, vale? ¿Referentes, leemos mucho, vale?
¿Entonces intentamos buscar, todos los días salen nuevas cosas y todos los artículos, pues, de todos los sitios con que nos traen, nos aporten valor, vale? Es decir, yo creo que esa sería nuestra primera intención, por lo menos creo.
[00:38:21] Speaker B: Yo diría que tanto el rol de Dani como el mío, los dos, a mí lo que me encanta de nuestro trabajo es que es un trabajo muy creativo. Entonces, lo que tenemos que hacer es mantenernos. ¿No es, desde luego, no es cada día hacer lo mismo como un mono, no es eso, no? ¿Vale? Eso creo que tenemos que mantenernos leyendo a todo esto referentes de muchas áreas porque eso nos va a inspirar a tener nuevas ideas y a darle un golpe de tuerca a diferentes cosas y aplicarlo nosotros en la realidad. Porque ese es otro de los puntos. Todo el mundo dice, las cosas son muy bonitas en una app t o en un tutorial de monta tu propio Kubernetes Cluster. ¿Vale? ¿No, cómo se enfrenta un Kubernetes Cluster en un entorno Enterprise Game? Eso es otra cosa. Entonces, yo creo que ese punto de la creatividad, dejar siempre coger todos tus referentes, meterlos en una coctelera y a ver qué sale de ahí.
[00:39:10] Speaker D: Zweitausendein, observan las chances de terminar las preguntas.
[00:39:17] Speaker A: La verdad es que ha estado genial hablar con vosotros, chicos. Hay mucho valor en el tema de libro, el tema del RoI creo que es muy, muy importante el tema de eso, de sacar el máximo valor al cloud y saber que te vas a gastar una pasta, que hay que tener controlado todos los datos y que hay que poner pues eso, guardarraíles, como dice Dani, de las cosas que vamos a hacer. Así que espero que la gente saca mucho valor. Yo desde luego sí. Así que chicos, muchas gracias por venir. Ha sido un placer y nada, un saludo y probablemente nos veamos otra vez.
[00:39:54] Speaker B: Muchísimas gracias, Víctor y Damier.
Un placer estar aquí con vosotros.
[00:40:01] Speaker C: Igual.
[00:40:02] Speaker A: Bueno, un saludo.
[00:40:04] Speaker D: Venga, un saludo.
