 Banco Galicia es uno de los principales bancos del sistema financiero argentino. Con más de 300 sucursales en el país, avanzadas plataformas de banca digital y banca móvil, ofrece un amplio rango de servicios financieros para más de 3 millones de clientes. Necesitábamos ser más ágiles para poder mejorar nuestra experiencia de cliente. La verdad que los clientes nos están demandando cada vez más. Nosotros entendimos que teníamos que trabajar de manera diferente, con una tecnología distinta que a la vez permita que fluya una cultura de empoderamiento y de agilidad. Y nosotros encontramos en Red Hat ese tipo de características y por eso los elegimos como socios. La iniciativa de la experiencia digital del Banco Galicia tuvo como objetivo migrar los canales transaccionales y de backend, que estaba en una plataforma legacy, a una plataforma en la nube completamente nativa y omnicanal. Es para ello que el Banco Galicia tomó la decisión de ir con soluciones open source y junto al conocimiento de nuestros técnicos y nuestros arquitectos, es que armamos en conjunto la plataforma OpenShift. En esta clase de proyectos, el protagonismo de las personas es fundamental. Es decir, un cambio de mentalidad en los talentos de la empresa que modifican su forma de actuar, dejan de trabajar en silos y adoptan un comportamiento mucho más colaborativo. Este fue realmente un desafío de personas, de cultura y eventualmente tecnológico. Un poco lo que nosotros buscábamos es refundar la forma de hacer las cosas en la empresa con una cultura más colaborativa y más ágil, de poder fallar y probar distintas cosas. Y la verdad es que encontramos en la cultura open source de Red Hat un excelente complemento para hacer que estas cosas pasen. Lo que se buscó fue lograr un cambio radical respecto del uso de la tecnología en la optimización de procesos, agilidad, reducción de costos y el impulso de nuevas unidades de negocio. El impacto más significativo lo tuvimos en términos de agilidad. Pasamos de hacer proyectos en años o meses a semanas. Para citar un ejemplo, logramos pasar de ideas a una producción controlada en menos de 12 semanas. Y esto, la verdad, fue un récord para el Banco. La nueva aplicación permite a los colaboradores recomendar la mejor combinación de productos para un cliente en particular, según sus necesidades, en apenas 10 minutos. La automatización te permite eliminar un montón de procesos manuales, que implican un mayor consumo de tiempo y de recursos. La agilidad en este camino es clave para la experiencia digital del cliente. Al crear una única plataforma omnicanal de PaKend, se logró una reducción del 25% en los costos de desarrollo y mantenimiento de la aplicación y un ahorro del 25% en el mantenimiento de nuevas funcionalidades orientadas al cliente. Las plataformas de contenedores de Red Hat no se limitan sólo a brindar mejoras de eficiencia, como por ejemplo la reducción de 2 semanas a 5 minutos en el tiempo de pasaje desde el código hasta la puesta en producción. También ofrecen una flexibilidad inigualable en el mercado porque permite mover diferentes cargas de trabajo a diferentes nubes. Esto significó para el banco un aumento del 40% en la disponibilidad de aplicaciones sin costos adicionales. Si bien muchas empresas atan las aplicaciones a proveedores de nubes particulares, nosotros lo que quisimos hacer es tomar una estrategia de flexibilidad. Entonces ahí donde encontramos que OpenShift nos permite tener esta flexibilidad y que por otro lado nos permite ser más eficientes en costos también. Tomando este camino prevemos que vamos a reducir hasta un 20% en licencias y hardware. El sistema de seguridad unificado propuesto por Red Hat provee al departamento de ciberseguridad un único punto de administración para la autentificación y autorización del consumidor. Esto permite al equipo de ciberseguridad reaccionar inmediatamente a episodios de fraude u otros incidentes. Al suspender la cuenta o revocar el acceso mientras el incidente es investigado. De este modo se mejora la seguridad y se reduce el estrés operativo. Los resultados del proyecto son alentadores. El Net Promoters Core ha mejorado. La participación de mercados de las plataformas digitales de Galicia ha crecido y el número de transacciones electrónicas aumentó significativamente. Las empresas del sector financiero están comenzando a comprender los beneficios de desarrollar una estrategia de transformación digital. Galicia ha sido uno de los pioneros en la Argentina. Desde Red Hat creemos que el Open Banking no solo permite ofrecer servicios por canales no tradicionales sino que además fomenta la disrupción tecnológica, promoviendo un modelo de liderazgo abierto y dándole a los colaboradores mucho protagonismo. Estamos convencidos de que este nuevo ecosistema innovador con una experiencia omnicanal mejorada nos está permitiendo acercarnos a los públicos más jóvenes y hacer de que sea más fácil la operación del día a día. Pero esto es solo el comienzo porque la verdad en un futuro cercano esperamos que el 100% de nuestras transacciones y operaciones y adquisición de nuevos productos se pueda hacer de manera completamente digital. Hola, buenas tardes a todos. Mi nombre es Gonzalo Gómez, soy arquitecto de solución en Banco Galicia y estoy acá con Adri Romero que como me gusta presentarlo es el mejor arquitecto de ops de los últimos 50 años más o menos. Tuvimos uno solo, así que es verdad. Así que bueno, el vídeo resume gran parte de lo que queremos contarles hoy. Vamos a contar nuestro último año y medio de historia en una hora y competimos fuertemente con el almorzo así que no sé si le pondremos onda pero vamos a intentar por lo menos ponerle ritmo. Vamos a arrancar con la agenda que tenemos estos cuatro temas importantes. El primero tiene que ver con lo que fue Gernis y transformación digital. Después vamos a ver un poco cómo escalamos esa agilidad hoy mismo al resto del banco y después vamos a centrarnos un poco en lo que es la plataforma Unicanal que es el proyecto más ambicioso que tenemos hoy al menos en la agerencia de arquitectura y después al final Adri les va a contar más de lleno bien todo lo que fue este año y medio desde que arrancamos con OpenShift. Todo el tiempo vamos a estar siendo viniendo con la cultura porque la cultura realmente es algo que atraviesa todo el proceso de transformación y que tiene que ver con el 90% básicamente de que esto sea un éxito o no por lo cual todo el tiempo vamos a estar mechando con ese aspecto. Perdón acá por la calidad de la imagen pero me pareció bastante bueno representar cómo trabajábamos antes en Galicia antes de empezar con esta transformación. Un poco era esto, proyecto de encascada de dos años donde se planificaba la setapa de análisis y diseño construcción que tampoco se cumplían a raja tabla donde tenías dos años construyendo un proyecto que el cliente todavía no había visto donde había muchas reuniones en distintas áreas, no había trabajo colaborativo todo retrasaba todo, mucha burocracia y después cuando llegabas a producción te terminaba explotando todo en la cara y realmente el cliente encima no había visto nada con lo cual el cliente en esos dos años había cambiado, el contexto había cambiado y realmente lo que se había ayudado al principio ya por ahí no servía y terminamos más o menos en esta imagen bastante conocida que el cliente no sabía lo que quería en realidad nosotros no sabíamos lo que quería el cliente porque no lo escuchábamos entonces un poco en enero de 2018 el banco decidió encarar en serio esta transformación que viene desde comité ejecutivo hacia el último desarrollador Vaquen para tratar de cambiar un poco esto y quizás también para no quedarnos afuera de mercado entonces en enero me acuerdo que nos juntaron en una sala los que habíamos elegido para este proceso y nos dijeron que teníamos la responsabilidad de cambiar la forma en que el banco iba a trabajar de acá el futuro vino el presidente y nos dijo van a poder innovar no van a tener que pedir permiso a nadie y van a poder materializar las ideas que les ocurran para el destino que nos habían elegido bien buenísimo entonces arrancamos con lo que es optimización de viajes que fue el primer equipo que se armó para esto y teníamos que transformar una experiencia completa de lo que era el proceso de vinculación de un cliente con el banco que era como el referal case que querían usar porque era el que más impacto tenía ahora que es un viaje para nosotros es un journey como le llamamos también internamente un viaje habla de un conjunto de interacciones relevante para el cliente con un fin y un inicio bien claro en nuestro caso fue un cliente que quiere vincularse al banco para abrir una cuenta o tener una tarjeta de crédito y el viaje arrancaba desde que el cliente se interesaba en una oferta en un canal digital o presencial hasta su primer uso de la tarjeta virtual básicamente lo que hicimos en 2 semanas con un poco lo que contaba el vídeo y lo que contaba Santi antes es un primer MVP donde transformamos un proceso que era demasiado engorroso donde el cliente tenía que ir a su cursal llenar mucho formulario en todo ese proceso esperaba 20 días hasta recibir el plástico teníamos mucho papel, es mucho gasto en papel y básicamente para resumir un poco las funcionalidades incorporamos que a través del DNI y sexo una consulta FIB pueda precargar todos los datos y asegurar la calidad incorporamos biometría para lo que es variación de identidad tuvimos la posibilidad de sacar la firma de papel por reemplazada por firma digital y con eso pasamos un proceso de media hora solamente 5 minutos que acá lo voy a mezclar un poco también con la cultura porque cuando empezamos a escalar esto en su momento la gente de sus cursores decía y ahora qué vamos a hacer con el tiempo que nos sobra vamos a perder el trabajo nos llevaba media hora, nos llevaba 4 minutos nos sobra la mitad del día también hay un proceso de gestión del cambio muy importante que es necesario para acompañar estos MVP que vienen a digitalizar estos procesos entonces un poco ahora cómo lo hicimos o cómo llegamos a ese MVP arruamos estos equipos multidisciplinarios donde había un Product1 y una lista de Product1 hirviendo negocio diseñador UXUI que era un rol que no existía en el banco en ese momento lo acompañamos por un Scrum Master que era el que nos facilitaba todas las ceremonias y nos ayudaba a incorporar Scrum en cada uno de estos equipos los desarrolladores vaquen, dos frontend empezamos a automatizar pruebas cosas que se hacía muy poco y por lugares separados en ese momento en el banco y el rol clave del DevOps que venía a unir tecnología o tecnología con desarrollo básicamente y lo teníamos en la mesa con lo cual ganábamos ya de entrada a mucha velocidad en algunos casos o en el primer caso usamos el proceso de Design Thinking que lo que buscaba era relevar con el cliente realmente qué necesitaba o sea comparado con el otro modelo empezamos a mirar al cliente siempre en el centro y empezara a construir a partir de lo que el cliente nos decía y lo que importaba acá era que hoy es Design Thinking pero mañana puede ser otra mejor y lo que importa de siempre es tener al cliente en el centro y apresar a construir a partir de ahí con esto lo que hacíamos era clasterizar los Insight armar los perfiles de esos clientes para los cuales íbamos a diseñar ese proceso y con eso lo que hacíamos era llevarlo para tener un consenso general y que todo el mundo pueda portar ideas nuevas a un taller de Visioning donde todas las ideas que habían sido relevadas y los Insight de esos clientes que habíamos estado estudiando se puede armar el camino ideal o el viaje ideal para este MVP de dos semanas que les mostré antes acá hay una diferencia como veníamos trabajando antes lo que sería la pirámide del estático y el rigido ante los cambios es ese proyecto encascada de dos años y cuando empezamos a trabajar con MVP lo que nos permite es citerar y revolucionando el producto entonces llegamos con el producto terminado y si a quien no le gustaba una vida a chance había que empezar todo de cero en este caso nosotros como teníamos un proceso que obviamente no era nada digital tuvimos mucho de resolver al principio fue construir algo que sea realmente viable para empezar a sumar a los canales y que a partir de ahí pudiera funcionar ese funcionario era para nosotros que este producto terminado con su punta a punta y que a la vez lo podamos rolar en los ocho canales que teníamos en ese momento y después se va a entrar en la parte de encantar que es la que por ahí estamos ahora después de un año y medio donde sí estamos haciendo cosas que por ahí generan alguna emoción más relevante y más de experiencia como resúmenos quedó básicamente esto cinco o seis pasos donde hay una oferta bien en mi canal donde bajamos esos tiempos de media hora a cuatro o seis minutos punta a punta eliminamos un montón de papel casi 2,5 toneladas por mes que es un montón de plata bajamos un montón de carga operativa en operaciones que lo que hacía antes era recibir una carpeta y cargar la mano y recién ahí empezaba a dispararse lo que era la venta y obviamente con esto que mostraba por ahí antes de Google y la localización de domicilio aseguramos mucha más calidad de datos y mejor aceptación en la entrega y al tener algo tan fácil después empezaron a abrir el juego para que otros canales quieran usar nuestra plataforma y la empezamos a distribuir a más de esos ocho canales que teníamos al inicio de la foto final y acá hay una pequeña prueba de lo que fue este escalamiento en VIP una vez que estamos asegurados que funciona que resuelve y empezamos a subir canales, volumen y distintas funcionalidades nuevas terminamos en lo que fue noviembre en este caso año pasado con siete mil ventas por día en todos esos canales con la misma solución acá una parte también interesante que también tiene que ver con la cultura transformamos bastante el modelo de operaciones el modelo de operaciones era un rol bastante automático en cuanto a carga de datos y nada más hoy operaciones pasó de 32 a 11 personas en lo que era este proceso nada más y dejaron de cargar datos a tener un control mucho más relevante donde hacen control de fraude hacen aseguramiento de los datos de delivery controlan la calidad de datos y operan el producto con el producto de alguna manera todo el tiempo estamos dando feedback para decirle Che en la sucursión está pasando esto fíjate de priorizarlo para el próximo sprint porque es importante y en cuanto a números puede parecer que esas personas se quedaron sin trabajo el contrario fueron a otras partes de la organización donde fueron formadas y capacitadas para tener una oportunidad de desempeñarse en otro rol muy distinto al que estaban acostumbrados y la verdad que funcionó muy bien lo que se hizo fue hacer más eficiente un área y aprovechar el potencial de esas personas que se quedó en otros puestos de la organización que sigue creciendo ventajas y desafíos de esta nueva forma de trabajar el Empowerment es uno de ellos cambia radicalmente el día a día cuando uno puede decidir qué quiere hacer y no hay alguien que se lo diga no está bueno que siempre te diga no que tenéis que hacer y a esos por ahí estábamos acostumbrados en ese momento después el desafío con el Empowerment es la apropiación de ese Empowerment tenemos mucha gente que no quiere liste en todas las cosas que tiene que hacer de un día al otro, sobre todo muchos de los desarrolladores entonces con lo cual el desafío es también decir tomar decisiones y probarlas y equivocarte rápido para capitalizar esa experiencia y aprender, digamos bueno, rapidez en la toma de decisiones aprendizaje de otros roles teníamos un equipo muy multidisciplinario con lo cual después de un año y medio tenemos al Product Owner que entiende perfectamente la tecnología y a los desarrolladores que están haciendo con la práctica de UX con lo cual el equipo entero responde de acuerdo a la necesidad del momento y todos aprenden de todos flexibilidad de la área también fue una ventaja porque al trabajar por objetivos empezamos a tener esa ventaja de por ahí no cumplir un horario rascatable pero también el desafío está que como siempre pasa algunos se pasa de mambo y por ahí en algún momento llegaban a las tres a tarde entonces siempre hay alguien que dice bueno, esto le está haciendo el control el equilibrio obviamente eso impactaba en la motivación del equipo y si este equipo está motivado se obtiene mejores resultados se genera un poco este espacio colaborativo donde el que sabe algo más que el otro lo está ayudando porque el objetivo es del equipo o sea, antes trabajábamos muy separados en áreas con lo cual eso nos cambió mucho y creo que no me quedó ninguna ¿Cuál era nuestra estaca de tecnología al inicio? bueno, obviamente como decía Santi y el vídeo OpenShift es una parte fundamental de nuestra transformación porque es el que nos dio la base para gilizar todo el primer proceso del MVP nosotros teníamos en el banco en ese momento para tener un servidor tres semanas para no poner un máximo y lo que hacía eso era que cuando elegieron en dos semanas tiene que tener el MVP en producción y ya tengo tres semanas hasta tener el primer servidor en desarrollo, va a ser imposible con lo cual como teníamos libertad de tecnología y pudimos abrir el juego a nuevas cosas empezamos a probar OpenShift y terminó siendo parte fundamental hasta hoy todavía y lo va a seguir siendo acá un dato de color en su momento como estábamos entusiasmados con cosas nuevas lo primero que hicimos fue montar OpenShift en Azure y bueno, después con un poco de racionalidad terminamos diciendo como el banco todavía no tenía su estrategia clau decidida y no queríamos atarnos a ningún proveedor en particular a KS en el otro caso decidimos tener el script de OpenShift nuestro para después poder usarlo en cualquier cloud cuando el banco decía bien el norte del cual iba a ir creo que después de un tiempo eso nos salió bien porque hoy las nubes también evolucionaron y están ofreciendo OpenShift como servicio en todos los casos con lo cual es mucho más fácil tener lo que ya tenemos armado llevarlo a cualquier cloud bueno, nuestra capa de microservicio que también es algo nuevo para el banco empezó con Netcore, con Spring algunas cosas con Node y después cuando empezamos a sumar nuevos journeys o nuevos viajes con estos equipos y no teníamos mucho tiempo de ponernos estrictos en la metrología empezamos a sumar Python bueno, creo que alguna masa ahí por ahí dando vuelta que obviamente Adri y equipo no le gustaba mucho porque cada tecnología nueva implicaba un nuevo pipeline y un nuevo pipeline para evolucionar, para mantener, para aprender con lo cual ahora ya estamos más la mayoría lo tenemos en Spring y Net tratamos de no sumar nuevas tecnologías en ese momento preferíamos contratar el talento por lo que sea la herramienta, digamos y creíamos que podíamos tener esa flexibilidad fue un poliamor de tecnologías en el momento tal cual y después lo que era la parte de Frontend de estos pequeños viajes era mayormente en React con su BFF en Node.js que es lo que más valoramos en todo este tiempo por poner 5 porque no nos entraba más y si va a ser muy largo el autoprovisionamiento, la infraestructura nuevamente está mezclado con lo cultural que les decía antes esto nos dio mucha velocidad y mucha flexibilidad también para todo lo que es el escalado de demanda de cada aplicación, que es lo que está en el cuarto punto la eliminación cultural de mi máquina funciona esto fue un cambio tremendo nos sigue pasando hoy todavía que tenemos muchos devs pero mi máquina me anda tenés que programar el estándar y tiene que andar en OpenShift eso eliminó un montón de problemas que por ahí había antes cuando desarrollo pasado un pedido de despliegue a tecnología y tecnología operaba una aplicación que no conocía y el desarrollarle pedía a tecnología que le resuelve algo que vaya a saber qué era entonces ahí la cultura DevOps y los mismos DevOps ayudando a respetar los estándares eso nos terminó dando mucha más velocidad en todo lo que era la construcción de desarrollo automatización es otra de las ventajas cuando incorporas el mindset de automatización que es automatizar todo y eso también empieza a generar algún miedo y vuelvo a la cultura con voy a perder el trabajo si vos me automatizas eso qué hago yo a mañana y bueno nada también es un desafío enorme convencer a la gente de que la automatización lo que va a hacer es liberarle el tiempo para poder hacer después otras cosas esto históricamente desde la revolución industrial para acá por lo menos cualquier automatización o mejora de las herramientas lo que terminó abriendo es una multiplicación de nuevas especialidades con lo cual se generó mucho más trabajo que el que se eliminó entonces poder tener ese mindset de automatización y de reinventarse y poder probar cosas nuevas para aprender cosas nuevas también a las personas las motiva para seguir creciendo y nunca dejar de aprender y bueno otra cosa también clave que al menos a mi me gusta mucho es lo que es Blue Green o Heavy Testing de cada versión nueva de microservicio que también es un tema muy cultural todo el tiempo le estamos diciendo de los equipos de desarrollo digo chicos tenemos la posibilidad de hacer un Blue Green empezar a esparramar tráfico a poco y subiendo el tráfico por cada funcionalidad bajando el impacto de incidentes en producción y no lo usan está todo listo y no lo usan de repente tengo un trascón que explotó algo no, bueno eso también es recontra cultura de poder generar ese cambio y esa incorporación de la tecnología o también otra cosa que nos pasa mucho es tienen el sprint de dos semanas o tenemos el sprint de dos semanas y el lunes primero ya termina en un vago o una funcional nueva y se espera hasta el final del sprint para pasar la producción tenemos una herramienta que con StarPipeline podemos llegar en 10 minutos a producción con todos los tests y queda colgado dos semanas sin aportar valor entonces también eso es un tema donde tratamos de estar encima para generar ese cambio y sobre todo los nuevos que por ahí se suman agilidad escala, acá también nos toca dentro de estos pilares de transformación en la parte de metología y cultura y talento que pasaba, empezamos a tener estos equipos desparramados por todos lados y necesitábamos darle de alguna manera un marco orgánico para poder escalar para que no sea un descontrol porque sino cada uno iba a decidir cómo era la agilidad para ese equipo o cómo desarrollar aplicaciones en OpenGIS para ese equipo entonces teníamos este mundo donde teníamos los equipos ágiles que en ese momento a fin de año eran 5 o 6 por lo que era viaje de cliente había algunos de escuade de analytics o de datos y teníamos operaciones ya dando feedback y alimentando el backlog del product owner y a los canales recibiendo MVPs con nuevos productos y donde era clave que culturalmente también tengan ese mindset de beta continuo y que se sientan protagonistas de alguna manera de esta construcción porque de alguna manera con el fica de ellos de lo que les íbamos lanzando a la red teníamos que seguir mejorando el producto en las células ágiles entonces en algún momento teníamos esto que era un lío bárbaro porque ya cualquiera hacía cualquier cosa todo el mundo se decía que era product owner sin saber qué era teníamos como muchas estas células o urbujas por todos lados parramadas ahí donde tomamos la decisión de armar un equipo que le llamamos el COBE que era el centro de excelencia de agilidad para escalar esto de manera orgánica al resto del banco entonces era la idea era un poco formar a estos Scrammasters que por ahí no teníamos tantos a los UX, bajar un alineamiento de prácticas comunes entre todos cómo íbamos a deployar en OpenGL cómo íbamos a llegar a producción cuál iba a ser nuestro modelo de despliegue bueno con un montón de cosas que entraron dentro de este marco de agilidad escala a esos equipos que veníamos multiplicando a meterlos en lo que llamamos tribus no sé si alguien conoce bien el modelo de Spotify a ver levanten a mano quién conoce el modelo de Spotify bueno nuestro modelo no es el de Spotify pero más o menos tiende a hacerlo siempre en algunos lugares escuchamos que ya no copies Spotify porque no sos Spotify entonces lo que tratamos a hacer es algo que realmente sigue esa línea pero que se adapte a la altura que tenemos en este momento en Galicia lo que empezamos a hacer es definir dos tribus para también en modo MVP aprender de lo que vaya pasando en ellas rompimos de alguna manera bruscamente productos segmentos en un día y armamos todo lo que era un canal digital en lo que era una tribu de producto y dejamos de hablar de canales en el banco a partir de esto empezamos a hablar de productos hay una escuadra de cuentas que mira cuentas en todos los canales antes teníamos el área de sucursales que miraba cuentas, el área de online banking que miraba cuentas eso fue un cambio bastante grande que mueve también, que moviliza culturalmente hoy tenemos dos una de daily banking y otra de cobros y pagos y estamos aprendiendo para después seguir escalando el mismo modelo al resto del banco y abajo tenemos lo que llamamos centro de expertiz o chapter que ahí tenemos cyber seguridad las prácticas de diseño el sistema de Galicia UI visuales que lo que hacen es tener también una mirada cross y de coherencia en lo que es toda la organización y la que está ahí en el medio que es la que voy a hablar en el próximo paso tiene que ver con las tribu que le llamamos habilitadoras porque llega un momento que lo que son las tribu de producto se quedan ya sin cosas para hacer si no acompañan las capacidades de atrás todo lo que es nuestro backend hoy tienen aplicaciones heredadas donde el primer día armamos estas tribu pero llega un momento que cuando quieran hacer cosas nuevas o escalar o modificar lo que existe van a citar de que las tribu habilitadoras o los backend de canales evolucionen más rápido y ese es nuestro proyecto de plataforma omnicanal no me estaría pasando ah, perdón perdón, para mí un poco como les comentaba así teníamos lo que era online banking en su momento aplicaciones 100% monolíticas donde para hacer un despliegue había que mínimamente tres semanas de regresión por más que hagas un mínimo cambio para asegurar que no rompas nada del canal teníamos distintas aplicaciones de negocios para ramadas algunas en net otras en visual6 bueno había un poco de todo y no teníamos algo que sea realmente omnicanal teníamos muchos ejemplos donde los saldos de las tarjetas en online banking se ven de una manera y en la app se ven de otra porque consumen distintos servicios backend es el proyecto de plataforma omnicanal lo que viene a hacer es justamente reemplazar eso para que no pase esto con eso estamos trabajando hace seis meses bien fuerte y lo que buscamos es tener una arquitectura de este tipo hace un año en realidad que veníamos trabajando pero hace seis meses estamos haciendo fuerte estas tribus están en su squad teniendo todas esas SPA en react con lo cual desarmamos el monolito de online banking para tenerlos orientado a producto en las SPA son las single page application que están independientes de de cada célula estamos formando la capa de appies ya hoy tenemos 250 microservicios solamente de lo que es el back de canales después en openshift hay muchos más en el resto del banco estamos tratando de terminarla a dejar full production tri-scale y después estamos usando mucho lo que es fuse para la conexión con los legacy distintos y ahí fuso lo que nos viene a hacer es ese mapper bastante fácil para el día mañana cuando esos corso empiecen a migrar a la tecnología nueva que la API de negocio no tenga impacto y que solamente cambiemos el backend obviamente todo esto corre sobre openshift alrededor de todo esto hay un mundo entero de lo que es ICB que adri les va a contar así que bueno hasta ahí llegó mi parte lo dejo adri con la suya gracias, yo soy adri asecas yo soy Roberto, digo Santiago que estaba por ahí y bueno todo lo que nos contó gonsa está realmente orientado a esta nueva metodología de trabajo ágil, muy dinámica y como eso impactó dentro del área de sistemas realmente cuando empezamos a trabajar con las células y empezamos a recibir todos estos requerimientos nos dimos cuenta que para poder estar a la altura de la agilidad de estas células teníamos que hacer un cambio realmente metodológico, sino también de herramientas para que sea una idea una célula desarrolla muchas veces entre 5 o 10 micro servicios por día, los cuales tienen que estar reployados en distintos ambientes incluyendo producción y cuando las células llegaban con estos requerimientos al área de sistemas se chocaban un poco con la realidad de la metodología que utilizamos en ese momento y realmente nos veían un poco así que contaba gonsa de que ya de por sí teníamos un procedimiento que tardaba semanas para dar un poco de provisioning de un servidor, de una plataforma base como sería un application server o un web server y esto llevaba a que la célula ya de por sí se atrasara en su agilidad las células como saben manejan este concepto de MVP de minimum variable product y cuando venían a plantearnos los requerimientos que necesitaban para poder llegar a ese MVP también nos planteaban el concepto de MVP casi como chiste diciéndonos un minimum variable bureaucracy porque realmente los procedimientos que teníamos para todo lo que era el provisioning de los ambientes eran muy largos y muchas veces burocráticos y estos son algunos de los desafíos más grandes que teníamos de infraestructura muy complejos involucrando distintos silos desde el silo de servidores hasta el silo de networking de plataforma y eso realmente alargaba mucho los tiempos después todo un número muy grande de estos short lived environments que son estos ambientes de muy corta vida que era muy difícil también determinar cuando se dejaban de usar o no para poder reciclar esos recursos bueno todo lo que era la arquestración de despliegue se manejaba a través de un grupo de implementaciones el cual terminaba haciendo un cuello de botella importante causando muchas veces down time en los despliegue porque el equipo de implementaciones realmente no sabía exactamente cómo hacer la automatización de un despliegue en producción no sabía cuál eran las características específicas de lo que se iba a deployar en un ambiente bueno todo lo que era configuración de ambiente fragmentados cómo asegurar la igualdad de todos los ambientes y todos los servidores y todos los componentes que uno tiene en un ecosistema tiempos de feedback entre desarrolladores y administradores de las plataformas también muy largos desde que algo se deploya en producción hasta que llega y realmente se valida que no tiene ningún back vuelve al equipo de implementaciones para poder hacer un rollback realmente eran a veces días conviviendo con bugs en producción y finalmente bueno el esquema tradicional de silos en el cual cada uno hace su parte el equipo de servidores tiene su tiempo para entregar un servidor el equipo de redes su tiempo para entregar una URL virtualizada el equipo de plataformas tiene su tiempo para instalar un application server o un web server y todo esto realmente cuando hablábamos con las células era chocarse contra una pared y realmente era impensado un poco desde el banco llegar a una arquitectura que pueda estar al ritmo de una célula por eso la decisión más sabia fue realmente crear una arquitectura como servicio crear un PAS obviamente la decisión fue ir por OpenShift porque bueno como saben nos da la agilidad de Docker donde uno realmente puede crear estas aplicaciones en segundos a partir de una imagen la orquestación de Kubernetes para poder orquestar toda esa cantidad de contenedores y todas las herramientas que OpenShift y la implementación de Kubernetes nos da y así fue que creamos esta plataforma como servicio con el horizonte de que cada squad puede autogestionar sus recursos de manera automatizada y al mismo tiempo con los estándares definidos teníamos la herramienta que nos iba a dar la agilidad elegimos el stack de herramientas que nos daba OpenShift y este fue un valor realmente muy grande que nos ayudó a poder absorber toda la nueva metodología y todo este nuevo paradigma de contenedores ¿Por qué? porque OpenShift nos da todas las herramientas para poder crear una cadena de SISD realmente casi out of the box con un playbook de Ansible no puede crear todo su stack de herramientas de SISD utilizamos Jenkins utilizamos un Git interno utilizamos un RQ para hacernos un ADC de código el Nexus como el repositorio de los artefactos empezamos a sumar distintas herramientas como Salenium para poder hacer nuestras pruebas automatizadas funcionales dentro del mismo PAS los contenedores y las imágenes Builders que trae OpenShift por default que de vuelta fue un cambio radical y si bien tuvimos esta jungla de tecnologías por la cantidad de desarrollos y cantidad de desarrolladores que absorbimos en las células fue muy fácil poder contenerizar todos esos microservicios y poder salir del meanda de mi máquina con las imágenes Builders de OpenShift tener una registry propia dentro para poder gestionar todas esas imágenes todo el stack de métricas de alarming, de monitoreo que trae OpenShift que fueron todas soluciones que si las hubiésemos tenido que pensar de cero hubiese sido un proyecto gigantesco pero con OpenShift realmente pudimos hacer una plataforma como servicio casi AuroDeVox con todo lo que nos traía y después fuimos poniendo más y más herramientas para una infraestructura en común como es Datagrid, como es AMQ para publicar todas las APIs que íbamos creando y que iban creando y gobernarlas dentro del PAS y todo esto está montado sobre máquinas virtuales de bienware cuando teníamos todas las herramientas cuando teníamos la agilidad de poder crear esto un poco como mostraba Gonzá se volvió todo un poco un caos porque todas las células tenían el acceso a poder crear y poder desarrollar sus ambientes entonces decidimos que necesitábamos un equipo de DevOps que fue el mejor de los últimos 50 años porque era el único que teníamos así que esa era el chiste que le decíamos siempre y como saben es un poco difícil encontrar este perfil en el mercado realmente encontrar un perfil que entienda tanto desarrollo del ciclo de vida de un aplicativo como de operaciones infraestructura pero bueno lo logramos formar que no sé si se ve acá porque está un poquito pequeño pero nos reunimos con todas las áreas del banco desde auditoría hasta compliance para poder automatizar de lleno y que la célula sea 100% autogestionable y puede hacer sus pasajes en todos los ambientes obviamente con el estándar que nosotros definimos que definió el equipo de DevOps y que fue bajado por el departamento de auditoría y de compliance entonces a través de todo este desarrollo que hicieron los DevOps 100% autogestionable puede no solamente crear sus aplicaciones sino hacer los pasajes al 100% y un poco para mostrarles lo que es el developer experience que creamos en 3 simples pasos una célula, un desarrollador de una célula puede crear eligiendo el framework que va a utilizar todos los objetos que necesita dentro de OpenShift utilizando también un arquetipo para tener un estándar sobre la utilización del framework y a través de templates que fuimos creando también en OpenShift estos desarrolladores crean todo su stack de aplicaciones dentro de su name space y para mostrarles un poco la arquitectura actual y cuánto son la cantidad de proyectos y células que tenemos actualmente como decía Gonzá se empezó con un grupo de 5 células pero hoy día hay 32 en producción lo cual nos empezó a agrandar obviamente todos los recursos tenemos 5 clusters, el laboratorio desarrollo integración producción en DMZ tenemos 23 nodos por cada uno de esos clusters los cuales tienen 8 cores y 32 GB de RAM mostrarles acá un poquito lo que es un screenshot de uno de los clusters es el cláster de desarrollo en esta semana cuenta con 868 pods tiene 180 cores en total y 640 GB de RAM hay que multiplicar esto por 5 por los 5 clusters que tenemos lo que nos llevó a tener un monstruo bastante grande y como soportábamos toda la cara y como velábamos de que todos estos pods realmente estén available para todas las células y cumplan con todos los estándares tuvimos que crear un equipo que realmente vele por la escalabilidad y el reliability del cláster que es el equipo de SRE los DevOps veían el ciclo de vida completo aplicativo pero no podían ver la infraestructura y este equipo lo creamos pensando en la automatización y la infraestructura como código para poder escalar el cláster de manera automatizada tener observabilidad del cláster empezamos a jugar con calles engineering romper un nodo, ver cómo nos recuperábamos ver hacia dónde migrábamos esos pods y inmutabilidad y resiliencia también automatizada para que el cláster siempre permanezca de la misma manera bueno, esto es un poco de lo que hablaba Gonzá esta nueva cultura de trabajo como estos tres equipos empezaron a obtener feedback entre sí como las células pasaban requerimientos a los DevOps los DevOps, requerimientos a infraestructuras y eso realmente fue formando una cultura de trabajo donde todos estamos interconectados y todos sabemos hacia dónde vamos y en una misma página hasta acá si lo vemos realmente parece una historia muy sencilla creamos grupos creamos infraestructura salió todo bien y realmente no fue 100% así tuvimos un montón de lecciones aprendidas creo que se dice ahora cuando metí la pata hasta el fondo tuvimos muchas les quería contar un poquito algunas porque realmente fue un aprendizaje muy grande, tuvimos mucho acompañamiento de Red Hat pero realmente fue aprender mucho esto que contaba un poco Gonzá también de abriernos a muchas tecnologías y tener diferentes tipos de integraciones y contarles tres que fueron pains muy grandes que tuvimos el primero fue un sizing de networking que no fue apropiado cuando creamos los primeros clusters de OpenShift nos reunimos con el equipo de networking y una de las principales cosas que uno tiene que definir cuando va a crear su cluster es el rango de IPS que va a utilizar dentro del cluster para todos los bots que va a crear ese rango de IPS se define por CDR, un barra 24, un barra 20, lo que uno decida que va a crecer el cluster esas IPS las teníamos que que separar de la LAN nuestra para que solamente sea utilizada dentro del cluster de OpenShift nos juntamos con el equipo de networking planteamos tener un barrio de 16 que son un 65.000 IPS nos dijeron que era como una locura que nunca lo íbamos a usar que lo bajemos un barra 20 4.000 IPS cada nodo de OpenShift por default, de Kubernetes realmente por default un máximo de 250 bots es lo que se recomienda 250 nos da 16 nodos utilizamos 3 para lo que son la administración de los masters 3 para lo que son la infraestructura nos quedaban 10 nos aplicativos de computing y más de ahí no pudimos crecer básicamente en 3 meses 4 nos comimos los recursos del cluster empezamos a tener problemas de generación de POT porque ya no teníamos espacio para nada fue una buena elección aprendida de la infraestructura como código que pudimos levantar otro cluster haciendo ese cambio de networking y pudimos pasar y con toda la implementación que los DevOps habían creado poder migrar ese cluster en un día tenerlo listo y haber recreado todos los pilons de las aplicaciones en otro cluster después cientos de pilons ese fue otro pain muy importante que hace relativamente poco que lo pudimos llegar a estandarizar cuando empezó toda la iniciativa y teníamos tantos tipos de tecnologías, fue muy difícil para los DevOps poder centralizar todo en un solo shanking file que realmente pueda darle toda la automatización a todos los desarrollos entonces empezaron a crear distintos tipos de shanking files distintos tipos de pilons que si bien hacían los mismos pasos con pilar, analizar código autorizaciones estaban atados a cada uno de los desarrollos de esos microservicios que se habían creado esto causó que en un momento tengamos 250 shanking files totalmente inmantenible el DevOps o los DevOps que teníamos en ese momento estaban sobrepasados ya algunos de los pilons lo tenían que llamar tenían que estar todo el tiempo tocando y monitoreando estos archivos lo que terminamos haciendo después de un desarrollo importante y después de muchas deliberaciones dentro del equipo fue centralizar todo en un solo archivo de pipeline el cual se utiliza a través de todas las aplicaciones básicamente cada DevOps nuevo en un proyecto era un pipeline distinto por las cinco tecnologías que usábamos, con lo cual era inmanejable porque cada una compila diferente cada una se analiza diferente cada una tiene su propia característica y eso fue algo que nos llevó mucho tiempo y fue un camino largo también que bueno lo pudimos sobrepasar y al final también contarles un poco sobre un problema que tuvimos sobre el file system que utilizamos de vuelta cuando hicimos la primera implementación de OpenShift que se utilizaba con un NFS como sistema de file descentralizado si bien Redcat tiene un cartel bastante grande que dice no utilices NFS en producción porque puede causarte problemas nos esquipiamos ese warning y lo usamos igual y nos trajo problemas de Ayo nos trajo problemas de no poder limitar la cantidad de espacio de los volúmenes persistentes que íbamos creando ahí bueno todo lo que era la automatización del pedido de esos volúmenes persistentes tenía que ser scriptiado, los DevOps tenían más sobrecarga de trabajo fue todo un problema finalmente fuimos a una solución más orientada contenedor y si para Coornet que es OpenShift Container Storage que es Glaster básicamente y lo pudimos resolver cambió muchísimo después de Glaster cambió todo para estar bastante bien si nos resolvió mucho la vida pero bueno así como esto tuvimos 10, 15 issues importantes más que fue un aprendizaje y fuimos viendo también los skills que necesitábamos para cada uno de los equipos que íbamos creando para los DevOps para el SRE y mismo para las células que se fueron educando un poco en su desarrollo y dejar un poco lo que contaba Gonzá de una máquina que ya era palabra prohibida en el piso y poder desarrollar para los contenedores después otra cosa importante que fue un cambio y un aprendizaje teníamos cada DevOps por célula era el modelo que planteamos al principio y eso además de que en una dependencia de todos los desarrolladores a no usar la infraestructura y mantener la propia hasta llegar a producción había una dependencia ya casi de Ticketing con el DevOps que estaba en la mesa y lo que hicimos fue separar los DevOps de las células ágiles los pusimos a un costado como un círculo de servicio donde se potenciaron mucho más y los desarrolladores empezaron a lo que podían hacer ellos realmente hacerlo y usar al DevOps cuando realmente se trabajan con algún problema y además que están carísimos en el mercado de los DevOps y era fortuna están sobrevaluados no sé bueno también era mostrarles un poco con esto que si bien la metodología es una parte muy importante también las herramientas lo son sin las herramientas ágiles es imposible lograr la agilidad que pide una célula y sin la agilidad de la metodología también nos volvemos otra vez los siglos como decía Gonzá donde es un sistema de Ticketing y es un pedido era mostrarles un poco como realmente nosotros adoptamos eso desde la parte de herramientas con Red Hat y la parte metodológica con la agilidad esperemos que le haya servido cualquier consulta bienvenido