Nueva edición del taller de Prácticas DevOps y Continuous Delivery

Los días 28 y 30 de mayo estaré dictando estos dos taller junto a la gente de 10 Pines. Como siempre hice algunos ajustes en el contenido:

  • Agregué un ejercicio de Kubernetes puro, que complementa el ejercicio de OpenShift que ya tenía
  • Actualicé el setup de los ejercicios de Jenkins para usar Docker como builder
  • Actualicé el material de teoríco incluyendo algunos slides con cuestiones que leí en el workbook de SRE.

Los interesados pueden encontrar más detalles en la página de 10 Pines University:

Sobre el State of Agile Report 2019

Hace un par de dias se publicó este reporte surgido de la encuesta que realiza anualmente la empresa Version One. Los resultados no me soprendieron, al contrario, me resultaron muy familiares respecto de lo que veo en mi día a día.

En el resumen ejecutivo se destacan tres puntos.

1. Scrum (y SAFE) sigue siendo el enfoque agile más popular

No me sorprende y en un punto me parece esperable ya que más allá de las bondades de Scrum, es el enfoque ágil con mayor marketing: Scrum Alliance, Scrum.Org, Certified Scrum zaraza, etc

2. La cultura organizacional es el mayor impedimento para adopción y escalamiento de agile

Me parece esperable considerando que agile es un mindset, una forma de hacer las cosas e incluso un forma de pararse frente a los problemas y desafios

3. DevOps es cada vez más relevante

Tengo la sospecha que esto se debe a que mucha de la gente que trabaja con Scrum, hace en realidad un Flaccid Scrum, o sea, solo aplican la parte de gestión de Agile. Pero en un punto toman conciencia que sin prácticas técnicas varias “promesas de Agile” no son posibles. Pero como ya se gastaron todo el presupuesto de Agile en tomar los curso de “Certified Scrum/Agile XXXX” ahora necesitan otro buzzword para conseguir presupuesto y ahí está DevOps al alcance de la mano.

Sobre las Certificaciones DevOps

Sobre las Certificaciones DevOps

El tema certificaciones en el mundo IT siempre ha generado polémicas. Recuerdo que en mis primeros años de universidad estaban muy de moda las certificaciones de Sun, Oracle y Cisco.

Tiempo después se pusieron de moda las certificaciones de Agile. En particular la certificación de Scrum Master se ha vuelto muy popular (y muy debatida).

El año pasado se popularizó una ola de certificaciones de “Agile a Escala” con temas tales como SAFe, LeSS y Nexus.

Ahora me parece que estamos en una nueva ola de certificaciones. En los últimos 10 días recibí dos consultas concretas sobre certificaciones DevOps. Para sorpresa de algunos efectivamente existen certificaciones DevOps, listo algunas aquí:

Yo personalmente no tengo ninguna certificación, ni tampoco ofrezco certificaciones por los los cursos que dicto.

Apt-Get install, un arma de doble filo

Primero un poco de contexto. APT son las siglas de Advanced Package Tool, una interface del sistema de paquetes de Debian Linux (y derivados). APT ofrece un conjunto utilidades para administrar paquetes (librerías y aplicaciones). Adicionalmente existen aplicaciones de más alto nivel como (Aptitude o Synaptic) que utilizan APT. A su vez APT utiliza otro utilitario llamado dpgk. O sea que la cadena de dependencias es: Aptitude => APT => dpgk. En particular quiero referirme a APT pues es la herramienta que más suelo utilizar de este conjunto.

APT (apt-get o simplemente apt dependiendo de la versión de sistema operativo que se utilice) permite utilizar el comando install para instalar paquetes: apt install X. Así de simple. Esta sentencia en términos simplificados consulta un conjunto de repositorios en la nube para ubicar el paquete en cuestión, lo descarga y lo instala junto con sus dependencias. De entrada el gestor de paquetes viene con una lista de repositorios y es posible agregarle repositorios adicionales. Hasta aquí todo feliz. Mucha gente utiliza APT para instalar aplicaciones en sus computadoras sin mayores complicaciones.

Sin embargo cuando uno quiere utilizar APT para configurar servidores en un contexto de software delivery pueden surgir algunas complicaciones si no se toman ciertas precauciones. Es aquí donde esta herramienta se convierte en un arma de doble filo y de ahí la idea de escribir este artículo.

El punto clave a tener presente es que muchas veces cuando uno ejecuta apt install X no especifica la versión de X, con lo cual los resultados pueden no ser los esperados. Cada versión de sistema operativo viene con ciertas referencias a repositorios y esos repositorios contienen ciertas versiones de paquetes que pueden o no ser las que uno requiere. Se abren aquí un par de opciones:

  • Verificar la versión del paquete que instalaría APT por default
  • Si la versión default a instalar por APT no es la buscada, ver si existe algún paquete con la versión que queremos. Esto podría requerir agregar alguna nueva entrada a la lista de repositorios.
  • Si no se encuentra un paquete APT para la versión que buscamos, entonces tendremos que utilizar algún método alternativo.

Más allá de esto, cuando se trata de servidores de aplicaciones/runtimes yo me inclino por seguir las instrucciones de instalación del propio producto en lugar de utilizar APT (en algunos casos el propio producto recomienda APT como método de instalación).

DevOps: un camino bottom-up

Actualmente estoy trabajando en una institución bancaria colaborando entre otras cosas en una iniciativa DevOps. En forma resumida la iniciativa surgió a partir de varios equipos de desarrollo trabajando en paralelo de forma independiente. Cada equipo fue trazando “su propio camino a producción” con la colaboración de algunos miembros del equipo de infraestructura. Luego, por iniciativa de un gerente de desarrollo, representantes de cada equipo y algunos miembros del equipo infraestructura comenzaron a reunirse para compartir lo hecho por cada uno.

De esta forma, con un esquema de reuniones periódicas, vamos generando acuerdos a partir de las experiencias concretas de cada equipo. Las primeras reuniones fueron un poco caóticas, pero gradualmente van mejorando y agregando más valor. 

A mi parece el uso de un enfoque bottom-up en una institución bancaria es algo novedoso porque tradicionalmente este tipo de organización tienen más a los enfoques top-down. En dicho enfoques top-down hay generalmente un equipo/grupo/gerencia que define/diseña/toma decisiones y luego baja linea al resto de la organización imponiendo dinámicas y políticas que suelen no convencer a la gente que concretamente hace el trabajo de desarrollo/operación.

En los enfoques bottom-up como el que menciono aquí, el trabajo suele ser más lento pero a mi parecer más efectivo ya que se le da voz a los equipos y se construye a partir de su experiencias.

Estrategia de versionado para DevOps, paper aceptado

Hace unos días me notificaron que mi paper Versioning Strategy for DevOps Implementations fue aprobado para ser presentado en Congreso Argentino de Ciencias de la Informática y Desarrollos de la Investigación (CACIDI2018). Comparto aquí el resumen de este trabajo:

DevOps is one of the most popular approaches for software delivery nowadays. Even though there is no unified definition of DevOps, there is wide consensus about the set of practices that are part of it. Two of those practices areInfrastructure as Code and Continuous Delivery, which bring new artifacts into the Software Development lifecycle. These new artifacts have direct impact on Software ConfigurationManagement, which is a well-known practice that has been around for decades in the Software Engineering discipline. In particular, these new practices have a direct impact on VersionControl. This article describes a Version Control Strategy to manage these new artifacts introduced by DevOps initiatives.The proposed strategy covers the identification of artifacts, versioning tools, version naming conventions and traceability between different artifacts versions. The strategy was validated in three cases of real world projects where it was successfully applied. Each case corresponds to a different kind of organization and in each case a different set of tools where used. Based on these cases, benefits and possible improvements are identified.

ArqConf: Infrastructure as Code

El próximo 11 de Octubre se realizará una edición especial de la ArqConf sobre la temática particular de Infrastructure as Code.  En ese contexto estaré dando una charla titulada “Consideraciones de Diseño para un modelo de Infraestructura”. Lo sé, el nombre no resulta muy atractivo pero confío en que contenido resultará valioso:

De la mano de DevOps, SREs y un conjunto de herramientas, la práctica de Infraestructura como Código ha adquirido una gran popularidad en los últimos años. La adopción de esta práctica implica una toma de decisiones que entre otras cosas incluye el diseño de un modelo de infraestructura y la selección de herramientas asociadas. En esta sesión veremos un conjunto de conceptos y recomendaciones para tomar estas decisiones de cara a una efectiva implementación de la práctica de Infraestructura como Código.

La cita es el 11 de Octubre a partir de las 14.30 en las instalaciones de Universidad Tecnológica Nacional, FRBA en Medrano 951, más info y registración en meetup.