 Bueno, antes que nada, buenas tardes. Gracias por estar con nosotros. Muchas gracias a Red Hat por permitirnos dar esta presentación. Veo que todavía sigue mucha gente acompañándonos. Así que qué bueno que se quedaron, porque de acá esperamos que se lleven algunas lecciones de lo que fue nuestro camino de adopción de la plataforma durante lo que va de todo este tiempo. Vamos a hablar un poquito de lo que es la transformación digital. Y, bueno, mi nombre es Pedro Cabello Salazar. Pertenezco al Grupo de Gerencia de Arquitectura del Banco Hipotecario. Bueno, nosotros, esta es la parte institucional del banco donde quien no conoce el Banco Hipotecario ha estado siempre presente en todas las familias y no es que en la gran mayoría de las familias desde hace mucho tiempo con créditos hipotecarios y de alguna manera ayudando a toda la gente a poder obtener su casa y poder hacer remodelaciones también de sus hogares. En los últimos años se ha consolidado como una banca universal con el objetivo de brindar soluciones integrales en materia de crédito, ahorro e inversión orientadas a familias y a empresas. El Banco Hipotecario ha otorgado a lo largo de toda su historia, a lo largo de los 133 años que lleva de historia aproximadamente 1,8 millones de créditos hipotecarios. Somos más de 1.800 empleados los que trabajamos dentro de esta institución. Es una industrial también terregulada como todas las entidades financieras y desde el 2017 el Banco está invirtiendo fuertemente en lo que es su transformación digital. Cuando hace dos años aproximadamente se nos planteó un desafío al tener algunos problemas con algunas de nuestras plataformas, sobre todo con una plataforma de integraciones con nuestro middleware que le daba toda la capa de integraciones a todos nuestros front-end y backend, teníamos serios problemas porque era una plataforma que estaba establecida desde hace algún tiempo aproximadamente más de 10 años y se nos estaba quedando fuera de soporte. El mantenimiento cada vez era un poquito más complejo, entonces se nos empezó a plantear un reto para poder apalancar lo que el Banco estaba transitando, lo que es su transformación digital. Lo que se nos pedía era poder mitigar los riesgos de infraestructura y de las aplicaciones por la ausolescencia de nuestra plataforma de integraciones. No solamente teníamos ese problema, después de algún tiempo se intentó subir otra plataforma de integraciones dentro del banco, lo cual tampoco fue a un buen éxito. Entonces el negocio nos pedía mucho esto para poder tener mayor disponibilidad de nuestros canales. La arquitectura que teníamos hace dos años era un tanto compleja donde teníamos, como lo han comentado ya varios de nuestros presentadores acá, aplicaciones monolíticas que en ocasiones llegaban directamente hasta los vaquens sin pasar por nuestra capa de integraciones. Así que lo que teníamos que hacer era aprovechar los recursos que teníamos de una manera más óptima, se nos pedía automatizar para ganar en velocidad y tratar de adoptar herramientas innovadoras y colaborativas. Hoy en el banco tenemos conectadas, desde entonces también desde hace dos años tenemos más de 30 aplicaciones que utilizan nuestra plataforma de integraciones que transitaban por nuestra vieja capa de integraciones, el cual era un producto que ya poco a poco se estaba discontinuando y transitamos alrededor de 5 millones de operaciones diarias, de transacciones diarias. Desde hace dos años con la llegada de una nueva jefatura al área de sistemas dentro del banco, este cambio y estos retos se le plantearon y por fortuna con la llegada de nuestra siello Julieta Alvala, empezamos a pensar cómo poder apalancar todos estos retos y hacer de alguna manera llevarlos y que el negocio no se preocupara ya de estos inconvenientes. Bueno, como comentaba, nosotros todavía teníamos aplicaciones que funcionaban como monolitos, lo que se nos pedía era empezar a pensar en una tendencia más digital donde pudiéramos transformar todo lo que teníamos de nuestra arquitectura, como lo mostraron en algunas diapositivas de Spagetti, donde todo se conectaba con todo y donde había pocas regulaciones para poder adoptar ciertos patrones y el trabajo empezamos a trabajar para poder empezar a pensar en una plataforma que nos brindará este tipo de soluciones, pensando siempre en microservicios y en APIs, ¿no? ¿Por qué? Porque era lo que habíamos visto desde hace un tiempo la tendencia y teníamos que ir hacia donde la mayoría de las personas estaba pensando y fijándose, ¿no? Estábamos viendo que la arquitectura de microservicios se sostenta en transformar grandes funcionalidades en pequeñas aplicaciones, cada una con un objetivo muy particular de solución para resolver un problema muy puntual y tener diferentes piezas que podamos manejar y orquestar de tal forma que nos puedan resolver esos grandes servicios que los teníamos montados dentro de un solo flujo. Bueno, la solución, ¿por qué Red Hat? Bueno, es tecnología open source, lo cual nos apalancaba para poder brindarle el negocio de cosas innovadoras, nuevas maneras de pensar de cómo solucionar las cosas, tiene una plataforma de autoaprovisionamiento, nos garantiza agilidad, velocidad, maneja soporte con recursos locales, la solución que tiene es una plataforma como servicio, la cual es escalable y lo que nos permitía también es poder pensar en tener una nube híbrida dentro de lo que es nuestro site y poder ya empezar a pensar cómo podíamos en un futuro apalancar todo esto para llevar todos nuestros microservicios en el momento en el que se aperture el poder migrarlos a cualquier tipo de nube. Bueno, todo lo que es nuestros parnes que nos acompañaron durante todo el proceso de adopción de esta plataforma nos guiaron y nos acompañaron durante todo este tiempo para poder garantizar el éxito de proyecto. Algo que es muy importante de lo que es esta plataforma cuando ustedes la empiezan a analizar, hay mucha información de cómo funciona, de cómo se puede armar los microservicios dentro de la plataforma, de qué tecnologías están soportadas, cuáles no, cómo debe ir cambiando para poder administrar tus servicios y ahora con las nuevas versiones de la plataforma, bueno, tiene nuevas funcionalidades, pero lo más importante de todo esto es que teníamos una plataforma que nos podía, nos permitía desplegar distintos tipos de tecnologías y nos permitía contenerizarlas de manera automática. De esta manera tratábamos de despegar a lo que era el desarrollador, que se tenía que dedicar única y exclusivamente a desarrollar y se deslindaba de pensar de cómo tenía que implementar dentro de la plataforma todo lo que era el microservicio. Bueno, como ya dijimos esta tecnología, es open source y la gran mayoría de las innovaciones por lo general viene desde el lado del open source, con lo cual tenemos garantizada esa parte de la plataforma. Cuando empezamos a evaluar la arquitectura del banco, vimos que teníamos un tanto, teníamos un trabajo muy importante que hacer, teníamos que empezar a desligar todo lo que eran nuestros canales de atención al cliente y nuestros backoffice, empezar a orientarlos a que empiecen a utilizar una arquitectura en la cual se maneje únicamente y exclusivamente con nuestra capa de integraciones para poder llegar a nuestros cores bancarios. Para ello, empezamos a pensar con OpenShift en montar toda nuestra capa de integraciones, que era la que estaba fuera de... por la que iniciamos este proyecto y con la cual empezamos a trabajar. ¿Cómo empezamos a trabajarla? Empezamos diagramando todo lo que es la arquitectura y para poder independizar a lo que era el desarrollo de los microservicios y su implementación, también adquirimos lo que era Triscale para manejar todo lo que es la capa de seguridad. Bueno, ¿cómo arrancamos? Cuando se nos planteó esta idea de poder montar la plataforma aproximadamente hace 14, 15 meses, nosotros empezamos a pensar con un MVP, donde lo primero que hicimos fue instalar un nodo master, un nodo de infraestructura y uno de aplicaciones. Sin embargo, ese tipo de recursos y esa plataforma nos quedó muy chica y eso nos derivó en tener algunos problemas. En el momento en el que empezamos a tener problemas, empezamos a evaluar junto con el equipo de Red Hat y junto con los partners, porque habíamos tenido ese tipo de inconvenientes y lo que nos dimos cuenta es que generalmente lo que se pide para instalar una plataforma de este estilo es minimamente contar con tres nodos master, con tres nodos de infraestructura y con tres nodos de aplicación. La versión de producto que utilizamos en ese entonces que decidimos cambiar fue 3.7. En esta plataforma instalamos la versión 3.9 de OpenShift y cada uno de los nodos lo montamos con cuatro cores en cada uno de ellos. En los nodos master le pusimos 24 gigas de RAM y en los nodos de aplicación también con cuatro cores los montamos con 24 gigas de RAM. Esta fue nuestra plataforma inicial para poder soportar todo lo que era la adopción de los microservicios. Nosotros al manejar cuatro entornos dentro del banco tomamos una decisión de qué hacer si instalábamos un cluster por cada entorno o lo dividíamos mediante tenance. La ventaja que tiene OpenShift es precisamente eso de poder dividir los entornos en distintos tenance para poder manejar distintos entornos. Así que nos dimos a la tarea de implementar únicamente dos clusters, uno pre-productivo donde se maneje todos nuestros ambientes bajos dividido por tenance, el tenance de desarrollo, el tenance de integración y el tenance de homologación y en producción lo dejamos exclusivo para poder manejar todos los microservicios en producción. Bueno, este trabajo nos llevó alrededor de dos meses y medio, tres meses el poder implementar la plataforma y desplegar todas las herramientas que están alrededor de ella para poder adoptarlos lo que son las herramientas ágiles. Como arrancamos, una vez que tuvimos instalada la plataforma teníamos que demostrar valor de la plataforma con lo cual hicimos una pequeña reunión con la agencia y les mostramos mediante un holamundo cuáles eran las guandas de la plataforma donde construimos un pequeño sitio dentro de OpenShift y ese sitio lo modificó durante la presentación que le hicimos a la alta agencia hicimos una pequeña modificación y lo hicimos transitar por todos nuestros entornos. Esa modificación se hizo el llevarlo hasta producción en veinte minutos, lo cual le agradó al negocio de cuando íbamos a tener esto implementado para poder trabajar y empezar a diseñar nuevas funcionalidades. Eso nos llevó a tener que diseñar un MVP. Nosotros, al tener la presión del negocio de tener que generar valor rápidamente, elegimos la posición consolidada del banco que es lo que te muestra todos los productos de un cliente y por la cual transitaban alrededor del 10% de las transacciones que se consumían dentro de nuestra vieja plataforma de integración. La posición consolidada la empezamos a diseñar con alrededor de 15 microservicios y fue un trabajo conjunto no solamente del área de desarrollo que se encarga de las integraciones sino que también participó el área de los distintos scores para poder rediseñar las funcionalidades necesarias para poder conectar a los canales con esos vaquens. La posición consolidada nos trajo unos beneficios muy satisfactorios. Comenzamos con diseñando la arquitectura. Después desarrollamos los microservicios que fue alrededor de 15 microservicios. Desarrollamos también servicios en las capas core para poder optimizar la obtención de la información. Efectamos las pruebas de estrés cuando pensamos en montarla en producción surgieron muchas incertidumbres. Todo el mundo tenía muchas dudas. Nuestra área de plataformas, nuestra área de gobierno, nuestras áreas que nos dan soporte a producción se preguntaban cómo iba a funcionar esta nueva posición consolidada cuando se montara en producción. Es lógico, es una plataforma nueva, es una tecnología nueva, es una arquitectura totalmente nueva con lo cual acarrea un montón de incertidumbres. Así que nos dimos a la tarea también en ese momento de pensar cómo garantizar que la implementación de esta nueva posición consolidada iba a ser un éxito. Nos sentamos junto con los proveedores, con Red Hat y vimos que teníamos que realizar pruebas de estrés sobre estos microservicios con lo cual nos dimos a la tarea con la ayuda de Jay Meter enviarle carga de aproximadamente el doble de lo que soporta con todos los canales en producción. Nos trajo buenos resultados, sin embargo no eran unas pruebas todavía concluyentes con lo cual empezamos a trabajar en ver cuáles eran las dudas que surgían de la incertidumbre de poder montar esta posición consolidada en producción y lo que nos planteaba era cómo se va a comportar la plataforma si se cae uno de los nodos, qué va a pasar si empieza de repente a recibir mayor carga, cómo vamos a reaccionar para poder hacer funciones y no tenemos el soporte que nos garantice que está trayendo la información correcta. Entonces empezamos a plantear otro tipo de pruebas, otro tipo de escenarios, como por ejemplo durante las pruebas de estrés drásticamente bajamos un nodo y vimos como automáticamente nuestros containers migraban a otro de los nodos que estaban disponibles. Así que empezamos a hacer otro tipo de pruebas también para poder garantizar la cantidad de transacciones que iba a recibir y seleccionamos uno de los canales piloto para poder trabajar con esta posición consolidada. Nosotros elegimos a lo que es nuestro CRM ya que tenía la factibilidad de poder configurar fácilmente el apuntar a la vieja posición consolidada o a la nueva posición consolidada dependiendo si había o no algún inconveniente cuando se desplega en producción. Es así como nos fuimos un año pasado con la posición consolidada hasta producción apuntando el canal CRM y qué fue lo que observamos. Las tuvimos monitoreando durante algún cierto periodo de tiempo durante la implementación igual muchas dudas, incertidumbre empezar a ver cómo iba a trabajar esta posición consolidada y lo que vimos gratamente es de que tanto el rediseño a microservicios el poder implementarla dentro de OpenShift y el rediseño del acompañamiento de los canales perdón de los vaquens nos hizo que al estar desplegando la información del cliente dentro de nuestra página del CRM de la página principal tardaba alrededor de un 30% más rápido lo cual era un gran alivio porque es el plantar la posición consolidada dentro de cualquier canal tiene que ser algo muy rápido y óptimo y esto nos dio una idea de que este era el camino que por acá teníamos que seguir y que de alguna manera teníamos alguna métrica la plataforma había respondido adecuadamente habíamos ganado en performance y todavía nos faltaba otras tantas cosas por descubrir. ¿Cómo fue la estrategia de implementación? Como ya comentamos instalamos la plataforma los dos clasters tanto el productivo como el productivo en mayo del 2018 por ahí de agosto pudimos hacer un pequeño MVP para mostrar como eran las bondades de la plataforma después para octubre implementamos el MVP que se llevaba el 10% de las transacciones aproximadamente de la vieja plataforma esta nueva plataforma de integraciones y con la garantía de que estaba funcionando y todo trabajaba adecuadamente en enero del 2019 empezamos masivamente a migrar ya a rediseñar todo lo que eran nuestros servicios de la vieja capa de integración a una arquitectura de microservicios y tenerla disponible y a la fecha hoy en día ya tenemos migrados el 100% de los servicios a esta nueva capa de integración y están transitando el 80% de las transacciones de esos 5 millones que habíamos visto al principio ya por la capa de integración dentro de OpenShift bueno como logramos un tanto el avanzar con este plan con recursos dedicados en un principio para poder avanzar con este con la prueba piloto y con el MVP de la posición consolidada teníamos un equipo de tres desarrolladores dos arquitectos una persona de plataformas y una persona part-time de seguridad informática el equipo fuertemente empoderado eso es algo sumamente importante porque cuando te sientas a negociar con cualquier área si no tienes el soporte y el apoyo de la alta dirección es imposible avanzar o se hace un poco tortuoso el camino para recorrer y avanzar e implementar una plataforma de este estilo ese equipo fue fuertemente empoderado por nuestra dirección por nuestra gerencia de IT y cada que teníamos la necesidad de ir a hablar con una área donde teníamos que ir a pedir o recursos o alguna necesidad de seguridad informática o algo que es natural que nos bloquee el seguir avanzando íbamos con la banderita de OpenShift y por fortuna siempre se nos sabían la poder es importantísimo tener el apoyo de la alta como para poder avanzar con este tipo de proyectos si no es un poco difícil que hicimos antes de poder despliegar el equipo que nos pidió durante esos meses en los que se estuvo trabajando fuertemente en la migración tuvimos que hacer la definición de estándares y patrones para poder garantizar que el despliegue de nuestros microservicios siempre fuera de la misma manera ahora en el siguiente slide vamos a ver con qué herramientas lo hicimos bueno, el empoderamiento al equipo con la toma de decisiones todos nuestros desarrollos están siempre pensados en la arquitectura de microservicios para acompañar la transformación digital que el banco nos estaba solicitando la integración de los canales también es via API con lo cual estamos trabajando fuertemente para pifificar el banco no solamente desde canales y la capa de integración, sino también estamos trabajando para que en las capas más abajo también empecemos a hablar solamente en APIs bueno, y con la ayuda de la integración de herramientas y armado de los ciclos de DevOps si esto no se automatiza es difícil que podamos tener esa velocidad que seguimos manteniendo la verdad que implementar este tipo de plataformas es solamente la punta del iceberg todo el resto que acompaña la implementación de esta plataforma del cambio cultural y de DevOps es lo, yo creo que es lo más importante es casi el 90% del trabajo que hay que hacer para poder hacer ese cambio cultural y que empecemos a pensar en automatizar a manejar otro tipo de herramientas hacer más open source a tener que investigar nosotros tuvimos que investigar muchísimo porque no somos expertos, no éramos expertos cuando empezamos a trabajar con Red Hat y con los parbles de Red Hat teníamos muchas dudas y eso solamente solventa investigando, probando y probando, fallando y volviendo a intentarlo bueno donde estamos la imagen que todos conocen DevOps tenemos integración continua dentro el ecosistema que manejamos de herramientas utilizamos Jenkins para los pipelines GitLab como la herramienta de centralización del código Sonar para lo que son el manejo de la verificación automática de código CSS como servidor o repositorio central de librerías Ansible Tower estamos haciendo algunas pruebas piloto para poder automatizar en su momento para poder implementar la plataforma lo que utilizamos fue Tower con los playbooks que brinda Red Hat para poder hacer el despliegue de todos los recursos Gira para todo lo que es el ciclo de vida CloudForms para monitorear en sus inicios empezamos a utilizar este CloudForm para empezar a ver cómo se comportaba la plataforma y a compararlo con las herramientas que ya teníamos dentro del banco y ver de qué manera encontraba mociere igual o no también nos surgieron un montón de dudas y empezamos a chapar con los equipos de Red Hat que de alguna manera se fueron clarificando después con el uso típico de la plataforma bueno para la captura de logs y la visualización para poder capturar la información la guardamos en elastic search y la visualizamos con Kibana y bueno nuestro API manager que es Triscay el cual lo tenemos en forma híbrida que más para monitorear la herramienta también como hemos visto se han vuelto algunos estándares Grafana y Prometheus además de las herramientas corporativas que tenemos bueno que tenemos en el abso de un año aproximadamente dentro de la plataforma tenemos migrados y desplegados el 100% de los servicios de nuestra capa de integraciones antigua estamos pensando ya en también migrar los servicios que están montados sobre el segundo middleware que se había implementado hace 5 años y que no llegó a buen puerto así que estamos trabajando fuertemente en eso pero no solamente hemos migrado microservicios dentro de nuestra capa de integraciones sino también tenemos trabajando o trabajamos directamente en la plataforma OpenShift al ver todos estos beneficios y las bondades que tenía sobre el onboarding digital nuestro onboarding digital del banco hipotecario está corriendo netamente sobre OpenShift confiamos en OpenShift y nos ha dado buenos resultados y como de alguna manera vimos que todo esto estaba funcionando trabajamos sobre el rediseño del nuevo Home Banking que hoy también está corriendo y contenerizado dentro de OpenShift así que estos estas plataformas que son sumamente importantes para nosotros hemos tenido la confianza como para poder montarla dentro de la plataforma de OpenShift porque nos ha dado resultados cuando empezamos a hacer las pruebas de estrés vimos que funcionaban no hemos tenido prácticamente ningún problema hoy cuando hemos trabajado muy fuertemente con la actualización de la plataforma no hemos tenido grandes riesgos en cuanto a sumarle más nodos así que tiene muchas bondades el poder empezar a trabajar con OpenShift ¿Qué tenemos hoy dentro de la plataforma? ¿Cómo está nuestro cláster actualmente, el de producción? tenemos los mismos tres nodos master que teníamos al principio con las mismas dimensiones cuatro cores, 16GB y 170GB en discoduro tenemos los mismos tres nodos de infraestructura el cual ese si se elevó pasó de tener cuatro cores a tener 16 cores cada uno de los nodos con 170GB en RAM y 24GB 170GB en discoduro y 24GB en RAM cada uno de los nodos y pasamos de tener tres nodos de aplicación a 8 nodos va a tener 8 nodos de aplicación soportando todo esto cada uno de esos nodos de aplicación tiene 8 cores maneja 24GB en RAM llegas en discoduro así que es nuestro cláster productivo el cual estamos también empezando a evaluar el crecerlo porque tenemos que meter más aplicaciones dentro de ese cláster y algo que comentaba yo ayer con Santi que por ahí le dije que me va a matar pero también hemos estado heredando algunas aplicaciones que están montadas sobre versiones viejas de Java y lo que hicimos fue contenerizarlas y meterlos dentro de la plataforma y las tenemos funcionando en forma productiva y no hemos tenido ningún problema sé que está soportado todo lo que es la infraestructura pero por ahí capaz el código no tanto pero bueno, empezamos a evaluar y a ver que el tema de la contenerización dentro de la plataforma nos da muchas bondades porque antes pensábamos que para una aplicación tener que montarla dentro de nuestro sistema dentro de nuestra infraestructura tenemos que pensar en un servidor de desarrollo de integración, en un servidor de homologación en el peor de los casos sino uno grande que soportará los tres ambientes y además dos servidores en el entorno productivo para poder soportar la alta disponibilidad y cada uno de esos servidores con sus licencias, su sistema operativo, con su sus herramientas de monitoreo con las cosas de seguridad informática que se mete para poder garantizar su funcionalidad más el tiempo que nos llevaría bueno, todo eso ahora cuando empezamos a tener aplicaciones lo primero que hacemos es tratar de contenerizarlas y montarlas sobre OpenShift no tenemos que pensar en la infraestructura y también nos estamos aislando de lo que es la capa de seguridad con Triscade a lo largo de todo este tiempo hemos tenido varias lecciones muchas cosas hemos transitado yo creo que como lo dije antes la instalación de la plataforma es la punta de LightBear, después todo lo que viene atrás es lo que va ligado con la adopción de las herramientas de DevOps, el ciclo de vida el poder sentarse a negociar con las áreas para poder trabajar y empoderar todo este trabajo así que la optimización de recursos nosotros lo hemos visto al comparar lo que era la vieja plataforma de integraciones donde estaba montada toda nuestra capa de integraciones que manejaba distribuida en 5 nodos aproximadamente 120 cores y 220 gigas de memoria RAM ahora tratando de abstraernos de los nodos de infraestructura y de los nodos de Master nuestra capa de integraciones con el 100% de las funcionalidades y el 80% de las transacciones corriendo sobre dicha plataforma en OpenShift maneja alrededor de 70, 80 cores dependiendo de la carga y no se come más allá de 120 gigas de memoria RAM esto lo que nos da es un ahorro aproximadamente de 30 a 40% en cuanto a la infraestructura pensando únicamente en infraestructura porque también hicimos un trabajo importante al pasar a la arquitectura de microservicios el rediseño, el acompañamiento de los vaques con nuevas funcionalidades más óptimas de alguna manera todo eso ayudo a que el trabajo de optimizar la infraestructura lo estemos viendo ahora bueno la escalabilidad es realmente me sorprende como poder soportar el doble de carga dentro de la plataforma para una aplicación más que apretar un botón para poder tener ya dos pods corriendo dentro de la plataforma y soportando prácticamente el doble de la carga bueno, la herramienta de DevOps el cambio cultural que tenemos que hacer para poder acompañar todo este ciclo de vida sin duda el trabajo colaborativo el poder sentarse con cada una de las áreas y negociar como vamos a avanzar con todo este proceso es muy importante el poder tener el empoderamiento de la dirección porque si no se vuelve un poco difícil antes el equipo que estaba trabajando sobre OpenShift únicamente eran tres desarrolladores únicamente eran tres desarrolladores, dos arquitectos una persona de plataformas y part time seguro informática OpenShift está de alguna manera permeando a todas las áreas de desarrollo y todo el equipo o la gran mayoría de nuestro equipo de plataformas lo conoce seguro informática también está consciente de lo que es la plataforma y cómo funciona la estenderización es sumamente importante plantear las reglas sobre las cuales vamos a trabajar para que todo esto funcione adecuadamente y lo más importante de todo es el cambio cultural gracias a las herramientas y las metodologías es que se puede lograr este tipo de cosas las preguntas me dijeron que no se pueden hacer así que nos vemos en un rato muchas gracias