 Quiero presentar ahora a un invitado muy especial, porque Martín de Liga es el gerente de arquitectura de Banco Itaú y fue el primer cliente en Argentina que nos abrió las puertas para poder hacer una prueba de concepto de OpenShift. Trabajamos bastante tiempo con él y su equipo y fue una experiencia muy agradable y es un honor poder tenerte hoy acá. Muchas gracias, Martín. Bienvenido. ¿Qué tal? Bueno, como Santi dijo, el Itaú hace bastante que venimos trabajando con esto. La verdad que hoy todavía no pudimos avanzar tanto como algunos de nuestros compañeros, pero lo venimos haciendo lento, pero con un objetivo un poquito diferente y eso es lo que le quiero contar ahora. Primero les cuento un poquito sobre Itaú, para que tengan idea de contexto. Itaú en Argentina es medio raro, Itaú. Itaú en Argentina es un banco mid-market que tiene aproximadamente 500 mil clientes, el número 12 en el mercado, y tiene aproximadamente 1.600 personas colaboradores. En Itaú es una bestia, en Brasil, perdón. Brasil tiene 5 mil sucursales y cerca de 60 millones de clientes. Banco Itaú en Brasil es más grande que todo el mercado argentino financiero junto. Entonces tenemos esa dicotomía de, somos un banco mediano acá, pero nuestra casa matriz es gigante, tienen todas las tecnologías cresta a la ola, entonces a veces jugar con esa visión regional y local nos cuesta. Y eso es lo que hizo que avancemos un poco más dentro en este tipo de iniciativos. Desde 2016 más o menos, nosotros emprendimos un programa de transformación digital bastante fuerte, por lo menos por un banco de nuestra tamaño. Estamos invirtiendo aproximadamente 30 millones de dólares en 3 años, que para nuestro tamaño, nuestro size es bastante, es muy fuerte, es una versión muy importante, y venimos sacando releases y nuevas aplicaciones varias veces por año. Nuestra idea es ser un player en este espacio bastante fuerte. Venimos trabajando mucho en todo lo que es nuevas prácticas, nuevas formas de laburar, escraba, malla, pero lo que nos pasa, y es parte de lo que les cuento ahora, es que IT está haciendo más lento de lo que necesita el negocio. Seguimos trabajando en nuevas metodologías y nuevas prácticas con una forma de hacer las cosas adentro a IT legacy, por serlo de alguna manera. Y esto está trayendo bastante ruidos y por eso estamos impulsando un cambio bastante fuerte. Esto para les una idea de a grandes rasgos que es el banco como está distribuido dentro de nuestra capa aplicativa. Tenemos dos plataformas grandes, todo nuestro core está en AS400 en miniseries, básicamente es COBOL y IGORPG, por lo tanto tenemos una planta bastante interesante de desarrolladores, tenemos aproximadamente 150 desarrolladores, los cuales 60 son COBOLeros. O sea, ya eso nos pone en una situación particular con estas nuevas prácticas. Estamos, si quieres, todavía no estamos en el mundo cloud, pero lo que es el mundo previo, estamos bastante bien. Básicamente somos 100% virtuales, básicamente no tenemos casi servidores físicos, algo es lo que es ver, pero todo nuestra infraestructura es legacy. Tenemos IPLAS SM Waterfall Comunes, hardware STCA para lo que lo conocen. Tenemos las aplicaciones tan desplegadas en share services, básicamente cluster de application servers como muchos ustedes van a tener, no tenés un application chiquitito server por cada aplicación, si no tenés bestias gigantes de múltiples hostes y que soportan muchas aplicaciones, que eso está bárbaro como un ahorro de costo, pero cuando querés velocidad y agilidad, se complica. Tenemos algo automotivación, pero no tanto, tenemos algunas pruebas integradas, pero como somos para ir eminentemente waterfall, hay mucha prueba manual, hay mucha regresión, hay mucha reprueba, nada que sea nuevo para todos. ¿Cuáles son los problemas? ¿Y por qué están empezando a crujir IT con la demanda que ha estado llegando en este momento? Básicamente tenemos muchos proyectos, tenemos más de 120 proyectos en paralelo en cualquier momento, entre proyectos grandes y chicos. Eso hace que tengamos teams de desarrollo tocando varios pedazos de la misma aplicación para diferentes proyectos. Barba con el branching, todo muy lindo, SSM, pero llega un punto de que los ambientes empiezan a hacer un stop-up. ¿Qué release pongo? ¿Quién? Ahora llega un regulatorio, tengo que sacar el código. En el momento que esto se paraleliza, llega un extremo que la forma de hacer las cosas, por más que esté, que sea eficiente, empiece a ser un stop-up para los pedidos del negocio. Entonces, esto ya no es IT, quiere tener una tecnología nueva. IT tiene que reinventarse para seguir el paso de un negocio que quiere cada vez más rápido. Tenemos una alta tasa de Conflation Drift. Básicamente, como nuestra estructura es todo virtual, todo lo que es cambios de Conflation son manuales, son administradores yendo y tocando parámetros de servidores, como pasa en las mayores casos. Eso hace que el estado de Conflation de ese servidor, que a vez sea más lejano a lo que era inicialmente. Los herramientes de Homo son diferentes a los de Prod, etcétera, etcétera, etcétera, extra de conocida a nosotros. Eso empieza a pegar la performance del grupo. Tenemos metodías de agiliza dentro del banco, pero con tooling adaptado, no nativamente agiliza. Eso también causa problemas en el desarrollo. Esto como no es ninguna noticia para nosotros, como uno de ustedes, es la solución. O la solución o no, por lo menos una aproximación de la solución. Lo que queremos es, y por qué, estamos adoptando OpenShift. No queremos que todas estas aplicaciones puedan entrar en un container. Eso es indiable. Tenemos alcohol. No hay ningún container que soporte alcohol. Pero sí queremos que esto sea la semilla para el cual un cambio de cultura dentro del banco se expanda no solamente para los usuarios de la nueva plataforma, sino para toda la realidad. Por esto estamos comprando e invirtiendo en OpenShift. Queremos que, porque una práctica de un pipeline de 6D para la realidad más adelante, también puede ser una máquina virtual. No tiene por qué ser en un container. Obviamente nuestra idea es empezar a tener unas nuevas prácticas y unas tecnologías si querés en una nueva plataforma. Pero queremos que eso permee al resto de la organización y cambie la cultura. Como dejeron algunos de los hablaros anteriores, lo más difícil no es la tecnología, sino cambiar el mindset de 200 developers que están acostumbrados a hacer lo mismo todos los días, se los mide para la misma forma y tienen las mismas herramientas de hace de años. Entonces el desafío y el approach es difícil. El status cubo humano es lo más difícil de avanzar, más que las herramientas tecnológicas. Después, básicamente, entonces, como lo dije antes, ¿por qué estamos en este camino? Porque queremos traer Cloud adentro del banco. Cuando digo Cloud, no digo desde un concepto de Yas o inclusive de Paz. Es una nueva forma de hacer las cosas. DevOps, eso es un given. Si quieren DevOps, me encanta la definición básica de todo automático y todo monitoreado. Obviamente es un camino, no es imposible llegar a ese state, pero todo lo que se hace tiene que tener ese norte, esa visión. Lo que dijimos del cambio cultural. Tenemos equipos ágiles en el banco, trabajando con pipelines waterfall, trabajando con administradores web soportando esos cambios que chocan entre los proyectos. Entonces soportar desarrollos ágiles sin metodologías DevOps no va, no funciona. Funciona por un tiempo, pero llega un punto donde cruje que es lo que está pasando. Entonces DevOps y esa cultura donde todo tiene que ser automático y el ownership no llega hasta que ya un drop de código y después me olvido, vas a ser vital para el time to market. Acuérdense que porque estamos haciendo esto es fácil. Queremos entregar valor más rápido y con más caridad. Y todo esto es parte de semantra. Influencer inmutable. Los containers son given, básicamente los containers nacen con inmutable. Pero como les dije antes, las prácticas de configuration management se pueden aplicar en infraestructuras que no son containers. Ese principio de yo no voy a modificar un código, un servidor, me lo veo como root y cambio la configuración. Si no, yo ejecuto un script ansible para que vaya y toque ese servidor se puede aplicar en containers o infraestructura virtualizada. Es independiente, solamente un cambio cultural que no es fácil. Pero el concepto de infraestructura inmutable hace que todas las peleas de ambientes, de también estar igual que antes, está igual que producción, mi ambiente de desarrollo, dejen de tener sentido. Y si podemos lograr que esas directrices y esos conceptos del mundo, que son naturales en el mundo web scale, en el mundo containers, permiten hacer lo que nunca va a ser un container, es ideal. Y eso es lo objetivo que estamos logrando, o queremos lograr. Esto no hace falta que descuente demasiado, digamos, queremos aplicaciones que sean cloud ready. No queremos, digamos, las aplicaciones que desarrollemos no nos tienen que importar dónde va a correr. Va a correr un premise, va a correr el AWS, va a correr la nube privada de Itaú, Brasil. No importa dónde corra, tiene que ser desarrollado de la misma manera bajo los mismos conceptos. Eso es clave, tenemos que despegar las aplicaciones de infraestructura. Ese concepto de sacoplar los componentes de la aplicación de los datos en infraestructura es lo que nos hace el más rápido. No me importa dónde corre. Yo sé que va a correr igual en todos lados. Si quieres llevarse algo de lo que es cloud ready, es eso, es desacople. Esa es la magia que hace que esto funcione y funcione en todos lados. ¿Cómo lo vamos a hacer? Así. No van a haber nada que no conozcan. Son todos productos, las mayores son productos ofensores. Eso básicamente es la combinación de productos de infra y pipeline que estamos usando, ok? Por lo menos para empezar. Si ven ahí con raro que está Ansible y Splunk, está Puppet en la misma slide porque tenemos los dos configuration managers, porque tenemos Puppet los hemos usando para algunas aplicaciones y Ansible lo vamos a usar para un friendship, después decidiremos con cuál nos quedamos. Esto es una decisión difícil, que estuvimos un montón de tiempo para tomar. ¿Qué hacemos? ¿Implementamos algo de cero, nuevo, sin mirar nada de lo que tenemos? O al revés. Miramos todo lo que tenemos y hacemos algo que se adapte a todas las necesidades de todos nuestros developers. Y la verdad que decidimos salir con el medio, ok? Implementación de containers para searching in film. No miro nada lo que tengo. No me importa si tengo Liberty, si tengo AAP, si tengo un developer que usa Node.js, es de cero, ok? Se va a hacer con los mejores estándares, con las herramientas open source, con las mejores metodologías, nada legacy ahí adentro. Ahora, nuestro pipeline de LLM, lo tenemos que hacer Brownfield. Tenemos que hacer que sea con las mejores tecnologías, pero con un ojo en lo que tenemos. Porque si no, nuestro desafío de que esto permé más hallado que en shift, nunca se va a lograr. Si yo no puedo hacer que las nuevas metodologías, las nuevas formas de laburar, permé para un PIB que tiene una aplicación en un ADM de BingWare normal comun y corriente, nos sirve. Si le voy a tener un subset de Rockstar developers adentro de OpenShift que tiran cadenas y tienen producción en minutos y después voy a tener una parada de 30 developers en otro lado del piso que se matan todos los días. No es lo que queremos. Más allá de las diferencias, obviamente nunca vas a poder hacer cosas en containers lo mismo con un AVM. Los conceptos sí pueden ser parecidos y sí pueden entender lo mismo. Esto es lo que estamos diseñando en este momento. No es tan complejo, pero básicamente son dos clusters, uno para Prod y uno para Preprod, en nuestro sitio principal y después obviamente a través de BingWare, todo esto está virtualizado. A propósito, elegimos no ir como uno de los conceptores, no hacer y así pasa a la vez, porque sería bastante disruptivo los procesos actuales que tenemos. Nosotros tenemos muchos procesos como Banco, de Disaster Recovery, todos los años tenemos que hacer la prueba de Recovery, está montado sobre BingWare, meter ahora un OpenStack o mismo un BingWare Realize para poner Yask pura, sería demasiado cambio. Queremos ir ya poco en ese sentido para que los clientes de operación no nos puedan seguir. Entonces elegimos montar los clusters de OpenShift sobre BingWare, por lo menos por ahora. Y otro concepto que también les comenté antes, nuestros pipeline de 6d van a estar pensados para desplegar en cualquier lado. Y bastantes bastantes integraciones, yo quiero que un container corra adentro al banco, en la Nube Brasil, en IBM Cloud, correndo solo ICP en cualquier lado, que ese es el concepto. Luego diría esas diferencias más allá de lo que es Confusion Management. Nuestro pipeline no es nada raro, bastante común. No puse todos los steps, puse las principales. Básicamente estamos emprendiendo un Oshira para todos, soportar todo lo que es Salline. Git, usando GitFlow, la verdad que no se supone, lo conocen todos, el esquema de branching pero es excelente. Lo estamos usando en algunos proyectos compartidos con Brasil. El esquema de branch by feature realmente te abre las puertas, como vos manejas los repos de código y los releases. Excelente. Sonar Cube, usamos Artifactory para todo lo que es binary. De Continues delivery, estamos usando tanto Puppet como Ansible y algo excelente para testing. Estamos esperando algunas cosas que ha cambiado para TDD, pero lo principal es esto. Un comentario abajo de todo. Como nosotros estamos hablando de tener un pipeline tanto para el mundo containers como para el mundo no containers, es super importante todo lo que es analítica de este pipeline. No queremos que un developer tenga que loguearse en 42 consolas diferentes para saber dónde fue el error, si Mayben pinchó porque le falta una librería, si salió un error en Ansible con algunos de los scripts, entonces todo va a la capa de Splunk. Splunk es un producto que para lo que es el mundo open sería Elastic, Ivana y Caravaggio. Es todo lo mismo. Básicamente es un ingestador de eventos que los correlaciona y te hace sessions. Pero la idea es que haya un solo lugar donde todos los eventos del pipeline, no importa quién lo genere, estén ahí disponibles para hacer analytics y para que los developers tengan un solo lugar para mirar. Ya sea con el evento con despliegue de AWS que falló, todo está en el mismo lugar. Eso es crítico. ¿Cómo empezamos este camino? ¿Cómo queremos cambiar con el objetivo más allá de el objetivo de infra o el objetivo de tener containers y ser Cloud Ready? Al final día queremos convencer a los developers a pasarse a este nuevo mundo. Yo como cliente de arquitectura les podría decirles que todo el mundo tiene que hacer esto, pero la verdad es que esa forma no funciona muy bien, por experiencia lo digo. Entonces, ¿qué estamos haciendo? Básicamente estamos siguiendo los mismos pasos que el container ocean program de Red Hat, pero en House. Elegimos un equipo de desarrollo que siga, que tiene ganas, que tiene problemas y pudimos decir, contame tus problemas. ¿Qué te duele? Hoy, con Jarvis, ¿qué te duele? ¿Por qué tenés release management, manejo de código? Contame todos tus pain points. ¿Qué te duele hoy? Por lo que no puede ser suficientemente eficiente para el que te pide el negocio. Venís, contame. Agarramos los mismos con los team de ops. Mira que tienes menos pain points, porque la verdad que la infra está bastante aceitada, pero también digamos. Me llama mucho. El administrador de WAZ es el experto número uno para soportar todas las aplicaciones. Hay developers que ni saben cómo hacer trabajos en la situación, porque se va al administrador de WAZ. Bueno, venís, contame. ¿Qué te duele? En base a eso, periodizamos una esquema de opción eligiendo aplicaciones y cómo desplegar el pipeline de 6D para ir cubriendo esos pain points de forma iterativa. No vamos a hacer un desplegue big bang. Nunca funciona, veamos. Todo el mundo dice, vaya, vaya, vaya, se desarrolla. Bueno, estos proyectos también tienen que ser ágiles. Tienen que ser iterativos, probar. Esto funciona. No, fit the look rapido para atrás. Entonces, fuimos con la impresión iterativa, pero con ejemplos reales y con teams reales que quieren subir esta plataforma. Qualidad de que estos sean nuestros embajadores después. Estos son los teams que después van a ir alrededor del banco y sumar más gente a este nuevo mundo. Porque funciona, porque es más rápido y los resulta problemas. No hay más magia que ésta. Si el developer nota que una nueva forma es a las cosas, le quita problemas, le amas en Powerment, puede hacer cosas más rápido y puede desplegar su aplicativo en producción más rápido, va a ir. Es cuestión de ir sumando casos de usos y sumando teams. El gran viejo conocido boca a boca. Estamos en este momento otra decisión consciente que tomamos y por ahí es un poco más lento. Estamos capacitando a los dos teams que están partes de piloto en la plataforma. Antes de que un server esté creado, estamos haciendo los cursos. Tanto los developers como los de operación. Si la gente que va a participar de esto, va a saber de estas tecnologías antes que se ponga el primer servidor. Y la idea es que lo hagan ellos. Con soporte de Red Hat, pero que lo hagan ellos. Ya hemos tenido otras experiencias anteriores que viene el proveedor, deja tu andando. Bueno, ahora hay que usarlo. Los sirven. Tienen que ser los mismos teams que están llevando a cabo el piloto, los dueños de que este proyecto salga a la luz y sea exitoso. Los para eso tienen que saber. Hacer la capacitación después que el transfer. Todo muy lindo. Pero tenés que entender de quién están hablando. Si el PDS cuántos master y cómo los replico, tenés que entender de qué están hablando y cómo adaptar eso a Itaú. Por eso la capacitación es clave. Los equipos tienen que saber de las tecnologías antes de que empiecen los proyectos. Y después, antes de fin de año, vamos a estar ya con el piloto lanzado. Este es nuestro roadmap de iterativo cómo vamos a ir sumando los features tanto a la plataforma como el pipeline de DevOps. El pain point número uno era branching. Lo sé que dijimos, it. Vamos a poner aquí el flow al principio para todos. De ahí vamos agregando. Por ejemplo, lo próximo que vamos a poner es gira. Vamos a poner todo lo que es métricas y el desarrollo ágin arriba. También lo vamos a usar para backtracking, para atar las historias y que las células de Kanban no pueden usar también. Porque fue el segundo pedido. De vuelta. Cada uno de estas cosas tiene un orden en base a los pain points, las personas que le van a usar. Esto les resuelve problemas, les resuelve la vida. Entonces, ellos van a ser los principales embajadores e impulsores de esta tecnología a través del long. Esto es clave. Esto no se hace, no se hace por decreto, se hace por adopción. Después, cuando termina nuestro roadmap, vamos a reemplazar todos los pain points del lm que tenemos por el nuevo. Por eso es clave y por eso es lo que he dicho antes, el lm brownfield. Tenemos que tener en cuenta todos los casos de uso del lm actual para que este lo pueda reemplazar. No me sirve tener nlms, porque si no, es un lío, digamos, la auditoría, los desarrolladores. Tenemos que empezar a homogenizar. Como en su momento, homogenizaron las plataformas de infra. Tenemos como engenzar la forma que nosotros despliegamos código. Lo importa si es a ese 400 cobol o si es .net o si es Java o si es Node.js. Todos tenemos que estar sobre la misma plataforma. Las métricas tienen que ser las mismas y la forma de medirnos tienen que ser las finas. Algunas lecciones, como dije, todavía no estamos en producción, pero ya tenemos algunos takeaways, por lo menos por lo que lo traducimos y donde estamos parados ahora. Esto no es un cambio tecnológico. Esto resuelve problemas de negocio. Tal vez a lo más jodido los techies tratamos de resolver un problema tecnológico, te lo vamos a traer un tilde, tengo containers, qué lindo. La pregunta es qué problema de negocio estoy resolviendo. ¿A qué stakeholder del negocio le estoy dando más valor, más rápido? Bueno, eso es clave para estos problemas de adopción, porque cuando termine van a decir, barba, muy lindo, tenés una aplicación montada, andando, feliz, 6D, bárbaro, anda todo bárbaro. ¿Y ahora? ¿Qué resuelvo? ¿Qué gané? Bueno, tener en claro qué problemas resuelvo de negocio es importantísimo para que esto después pasa a ser una estrategia de banco. Esto, obviamente, yo como gente del que yo no estoy perdiendo como estrategia, pero la única forma que una estrategia se convierta en la sangre y también la cultura de un banco es que resuelva problemas de negocio. No hay más que eso y no se puede perder la vista de eso, jamás. Lo segundo que les dije, capacitación tentana, agarrar un administrador de toda la vida de otra marca y ponerle una consola a administrar esto es un cambio tremendo, porque no es aprender otra cosa, sino es aprender otra forma de laburar. Es que el PIB sepa que no lo van a tener que llamar a él para si la aplicación funciona lento. Vamos a vaquear los monitoreos dentro de la plataforma y el developer va a poder ver si su aplicación funciona bien o mal. Entonces, ese cambio de chip lleva mucho tiempo. Entonces, la capacitación, no solamente técnica, sino de qué queremos lograr y cuál es el rol de cada uno en esta nueva forma de trabajar es clave y es de lo que más cuesta. Si se lleva en algo es esto. La capacitación, la evangelización es lo número uno que necesita para hacer estos cambios. Lo técnico se puede contratar experto si bien, pero que después ese conocimiento y esa nueva forma de laburar, permee y sea parte del día a día y la sangre de una organización de IT, lleva un montón de esfuerzo. Seguridad. Bárbaro con containers, todo el mundo anda. Es un ligo seguridad. Tagueo de máquinas virtuales, roles, perfiles, 46.09 para los que son bancos. Tenemos un montón de regulaciones. El aspecto de seguridad es clave. Hay que meter a la gente de seguridad y compliance no lo puse ahí, pero también. ¿Por qué? ¿Por qué ellas también tienen ganado el chip? Se han estado hablando con uno de los chicos de DevOps. La gente de seguridad no quiere que el DevOps tenga acciones de los servidores. ¿Y para qué el DevOps tiene que tener acceso a los servidores? Y todo teóricamente está orquestado por un configuration manager. Obviamente está echando el extremo, pero la gente de seguridad y la gente de compliance también tiene que acompañar este cambio. Tiene que abrir la cabeza. Hay que evangelizar a ellos también. Ellos están más lejos que nosotros todavía de la forma de laburo, de estas nuevas tecnologías. El concepto de DevOps, para ellos, es raro. Hay que ir a explicárselo. Se puede decir, bueno, el mercado lo tiene. Hay que meterlo. No, no. Porque cada empresa tiene su forma de laburar, tiene su estatus cubo también en esas áreas. Entonces, meternos temprano y meternos dentro de la realización es clave. Está bien. El Banco Central nos deja ir a clave ahora. Sí, pero por ahí la gente de auditoría dice que tiene miedo o que no, y es un stopper. Entonces hay que meter a esta gente lo más temprano posible en este tipo de procesos de cambio. Lo que dije antes, esto es hidrativo, pero es un peligro hidrativo también. Hoy vamos a hacer esto. Mañana vamos a hacer lo otro. Pasado vamos a hacer otro esto. Como te querés acordar, estás en un lugar totalmente diferente de donde empezaste. Entonces, para hacer un proceso hidrativo, tenemos que tener muy claro lo que dije antes. ¿Cuál es el objetivo, negocio que queremos lograr? Queremos que esto sea la mejor plataforma, solo la mejor plataforma de containers con mejor ADM, es una cosa. Quiero que este permee al resto de la procesión es otra. Quiero un cambio cultural es otra. Entonces, tener en claro el objetivo final es clave, porque cada paso si no es un paso falso. Tenés que tener muy claro qué agrega cada paso de valor y comprobar ese hipótesis. A ver si lo logró. Cuidado con la cantidad de datos. A ver, este tipo de pipelines y de plataformas genera una captura absurda de datos. Y los datos no sirven para nada. Hay que transformar las informaciones. Por eso ya he dicho lo de Splunk o lo de Lasties Archantes. Hay que tener mucho cuidado para que la información llegue a las personas correctas y de una forma digerible. Tirarle un log de ingesta de un Splunk a un developer y decir, toma acá tenés tu log, no sirve para nada. Ahí hay que darle información. Entonces, cómo esos datos se trasladan a información tienen que ser parte también del diseño de la plataforma en cada paso. Si no, no sirve para nada. Después, cuando tengas un problema, el video va a estar con la mejor plataforma del mundo, 20 minutos en el caballote para saber que había un puerto cerrado porque el SDN no lo abrió. Lo que sea. Todo tiene que estar en el mismo lugar y todo tiene que ser entendible para todas las personas de una forma clara. Lo que dije antes, bárbaro con el mundo de containers. Pero hay otros mundos que no son containers. Jamás voy a poner una aplicación comprada de un proveedor que tiene 12 cores, 48 giga ramas entre un container. No va a pasar. Nunca. Entonces, tenés que tener en cuenta esos casos. No obviamente metarlos el día uno en la complejidad porque no se puede cubrir todos los casos porque si no termina jamás pero tenés que tener uno con eso. Es decir, bueno, algún día va a tener que taclar eso. O no, queda fuera. Pero primero tenés que mirar el bosque y después decidir qué batallas vas a jugar. Pero jamás olvidarte de ver todo lo que tenés alrededor. Y lo último a los que se había dicho antes. El concepto regulatorio. Me encanta la idea de containers deployment. No lo puedo hacer. Necesito un tipito, un usuario en algún lugar pero cuando se hace el nuevo que me diga, sí, ok, estoy ok con este despliegue. Bueno, listo. Vamos hasta containers delivery. Pero como eso, mil cosas. Cloud, el tema de roles y responsabilidades y creación de funciones. Cada plataforma es bárbara. Pero la regulación de cada país la hace unique. Hay que bajar la implementación y las estándares y las reglas y los mejores prácticos del mundo a cada organización o a cada país. Porque eso es clave. Porque si no te puede llevar una muy mala sorpresa o no querías salir a producir. Y eso es todo. Gracias.