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.

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

Servidores CI/CD: diferencias de modelos, Jenkins vs CircleCI

Servidores CI/CD: diferencias de modelos, Jenkins vs CircleCI

Jenkins es una de las herramientas de CI/CD más difundidas, posiblemente por su potencia y también por su larga historia (su primera versión es de 2005). Yo empecé a utilizarlo allá por 2008 cuando aún era Hudson. Inicialmente era un servidor de integración continua. Luego con el auge de la entrega continua se lo empezó a utilizar para hacer deployments. Esta última característica cobró más impulso a partir de la versión 2.

CircleCI es una herramienta de aparición mucho más reciente y viene a resolver el mismo problema que Jenkins pero con un modelo distinto.

En este post decidí hablar concretamente de Jenkins y Circle porque hoy en día estoy trabajando en dos proyectos, cada uno con una de estas herramientas. Pero en realidad es que en lugar de Circle podría referirme a Travis o a los Builders de Gitlab, pues conceptualmente representan el mismo modelo. Del mismo modo, en lugar de Jenkins podría hablar de Bamboo.

Veamos entonces algunas diferencias de estos dos modelos. CircleCI funciona atado a un repositorio Git (puede ser GitHub, BitBucket o algún otro). Al mismo tiempo, el funcionamiento de la herramienta está definido por un archivo (en formato yaml) donde uno define sus Jobs/Workflows. Si bien la herramienta provee una interface gráfica web, la misma es principalmente para visualización y solo permite ajustar algunos pocos settings, pero no permite la creación de Jobs. La situación es análoga al utilizar Travis o GitLab. Este modelo va muy bien con las estrategias del tipo GitOps, donde todo el pipeline de delivery se articula a partir de operaciones/eventos Git.

Por otro lado, Jenkins ofrece un modelo distinto, uno puede crear jobs asociados a distintos tipos de repositorios o incluso permite crear jobs sin asociación alguna a repositorios. Al mismo tiempo ofrece una interface de usuario web que permite manipular completamente la herramienta, de hecho, durante mucho tiempo esta era la única opción. Luego fueron apareciendo distintas opciones/plugins que posibilitaron tener un manejo similar al de Circle/Travis.

En otra dimensión de análisis podríamos decir que el modelo de Circle/Travis es en cierto modo “CI/CD as a Service”. Son herramientas muy enfocadas en CI/CD con toda una serie de cuestiones de diseño ya tomadas de antemano. De hecho en general el modelo de extensibilidad de estas herramientas es bastante limitado.

Por su parte Jenkins surgió inicialmente en modelo más On-Premises/Producto, contando desde su inicio con un modelo muy potente de extensibilidad y luego fue evolucionando incorporando características de los modelo más SaaS. La arquitectura extensible de Jenkins ha posibilitado la aparición de nuevos proyectos montados sobre Jenkins como ser JenkinsX.

Personalmente me siendo muy a gusto trabajando con Jenkins, creo que es un producto muy versátil y lo he utilizado para algunas cosillas más allá de CI/CD. Al mismo tiempo que creo en un contexto organizacional Jenkins ofrece varias características y posibilidades de extensibilidad no presentes en el otro modelo. Entre las bondades de Jenkins podría nombrar la integración con muchísimas herramientas, las capacidades de templating, slicing configuration y la posibilidad de generar plugins en caso que uno lo necesite (lo he hecho y no pareció complicado). Sin embargo y a pesar de mi gusto por Jenkins, creo que la característica de Pipeline as Code (jenkinsfile) no está lo suficientemente lograda. Perdón, creo que la funcionalidad está bien, pero personalmente me siento más a gusto utilizando un set de plugins tradicionales (como JobDSL, el JobBuilder y BuildPipeline) que usando los Jenkinsfile.

Encuesta de Sueldos IT

Encuesta de Sueldos IT

Hace unos días me llegó un mail de la gente de SysArmy con la invitación para completar la encuesta de sueldos que hacen en conjunto con Openqube.

Esta encuesta se hace dos veces por año lo cual me parece una muy buena iniciativa (aquí están los resultados de la segunda edición de 2018).

Complementariamente a la encuesta, la plataforma Openqube es un sitio que recolecta y sumariza información sobre empresas del sector informático, una fuente excelente para consultar a la hora de evaluar cambios de trabajo.

Libro: Agile Software Requirements

Por estos dias estoy leyendo el libro Agile Software Requirements, de Dean Leffingwell, un libro que compré el año pasado pero que en aquel momento leí apenas algunos capítulos. El libro pertenece a la serie Agile Software Development de Addison-Wesley cuyos editores son Alistair Cockburn y Jim Highsmith. La edición física es excelente, es un libro tapa dura con un formato de página muy ameno a la lectura.

El autor, Dean Leffingwell, ha cobrado cierta popularidad en los últimos años por ser el creador de SAFe, uno de los enfoques de escalamiento de Agile más difundidos en la actualidad. Sin embargo yo ya conocía a Leffingwell por un libro anterior que escribió a fines de los 90′: Managing Software Requirements: A Unified Approach.

El libro propone un enfoque ágil para el manejo de requerimientos a distintos niveles: empresa, programa y equipo. En cierto modo el enfoque propuesto es como una precuela de SAFe (digo esto sin conocer demasiado de SAFe). Aunque aún no terminé de leerlo, me parece que el enfoque propuesto es muy completo sobre todo teniendo presente que inicialmente el foco de los métodos ágiles estaba a nivel de equipo. Me parece importante destacar que el libro no se queda solo en el tema de requerimientos, sino que también tiene capítulos enteros dedicados a temas como arquitectura, planificación y testing entre otros.