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