¡LLegamos a producción!

Hace unos días comenté que teníamos el desafió de llegar a producción en 8 días con una aplicación construida desde cero.

Ayer cumplimos el objetivo.

En el camino nos encontramos con varios imprevistos relacionados principalmente con las aplicaciones existentes con las que teníamos que interactuar. Cuestiones principalmente de networking, seguridad y accesos. Todas cuestiones que intentaremos ir puliendo en las próximas iteraciones.

El siguiente gráfico resume la arquitectura productiva de nuestra aplicación:

Nuestra aplicación consiste en un frontend construido con Angular (servido por Nginx) y un backend construido con Net Core (aspnet/kestrel) que consume servicios WFC/SOAP que proveen acceso al core de la organización. Tanto front como back son empaquedados en imágenes docker que luego corren en Kubernetes. Dentro de Kubernetes tenemos pods de front y pods de back que en ambos casos corren en un esquema de sidecars con filebeat. Esto es: cada pod corre dos contenedores, uno con nuestra aplicación (front o back) y uno con filebeat que se encarga de leer los logs escritos por nuestra aplicación y mandarlos a Elastic/Kibana para tener así un acceso centralizado al log. Por otro lado, por fuera del cluster Kubernetes hay un conjunto de dispositivos de red (routes, balancers, firewalls, etc) y servidores de distintos tipo donde corren los servicios con los que interactua nuestra aplicación.

En próximos post compartiré algunos detalles de nuestra forma de trabajo y nuestro pipeline de delivery.

Breve reseña de algunos libros de arquitectura

Hace un tiempo escribí una breve reseña sobre libros de patrones de diseño y en ese momento dudé de mencionar algunas libros que finalmente decidí dejar para incluirlos posteriormente en un post sobre libros de arquitectura. Llegó el momento.

Software Architecture in Practice

Este es un clásico, la primera edición data de fines de los 90′. Yo tengo la segunda edición que es del 2003 y hay también una tercera edición del 2012. Es un libro del Software Engineering Institute, un lugar de referencia en todo lo que tiene que ver con Ingeniería y Arquitectura de Software. No es un libro brillante pero sienta algunas bases. La primera parte de libro presenta conceptos y la segunda parte presenta casos. Es un libro bien conceptual, no se centra en tecnologías aunque obviamente hace alguna mención tecnológica cuando presenta los casos.

Designing Software Architectures

Este libro también es de la gente de SEI aunque me parece que es mucho menos conocido que el anterior, tal vez porque es más reciente, fue publicado en 2016. Este libro me resultó mucho más entretenido que el anterior, es más corto y está enfocado concretamente en cómo diseñar una arquitectura. Me gustó tanto el enfoque de Architectural Drivers que lo incluí en mi materia de FIUBA.

Patterns of Enterprise Application Architecture

A estas alturas este libro también se ha convertido en un clásico y me animo a decir que este libro en particular posiblemente sea uno de los libros de arquitectura de software más famosos actualmente.

Este libro fue escrito por Martin Fowler y fue publicado en 2002 dentro una serie de Addison-Wesley que lleva a firma del propio Fowler. Creo que casi todos los libros de esta serie están relacionados a cuestiones de arquitectura. Este libro lo leí en digital y hace tiempo que lo tengo anotado en lista de compra de libros físicos.

Beyond Software Architecture

Este libro también es de la serie Martin Fowler de Addison-Wesley, tal vez el menos famoso de esa serie, pero curiosamente es un libro muy interesante. Trata de cuestiones, que como su nombre lo indica exceden la idea tradicional de arquitectura pero que tienen una relación directa. Cuestiones tales como instalación, configuración, actualización, modelo de licenciamiento, etc.

Microsoft .NET: Architecting Applications for the Enterprise

Me compré este libro por uno de los autores: Dino Esposito. Ya había leído otros libros de él que me parecieron muy buenos y este no fue la excepción. A pesar de ser un libro centrado en tecnología .NET los temas están presentados de una forma tal que son fácilmente portables a otras tecnología. Al presentar un tema primero hay un capítulo que presenta el tema conceptualmente y a continuación en otro capítulo se centra en la implementación en tecnología .NET. en un primera parte el libro trata algunos temas conceptuales como SOLID y luego va analizando distintos patrones de arquitectura con bastante nivel de detalle. Cubre particularmente bien Domain Model, CQRS y Event Sourcing.

Just Enough Software Architecture

Este libro propone un enfoque de definición de arquitectura basado en riesgos que me resultó concreto y afín a mis propias ideas. A diferencia de otros libros de arquitectura que “le hablan al arquitecto”, este libro “le habla a developers”. El libro pone un foco importante en el modelado pero también toca de forma superficial algo de patrones.

Application Architecture Guide

Es es un libro gratuito (la versión digital) publicado por el grupo de Prácticas y Patrones de Microsoft.

Es básicamente un libro de patrones de arquitectura. Habla de atributos de calidad y propone un método para definir la arquitectura de un sistema. Resulta interesante que el libro contempla distintos tipos de arquetipos de aplicaciones: web, desktop, mobile, rich clients, etc. Más allá de que es un libro de Microsoft y que como tal tiene foco en su tecnología, creo que la mayor parte del contenido es agnóstico de tecnología. Es así que en mi materia de FIUBA leemos un par de capítulos.

Building Microservices

Este libro de Sam Newman ha cobrado mucha popularidad en los últimos años. Creo que es un libro muy interesante porque más allá de los conceptos de microservicios sirve también para entender un conjunto de técnicas y estrategias muy en moda en la actualidad, cuestiones tales como: Circuit breakers, Api Gateaways, Api Vesioning, etc.

Yo leí primeramente una versión preview de 3 capítulos que conseguí gratuitamente, con eso me bastó para decidir comprar el libro completo.

Building Evolutionary Architectures

Este libro aún lo estoy leyendo. Me parece muy bueno. La premisa central del libro es que la arquitectura de una aplicación no es estática, puede necesitar cambiar a lo largo del tiempo, pero independientemente de cómo evolucione hay ciertas propiedades que uno querrá asegurar que siempre se cumplan. En este sentido el libro analiza puntos fuertes y flojos de distintas arquitecturas y provee herramientas para facilitar la evolución de de una arquitectura.

He leído algunos libros más que podrían entrar en esta categoría de arquitectura pero estos son los que más me han gustado y me parece que merecían recomendación.

DevOops!

Tengo la sensación que más de una organización la está pifiando con DevOps tal como ocurrió (¿sigue ocurriendo?) con Agile.

Hubo casos en los que se creyó que Agile era pegar post-its, tener Scrum Masters y trabajar en forma iterativa. Muchos Scrum Master resultaron ser “PMs reciclados” y si bien los post-its sumaron alegría, el software seguió apestando. Tal magnitud tomó el fenómeno que le dieron nombre propio: Dark Agile según Ron Jeffries o Flaccid Scrum según Fowler. Yo lo llamo simplemente Fragile.

Con DevOps percibo algo similar. Como developer antes tenia que lidiar con áreas de operaciones, ahora tengo que lidiar con áreas de DevOps. El nombre es distinto pero las fricciones siguen estando. Apenas han sido mitigadas por el uso de ciertas herramientas de automatización. Más aún las personas en muchos casos siguen siendo las mismas, son “SysAdmins reciclados”. Basta una búsqueda rápida en Linked de perfiles DevOps para confirmar que muchos de ellos eran SysAdmins poco tiempo atrás.

Hay organizaciones que directamente decidieron poner un área de DevOps cosa que personalmente no me convence. He logrado distinguir dos patrones cuando una organización crea un área de DevOps:

  • Un caso es cuando ese área DevOps es un refactor del área de Operaciones. Incluso en algún caso más que un refactor es un simple rename. Aquí no hay grandes cambios para la dinámica de trabajo con el equipo de desarrollo más allá de algunas nuevas herramientas principalmente de automatización y monitoreo. Las caras son las mismas, los actores y las actitudes también.
  • Un caso distinto es cuando ese área de DevOps es creada desde cero incorporando nueva gente a la organización. En estos casos este área de DevOps se convierte en la nueva interface con la que el equipo de desarrollo debe interactuar. Ese área de DevOps es como un proxy del área de Operaciones. Desarrollo interactuar con DevOps y luego DevOps se encarga de lidiar con los distintos actores de operaciones (networking, base de datos, seguridad, etc.)

A mi parece ninguno de los dos casos es “True DevOps” porque la realidad es que la fricciones no desaparecen sino que a lo sumo se mitigan y/o cambian de lugar.

En otro post contaré otros patrones DevOps que me mi entender son más efectivos o al menos con los que yo me siento más cómodo.

De desarrollo a Producción en 8 días

El jueves pasado completamos la primera iteración. Construimos una funcionalidad mínima pero que nos sirvió para sentar las bases del proyecto y mitigar muchos riesgos técnicos. Al mismo tiempo montamos la infraestructura de CI/CD y el ambiente de desarrollo.

En esta segunda iteración tenemos el objetivo de agregar un poco más de funcionalidad, ajustar la estética/pantallas de la aplicación e ir a producción. Para esto tenemos 8 días hábiles. Puede parecer más que suficiente pero yo tengo mis dudas. Ninguno de los presentes en la reunión de planificación conocía a ciencia cierta el procedimiento formal para ir a producción con una nueva aplicación. La complejidad radica en que la organización es una entidad financiera que está sujeta a ciertas normas y regulaciones generales definidas por una entidad controladora externa. Al mismo tiempo ocurre que la implementación de algunas de esas normas es en ciertos casos obsoleta, extremadamente burocrática y sin sentido.

En 2 semanales cuento que tal nos fue.

Sobre la cadencia de iteración

Sobre la cadencia de iteración

Personalmente me gusta trabajar con iteraciones de 1 semana. Pero en el proyecto que estoy trabajando actualmente acordamos trabajar en iteraciones de 2 semanas pues la mayoría del equipo así lo prefiere y no logré convencerlos. Y cuando digo la mayoría del equipo en este caso es todo el equipo salvo yo. Entre los argumentos de mis compañeros para no hacer iteraciones de 1 semanas se destacó: “si hacemos iteraciones de una semana vamos a invertir demasiado tiempo porcentual en planning, review y retro”. Personalmente no coincido, al ser las iteraciones más cortas, la planning y la review deberían también ser más cortas. Pero es cierto que más allá del tiempo dedicado a planning y review hay un costo de logística/setup de cada reunión.

Mi preferencia por las iteraciones de una semana se remonta a unos 10 años atrás. Desde entonces siempre que puedo intento trabajar de esta forma. Otra de mis preferencias es hacer las iteraciones en continuado agrupado en un mismo día las reuniones de revisión y planificación. Respecto de las retrospectivas no considero mandatorio que tengan la misma cadencia que la planificación. En varios proyectos he trabajado con una cadencia de planning/review semanal y con retrospectivas cada 2 o 3 semanas dependiendo de la consolidación del equipo.

Cuando me toca trabajar en iteraciones de 2 semanas (como en mi proyecto actual) yo igualmente en iteraciones de 1. No es que yo haga planning y review en solitario ni en paralelo, sino que al inicio de la iteración yo mentalmente planifico que voy hacer durante la primera semana. Una vez completa la primera semana, hago un checkpoint de mitad de iteración, leo el burndown chart, analizo cuánto hemos completado y veo como enfocar la semana siguiente de cara a intentar asegurar cumplir con el plan de la iteración o de ajustarlo si es que el contexto así lo requiere.

El dilema de dónde estudiar informática, algunas cuestiones a considerar

El dilema de dónde estudiar informática, algunas cuestiones a considerar

En la época en que inicié mis estudios universitarios todavía estaba vigente la creencia de que un estudio universitario “aseguraba un futuro”. Con lo cual si uno tenia la posibilidad económica y las ganas de hacerlo, solo había que decir qué estudiar. Al mismo tiempo en aquella época (fines de los ’90) internet no era lo que hoy y el acceso a la información era mucho más acotado. Hoy en día las cosas han cambiado mucho, comenzando por el hecho de que ya es claro qué hacer una carrera universitaria no asegura un futuro.

En en el caso particular de la informática hoy en día existen muchas opciones de estudio tanto dentro como fuera de la universidad. Intentaré resumir algunas de las opciones en forma simplificada.

Dentro de la educación universitaria hay un conjunto interesante de opciones que no existían cuando yo comencé a estudiar. En este punto me refiero concretamente a carreras universitarias cortas: diplomaturas y tecnicaturas como las que ofrece la Universidad Nacional de Quilmes. Son carreras cortas de 2 o 3 años que representan una opción rápida (en comparación con las carreras tradicionales) para la inserción laboral.

Fuera de la educación universitaria hay dos subgrupos: la educación no universitaria formal y la informal. Con educación no universitaria formal me refiero a carreras terciarias que tienen el aval/regulación del estado. Un caso de esto son las tecnicaturas superiores que ofrecen los Institutos Superiores de Formación Docente y Técnica.

En cuanto a la educación informal tenemos una variada oferta que incluye cursos presenciales, como los que ofrecen IT College, Digital House y Educación IT y cursos online, como los disponibles en Acamica y Coursera. Algunas de estas instituciones ofrecen incluso algunos cursos en modalidad mixta de clases online y encuentros presenciales. Estos tupo

Para cerrar esta enumeración vuelvo al comienzo: las carreras universitarias tradicionales de informática. Ingenierías y licenciaturas, carreras largas, de 4 o 5 años en los papeles pero más cerca de los 7 u 8 años en la práctica. Incluso dentro de esta opción hay varios caminos, uno típico de polémica es universidad pública o universidad privada.

Personalmente no creo que haya una opción mejor que otra, es simplemente una cuestión de expectativas y necesidades. Lo que me parece interesante e importante es que hay muchas opciones y la profesión está en ascenso. Al mismo tiempo es importante tener presente que el estudio es un primer paso que no está necesariamente relacionado al desempeño profesional. He trabajado con excelentes profesionales de diversa formación, algunos de ellos nunca completaron un estudio formal.

Insisto en que es una cuestión de expectativas, lo cual no es un tema menor. Si lo que pretendemos es hacer apps para iPhone, no me parece que sea imprescindible hacer una carrera universitaria larga. Pero si lo que buscamos es hacer aplicaciones de tiempo real tal vez sea distinto.

Cada una de las opciones de estudio habilita un conjunto de potenciales oportunidades. Un ejemplo concreto: conozco de empresas que para determinados puestos solo contratan personas con título de ingeniero y solo de determinas universidades. Tal vez este tipo de políticas cambie a futuro, pero no estoy tan seguro. De todas formas, si a uno no le interesa trabajar en empresas con esas políticas, no tiene de qué preocuparse. Ojo, con esto no estoy diciendo que sea mejor estudiar ingeniería, sino que lo importante es tener en claro las expectativas de cada uno y elegir en base a eso.

El curioso incidente del Scrum Master y el merge a master

El curioso incidente del Scrum Master y el merge a master

Estábamos arrancando con el setup del proyecto y nos enteramos que el área arquitectura definió que el único que puede aprobar los merge-requests a master es el Maintainer. Curiosamente arquitectura asignó el rol de Maintainer en nuestro proyecto al Scrum Master, el único miembro del equipo (junto con el PO) que no codea, ¡ooops!

Ayer comenté esto en twitter y generó varias reacciones.

Lo que me incomoda de esta situación no es el hecho de quién puede aprobar los merge-request sino el hecho de que alguien externo al equipo defina cómo debe trabajar el equipo. Entiendo que haya ciertos lineamientos generales en cuestiones que puedan tener impacto fuera del equipo, pero cuestiones como el esquema de branching creo que no es una de esas cuestiones.

Al mismo tiempo quiero destacar que si bien recién estamos comenzando con el proyecto, la persona en el rol de Scrum Master me cae muy bien, creo que está haciendo un buen trabajo y si bien actualmente no codea lo hizo en el pasado.

Otra curiosidad es que en los lineamientos de arquitectura se asume en cierto modo que el equipo utilizará branches y merge-request, cuando en realidad la intención de nuestro equipo es hacer trunk-based development trabajando de pares para todo código productivo.

En fin, como conozco a uno de los referentes de arquitectura y me parece una persona bastante criteriosa y accesible lo llamé por teléfono para comentarle esta situación. Me explicó algo razonable: solo una persona por equipo tiene el permiso Maintainer y cuando se creo el proyecto el único miembro del equipo de desarrollo que estaba confirmado era el Scrum Master. Adicionalmente me explicó que lo que hizo arquitectura no fue establecer “reglas de piedra” sino lineamientos generales que surgieron del diálogo con diversos referentes de la organización y que pueden revisarse en cada caso particular. Esto también me resultó muy razonable. Más aún me parece muy sano cuando uno comienza un proyecto no se encuentre con la nada misma, está bueno tener algunos lineamientos que luego uno pueda debatir y eventualmente ajustar.

Cerrando la historia pinta que el equipo trabajará sobre un branch develop y luego en la salida a producción haremos el trámite de merge-master.