 Bueno, les vamos a contar cómo es la implementación de GDM y un poco es nuestro gran proyecto de simplificación y de despapelización en el Estado y cómo es la arquitectura que usamos para esto. Primero, me presento, soy director de firma digital, hace 20 años más o menos que uso Linux y bueno, me tocó colaborar, no es exactamente mi área pero colaborar en temas de arquitectura y a otras definiciones en GDM. GDM es una plataforma compuesta por más de 20 módulos, digamos, a nivel infraestructura lo único que tal vez les interese es que son distintos TomCat corriendo de distintas aplicaciones Java, bastante complejas, muy complejas desde lo funcional y en las interacciones que tienen entre ellos, eso lo hace bastante difícil de administrar, pero en lo funcional lo que hace es implementar todas las normas que hay en un gobierno, todas las normas legales, todos los procesos que le permiten una persona a cero no, a un funcionario a cero no, determinada cosa legalmente, no es un BPM, sino que es una plataforma a través de la cual todos los procesos de gobierno de toda la nación y de un montón de municipios y entidades estatales pueden funcionar. Básicamente trabaja con documentos, expedientes, trámites, usuarios y otras entidades, no les va, bueno esto se salió el formateo, no les vamos a hablar acá de pruebas de concepto ni de beta, sino de cosas que ya están implementadas, cosas con las que en la ciudad se eliminó completamente el papel, sistemas que están implementados en los 23 ministerios y en otros organismos y ya tenemos 65 millones de documentos almacenados, todo confirma digital, no son digitalizados sino nacieron digitales, todos están firmados, todos son el producto o digamos tienen claramente identificado al autor y tienen valor legal y en procedimientos, tenemos 6 millones 700 mil expedientes, un expediente es una colección de documentos y tenemos ya 1.024 y creciendo trámites a distancia, en mi experiencia anterior me ha pasado tener reuniones y desarrollos y proyectos enteros para hacer el sistema de un trámite o el sistema o todo el proyecto de hacer la reingeniería o la informatización de un proceso, esta plataforma es mucho más libre, tiene un montón de reglas internas pero nos permitió hacer todo esto en menos de 2 años, está compuesto como le dije de estos módulos principalmente pero son unos 20 que se comunican entre sí y lo que garantiza es poder informatizar el gobierno, cumpliendo todas las leyes, uno no puede en un gobierno instalar un IRP y decir que lo que vale, el gobierno se rege por expedientes y documentos y cosas que tienen que tener valor legal, entonces uno no puede instalar un IRP y decir que determinada compra la ISO y que la evidencia está en el registro de la base de datos número tal, tiene que haber un documento con valor legal, la ley argentina dice que el documento con valor legal es el documento que tiene firma digital, entonces estos objetivos los logramos con esta plataforma y lo que decimos es que lo más efectivo es agilizar los procesos, muchas veces se arranca por la parte de hacer una reingeniería de proceso, se encuentra algo ineficiente y se plantea todo un proyecto para hacerlo, tenemos un ejemplo, estas fechas o tiempos son reales de un trámite naduana que tardaba 90 días antes de digitalizarlo y por qué decimos que agilizar es la clave más que hacer la reingeniería porque en muchos casos no tenés el proceso y podés estar 6 meses haciendo el análisis de la reingeniería funcional, nosotros desburocratizando y digitalizando, que es lo que llamamos simplificar, a este trámite le sacamos 60 días con lo cual te quedan 30 y la efectividad del esfuerzo que podés poner en hacer reingeniería de procesos le puede sacar como mucho 15 días a eso pero hiciste un enorme avance nada más desburocratizando y digitalizando desburocratizar que es sacar lo que no hace falta, los trámites o los procesos o pasos que son innecesarios los bolás y el resto los digitalizás, tenemos un BPM perfecto de cada proceso? No, siguen trabajando como ahora que es un workflow abierto en el que los procesos existen pero están en el modo de trabajo de cada oficina, de cada uno de los 23 ministerios y miles de reparticiones y las reglas que los regían en papel los siguen regiendo en digital, pero esto te permite hacer este tipo de mejoras, voy un poco rápido para tratar de dejar lugar a preguntas, principalmente acá estamos para explicar porque usamos Docker y cómo fue nuestra implementación en todo lo que es la parte Docker, tenemos una instalación principal que se está que les conté, esos números son solamente de la administración pública central, pero vimos que había que llevarlo a un montón de otros lugares, o sea tener un montón de otros clientes que en algunos casos uno lo que haría es una instalación multitenant que permite tener distintas organizaciones por temas de gobierno, de gobernanza del dato y de separación jurídica también hay veces que necesitas instalaciones separadas, cuando nos planteamos qué hacer para ampliar el alcance de este sistema bastante complejo que se tarda bastante en implementar y en armar la infraestructura decidimos ir por Docker o por soluciones por Docker porque por un lado necesitamos optimizar los recursos, o sea hacer la misma instalación que ocupaba 20 o 40 máquinas virtuales o 20 máquinas virtuales sin escalabilidad, o sea una sola máquina virtual por módulo y en la práctica nosotros por ahí tenemos de un módulo 8 máquinas virtuales balanceando carga, para manejar todo eso hay que optimizar los recursos, tanto de los administradores, tanto el recurso físico o de datacenter como el de la cantidad de administradores, con el equipo que tenemos podemos administrar instalaciones basadas en BMs como mucho 3 y explotamos, hoy en día tenemos de esas instalaciones 100, en producción funcionando que son municipios, universidades, empresas estatales, otras jurisdicciones y un poco lo que vimos es un grado de mejora enorme en estos 3 pasos que fuimos haciendo, que es pasar, hacer una instalación con máquinas virtuales nos tomaba en el orden de meses, o sea un mes entero para poder entregar la infraestructura configurada y funcionando, en el mejor de los casos un mes, cuando pasamos a Docker, que fue lo primero, fue enlatemos todo esto, hagamos que esto que corre en un Tomcat y que alguien tiene que entrar y tocar un archivo XML y configurarlo y demás, hagamos que eso pase a ser infraestructura como código, que fue el primer gran paso, con infraestructura como código conseguimos replicar lo mismo en un montón de lugares, o sea poder tener un control que las mismas 10 personas puedan administrar 100 instalaciones nada más tocando variables de configuración, expusimos todo lo que era externo como variables de configuración, variables de entorno, y llegamos a una solución con Docker Compose en la que podemos levantar en cuestión de días, un día, dos días, un entorno nuevo, instalar un entorno nuevo, después Matías les va a contar más, pero no es solo levantar los containers, también hay temas de base de datos, de DNS, de dar de alta en el balanceador de carga externo, pero bueno, todo eso lo redujimos a que desde que nos piden un organismo nuevo, una instalación completa, en vez de tardar un mes, podemos entregarlo en un día, dos días, a veces menos, a veces un poco más. Y el siguiente gran paso es el que estamos ahora, ya en producción, que es ir por Kubernetes y en una plataforma que nos permita administrarlo, y eso es, digamos, por eso es que decidimos después de evaluar varias opciones, ir por OpenShift, ya queremos llegar a que sea la cuestión de horas, instalarlo, y además, optimizar los recursos de datacenter, nosotros estamos basando nuestra solución de Docker en, levanto los 20 contenedores en una máquina virtual, y en el caso de tener que escalar, como tenemos la frontera de la máquina virtual, no la podíamos romper, entonces con esas instalaciones basadas en Docker podemos llegar hasta la mayor potencia que le podamos dar a una máquina virtual, que depende en el fondo del host físico que tenemos, tenemos host bastante grandes, pero ya desde el año pasado nos planteamos que teníamos que poder pasar la frontera de un solo host, y ahí decidimos ir por algo que maneje Kubernetes. Bueno, les puedo contar, o no les voy a contar cada uno de los módulos, son 20, hacen cuestiones administrativas, uno es el acceso general al sistema, desde donde uno elige las cosas, otro manda comunicaciones oficiales, genera documentos en otra grupa, expedientes, y como ven hay un montón de otros módulos, y no están todos acá, después hay integraciones con otros servicios, todas las compras digitales, todas las compras electrónicas que hace el Gobierno, y cualquier otro sistema transaccional del Gobierno para que tenga valor legal tiene que dejar estos documentos de valor legal, entonces no es que no permitimos usar un IRP o no permitimos usar un sistema de nicho específico vertical, lo que hacemos son puntos de integración donde esos sistemas verticales llaman web services que terminan generando el registro legal de esa transacción, esto es más o menos el universo, y un paneo de quienes lo usan es todo el Gobierno Nacional, ANSES, PAMI, varios puertos, todas las aseguradoras, estamos centralizando o recibiendo de instalaciones de GD de aseguradoras todas las polizas de todas las aseguradoras del país, en teoría eso nos tiene que llevar a que uno no tenga que presentar más una poliza, y que tampoco nadie pueda presentar un papel que dice que es la poliza de algo y que no lo sea, porque va a estar registrado todo centralmente. Muchos municipios se benefician de tener un sistema de gobierno electrónico, un sistema de gestión interno de gestión documental, pero no tienen el presupuesto para hacerlo, no pueden encarar un proyecto de esta magnitud, entonces gracias a esta solución les podemos disponibilizar en el Centro Nacional de Datos una instalación cloud, o sea el cloud entre comillas obviamente es infraestructura, pero ellos lo ven como un cloud porque se les entregan las credenciales determinada URL, entran y lo usan, les damos el servicio y lo administramos nosotros o más precisamente Matías y su equipo, y ahora los dejo para que cuente cómo funciona todo esto o cómo lo hicimos, cómo lo hicimos. Bueno, arrancamos con el modelo de, vamos a ver los tópicos a tratar, vamos a ver la arquitectura más o menos de lo que es GDE de manera global, el estado actual, que es lo que tenemos en este momento, los distintos modelos de implementación de GD porque nació con máquinas virtuales y ahora llegó a tener algunos ambientes productivos en OpenShift y hacia dónde vamos, qué es lo que queremos lograr en un futuro a corto plazo y la arquitectura de GD es muy simple, o sea lo único que tiene es muchas cosas, arrancan los usuarios que se conectan con una playa que lo reirige a un HAProxy, este HAProxy tiene las aplicaciones en verde que son 15, 16, tiene una API que es lo que hemos en azul situa ya, que eso no es una API, son varias, tenemos el pediente API, escritorio único API, lo que va a reemplazar a los web services que están corriendo actualmente. El storage donde están los documentos también lo resuelve el HAProxy, lo único que está atrás del HAProxy que nunca toca al HAProxy son las bases de datos que está en un exa data replicado en los tres datacenters que tenemos, en los dos, el tercero todavía no está operativo. Actualmente tenemos más de 100 ecosistemas de GD operativos que incluye la Administración Pública Nacional con la Administración Pública Nacional también con máquinas virtuales, estamos josteando ANSES, estamos josteando APAMI y hay otro chiquitito que es Nación Servicios que en algún momento quizás sea, entran quizás no. Hay tres modelos de implementación como les comenté hace unos minutos atrás y todo esto está distribuido en tres datacenters, uno en Tubumán, en Microcentro y dos en Arsat, que en Arsat está sala uno, que es la que tenemos las máquinas virtuales y sala dos, que es donde estamos josteando OpenShift, que dentro de poco también va a tener una réplica en sala uno y más adelante en Tubumán. Módelo máquina virtual, modelo Docker Compose y modelo OpenShift. Las máquinas virtuales corren sobre BingWare, o sea tenemos, BingWare creo que ya lo migramos a 6.5, es un quilombo de manejar. Los ambientes que están en este modelo de máquina virtual son TEST con los ecosistemas de PAMI, ANSES y APN, el ambiente de homologación que donde está APN y ANSES, nada más lo tuvimos que acortar porque ya la infraestructura no daba para seguir creciendo y el ambiente de producción en donde está ANSES, PAMI, APN y acá falta Nación Servicios. Y además tenemos varios templates que es lo que se empaqueta, o sea en un TAR, o sea no es nada mágico y esa TAR viaja a las provincias que lo quieran implementar. O entes autárticos, o sea la FIP en este momento está con ese template de ese paquete. Como les comentaba hay diferentes ecosistemas, APN es GD completo, corren las 20 pico de aplicaciones con todas las APS bien completitos. PAMI, ANSES corren GD con ModuloScore que serán en un total de 10 aplicaciones, 15 con las APS. Las APS son dedicadas para cada ecosistema, no se comparte. GD OAPI hay una para ANSES, para APN, para lo que sea. Y también hay un Mule que es el que atiende web services, también dedicado a cada uno de los ecosistemas. Este modelo ya se entregó a Neuquén Córdoba, Santa Fe, Catamarca, a la FIP. Hay un montón de provincias que están faltando acá que no las agregue porque obviamente no había lugar. Y ahora se añade la posibilidad de interoperar entre los distintos ecosistemas en ten juntos o no. Como ya les había comentado, producción, onoación y test tienen al APAMI, ANSES y APN que pueden compartir documentos interoperando. Pero otra instalación de GD en algún momento no podía hacer esto de basarse documentos de un ente a otro. Lo logramos con este módulo y gracias a este módulo podemos ahora tener cloud andando y OpenShift. ¿Qué desventajas tuvimos con las máquinas virtuales? Que es lo que vimos, o sea, los desplieges son lentos. Si bien estamos usando Ansible para desplegar y hacer cambios en la configuración y muchas otras cosas, tenés siempre la poder poner un error, que la conexión SSH puede llegar a demorar, porque para que sea una idea, máquinas virtuales solo de GD son 15 y eso demora si vas haciendo uno a uno el despliegue del war y demás. Cuando se escala, es un clonado de un equipo o crear un equipo nuevo con las mismas características que tenía el anterior, entonces vas creciendo exponencialmente los recursos. No tenemos auto-scaling con máquinas virtuales, mayor prioridad de volcarla porque en un momento tocaste mal un botón, se desplegó mal algún módulo, no arranca y cayó todo, o sea, también con la configuración de ese módulo, quizás al templo y de Shinya algo quedó mal y no te das cuenta hasta que alguien te lo reporta, porque es uno o dos servidores que están fallando y no te diste cuenta y generaste problemas porque al trabajar con documentos oficiales que son del Estado, si hay algún documento que se creó mal y se generó mal, perdiste. Y nos daba la complejidad de crear un nuevo ambiente, o sea, nosotros para generar todas las máquinas virtuales lo vimos en las provincias, las provincias la entregamos las máquinas virtuales y después tenían que entrar una a una configurando cada BM, ya sea en la configuración de su ecosistema, las configuraciones de Tomcat, si podían o no darle 16 gigas o 8 o 4, y era todo edición manual, hasta se pensó en un momento también con todo el paquete mandar un ansio al chiquitito para que puedan hacer las modificaciones que necesiten. Después vino Docker Compose, con Docker Compose empezamos a estar un poquito más cómodos a la hora de despachar nuevos ecosistemas, ya sea para entes, para los municipios. El tema es que es una máquina virtual por ambiente, o sea no clasterizamos, hicimos una máquina virtual, es un ambiente, es un ecosistema, entonces si tengo 100 aseguradoras van a ser 100 máquinas virtuales. Con los mismos recursos, la configuración se toma un repogit, o sea que para instalarlo por suerte es fácil para desplegarlo, tiene disponible manual interoperabilidad y todo esto ya está automatizado con Ansible, lo están usando los municipios, o sea hay un montón de municipios que se prendieron, también lo van a empezar a usar los puertos, si mal no recuerdo Vaya Blanca ya es productivo, está operando un GD, universidades, está arrancando Uba, un LAM, hay otras más que no recuerdo, y van a tener que estar acá todas las aseguradoras. En este momento no están las todas las aseguradoras, están en un 50%, si nosotros no nos movemos de acá, no nos va a alcanzar la infraestructura, vamos a volcarla de nuevo completamente. Ventajas, escala fácil, ecosistemas independientes, mejor tiempo de implementación. Hay otro tema, eso de los ecosistemas independientes es muy importante porque si yo le entrego algo a Vicente López, Vicente López quiere que no se comparta nada con otro, o sea con otro ecosistema, o sea que se guarden un lugar distinto, en otra estora es diferente. Y mejoramos los tiempo de implementación y de despliegue, o sea antes era cuando configuramos PAMI que era un apéndice de lo que es APN, estuvimos un montón de tiempo, las provincias estuvieron un montón de tiempo para llegar a tener GD productivo. Las desventajas es una complejidad en la configuración, es un llamel inmenso de Docker Compose, y cuando arrancaron los primeros chicos, cuando yo no lo podía hacerlo, tenía que hacer otra persona, pasarle ese conocimiento a alguien que no está acostumbrado a Docker, a Llamel, que no entendía para dónde ir, no entendía que había que editar. El 80% de las BMS están sobredimensionadas, tienen mucho disco, mucho CPU, mucha memoria y no la están usando. Ir una por una viendo a ver qué es lo que necesita o qué no, también se complica. Bueno, el modelo OpenShift, la idea de OpenShift era llegar a poder automatizar todo. Desde la configuración del rev, que es donde está arriba, o sea OpenShift nosotros lo montamos arriba de un rev, queríamos arriba OpenStack, pero por los tiempos del Estado no pudimos porque, viste que la carreta siempre está adelante en el estado, o sea vos vas corriendo atrás de la carreta acomodando las cosas como podés. Entonces, usamos rev para esto. Y por el momento, usamos NFS para la registry y para los volúmenes persistentes. Estamos queriendo llegar a Glaster, eso va a llegar, esperamos que llegue pronto, no es un problema nuestro lamentablemente, ni que pueda depender de mí, porque en el parte de no queremos usar Community. Bueno, la arquitectura que tenemos como les comenté, estamos soportados por rev, tenemos los nodos master, los nodos de infra, los nodos de aplicación, en este momento en sobre rev tenemos dos datacenters de rev, no datacenters físicos, sino dos datacenters de rev. Uno que es de producción, que todavía no está prendido, porque nos falta storage, que si me pensamos que va a crecer a 6 hos, y 10 tera que tiene bajos, o sea los ambientes de homologación, test, donde están probando, que ya vamos esto a cambiarlo, yo no tenemos un cosa de producción, vamos a meter toda la misma bolsa y vamos a trabajar con lo que tenemos, porque también tiene sentido, tiene que en realidad un ecosistema que entregamos es testing hasta que no le pongamos el certificado con el que va a firmar el documento de manera oficial. Entonces hay un flag que dice, bueno, esto es testing hasta que pasa esto. Entonces no tiene sentido hacer lo que estábamos planteándonos, esto lo hablábamos ayer, es no tiene sentido si tenemos ya un ecosistema en test, en el datacenters de test, pasarlo a producción porque ya es productivo por solamente un flag, por solamente una pequeñez. Fue nuestro primer acercamiento a IAC, desde Ansible configuramos todo lo que tiene que ver con rev, todo, fue prueba, error, prueba, error, hasta que golpe salió andando todo, se pudo replicar otra vez, o sea cuando llegó y quedó andando, lo boletíe, hicimos otra vez, salió bárbaro, perfecto, eso es lo que va a quedar. El despliegue de las BMS de OpenShift, o sea de todo lo que son los nodos de aplicación, el nodo de, el nodo master y el de infra, todo está automatizado. Lo hicimos también con los componentes built-in de Elasticsearch y desplegamos Prometheus que ya lo tenemos viendo algunos de los GEDOS, ya están otros módulos, voy apurando porque me quedan tres minutos. ¿Model OpenShift es sistema OpenShift bajo? Bueno, esto significa que tenemos ya trece ecosistemas en el cluster de OpenShift bajos, como le dije ya quizás no lo usemos más el bajo, va a pasar a hacer toda producción. Estos todavía no están con el flag que le dice que son productivos, sino que están siendo todavía probados por los funcionales del equipo de modernización. Cada ecosistema es un proyecto diferente, sin multi-tining, o sea es solo. Y la gente nos dijo que ya está 100% productivo, ya se firma, se crea documentos, expedientes, se puede interoperar, o sea que está completo, está para poner el flag y salen a producción. ¿Cómo estamos haciendo el despiegue de los ecosistemas? Usamos un config map gigante, la estrategia es un docker file que está en un git interno nuestro y cuando ponemos los builds y demás hacemos una importación de la configuración. Con eso en dos horas ya tenemos un ecosistema andando. Falta previo que nos disponibilizen la máquina virtual que lo hace nuestro DBA en tiempo generalmente récords. Las ventajas que vimos escala como docker compose de manera fácil, los ecosistemas son independientes, mejoramos el tiempo de despiegue, simplificamos la configuración, optimizamos los recursos, que eso es lo que nos faltaba con docker compose. También es fácil administrar los nodos, por ansíbles es muy fácil, aparte viene preparado para eso, nos encantó. La visualización de log ya la tenemos resuelta, que hoy existen un incidente en docker compose, tenemos que andar entrando a cada VM, con LK que dobaron, y el monitoreo del proyecto, que ya lo estamos por terminar con Prometheus. ¿Hace dónde vamos? Vamos a cambiar la estrategia de docker compose porque creemos que se puede mejorar con source to image, se va a migrar todo lo que está en docker compose a open shift. Vamos a arrancar con lotes de A3, de A4, y vamos a ir todo pasando a open shift con también la salida de que todo lo nuevo que llega, también se va a instalar sobre open shift. Ya sea municipios, entes, escenas, aseguradoras, lo que sea. Queremos ya terminar el layout completo, no queremos ya depender de un tipo, queremos todo lo que se puede automatizar, automatizarlo, punto. Migrar a mente bajo del modelo de máquina virtual, no queremos que haya más máquinas virtuales de test, sino que seguramente se va a pasar a open shift, y a largo plazo la idea es llevar a PN a open shift. Bueno, termine justo, cero. No sé si alguien tiene alguna pregunta. Algo, perfecto. Muchísimas gracias.