Mis sesiones en Agile 2017

En agosto estaré participando por primera vez en la conferencia Agile donde estaré presentando dos sesiones:

Ambas sesiones están inspiradas en las experiencias y lecciones aprendidas que he recolectado en los últimos años. Ambas sesiones son en formato presentación con una duración de 75 minutos (con espacio de preguntas incluido).

A modo de ensayo, estaré dando la segunda de estas sesiones el próximo Jueves 20 de Julio en el contexto del Meetup de Ágiles Argentina. La cita es en la Facultad de Ingeniería de la UBA a las 19 horas (aula a confirmar).

DevOps: dos caminos, un objetivo

En mi experiencia, cuando una organización quiere adoptar una estrategia DevOps, hay una cuestión central que determina en gran medida el plan de trabajo: ¿ya está esa organización operando? Veamos dos ejemplos para que se entienda a que me refiero.

Caso 1: supongamos que la organización en cuestión es un banco que ya lleva varios años en funcionamiento y por lo tanto ya está operando. Posiblemente tenga un todo un grupo de gente dentro de área de IT dedicada a la operación. En este tipo de casos la motivación de la iniciativa DevOps pasa en gran medida por optimizar procesos existentes de cara a mejorar la entrega de valor, el costo de operación y el time-to-market.

Caso 2: en este caso la organización es una startup que ha trabajado por un par de meses en generar un mínimo producto viable y que para ponerlo en funcionamiento necesita definir un esquema de operación. En ese contexto la organización quiere desde el comienzo que su esquema de operaciones sea concebido en el paradigma DevOps.

En ocasiones el caso 1 puede resultar bastante complejo ya que una iniciativa DevOps suele tocar los intereses de algunas personas y sacar de la zona de confort a otras tantas. Sin embargo hay un punto a favor muy importante: la organización ya está operando, bien o mal, pero operando al fin. Ya hay ciertas cuestiones que la organización sabe hacer.

Al mismo tiempo en el caso 2, como se trata de una organización nueva, la gente suele estar más abierta, lo cual es muy positivo para la inicitiva. Pero al mismo tiempo hay un desafió muy grande: la organización aún no está operando y para empezar a hacerlo (ya sea en modo DevOps o no) hay una serie de decisiones críticas que deben tomarse.

Estas dos realidades distintas pueden impactar de manera determinante en la estrategia de adopción DevOps.

Continuará…

Categorias de prácticas DevOps

Por estos días me encuentro leyendo el libro de DevOps del SEI que me compré el mes pasado. Llevo leído aproximadamente un tercio de libro y por el momento viene bien, o sea, la mayoría de las cosas ya las conocía, algunas pocas no y otras pocas no estoy seguro de compartirlas. Entre las cosas que no conocía hay una en particular que me resultó muy interesante: la categorización de las prácticas DevOps. El libro propone agrupar las prácticas en 5 categorías:

Hacer al grupo de Operaciones un ciudadano de primera clase (first-class citizen).
Hacer al grupo de Desarrollo responsable del manejo de los incidentes en producción
Establecer un proceso formal de deployment
Usar Continuous Deployment
Manejar la infraestructura como código

En teoría todas las prácticas DevOps podrían caer en alguna de estas 5 categorías. A mi parecer las 3 primeras categorías son más de índole «cultural» o de proceso, mientras que las 2 últimas son más de índole técnica. En este sentido el poder hacer la distinción puede ayudar a la hora de armar un plan de adopción de DevOps.

El equipo de DevOps

Como mencioné anteriormente ya estamos en producción y dado que el cliente no tiene un area de sistemas está acordado que nosotros mismos nos encarguemos de la operación. Para esto armamos el equipo «DevOps», y para ser sincero debo admitir que inicialmente el nombre no me cerró, yo lo habría llamado directamente «operaciones». Pero creo que la intención al llamarle «DevOps» fue ya desde el nombre intentar transmitir el mindset con el que se quiere trabajar. En fin, en punto del nombre no es tan relevante. Creo que lo interesante es la forma en que estamos intentando trabajar. En este momento somos 3 personas:

Una persona con skills de operaciones/sysadmin y automatización (en particular usando Chef)
Una persona proveniente del equipo de UI (js/html/css)
Una persona proveniente del equipo de desarrollo server-side (C#). Este soy yo, que adicionalmente estoy oficiando de «facilitador» del equipo

Para la coordinación/organización del equipo estamos usando las siguientes herramientas:

Una lista de correo
Un canal de Slack
Un tablero Kanban (en Jira)

Respecto de la dinámica de trabajo, trabajamos en un flujo continuo, limitando el work-in-progress e intentando planificar semanalmente. En este sentido cada lunes reportamos los items completados la semana anterior e identificamos los items más prioritarios para trabajar en la semana actual. Luego con el correr los días se van sumando a nuestro backlog nuevos items que debemos atender en forma inmediata. En todos los casos estos items «urgentes y no planeados» los registramos en el Jira para que quede constancia de nuestro trabajo.

Respeto del tipo de tareas que realizamos, en este momento tenemos 3 hilos de trabajo principales:

Automatizar el provisionamiento de toda nuestra infraestructura
Armar la arquitectura de build y el pipeline de deployment
Atender pedidos puntuales de los equipos de desarrollo (por ejemplo asistir a un equipo en la configuración de alguna herramienta cuya configuración aún no está automatizada)

Un punto que puede resultar curioso es que este equipo de operaciones no se encarga completamente de la operación, al menos no por ahora. En este momento tenemos una solo aplicación en producción pero es el equipo que la desarrolló quien la monitorea y atiende eventuales alertas.

Por el momento me gusta la forma en que esto está fluyendo, pero recién empezamos, ya veremos como evoluciona.

PCE-Evolution: An infrastructure pattern

Beyond which environments I use on different project/organisation there is one recurrent strategy that I have applied several times in different context. I may say it is a pattern.

The problem

Like any pattern explanation it should start with a problem, so here it is: it is very common production environments to be large in term of hardware capacity and also in size of data. This makes difficult (and/or very expensive) to replicate the production environment to test your application. If you test in an environment different from the production environment you are taking a risk, and the bigger the difference is the higher the risk you are taking.

The solution

Your application pass through different environments from you local development machine to the final production environment. These two environments are the extremes of your pipeline, so you should make use that each intermediate environment is «closer» to the production environment.

Example

Local development environment (your workstation): here you run the whole application in an isolated way, you have a local DB installed and external services dependencies may be mocked. Your hardware is not comparable to production’s hardware. Even your OS may be different: you may use Windows 10 or Mac or Ubuntu Desktop, while your production server may run Windows Server or Ubuntu Server. In terms of the previously mentioned dimensions, all of them are different from production.

Development environment: your hardware is still far from production, but at least you have the same OS asp production but the other dimensions are still different.

Test Environment: here your layout is the same as production, that is: if you have a cluster for the production DB, then you also have a cluster for test DB but possibly your test DB cluster has less servers that the production one.

This way the closer to production the more Production-like, Complex and Expensive.

Una visión formal/académica sobre DevOps

Ayer por la tarde «me interné» en un local de Barnes&Noble y recorriendo la sección de libros de tecnología me encontré con un libro cuya existencia desconocía: DevOps, a Software Architect’s Perspective de Len Bass y Cía.

Apenas leí el índice no dudé ni un instante en comprarlo ya que es el primer libro que veo sobre esta temática de una fuente «formal/académica» como es el SEI-CMU.

Anoche empecé a leerlo y por el momento pinta muy interesante.

DevOps se busca ¿como sería tal cosa?

Desde hace un tiempo estamos en la búsqueda de una persona con perfil «DevOps» lo cual para algunos resulta imposible ya que tal perfil no existe ¿¡!?.

Uno de ellos es mi colega @carlospeix con quien mantuvimos una muy entretenida charla ayer por la tarde al respecto de este tema. Coincido completamente con la visión de Carlos: DevOps no es un rol sino un mindset, una forma de colaboración entre entre las áreas de desarrollo y operaciones, un estrategia distinta para realizar las tareas que típicamente atañen a estas áreas.

Sin embargo muchos ven «DevOps» como un perfil, lo cual puede apreciarse con una simple búsqueda en LinkedIn donde uno encontrará miles de profesionales etiquetados como «DevOps». Bueno, ponele que sí, que DevOps es un perfil entonces ¿que habilidades, capacidades y conocimientos debería tener una persona con este perfil?

En primer instancia el término sugiere una mezcla de desarrollo y operaciones, de developer y sysadmin. Alguien que debería poder construir una aplicación, ponerla en un ambiente productivo y operarla. Si, en principio es eso lo que yo esperaría de mínima, pero también algo más. Esperaría una persona con muy buenas habilidades de comunicación y facilitación.

Curiosamente, la gran mayoría de CVs de DevOps que me visto mencionan una larga lista de herramientas, pero poco dicen de las llamadas «habilidades blandas». Y algo similar ocurre con los avisos de búsqueda de DevOps que he visto publicado por muchas organizaciones.

En fin, volviendo al tema original, estamos buscando un profesional con los siguientes conocimiento/habilidades:

Administración de ambientes Windows
Administración de ambientes AWS
Programación en .Net / C#
Programación con alguna herramienta automatización (Chef, Ansible o similar)
Muy buena comunicación
Habilidades interpersonales
Lean / eXtreme Programming / Scrum
Idioma inglés

Interesados no duden en contactarme.

Estrategias de provisioning + deployment (parte 2)

En el proyecto en el que estoy trabajando actualmente utilizamos Ansible para hacer el provisioning de la infraestructura y CodeDeploy para manejar el deployment. CodeDeploy es un servicio que Amazon provee gratuitamente a los usuarios de EC2, la plataforma cloud de servidores virtualizados de Amazon.

El funcionamiento de CodeDeploy es bastante simple: copia archivos desde Github o S3 hacia el servidor destino y permite como parte de ese proceso ejecutar algunos scripts. Pero más allá de este funcionamiento simple, la parte más valiosa de CodeDeploy es la capacidad de trabajar en conjunto con el mecanismo de auto-scaling de Amazon de forma de simplificar el deployment a una cantidad variable de instancias ofreciendo incluso algunas variantes de estrategia (one-by-one, all-together, half-and-half).

La siguiente imagen ofrece una vista de alto nivel del proceso de deployment que estamos usando en el proyecto.

Continuará…

Estrategias de provisioning + deployment (parte 1)

En los últimos años he participado en diversos proyectos utilizando diversas estrategias de deployment. Dado que este es un tema que está despertando cada vez más interés me parece que puedo colaborar compartiendo las experiencias que he tenido.

Esta primer estrategia que quiero compartir está basada en Puppet y en paquetes Debian. Todo el provisioning del ambiente se hace utilizando Puppet y luego para el deployment se usa el siguiente proceso:

Jenkins buildea la aplicación y genera un paquete Debian incluyendo la aplicación buildeada.
El paquete generado se publica en un repositorio de paquetes Debian.
Se actualiza el Puppet master con la definición del nuevo paquete.
Se envía un mensaje a cada máquina del ambiente para que el agente Puppet actualice la máquina instalando el nuevo paquete que trae la nueva versión de la aplicación. (esto es necesario porque generalmente no se quiere una actualización automática de los agentes y por ello su actualización automática está desactivada)

Algunos puntos interesantes de esta estrategia son:

Es muy fácil realizar el rollback pues se hace utilizando el sistema de paquetes del sistema operativo
El tratar nuestra aplicación como un paquete del sistema operativo gozamos de todos los beneficios/funcionalidades que provee el sistema operativo para gestión de paquetes. Un ejemplo de esto es la posibilidad de explicar las dependencias de nuestra aplicación con otros paquetes dejando así que el propio gestor de paquetes se encargue de su resolución.
Si bien en mi descripción me refiero a paquetes Debian (.deb) lo mismo puede hacer con paquetes de otras distribuciones.
Dependiendo de cómo se armen los paquetes, se puede incluir en los mismos los archivos de configuración de la aplicación.

sopackages_puppet

Esta estrategia (y algunas más) la estaré compartiendo con mayor profundidad en mi Taller de prácticas de DevOps que dictaré el próximo 19 de abril.

Continuará..

Blog de NicoPaez

Ingeniería de Software, Docencia y Programación

Etiqueta: devops