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.

Anuncios

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, if will download some stuff from the cloud, so I 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.

 

Spring Config: a key tool for DevOps & Continuous Delivery

Spring Cloud Config (scc) is a tool that provides support to externalize application configuration in a REST Service. The big picture is:

  • Add a SCC client your application so when your application starts, it can fetch its configuration from SCC server.
  • Setup a SCC server, which is a Java REST Service (more specifically is a Spring-Boot application).

The following image offers a overview of how Spring Cloud Config fits in you application architecture.

Some benefits of this strategy are:

  • You decouple the evolution of your application from the evolution of the configuration, that is: you application will be the same in every environment while the configuration will be different in each environment. At the same time the change rate of your application is different from the change rate of the configuration.
  • Your application forgets about where the configuration it stored because it delegates that concern to SCC server.
  • SCC server supports several storage options: Git, File System, Vault, Database, ConfigMaps, etc. The default option is Git which is great because it “force” you to have your configuration versioned.
  • SCC provides several common features related to configuration management like: check the current configuration values, configuration reloading, encryption of secrets and support for different configuration formats among other things.

While working with SCC I faced some issues regarding how to specify its configuration so I want to share some details here.

To make SCC Server read configuration from a remote Git repository:

spring.cloud.config.server.git.uri=https://.....

(this would work fine for public repositories, but if you need to use a private repository, which is a common case, you will need to specify some more parameters like strictHostKeyChecking and privateKey that are very well explained in the official documentation). When SCC server starts, it will clone the remote repository into a local directory whose location will be generated randomly at runtime (but it is also possible to specify the clone location).

To make it work with a local git repository (which contains a .git subdirectory), just use:

cloud.config.server.git.uri=file:///your/local/git/repo

To make ir work with a local “plain” directory we need to specify active profile as “native” which makes SCC server to read the config from a plain local directory (not a git directory)

spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file:/your/directory

It worth mentioning that even when Spring Cloud Config is built on Java, you can use any client technology to consume it because it exposes a REST API. The Spring team provides a Java client, but there are also clients for other technologies.

 

Nueva edición del Taller de Prácticas DevOps incluyendo OpenShift/Kubernetes

El próximo jueves 3 de mayo voy a dictar una nueva edición de mi taller de prácticas devops, pero esta vez con nuevo agregado: OpenShift, la plataforma de gestión de contenedores desarrollada por Red Hat y basada en Kubernetes.

Hacía tiempo que tenía ganas de incorporar al taller algún ejercicio de Kubernetes pero no lograba buscarle para vuelta para que me dieran los tiempos. Finalmente decidí sacar un ejercicio de Puppet para agregar uno de OpenShift/Kubernetes.

Los interesados en participar pueden completar este formulario y los contactaré en breve: