Primeras Jornadas de Ingeniería de Software del Uruguay

Los días 16 y 17 de Octubre se realizarán en Uruguay las Primeras Jornadas de Ingeniería de Software y tengo el honor de haber sido invitado como orador.

En ese contexto estaré hablando sobre unos de los temas “calientes” de la actualidad: DevOps. Concretamente el título de mi disertación será “DevOps, myths and facts of a new paradigm“. También estaré dando un taller enfocado en Test-Driven Development, Continuous Integration y Pair-Programming.

Las jornadas son de entrada libre y gratuita pero es necesario registrarse. Pueden encontrar más información en la página del evento y siguiendo la cuenta oficial de twitter.

Gestión de ambientes y Diseño de Infraestructura para DevOps

EL próximo Jueves 26 estaré dando una charla abierta sobre esta temática:

El manejo de ambientes de desarrollo y tests es un tema relevante a la hora de intentar optimizar el flujo de valor de todo proyecto de desarrollo de software. En este contexto la práctica de Self-Service Infrastructure puede ayudar a una organización a simplificar el manejo de estos ambientes, dando más libertad a sus equipos de desarrollo sin sacrificar estabilidad. En esta charla veremos los principios, beneficios y desafíos de esta práctica, junto con algunos patrones y herramientas para su implementación. Entre otras cuestiones hablaremos de modelos de infraestructura, continuous delivery, infraestructura como código y chatops.

La cita es este Jueves 26 a las 19.00 hs en Facultad de Ingeniería de la UBA (Paseo Colón 850), aula 319. Interesados por favor registrarse en este Meetup.

Preparando la versión 5 de mi Taller de Prácticas DevOps

A partir de un pedido de un cliente he empezado trabajar en un nuevo módulo para la versión 5 del taller. Este módulo estará enfocado en el ecosistema Docker (particularmente Swarm, Compose y Kubernetes) y en cuestiones de monitoreo y logging. Estimo que esto podría llegar a extender la duración del taller unas 3 o 4 horas adicionales.

Esta semana debería terminar de completar el contenido conceptual (diapositivas) y la semana próxima debería comenzar a trabajar en el diseño de los ejercicios. Una vez tenga estos ejercicios completos será hora poner fecha para el estreno de esta versión, lo cual con viento a favor será hacia fines de agosto.

Mi enfoque para una adopción DevOps

Recientemente me he encontrado hablando con varios colegas sobre posibles estrategias para “adoptar” DevOps y eso me llevó a poner por escrito lo que viene siendo mi estrategia preferida cuando me toca participar.

De cara  lograr una adopción efectiva de una estrategia DevOps y considerando las experiencias en organizaciones de distinta índole en las que he estado involucrado mi propuesta consiste en 3 fases:

Fase 1: assessment
Me gusta comenzar realizando una primer reunión con quien será el sponsor de esta iniciativa de cara a  asegurar la intención/motivación de todos los sectores involucrados: negocio + desarrollo + operaciones.
Luego suelo pedir al sponsor que encuentre dos equipo de desarrollo que quieran recorrer este camino y que actualmente sea conscientes de algunas limitaciones/situaciones que quieran resolver/mejorar a partir de una iniciativa DevOps. Como siguiente paso propongo realizar un par de entrevistas (~30 minutos) con los equipos identificados y también con gente de las otras área (negocio y operaciones)
Esta fase cierra con un informe y una propuesta de plan a corto plazo y una visión a largo plazo. Para este trabajo estimo un esfuerzo de unas 10 horas máximo y debería poder ejecutarse en 1 semana (o eventualmente 2 semanas si se complica agendar las reuniones). Más allá de las particularidades del caso, la propuesta es trabajar bottom-up, generando consenso desde la gente que realiza el trabajo en el día a día. Esto difiere de otras estrategias muy comunes, generalmente de tipo top-down: los jefes/gerentes/directivos definen como los developers deben trabajar.

Fase 2: exploración
Partiendo de lo realizado en la fase anterior, empiezo a trabajar con 1 de los equipos identificados durante 3 iteraciones (asumiendo que el equipo trabaja en forma iterativa). Yo me sumo al equipo en forma part-time para ayudar en la mejora actuando de coach tanto en lo técnico como en la gestión y coordinación con las otras areas.
Durante la primer iteración relevo el proceso y los impedimentos, y establecemos métricas que nos permitan medir objetivamente el estado actual y la potencial mejora.
Al cabo de dos iteraciones más, debería empezar a notarse alguna mejora en las métricas. En este punto hacemos un checkpoint y vemos si mi participación ha generado alguna mejora razonable y en base a ello decidimos mi continuidad o no.
Aproximadamente en la sexta iteración el equipo ya debería tener una mejora visible y podríamos empezar a replicar el proceso con un segundo equipo.
Habiendo recorrido este camino de mejora con al menos 2 equipos, estamos en condiciones de refinar la visión y definir un plan de implementación a mediano plazo.

Fase 3: expansión
En esta fase trabajamos en implementar el plan de mediano plazo y deberíamos poder generar líderes internos que serán los encargado de materializar el plan de largo plazo. Es aquí donde comenzar a intentar formalizar acuerdos y convención sumando iterativamente más gente a la iniciativa.

 

Materiales de la charla en Madriagil

El miércoles pasado estuve dando una charla en el meetup de Madriagil en las oficnias de RyanAir Madrid.

Agradezco a Israel Alcázar por la coordinación y a David Cuesta por ser anfitrión de este encuentro

Hubo alrededor de unos ~20 participantes. La evaluación general de la charla fue de 4.1/5.

Los slides de la utilizados durante la presentación está disponibles aquí.

Comparto aquí algunas fotos del encuentro.

DevOps Practices Tutorial: Preparation Instructions

My DevOps Practices Tutorial covers a set of tools that my not be easy to setup, so I created a Vagrant configuration to simplify this setup. It does not matter if have no idea about vagrant (you will learn about it during the tutorial) but ensure to perform the following tasks before attending the tutorial session:

  1. Install Git
  2. Install Virtual Box (version 5 o newer)
  3. Install Vagrant (version 2 o newer)
  4. Download this vagrantfile and place it in a directory
  5. Open a terminal and move to the directory where you placed the vagrantfile
  6. Run the command vagrant up, it will download some stuff from the cloud, so it may take some time (depending on your connection it could take around ~10 minutes)
  7. When the vagrant up completes, you should the message “Welcome to NicoPaez DevOps tutorial”

Tareas de un DevOp Engineer

Hoy un colega me consultó si tenía alguna descripción de las tareas que debería hacer un DevOp Engineer y eso motivo a escribir este artículo.

Debo empezar diciendo que no estoy muy convencido de que exista la profesión  DevOp Engineer, o sea: me consta que existe pero dudo que sea conceptualmente correcta su existencia. Al margen de esto: actualmente estoy trabajando como DevOps Engineer en un proyecto, ¡ja!.

Vamos por partes: la idea de DevOps es derribar los silos organizacionales para optimizar el flujo de entrega de valor. Si tenemos un área de operaciones y un área de desarrollo, deberíamos apuntar a que comiencen a trabajar de forma más integrada. En principio no creo que eso requiera de la aparición de un nuevo rol porque en principio no hay una nueva tarea. Alguien podría pensar que sí hay una nueva tarea dentro del grupo de operaciones (o del de desarrollo) y que esa tarea es encargarse de la interacción con el otro grupo. Esto podría tener sentido (de hecho es una de las tareas que estoy haciendo en mi proyecto actual) pero no estoy convencido porque se corre el riesgo de seguir operando como silos.

Por otro lado, dependiendo del estado en que nos encontremos, puede que como parte de la iniciativa DevOps decidamos empezar a utilizar nuevas herramientas (por ejemplo para automatizar tareas). Entonces podría tener sentido incorporar un nuevo rol con conocimiento de  dichas herramientas y de los conceptos que las mismas implementan. Este es justamente mi caso: la organización a la que pertenece el proyecto en el que estoy trabajando ha decido dockerizar su infraestructura y justamente esa la razón de mi involucramiento en el proyecto.

Dicho todo esto, podríamos decir que las tareas de un DevOp Engineer incluirían principalmente:

  • Facilitar el trabajo conjunto de las área de Desarrollo y Operaciones
  • Asistir a los equipos de Operaciones y Desarrollo en las tareas de definición e implementación de arquitectura (lógica y física) de aplicaciones
  • Asistir a los equipos de Operaciones y Desarrollo en la definición e implementación de la infraestructura de CI/CD
  • Asistir a los equipos de Operaciones y Desarrollo en la definición de procesos de monitoreo.

De estas tareas se desprenden una serie de habilidades/conocimientos de distinta índole: “soft-skills”, configuration management, scripting/programación, operación, etc. A mi me suena que una persona aspirante a un puesto así debería tener bastante experiencia en la profesión.

Para cerrar: lo importante es que desarrollo, operaciones y el negocio trabajen en forma conjunta, coordinada e integrada para optimizar el flujo de entrega de valor, la incorporación de un nuevo rol para lograr esto es un detalle de implementación.