 Buenos días. Antes que nada, muchas gracias por la invitación. Es un placer estar de nuevo acá. Gracias a HG y a Netlabs, que son los proveedores en Uruguay que nos acompañan siempre. Gracias a la gente de la Cátedrayer por la milanesa que nos sirvieron. La verdad nunca había algo tan grande. No sé cómo cortan a la vaca si le hacen tipo la pelan con una naranja, pero era una cosa impresionante. Y después, gracias por los dos goles que nos metieron en la semifinal. Y así, Genito nos fuimos a dormir. Y bueno, hoy estamos acá, pero con un placer de compartir un poco la experiencia nuestra. Bueno, el año pasado les contamos un poco cómo habíamos desembarcado en OpenShift nosotros. Esta es una mitografía de un poco la historia de lo que hemos ido haciendo. No voy a entrar en detalle hoy. Tenemos poco tiempo. Esto va de regalo en la presentación cuando se la pasen si quieren leer un poco más y ver los diferentes hitos que hemos hecho en más de 10 años, que tiene la agencia. Muy relacionado con lo que es clado, con lo que es nube, en lo que tiene que ver gobierno. Este año nos queremos entrar en DevOps. Nos queremos entrar en DevOps porque entendemos que la plataforma o este nuevo cambio cultural estaba siendo muy lento. Imagínense en el estado, un lugar duro para entrar con todo esto. Particularmente a nivel gobierno la mayoría de los desarrollos son outsourcing, es decir, no tenemos software factory dentro de gobierno y esto lo hace más duro aún. Los procesos de compra son lento, los procesos de compra son duros. No hay una buena interacción y ahí teníamos que trabajar. Nos entramos básicamente en tres pilares, lo que es trabajar muy fuerte en la cultura, en este cambio, trabajar en generar capacidades para afrontar este cambio y obviamente apoyarnos en tecnología. Marcamos líneas de acción, a nivel cultura, bueno, esto de habilidades blandas, como se dicen ahora, generar equipos transversales, equipos que integre gente de todas las áreas. Nosotros, generalmente, cuando recibimos una solución, viene pasando como una serie, va haciendo hasta que llegue operaciones y te dicen instalar esto que ni sabe de dónde venía, ni sabe cómo se originó. Entonces los equipos ya se generan con gente de operaciones, con gente de desarrollo, con gente de negocios del día uno. Autogestión, queremos que los equipos se autogestionen, que trabajen más solos y no dependiendo tanto de tomadores de decisiones. Capacidades, bueno, trabajar con agilismo, sin duda, no es convertirnos en ágiles, sino incorporar herramientas para que alguna manera seamos más ágiles y estemos en altura de los proveedores que vienen a proponer trabajar de esta manera. Trabajar fuerte en calidad, la verdad es un debe, las soluciones no tenían pedidos de calidad estrictos, como digamos nosotros, o mínimos, requerimientos mínimos para las entregas y bueno, en eso se está trabajando. Y bueno, y todo lo que tiene a ver con las nuevas arquitecturas, microservicios y nuevas técnicas de desarrollo. A nivel tecnología, obviamente OpenShift es un gran facilitador, es el título de la presentación, entendemos que es un facilitador para DevOps, apoyar en la gestión con herramientas disponibles para hacer la gestión y trabajar muy fuerte, sí, en automatismo, todo lo que veíamos recién, la verdad que es muy interesante, estamos lejos creo, pero es el camino que queremos seguir. ¿Qué estamos haciendo puntualmente sobre esta línea de acción? Bueno, a nivel cultura, pequeños cambios como evaluaciones 180, ya son cosas que se ven muy bien en la agencia, muy bien en la gente, se generan como otros vínculos que antes no se daban, bueno, como decíamos los equipos transversales, los niñamientos estratégicos, realmente, bajarle más a la gente lo que tienen que lograr y que la gente lo pueda hacer por sí solos. Y acá definimos con esto la innovación, siempre que estamos en espíritu, algo que les voy a contar más tarde que es el termómetro de DevOps, de alguna manera, poder medir el nivel de madurez que estamos llevando en esta transformación. A nivel capacidades, sí, obviamente, planificación estratégica y todo lo que tiene que ver con proyectos ágiles, transformación de la arquitectura de soluciones, tenemos muchas soluciones, allá en la infografía lo van a ver, tenemos una nube basada en infraestructura virtual que tiene más de 5.000 máquinas virtuales hoy en día y hay soluciones, hay una gran BM que la tenemos como identificada, que es como el gran Toro que tiene 64 giga de RAM, 16 CPU, es como un monstruo todo entero, es inmovible, es una cosa tremenda. Bueno, queremos cambiar un poco eso. Foco fuerte en la calidad, obviamente, y trabajando, algo que veníamos trabajando del año pasado, son estas guías para migrar de ellas a PAS, guías que te permiten evaluar, cuánto esfuerzo tengo que hacer para esta aplicación pasar la PAS, pasar un componente o si realmente me sale muy caro y la tengo que hacer toda de nuevo. A nivel de tecnología, trabajar en la conceptualización de plataforma como servicio, AGSIG no solo da servicios para algunos organismos, sino que define ciertos marcos para que otros organismos los adopten y a partir de ahí creen sus soluciones. Si tener nuestra solución de PAS, que es AdopenShift, es el producto que elegimos y es lo que estamos trabajando, generamos esta otra historia de Devbox, esta caja de herramientas para el desarrollador, de manera de poder ya definir ciertos lineamientos para que cuando vengan los equipos de desarrollo, tanto adentro como fuera la agencia, empezá por acá. Ya acá hay cosas armadas, no reinventes cosas que ya hicimos en otros proyectos, sino que las templetizamos y las dejamos disponibles para los equipos de desarrollo. Y todo lo que tiene que ver con integración, con infraestructura, como servicio. Tenemos muchas cosas que siguen en infraestructura como servicio. Y si empezamos a partir las aplicaciones y a llevarlas hacia PAS, queremos que la experiencia sea bastante fluida y que podamos seguir manejando todos de OpenShift, porque como plataforma de desarrollo de aplicaciones, pero cuando tengo que interactuar con lo que tengo en infraestructura como servicio, sea muy, muy, muy fácil. Vamos a entrar un poquito en lo que es esto, el termómetro de DevOps. Básicamente lo que intenta es medir el nivel de madurez, basado en los pilares que nombra ahí, que son procedimientos, herramientas y personas, a través de diferentes criterios que se definen, donde hay preguntas, lineamientos, algunas prácticas, etcétera, que se le hace como un diagnóstico al equipo, de qué estamos midiendo, bueno, las diferentes etapas del ciclo de DevOps. Planificar, construcción, integración continua, desplegar, etcétera. Básicamente para determinado etapa de ese plan se hace unas entradas que son preguntas que se le hacen al equipo, preguntas de diferentes aspectos que se valuen y en la medida que esos criterios van pasando, van pasando, chique, llega un momento que digo, bueno, hasta acá es el nivel de madurez que tengo para determinada parte del plan, por ejemplo, construir, es decir, construir o tengo en verde, ¿sí? ¿En qué me vaso? Me vaso, básicamente en esto, es ilegible, estoy de acuerdo, después si alguien lo necesita, no lo piden, tenemos la imagen grande, pero básicamente con esto lo que estamos logrando, lo estamos haciendo a nivel de proyecto es tener un poco una idea, bueno, dónde tenemos que fortalecer más, ¿sí? Entonces, con simple preguntas que se hace el equipo, la verdad que ya lo hicimos en dos proyectos y fue bienvenido y arrojó resultados interesantes, esto está en construcción, es la segunda versión que tenemos, la idea es ir teniendo diferentes iteraciones para llegar a algo utilizable y es algo que está para compartir. Obviamente, como decíamos, capacidades, bueno, Conagile, con todo que tiene Conagile, un Agile Mentoring, lo estamos haciendo, lo llamamos así, desembarcó un equipo de una empresa allá y lo que está haciendo es meterse en los proyectos, meterse en los equipos, hacer todo este tipo de dinámicas del Golden Circle, el Cata Improvement, Vision Board y otras más que hay por ahí, que la verdad están buenas, están buenas aclaran bastante, el Vision Board particularmente estuvo muy buena, la del Golden Circle esto, el qué, cómo y para qué, resultó súper interesante para alinear lo que decíamos alinear a la gente, bueno, si acá vamos, ahora hagan ustedes y esto es algo que está sirviendo mucho, la verdad. Bueno, ¿qué es un poco lo de la conceptualización de Paz? Bueno, partir de una definición de Paz, de plataforma como servicio, para pasar a tener lo que llamamos este diseño que hicimos nosotros de cajas, para pasar a tener foco y entender un poco cómo estamos parados hoy en día. Bueno, este es un poco el esquema que definimos nosotros, donde hay una capa de publicación de servicios, malla de servicios, una capa de orquestación, un entorno de ejecución, los repositorios, integración continua, despliegue y deployment continuo, métricas, red, la integración con infraestructura como servicio como hablábamos hoy, por un lado administración y por un lado seguridad. ¿Cómo estamos nosotros respecto a eso? Bueno, malla de servicio en rojo, obviamente estamos a la espera de la gente que saca el cuatro con service mesh, en orquestación estamos bien, a nivel de entorno de ejecución están rojo, porque lo que tiene que ver con bases de datos, ahora te diré que están naranjas, tenemos algún, algún Mongo corriendo, algún POSGRE, pero las bases de datos corrención por ciento de infraestructura como servicio, todavía no salgo que tengamos en la plataforma Penchif corriendo bases de datos fuertes. Estamos bien, tenemos un repositorio de imágenes, tenemos un repositorio de codios que se está usando, tenemos la capa publicación de servicios, integrada a su vez con una capa de seguridad, en AGC está lo que se llama el SIR2E, que define cierto asignamiento de seguridad y ellos definieron que cada aplicación que se publica tiene que pasar por un WAF, un web application firewall, donde el SIR se encarga de customizarlo, definir ciertas reglas para asegurar digamos la aplicación. Esto se pudo lograr, hay una integración ya por donde pasa y entonces la capa de publicación entendemos que en ese aspecto está completa. A nivel SIR2E entendemos que estamos haciendo cosas, ahora después vamos a mostrar un poquito con esto de desbox, se puede hacer mucho más, sí, pero entiendo que con lo que hay ya estamos. Métricas y registros no falta un poco, todavía está medio duro, el tema de, tenemos la plataforma con concentración de logs, tenemos pero entiendo que son cosas que las nuevas versiones también te van a dar, ¿sí? A nivel networking bien, integración con IaaS, esto un poquito viejo, podría estar naranja, podría estar amarillo, tenemos ya algunos procedimientos que hablan directo, la plataforma nuestra de IaaS es VMware y estamos haciendo que desde los pipeline que corren en OpenShift, la parte que tiene que ir contra las máquinas virtuales va directo a través de la API que habla con VMware. Y bueno, la administración, la verdad que está funcionando muy bien, incluso rompimos con ciertos paradigmas de que todo era por VPN, todo era bueno, estamos saliendo un poco de eso para que sea más ágil también el proceso de desarrollo. Bueno, ¿qué es esto de desbox? Bueno, la idea era cada vez que nos enfrentamos a una nueva solución que viene, si nosotros nos paramos en OpenShift como una plataforma para construir la aplicación, hay tareas que se van a repetir, ¿sí? Es decir, la generación de ambientes, la generación de los pipelines, cierto template que yo podría tener. Bueno, fue lo que hicimos, trabajamos primero con Java, luego con PHP y hace poco incorporamos GeneXus. La particularidad es que hay ambientes de estos que permiten escenarios completos en PAS como es Java o como es PHP, donde yo puedo definir completamente los flujos, se disponibilizan templates de 6D, template tipo de ambiente y algunas herramientas como manuales, junto con los templates de Pipeline, para que se puedan fácilmente provisionar. Y ya viene con ciertas compliance de Agesig, no, mínimamente tiene que haber todo lo que tiene que ver con anéis y código estático, antes nadie hacía, y mínimamente tiene que tener x% de cobertura, si no va, con lo que tiene que ver con Tsunitario. Bueno, eso ya se define y ya el proveedor ya sabe que va a ser de alguna manera validado su código en base a lo que yo ya te estoy diciendo. Pero hay escenarios híbridos como en el caso de GeneXus, porque todo lo que es la suite, la integración continua de GeneXus, corre en Windows, no corre sobre Linux. Entonces, bueno, ahí hubo que hacer toda una reengeñería para tener los ambientes en Windows, pero la experiencia final del desarrollador es transparente. Él sigue teniendo su pipeline corriendo desde OpenShift, en el momento que tiene que ir a buscar el código y trabajar integrando en el servidor de Windows, va y vuelve y sigue su camino. Por ejemplo, en el caso de Java, cuando te aprobísas el ambiente completo con los templates, todo esto es lo que te despliega y todo esto ya está interconectado. Si cada vez que yo tengo que hacer esto en un equipo, en un proyecto, es plata y entendemos que esto está ahorrando un poco por ese lado. Casos de uso. El año pasado, bueno, les contamos, las dos aplicaciones más importantes que tendríamos hasta ahora son trazabilidad. Es la aplicación que permite trazar todos los trámites que se están haciendo. Desde el 2016, el 100% de los trámites en Uruguay se inician en línea. Y para 2020, la meta es que se terminen en línea. Al día de hoy, algunos ya terminan en línea, pero algunos requieren que todavía te precedente, tengas una firma o te vas a hacer algo y no se lo puedes terminar en línea. Trazabilidad permite eso mismo. Saber dónde está tu trámite, a través de tu idea que se da de tu trámite en particular, puedes hacer un seguimiento y saber en qué estado está ahí, después cuánto demore, etcétera. Y en Uruguay vendría a ser el single design no, es un poco lo que hablaban hoy. La idea es tener un unicusuario para ingresar a todos mis servicios del estado. Y después, alguna prueba de concepto. No sé, este año, estuvimos trabajando mucho con Hyperledger, con todo lo que tiene que ver con Blockchain. Hicimos un refactor y para, es decir, esto venía en Docker. Las imágenes venían sobre Ubuntu. Entonces, utilizando al Pine, alguien lo nombró hoy, que está muy interesante. Hicimos un refactor de las imágenes y disponibilizamos ambientes de lo que tiene que ver con Composer, Explorer y Fabric de Hyperledger para poder desarrollar fácilmente casos de uso de Blockchain y poder probarlos en la plataforma. Levantar todo eso es un poco tedioso. Bueno, acá lo tenés ya rápidamente y vos podés ya empezar a desarrollar sobre Composer, un caso de uso de Blockchain. ¿Qué casos nuevos trajimos? Bueno, el primer caso que estamos este año trabajando es esta herramienta que se llama Wiccan. ¿Alguno de acá usa Trello? ¿La herramienta Trello? Está. Es una herramienta Kanban para tableros. ¿Cuál es el problema de Trello para nosotros? Nosotros tenemos un decreto que salió hace unos años que ese decreto, que es el decreto 92, impide que cierta información salga del país y tiene ahí como una letra chica donde dice salvo que esa información no sea crítica. El tema es que evaluar si es crítica o no es una línea que nadie quiera atravesar. El problema con Trello, por un lado, era que en la medida que empezás a usar estas herramientas, empezás a colar información y lo primero es un comentario sobre un proyecto y después aparece un diagrama y después empiezan a parecer datos que ya estás en la duda, realmente los tengo que tener ahí o no. Se vuelve una herramienta fundamental para la dinámica diaria y donde no tengas la otra vez que teníamos un problema de conectividad, quedamos una hora parados porque realmente, es decir, lo estábamos usando tan fuerte para seguir los proyectos que quedamos ahí trancados. Wiccan es una herramienta open source que, como ven, es muy parecida. Es más, podés importar los tableros que tenés en Trello directamente acá dentro. Incluso si vos estás trabajando en Trello hoy en día, los importás para acá. Bueno, instalamos esta solución. Esta solución utiliza abajo, utiliza Mongo como base de datos. Generamos también un cartucho. Yo le digo cartucho, es una imagen más bien. Empezamos con OpenShift hace años, con el 2, entonces todavía tengo ese tipo de cosas en la cabeza. Generamos una imagen que lo que hace es automatizar el backup de esta base de Mongo y de alguna manera le entregamos a la gente operaciones. Todo un paquetito con una solución Wiccan que hoy en día lo está usando toda la agencia y que próximamente lo van a empezar a usar otros organismos porque la verdad está resultó muy útil y muy interesante. El otro caso que era interesante que quería contar es esto OpenFisk. OpenFisk es un software que desarrolló el gobierno francés con el fin de impulsar una iniciativa que se llama legislation as code, es decir, legislación como código. La idea es poder llevar a código ciertos tipos de leyes que son las leyes computables, digamos, aquellas leyes que refieren a beneficios, que refieren a elegibilidad para determinadas obligaciones fiscales o que incluso se usa para evaluar el impacto de reformas. Es decir, el gobierno francés lo está en Uruguay, tenemos un impuesto que es el IRPF. Si en un momento quisiera hacer un cambio porque ese impuesto va variando según las franjas que tenés de sueldo que cobras, vos podrías acá simular y decir, bueno, ¿qué pasa si esto lo aplico a 100.000 personas? Bueno, la verdad que está muy interesante, lo estuvimos usando. Participamos entonces una prueba de concepto que se hizo el año pasado, eso fue lo primero que hicimos con Uruguay en una ceranda de Israel, modelamos lo que es la ley de jubilaciones. Eran muy similares a la ley de jubilaciones de cada país. Entonces lo que hizo se modeló, se llevó a un frontend, entonces ahí un ciudadano podría perfectamente validar si aplica o no para determinada jubilación o a su vez lo podría consumir un sistema, ¿no? Que es lo que vemos que es donde tiene más potencial. Entonces, seguimos trabajando y ahí hicimos un trabajo con la agencia de compras también que estamos haciendo ahora para evaluar cuando llegan varias ofertas y hay condiciones que se tienen que dar con lo que se llama por el régimen de preferencia de precios. Bueno, lo estamos trabajando y está muy interesante. Pero algo que arrojó esto fue un interés muy fuerte del lado de los abogados. Entonces surgió hay una iniciativa en la agencia que era acercarlo a los abogados a la programación. Y comenzamos a hacer talleres. Estos talleres lo que nos permiten es, si ustedes ven en la otra imagen, desde una ley trabajando junto a los abogados llevarlo lo que se llama un pseudo-código, que ese es el pseudo-código que es lo que ven al medio que se construye con ellos para que luego ya un desarrollador lo pueda llevar a códigos ejecutables. Nos parecía que iba a ser raro y la verdad estuvo muy bueno. Ya el segundo taller convocamos a 50 abogados que vinieron a trabajar, se colgaron y empezaron a sacar leyes ya. Ellos incluso están trayendo partes del pseudo-código y ahí lo que hacemos con ellos ya es un trabajo de corregir celó. Y bueno, la iniciativa es seguir sumando leyes y de a poco que funcione tanto como un portal para el ciudadano como para que lo pueda consumir un aplicativo, digamos, como que esto se usa como un backend. Esto está corriendo sobre OpenShift, fue refactorizado, lo compartimos el código con la gente de Francia para que lo tuviera también, porque también como te digo venía todo en Docker y bueno, nosotros lo preparamos para correr en OpenShift. Y bueno, y por último, ¿qué estamos haciendo? A futuro, un lavatorio de pruebas del stack completo. Nosotros todo lo que es OpenShift ha montado ser o bienware, es nuestra infraestructura por defecto, pero estamos investigando todo lo que tiene que ver con HCI, todo lo que tiene que ver con OpenStack, tratando de ver si podemos salir un poquito de la zona donde estamos trabajando ahora y tener otras opciones. A actualizar la plataforma, 4x, porque todavía, bueno, no sé si vamos a ir a 4.1, a 4.2, a 4.3 estamos ahí en dudas. Trabajar más en el concepto este multicloud, obviamente estamos en versión 3.11, entonces todavía el tema de federación no está habilitado y tenemos dos locaciones geográficas, entonces las pensamos más como dos cloud diferentes y bueno, estamos trabajando para eso, para que las aplicaciones puedan convivir en estos dos ambientes como si fueran cloud completamente desconocidas entre sí. Bueno, seguimos con el tema de los casos de desarrollo, ahora sí, completos entre lo que es PAS y YAS, entendiendo que eso va a vivir así, en un momento entendimos que todo tenía que ir para PAS, es decir, pasar de YAS a PAS, no, ahora ya estamos claros que hay cosas que van a plataforma y cosas que van a infraestructura, pero que el ciclo de desarrollo tiene que ser uno solo. Y bueno, y básicamente lo que estamos haciendo más fuerza ahora es con esta estrategia de opción de DevOps, de que alguna manera fortalecer todo esto que le conté al principio para tratar de ablandar un poco a la agencia y tener algo más ágil, productos de mejor calidad y estar preparados para todo esto que le decía el 2020 para que los trámites tenen línea y podamos responder, tenemos que hacerlo de esta manera, si no, no va a suceder. Es todo por ahora, muchas gracias.