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.

Primeras Jornadas de Ingeniería de Software del Uruguay

Los días 16 y 17 de Octubre se realizarán en Uruguay las Primeras Jornadas de Ingeniería de Software y tengo el honor de haber sido invitado como orador.

En ese contexto estaré hablando sobre unos de los temas “calientes” de la actualidad: DevOps. Concretamente el título de mi disertación será “DevOps, myths and facts of a new paradigm“. También estaré dando un taller enfocado en Test-Driven Development, Continuous Integration y Pair-Programming.

Las jornadas son de entrada libre y gratuita pero es necesario registrarse. Pueden encontrar más información en la página del evento y siguiendo la cuenta oficial de twitter.

Gestión de ambientes y Diseño de Infraestructura para DevOps

EL próximo Jueves 26 estaré dando una charla abierta sobre esta temática:

El manejo de ambientes de desarrollo y tests es un tema relevante a la hora de intentar optimizar el flujo de valor de todo proyecto de desarrollo de software. En este contexto la práctica de Self-Service Infrastructure puede ayudar a una organización a simplificar el manejo de estos ambientes, dando más libertad a sus equipos de desarrollo sin sacrificar estabilidad. En esta charla veremos los principios, beneficios y desafíos de esta práctica, junto con algunos patrones y herramientas para su implementación. Entre otras cuestiones hablaremos de modelos de infraestructura, continuous delivery, infraestructura como código y chatops.

La cita es este Jueves 26 a las 19.00 hs en Facultad de Ingeniería de la UBA (Paseo Colón 850), aula 319. Interesados por favor registrarse en este Meetup.