Mes: marzo 2020

Consultorio DevOps, una visión académica basada en la experiencia

Algunos post/tweets que escribí con anterioridad sobre el tema DevOps generaron cierta polémica y me llegaron varias consultas. Por ello es que el martes próximo a las 19 horas voy hacer una sesión online sobre DevOps. La idea es compartir una visión académica del tema, algunos casos de estudio y atender consultas. Algunos de los temas/situaciones a tratar serán:

  • «En mi empresa hay «DevOps» pero seguimos con las mismas fricciones del día a día»
  • Por qué DevOps no debería ser un área
  • Cuándo DevOps podría ser un área
  • ¿Qué es un Ingeniero DevOps?
  • ¿Existen los Ingenieros DevOps?
  • Cuándo no (y cuándo sí) contratar Ingenieros DevOps
  • DevOps, Lean y Agile
  • La relación entre DevOps y SRE

A esto se suma todo lo que participantes quieren traer.

Update: el link de conexión lo compartiré por las redes minutos antes de comenzar.

Update2: el link de conexión es: http://nicolaspaez.com.ar/condevops

Preparando el inicio de un cuatrimestre atípico

Hoy comenzaremos informalmente las clases de MeMo2 en Fiuba. Más allá de la cuarentena el cuatrimestre ya venia condimentado con un incidente en el sistema de inscripción que retrasó la inscripción 1 semana.

Si bien el inicio del cuatrimestre se encuentra fijado oficialmente para el 13 de abril, es muy posible dadas las condiciones que terminemos teniendo un cuatrimestre «online». En nuestro caso particular ya veníamos trabajando con un campus virtual como complemento a las clases presenciales. En esta situación ya tener el campus virtual listo es un punto muy importante en caso de tener que llevar un cuatrimestre online. El campus virtual nos permite compartir materiales, intercambiar consultas y realizar actividades de evaluación (quizzes). También tenemos un canal de Slack para chats compartidos.

Lo que aún no tenemos resuelto es el tema de la video conferencia. Si bien en cuatrimestres anteriores hicimos algún experimento, ninguno resultó completamente satisfactorio. Es por ello que hoy haremos una primera actividad en la que probaremos Google Meet. Hicimos algunas pruebas preliminares y creemos que nos puede funcionar bien. La actividad que haremos hoy será optativa, ya que formalmente hasta el 13 Abril no se puede comenzar oficialmente con las clases. Mañana les cuento que tal nos fue.

Si algún docente está trabajando en mover su materia a un esquema online y tiene dudas puede contactarme por este medio, confío en que puedo dar una mano.

Todos contra master: Trunk-Based Development

Más de una vez me he encontrado con gente sorprendida cuando le comento de esta práctica, por ello quiero compartir algunas reflexiones y explicaciones.

La idea es bastante simple, todo el equipo trabaja sobre un mismo branch todo el tiempo. Siendo un poco más laxos con la definición es posible trabajar sobre distintos branches en la medida que dichos branches no vivan más de 1 o 2 días.

La práctica de Trunk-Based Development va muy en línea con la practica de integración continua la cual, como su nombre lo indica, propone integrar el producto en forma continua mínimamente 1 vez al día. Desde la perspectiva de integración continua uno podría trabajar en distintos branches pero al fin del día uno debería integrar todos esos branches. Esto no es opinable ni discutible, es una definición. Puede gustar o no, pero es así como la práctica fue definida hace ya ~20 años. El punto es, no podemos decir que hacemos integración continua si estamos escribiendo código en distintos branches por varios días. En todo caso podemos decir que hacemos integración frecuente o esporádica, pero no continua, lo cual no tiene nada de malo.

Ahora bien, cuando uno piensa en hacer Trunk-Based Development surgen una serie de preguntas sobre cómo manejar diversas situaciones. No voy a entrar en detalle sobre esas diversas cuestiones, simplemente les voy a recomendar este excelente libro de Paul Hammant: https://trunkbaseddevelopment.com/book/.

Adicionalmente a los consejos de Hammant voy a compartir un conjunto de prácticas/premisas que yo suelo utilizar en conjunto con Trunk-Based Development.

  1. En primer lugar hablamos de un equipo chico, no más de 6 o 7 personas commiteando.
  2. Al mismo tiempo ese equipo chico trabaja en un pieza chica, un bounded context o un microservicio. Eventualmente puede trabajar en varios bounded context pero cada uno en un repositorio separado.
  3. Todo el código se escribe en pairing o mobbing, lo cual reduce la cantidad de cantidad de commits.
  4. Todo el código se escribe haciendo TDD, lo cual colateralmente genera una alta cobertura que funciona como una red de seguridad cuando están entrando varios commits sobre el mismo branch.
  5. Las funcionalidades están cortadas en «pequeñas fetas», esto permite trabajar en pequeños incrementos que pueden completarse rápidamente (1, 2 o 3 días máximo).
  6. Ante cada commit, se integra el código, se buildea y se corren pruebas unitarias, se despliega a un ambiente compartido y se corren pruebras de aceptación. Si todo esto va bien, estamos en condiciones de ir a producción.

Se que algunos de estos puntos pueden resultar polémicos, incluso más polémicos que Trunk-based Development, pero esto es lo que a mi me suele funcionar. No digo que estoy vaya a funcionar en todos los contextos, pero creo que para descubrirlo hay que probarlo.

MeMo2: materiales de estudio para ir adelantando durante la cuarentena

Para aquellos alumnos inscriptos en MeMo2 para este primer cuatrimestre de 2020 que quieran ir adelantando algo de trabajo les comparto aquí algunos materiales de estudio que utilizaremos en la materia:

Si algún alumno estudia todos estos materiales y quiere adelantar más, no dude en contactarme.

Dilemas del Slicing

Veníamos haciendo un muy buen trabajo slicing, en realidad no se si tan bueno pero yo me sentía muy cómodo. Primero definimos las stories, hacíamos alguna apertura en tarea y si nos parecía muy grande/complejo, abríamos una story. Finalmente hacíamos una puntuación a modo de doble validación. En términos de puntuación todas nuestras stories eran 1, 2 o 3.

Pero resulta que en la última planning, nos encontramos con una story puntuada en 5. ¡Recórchilis! Intentamos buscarle la vuelta para partirla pero no lo logramos. Entonces uno de los muchachos sugirió partir la story en front y back, ya que tan front como back son tecnología distintas, repos distintos y artefactos de runtime distintos.

He aquí el dilema:

  • Opción 1: planificar una story demasiado grande.

  • Opción 2: partir la story en dos stories donde cada una en forma independiente no agrega valor.

La opción 2 para mi no era válida, con lo cual decidimos ir por la opción 1. Personalmente me hacía mucho ruido el 5, pero internamente yo estaba convencido que la story estaba más cerca de un 3 que de un 5.

La semana próxima les cuento que tal nos fue.

¡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.