DevOops! tal vez igual sirve

Hace un tiempo escribí sobre algunos malentendidos de DevOps en la práctica, hoy quiero compartir algunas otras situaciones a la luz de una definición formal.

De acuerdo a Len Bass y sus colegas del SEI DevOps tiene 5 pilares fundamentales:

  1. Operaciones como ciudadano de primera categoría en el proceso de software delivery
  2. Involucramiento de los desarrolladores en los incidentes productivos
  3. Un proceso formal de deployment
  4. Continuous Delivery
  5. Infrastructure as Code

Pero en la práctica veo que muchas organizaciones que:

  • Pasan completamente por alto los dos primeros puntos, son cuestiones casi “culturales” que no son triviales de cambiar.
  • Van directo al punto 5, incorporan herramientas para la automatización de infraestructura para lo cual contratan algunas nuevas personas, típicamente bajo del rol de “Ingenieros DevOps”. Hacer esto es muy más simple que pretender cambiar una estructura organizacional o un mindset.
  • El punto 4 lo toman solo parcialmente, invierten en la automatización de pipelines de despliegue (tarea que hacen los recientemente incorporados “Ingenieros DevOps”) pero ni noticia de la automatización de pruebas (claro, los DevOps no automatizan pruebas)
  • El punto 3 lo logran como un efecto colateral de la automatización de los despliegues.

El resultado dista bastante de la idea de DevOps de Bass, pero no es tan malo porque a pesar de ello representa una mejora radical respecto de la situación previa.

#HistoriaDeTrinchera: equipo completo

Al cabo de 6 iteraciones hemos completado el equipo. Resulta que al comenzar la sexta iteración se sumó el miembro faltante. Tenemos ahora cubiertos todos los roles/habilidades que consideramos necesarios para llevar adelante el proyecto y al mismo tiempo hemos alcanzado, a mi criterio (no estoy seguro que mis colegas compartan) el número máximo de personas que el equipo puede tener.

Nuestra expectativa es poder tener dentro del equipo todas las habilidades (y autorizaciones) para operar en un esquema de entrega continua dentro de ciertas restricciones organizacionales que por el momento no parecen estar abiertas a negociación (tema de otro post). En este sentido tenemos los siguientes roles/habilidades:

  • Developer
  • Tester
  • Diseñador de UI/UX
  • Facilitador
  • Product Owner
  • Infraestructura

Estos roles/habilidades son ocupados por personas que están en el día a día del proyecto y que como tal participan diariamente de las reuniones de sincronización (daily standups). Algunas aclaraciones que pueden resultar relevantes para el lector:

  • Developers: apuntamos a que puedan desarrollar una funcionalidad de punta a punta, lo cual implica tanto hacer tanto front (angular) como back (netCore) y tocar algunas cuestiones de infra como pipeline de CI/CD y generación de los correspondientes contenedores.
  • Testers: en el sentido de Agile, trabajan muy de la mano de la gente de negocio y con una visión funcional. Colaboran en la identificación/definición de casos y también en su automatización.
  • Diseñadores de UI/UX: diseñan/validan la experiencia del usuario y definen las pantallas. Trabajan muy de cerca con la gente del negocio y los usuarios. No codean, su trabajo llega hasta el maquetado con alguna herramienta tipo Miro, Marvel y Zeplin.
  • Facilitadores: llamados a veces Scrum Masters o coaches, ayudan a que el equipo mantenga el foco en el proceso y la entrega de valor, destraban impedimentos y mantienen los diálogos abiertos con otros equipos/áreas.
  • Product Owners: es gente con perfil de negocio que define el norte del producto, concentra los pedidos de los usuarios y los prioriza.
  • Infraestructura: más allá del control que tenga el equipo sobre la infraestructura es fundamental que el equipo entienda (y pueda definir y discutir) ciertas cuestiones de infraestructura porque pueden impactar en la implementación de algunas características/funcionalidades de la aplicación. En este caso particular, la organización tiene un área de DevOps con la cual nosotros como equipo de desarrollo trabajamos muy cerca en un ida y vuelta constante. Luego ese equipo de DevOps se encarga de la interacción con el resto de los sectores de infraestructura como seguridad, networking, etc.
    (este es un punto que puede resultar polémico y por ello le dedicaré un post aparte)

Todo este conjunto de roles/habilidades está repartido entre 12 personas, varias de ellas con asignación parcial (yo entre ellas). Para mi gusto ya son demasiadas personas y como algunos colegas coinciden con esto, es muy posible que en el corto/mediano plazo sumemos más gente y partamos el equipo en 2.

Notas del Consultorio DevOps

Ayer hice la actividad online del Consultorio DevOps y personalmente me parece que fue un éxito. Durante toda la sesión hubo alrededor de 25 personas conectadas. Fueron aproximadamente unos 80 minutos de sesión.

Comencé compartiendo algunas definiciones y estudios académicos y luego largamos las consultas y el debate. Personalmente me gustó mucho como salió la actividad. Me resultó muy gratificante encontrar entre los participantes algunos ex-alumnos y algunos lectores habituales de mi blog.

Le agradezco a todos los participantes y estén atentos porque el martes próximo (7 de Abril) se viene otra sesión (más info en breve).

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

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.

El polémico perfil del Ingeniero DevOps

El polémico perfil del Ingeniero DevOps

Ayer estuve participando del Meetup de Infrastructure as Code. Hubo un par de presentaciones y luego un panel de debate con los disertantes. En ese contexto un participante planteó una consulta sobre la formación de perfiles DevOps. Yo di una respuesta que me parece resultó polémica para algunos: no creo en un perfil DevOps.

A esta altura claro está que DevOps es un mindset que busca remover las fricciones típicas entre las áreas de Desarrollo y Operaciones a partir de un trabajo colaborativo y la implementación de ciertas prácticas. No creo que esto implique un nuevo perfil ya que me parece que no hay nuevas responsabilidades ni tareas. Es cierto que entre las prácticas “novedosas”que propone DevOps está el manejo de infraestructura como código, pero no creo que amerite un nuevo perfil, pues la infraestructura ya era una cuestión que teníamos que administrar, la novedad está en todo caso en la forma en que lo haremos: ahora quienes esten a cargo de la administración de la infraestructura deben escribir código ¿vamos a contratar nuevos perfiles para eso o vamos a pedir a los sysAdmins o developers que se encarguen? Yo voto por esto último.

Por otro, si uno mira las búsquedas de perfiles DevOps, en general se encuentra con una extensa lista de conocimientos técnicos y de herramientas, pero casi nada sobre “soft-skills”, o sea: DevOps tiene que ver con colaboración, supongamos por un momento que generamos un nuevo perfil (Ingeniero DevOps) para que facilite que la organización pueda trabajar de en una cultura DevOps ¿no debería entonces ese perfil de Ingeniero DevOps tener ciertas habilidades de facilitación, generación de acuerdos, vocación de servicio, etc? Pues para varios parece que no, pues estas cuestiones son muchas veces omitidas en las búsquedas de DevOps.

Continuará…

Review of my DevOps Tutorial @ Profes 2019

I delivery this tutorial yesterday morning. Seven people participated on it: 2 from Austria, 2 from Spain, 2 from Finland and 1 from Germany.

The tutorial flowed as expected but I would have like to have 30 extra minutes to cover the Continuous Delivery part with a hands-on exercise.

Participants evaluated the tutorial with 5 points out of 5 🙂

Here is the formal summary of the tutorial.

Prácticas DevOps para todos y todas

Este fue el título de la charla que estuve dando el lunes pasado en el meetup de Software Crafters Barcelona. La charla estuvo basada en el material de mi charla “No contrates Ingenieros DevOps”, pero decidí darle una dinámica distinta. Inicialmente hice una introducción al mindset DevOps y luego debatimos sobre el rol del Ingeniero DevOps usando una dinámica de Fishbowl. Finalmente cerramos revisando algunas prácticas para intentar acercar y mejorar el flujo de la gente de Dev y gente de Ops.

Me gustó mucho la forma en que fluyó la actividad. Luego de la charla nos quedamos compartiendo unos tragos con los participantes. Agradezco a la comunidad de Crafters, a la gente de Voxel Group y a Adrián Perreau porque hicieron posible el meetup.

Comparto aquí algunos recursos que mencioné durante la charla:

DevOps Tutorial at Profes 2019

Next week I will deliver my DevOps Tutorial at the International Conference on Product-Focused Software Process Improvement, Profes 2019. This will be my second time delivering this tutorial in Europe, but this time I have updated the tutorial to include Kubernetes-related content and of course I had to remove some other content that was not so relevant.

The conference will be held in the North Campus of the Technical University of Barcelona. The tutorial is scheduled for November 27 morning.

For those that plan to participate ensure to install the following software on your notebooks: an Ssh client, Git and Docker Desktop (or docker-engine for those running on Linux).

Estructura de equipo para desarrollo de producto

Desde hace un tiempo estoy trabajando un equipo de producto de más de 20 personas y estamos organizados en una estructura que es nueva para mi pero que al mismo tiempo me parece viene resultando efectiva. La siguiente figura resume esta estructura.

Si bien todo el equipo de producto son más de 20 personas, en el día a día estamos divididos en 4 equipos: 3 feature teams y 1 equipo de toolsmiths (este nombre lo tomé del enfoque FDD, pero no es el nombre real del equipo)

Los 3 feature teams trabajan en funcionalidades del producto y están en el día a día con gente de negocio.

El equipo de toolsmiths es donde yo trabajo. Actuamos como proveedores/facilitadores de los features teams y nos encargamos de mantener/optimizar la infraestructura de desarrollo: repositorios, build server, ambientes, etc. Incluso en ocasiones agregamos código al producto, pero obviamente relacionado a cuestiones de soporte/infra como feature flags, health endpoints, etc. Como parte de nuestro trabajo tenemos que interactuar con otros grupos de soporte organizacional que se encargan de infraestructura de base y regulaciones (seguridad, red, etc). En el equipo somos 3 personas con skills mixtos: podemos codear, agregar tests, configurar servers, scriptear infraestructura pero sobre todo podemos hablar con otros grupos y generar concenso. Alguien podría tentarse de decir que somos DevOps, pero no lo vemos así, porque de entrada no creemos que DevOps sea ni un rol ni un área, sino un mindset con un conjunto de prácticas.

No se si este es el mejor enfoque para la estructura de un equipo de producto, pero consideramos que nos viene resultando bien: el negocio está contento, los distintos equipos están contentos, el producto está estable y tenemos la capacidad de ir a producción bajo demanda y de forma altamente automatizada.