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.

test && commit || revert

Esta es una idea experimental de la cual Kent Beck comenzó a hablar hace un par de meses. La primera vez que escuché al respecto me sonó raro. Ya llevo varias semanas dándole vueltas y me sigue resultado raro pero el hecho de haber estado probándolo me permitió reflexionar sobre mi flujo de trabajo al programar.

Más aún, he estado trabajando en un mini-taller exploratorio de TCR para compartir esta idea y poder destilarla en conjunto con otros practicantes. Voy a aprovechar el Open Space que se realizará en Buenos Aires en el contexto de la semana de la agilidad, los interesados traigan sus notebooks, git y ganas de codear.

No más .dlls en Git: infraestructura de desarrollo .Net

Una y otra vez me encuentro con equipos de desarrollo trabajando con tecnología .Net que guardan .dlls (librerías/packages) en repositorios de código fuente. Esto fue una práctica común en una época (lejana) y que yo mismo utilicé en algún momento. Pero desde la aparición de NuGet la gestión de librerías en en mundo .Net tomó un camino distinto.

Cuando uno tiene una dependencia de una librería a nivel binario, simplemente declara la dependencia en un archivo package.json y la herramienta NuGet se encarga de buscarlo en el repositorio binario y descargarlo. NuGet por default busca las librerías/paquetes en https://www.nuget.org/. Sin embargo hay dos casos donde seguramente no encontremos la librería en este repositorio:

  • Si estamos usando librerías de terceros, puede que por algún motivo esos terceros no hayan publicado el correspondiente paquete en nuget.org y dependiendo del tipo de licencia del paquete puede que no tengamos derecho a publicarlo nosotros mismos en un repositorio abierto.
  • Por otro lado es muy común hoy en día con el auge de los microservicios que uno tenga librerías propias que utilice en diversos proyectos de la organización y a menos que nuestros proyectos sean open source, es poco probable que querramos publicar esas librerías en nuget.org

Entonces, para estos dos casos la estrategia a seguir es utilizar un repositorio privado de binarios ya sea on-prem (instalando por ejemplo un Nexus) o utilizando algún servicio en la nube (como por ejemplo myget).

Si ponemos todo esto en contexto, una arquitectura de desarrollo de referencia podría incluir:

  • Un servidor de repositorios de código fuente, por ejemplo alguna implementación de Git como GitHub, GitLab o BitBucket.
  • Un servidor de CI/CD como Jenkins o TeamCity
  • Un servidor de repositorios de binarios NuGet como Nexus, MyGet o Artifactory

Simplificando el setup de Jenkins con Docker

A la hora de hacer el setup de Jenkins hay diversas cuestiones que resolver las cuales pueden variar dependiendo del contexto. En términos muy generales esas cuestiones se resuelven:

  • operando directamente sobre Jenkins, por ejemplo para instalar plugins
  • o bien operando sobre el servidor en el cual Jenkins está corriendo, por ejemplo para instalar un SDK

La importancia que se le da al primer punto es muy variable y depende de si se trata de un “Jenkins Silvestre” (Jenkins manejado por un equipo de desarrollo sin ningún tipo de soporte organizacional) o si se trata de un “Jenkins Corporativo” que es administrado por un grupo de la organización.

Pero el segundo punto, es algo central si pretendemos utilizar Jenkins para buildear. Si queremos utilizar Jenkins para buildear C#, tendremos que asegurar que el servidor donde corre Jenkins tenga el correspondiente SDK instalado (o eventualmente necesitaremos un Jenkins Slave que tenga el SDK.) Esta situación se repite para cada tecnología/lenguaje que uno pretenda buildear. Más allá de la tarea de instalar el SDK en si misma, el punto es que hay que loguearse en el servidor para llevarla a cabo. Una forma de simplificar este setup es utilizar Docker. O sea, en lugar de instalar los SDK en el servidor de Jenkins, uno instala simplemente Docker y luego utiliza un contenedor Docker que contenga el SDK que cada proyecto requiera. Al mismo tiempo esto simplifica el escenario donde tenemos proyectos con dependencias de SDK que tiene conflictos entre si.

A mi parecer esta estrategia aún no está muy difundida pero me parece que a mediado plazo se impondrá como estándar de facto. De hecho, las últimas versiones de Jenkins (las que vienen nativamente con el plugin de Pipeline 2.5 o superior) simplifican mucho este setup. Basta con tener Docker instalado en el servidor de Jenkins y declarar la imagen builder a utilizar en nuestro Jenkinsfile.

El siguiente fragmento de código muestra un job de Jenkins que utiliza una imagen de node 8.9. Lo que hace es trivial, simplemente invoca node –version y escribe el output en un archivo de texto. Lo interesante es que el archivo de texto resultante queda dentro del workspace del job, o sea: Jenkins se está encargando de “sacar” el archivo que se genera dentro del contenedor Docker.

node {
docker.image('node:8.9-alpine').inside {
stage('Test') {
sh 'node --version > version.txt'
}
}
}

Taller Online de Docker & Kubernetes: resultado de la primera edición

La semana pasada completé la primera edición de este taller. Participaron 8 personas, porque si bien hubo alrededor de 30 interesados, decidí limitar la cantidad de participantes pues no estaba seguro de como funcionaría la herramienta de conferencia. Por suerte funcionó bien.

El taller consistió en 4 sesiones online de entre 1 y 2 horas cada una. Estimar la duración de la sesiones es lo que más me costó, en parte por ser un contenido nuevo y en parte por ser una dinámica nueva.

La evaluación de los participantes fue muy positiva:

  • Evaluación general del taller: muy bueno 50% , excelente 50%
  • Evaluación de los encuentros online: muy bueno 66%, excelente 30%
  • ¿Recomendarías este taller a un colega? Definitivamente si 100%

Por otro lado las respuestas de feedback libre fueron también muy positivas. A partir de estos resultados y dado el interés que hay en la temática, en breve estaré anunciado la fecha de la próxima edición. Los interesados pueden pre-registrarse aquí y los contactaré cuando tenga los detalles de la nueva siguiente edición.

Les comparto una foto de mi “estudio de transmisión”. Al centro mi computadora primaria con una segunda pantalla conectada a la izquierda. La pantalla de la computadora la utilizo para pasar las diapositivas y mostrar las herramienta mientras que la pantalla extendida la utilizo para la conferencia y el chat con los participantes. Del lado derecho, mi computadora secundaria como plan B en caso de que por algún motivo mi computadora primaria deje de funcionar. Junto al teclado mi cuaderno de anotaciones. Finalmente en el banquito de madera, un infaltable: el mate.

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

Sueldos DevOps a nivel global (2018)

La semana pasada recibí un mail de la gente de Puppet con un link a su “2018 DevOps Salary Report”. Es la quinta vez que Puppet realiza este estudio. El mismo está basado en una encuesta global que en su edición 2018 contó con 3000 participantes.

A diferencia de otras encuestas que preguntan concretamente sobre el sueldo en términos numéricos (¿cual es tu sueldo?), esta encuesta pregunta por rangos salariales.

Si bien solo el 3% de las respuesta corresponde a Latinoamérica (esto es alrededor de unas 100 respuestas), creo que el reporte resulta igualmente interesante porque hoy en día es perfectamente factible trabajar en forma remota.

Según indica este estudio los salarios en USA son más altos que en el resto del mundo. En dicha parte del mundo el 80% de los practicantes cobra al menos 75.000 dólares anuales (el término practicante aplica a la gente que hace concretamente trabajo de DevOps, no gerentes/managers). Este número es coincidente con lo que indica la encuesta anual de StackOverflow, donde precisamente los especialistas DevOps están entre los mejores pagos.

Si miramos más en detalle en la encuesta de Puppet vemos que en USA tenemos:

% de encuestadosRango salarial (en miles de dólares anuales)
2575 – 100
24100 – 125
19125 – 150
12150 – 250

Los interesados pueden ver el reporte completo aquí.