Imágenes

Enfrentando al “Agile Industrial Complex”

Enfrentando al “Agile Industrial Complex”

En los últimos años “el mundo agile” ha sido invadido por lo que Martin Fowler ha denominado como el “Agile Industrial Complex” y de la mano de ello las prácticas técnicas han quedado de lado. Mucho post-it y poco TDD, mucho “agile coach” y poca excelencia técnica. Esta situación desdibuja (o incluso viola) la ideas expresadas inicialmente en el manifiesto ágil.

Esto ha sido advertido por varios referentes de la industria mucho antes de que Fowler acuñara este título y ha generado a mi entender 2 corrientes:

  • Por un lado están lo que “luchan” con el “Agile Industrial Complex” intentando “reencauzar” el movimiento ágil.
  • Por otro lado están quienes en cierto modo han cortado por lo sano, inaugurando nuevos movimientos como Heart of Agile, Modern Agile, y Software Craftsmanship. 

Personalmente creo que yo también soy parte de este Agile Industrial Complex y no me gusta. Me incomoda. No estoy en contra de que se hagan negocios a partir de Agile pero me molesta cuando esos negocios se hacen utilizando el nombre/marca Agile sin respetar las cuestiones esenciales. No se puede hablar/vender Agile Software Development dejando de lado la excelencia técnica, la auto-organización, la entrega de valor y la mejora continua.

En un momento pensé en dejar de utilizar el término “Agile/Ágil” y en su lugar hablar de “Desarrollo Adaptativo” o “Ingeniería de Software centrada en el Valor” pero esas alternativas (al igual que algunas otras) no terminaron de convencerme pues si bien son correctas conceptualmente, no resultan cómodas. Finalmente decidí intentar evitar el término “Agile” y hablar de prácticas más concretas como Continuous Delivery, TDD y Planificación Adaptativa.

Continuará…

Taller online de Docker/Kubernetes

Taller online de Docker/Kubernetes

Hace tiempo que vengo haciendo experimentos con distintas técnicas de enseñanza/entrenamiento y finalmente he decidido hacer un taller online. Una parte de la motivación pasa por pura curiosidad y otra parte tiene que ver con un experimento para mi maestría en informática aplicada a educación.

La temática del taller será Docker/Kubernetes. Lo dictaré durante el mes de Enero y tendrá una carga horaria de unas 5 horas semanales divididas en 2 horas de trabajo online (clase + consultas) y unas 3 horas de trabajo offline (tareas varias como lecturas, videos, programación, etc.). Los horarios de los encuentros online los definiré en conjunto con los interesados en participar del taller.

Inicialmente pensaba hacerlo gratuitamente, pero estoy harto de organizar eventos gratuitos en los que rápidamente se completan los cupos de inscripción y luego asisten tan solo 35% de los inscriptos. Explicado mi punto de vista, el taller tendrá un costo de u$d 50 (dólares) para profesionales y 15 dólares para estudiantes que no trabajan.

A grandes rasgos el temario del taller será:

  • Introducción a Docker
  • Consideraciones para la elección de imágenes base
  • Recomendaciones para la creación de imágenes
  • El ecosistema de herramientas Docker
  • Tecnologías de contenedores más allá de Docker
  • Introducción a Kubernetes
  • Recomendaciones para el diseño de aplicaciones Kubernetes
  • Manejo de configuración con Secrets y ConfigMaps
  • El ecosistema de herramientas Kubernetes
  • Deploy y monitoreo
  • Distribución de aplicaciones Kubernetes con Helm

El taller está destinado de más a usuarios de kubernetes que a administradores de Kubernetes por ello no se cubriran cuestiones tales como la instalación de Kubernetes.

Los interesados pueden completar este formulario de inscripción y si tienen consultas pueden escribir un comentario en este post.

#camino-docker: elección de la plataforma

#camino-docker: elección de la plataforma

Cuando una organización decide adoptar Docker debe decidir de qué runtime utilizará. En forma simplificada y a muy grandes rasgos podríamos decir que hay 2 estrategias posibles:

  1. Correr directamente docker-machine/docker-compose en sus servers
  2. Correr una plataforma de administración/orquestación de contenedores

Entre estos dos extremos hay algunas otras opciones que están a mitad de camino como ser Nomad, que combinándose con otras herramientas puede proveer funcionalidades comparables con las de un administrador/orquestador.

Personalmente la opción 1 me parece medio precaria y no aplicable a algunos escenarios ya que implica tener que resolver N cuestiones adicionales que en la opción 2 ya vienen resueltas como ser escalabilidad y disponibilidad.

Entonces, suponiendo que uno elige la opción 2 aparece otra decisión a tomar: qué plataforma de administración de contenedores utilizar. En este sentido Kubernetes, la plataforma de administración de contenedores open source desarrollada por Google, viene con un crecimiento muy importante. Este crecimiento está evidenciado por el hecho de que varios vendors (Microsoft, RedHat, IBM, Amazon, etc) han generado productos/servicios basados en Kubernetes. Un punto a tener presente para tomar esta decisión es si uno pretende correr on-premises o en la nube pues a partir de ello uno tendrá ciertas opciones para correr su propio cluster de Kubernetes o podrá directamente utilizar “Kubernetes as a  Service” transfiriendo el costo de administración del cluster a un proveedor.

Personalmente, en términos de cloud he estado en proyectos utilizando el servicio de Kubernetes de Google, mientras que en escenarios on-premises he estado en proyectos utilizando OpenShift. Actualmente estoy en un proyecto que utiliza la solución on-promises de IBM que está basada en Kubernetes. Hay dos opciones bastante populares con las que aún no he tenido oportunidad de trabajar: Amazon EKS y Azure AKS.

El desafió de Enseñar a Diseñar

El desafió de Enseñar a Diseñar

Desde mi comienzo en la carrera docente siempre he estado en materias que en mayor o menor medida han incluido la temática de diseño de software. Cuando estaba en Algo3 y AyDOO era diseño a nivel de clases, ahora en MeMo2 cubrimos un poco de diseño a nivel de clases y también diseño de más alto nivel (arquitectura e infraestructura). Enseñar a diseñar es una tarea que me parece muy difícil. De entrada debemos decir que no hay diseños “malos” o “buenos”, sino que un diseño podrá ser más o menos conveniente dependiente del contexto. Un diseño es consecuencia de un conjunto de decisiones, diseñar es decidir, elegir. Pensando en el proceso de diseño veo al menos 3 pasos:
  1. Entender el contexto, el problema a resolver, las restricciones y necesidades. Esto es lo que Kazman denomina Architectural Drivers.
  2. Entendido el contexto hay que identificar las decisiones relevantes que deben tomarse.
  3. Finalmente para cada decisión relevante hay que analizar las posibles alternativas y elegir una. Esto puede implicar hacer algunas pruebas de concepto para poder tomar decisiones con evidencia que las respalde.
El punto 1 cae dentro del área denominada ingeniería de requerimientos y cuenta con un amplio cuerpo de conocimiento. El punto 2, ya es más complejo y más allá del cuerpo de conocimiento requiere de experiencia, lo cual es bastante difícil de transmitir. El punto 3 también reviste de complejidad pero creo que en general es más fácil que el punto 2. A mi parecer identificar opciones y evaluarlas para decidir es una trabajo en esencia muy ingenieril. A comienzo de año estábamos hablando con mi colega docente Diego Marcet sobre los criterios de corrección de un ejercicio de AyDOO y lo vimos:
Pretender que en un cuatrimestre académico alguien aprenda a diseñar es demasiado ambicioso, o sea, se puede enseñar algún método/heurística pero pretender dominarlo y generar buenos resultados puede ser difícil. Por ello ajustamos nuestro objetivo para centrarnos en dar a los alumnos herramientas para ser capaces de detectar las decisiones importantes y al mismo tiempo que sean capaces de detectar decisiones inapropiadas para un contexto dado.
De cara a este objetivo trabajamos bastante sobre código ajeno, o sea, analizando y extendiendo código existente. Continuará….
Fin de proyecto

Fin de proyecto

Luego de 3 intensos meses esta semana terminé mi segundo proyecto inmersivo del año.  Me sumé al equipo para dar una mano con cuestiones de arquitectura y operaciones, pero como de costumbre, al trabajar inmersivamente con el equipo uno siempre termina en medio en otras cuestiones. En estos tres meses además de completar diversas funcionalidades también hicimos lo siguiente:

  • Corrimos pruebas de performance y en base a ellas hicimos diversos ajustes en la aplicación.
  • Diseñamos e implementamos una infraestructura escalable basada en AWS
  • Implementamos un proceso de despliegue automatizado basado en CodeDeploy
  • Instrumentamos la aplicación para posibilitar su monitoreo con New Relic y CloudWatch
  • Pasamos de un esquema de trabajo basado en iteraciones de 2 semanas a un esquema de entrega continua liberando funcionalidad tan pronto como se completa

En verdad disfrute mucho ser parte del equipo y estoy muy conforme con el trabajo realizado.