Creo que encontrarán cientos de páginas hablando sobre el tema, sin embargo aquí entraré en detalles específicos de la aplicación de DevOps, los perfiles que se buscan en el mercado (tanto en Latinoamérica como Norteamérica y Europa) y qué es necesario para que de una u otra forma seamos considerados un rol «DevOps».

De dónde nace DevOps

Creo que para empezar, primero necesitamos entender de dónde viene antes de saber qué es DevOps.

La forma de crear software ha cambiado con el paso de los años. En el año 2001 nace la cada vez más conocida «Metodología Agile«. Esta forma de construir software es sin duda muy flexible y supera por mucho a sus predecesores entre las ventajas clave están: Un ROI (Return of Investment) más rápido debido a que se crea más software en menos tiempo y con mayor calidad.

Historia de las metodogías de desarrollo.

Historia de las metodogías de desarrollo.

Para el 2008 se comienza a tomar más en cuenta la brecha entre la metodología ágil e infraestructura. La infraestructura no estaba bien preparada para esta forma de desarrollo, con lo cual alguien en una conferencia dijo «Infraestructura Ágil» y al año siguiente en el 2009 se quedó el término DevOps para hacer referencia a esto.

Qué es DevOps

En Wikipedia encontrarán la siguiente definición:

Es una metodología de desarrollo con una serie de prácticas que apuntan a integrar las áreas de Desarrollo y Operaciones haciendo énfasis en la comunicación, colaboración, integración continua, asegurando la calidad y entregando soluciones de software con despliegues automatizados.

La cual me parece bastante apropiada.

¿Y qué no es DevOps?

  • No son únicamente herramientas Open Source (FOSS) o Closed Source
  • No son solo metodologías ágiles.
  • No es algo que se aplica del mismo modo en todas las industrias.
  • No es una sola persona; es la unión de todos los esfuerzos entre el negocio, operaciones (IT, Release Management) y Desarrollo.

El Perfil DevOps

Constantemente me llegan ofertas y evalúo los requerimientos que se exigen para un cargo de esta naturaleza.

Basándome en varias ofertas creé una matriz de datos para entender lo que las empresas quieren cuando piden un perfil DevOps. Los resultados son bastante interesantes para su análsis:

Top 10 Skills específicos

Estas son las tecnologías / conocimientos que debe tener una persona que aspira al cargo de DevOps, teniendo las primeras 5 skills ya podemos entrar en el scope de las búsquedas DevOps.

  1. Linux principalmente y en muchísima menor medida Windows.
  2. AWS (Amazon Web Services, específicamente desarrollo no infraestructura en Cloud)
  3. Scripting (Bash, Python, PHP) preferiblemente.
  4. Herramientas de Configuración distribuida (Puppet, Ansible, Chef) preferiblemente.
  5. Administración de servidores web (Apache HTTP, Nginx) preferiblemente.
  6. Administración y configuración de sistemas de monitoreo (New Relic, Nagios, Zabbix) preferiblemente.
  7. Administración y configuración de bases de datos (MySQL, MariaDB) preferiblemente
  8. Conocimientos de Networking y herramientas (Balanceo, DNS, TCP, UDP, HTTP – tcpdump, telnet, dig, traceroute)
  9. Administración y configuración de sistemas de caché (memcache, redis)
  10. Conocimientos de Virtualización y Contenedores (VMWare, Docker)

Aunque estas suelen ser las skills que solicitan para el cargo, cuando hacemos una sumatoria de las categorías a las cuales pertenece cada skill (Ejemplo: AWS y Scripting = Desarrollo, Linux y Windows = S.O) vemos como toman más importancia los conocimientos de desarrollo y otro tipo de habilidades, todo lo que solicitan las empresas se encuentra en estas nueve categorías:

  1. Desarrollo (Habilidades para desarrollar software, haber trabajado como developer)
  2. Delivering (conocimientos de herramientas para distribución de deployments)
  3. S.O Arch (Arquitectura de S.O, especialmente Linux)
  4. Webservers (Administración y configuración de  webservers Apache HTTP y/o Ngnix)
  5. Troubleshooting (Habilidades para resolución de problemas de desarrollo e infraestructura)
  6. Virtualization (Conocimientos y conceptos de virtualización )
  7. Cache (Configuración de sistemas de cache)
  8. Cloud (Conocimientos de Cloud, Webservices, APIs, REST, SOAP)
  9. Database (Administración y configuración de bases de datos relacionales y no relacionales).

Si fueramos puristas, el resultado del perfil DevOps debería ser algo como:

  1. Tres años o más de experiencia en desarrollo y metodologías
  2. Tres años o más de experiencia con sistemas operativos Linux
  3. Un año o más de experiencia en administración de Webservers
  4. Excelentes capacidades analíticas para troubleshooting de código e infraestructura
  5. Un año o más de experiencia con Cloud
  6. Un año o más de experiencia con base de datos relacionales y no relacionales

Teniendo esto en cuenta van a notar que diferentes startup de recruiting se van a orientar fuertemente a encontrar personas con perfiles de developer que quieran seguir desarrollando código pero también que comiencen a cumplir el rol de infraestructura para formar el llamado «DevOps».

Esto lo podemos notar en startups como Honeypot o FoodPanda (de quienes ya he recibido ofertas) quienes tienen plataformas u ofertas de DevOps visto desde la perspectiva de Desarrollo primero y Operaciones luego. De hecho Honeypot cuenta con una plataforma llamada Hackerrank para evaluar a sus candidatos, verán que al menos el 99% de los desafios están orientados a personas de desarrollo y muy poco a alguien con experiencia en Linux (solo cuentan con una categoría de Bash Scripting).

Un sysadmin es mejor para DevOps que un Developer

Aquí seguramente muchos desarrolladores van a saltar como un pochoclo (popcorn) preguntando el por qué . Lo cual me tomaré el tiempo de explicar en los siguientes párrafos.

Si quisieramos tener un perfil de DevOps integral, es decir, una persona que tenga conocimientos «de todo» el pipeline desde desarrollo hasta producción, lo más natural y sencillo sería adoptar a un Sysadmin en vez de un Developer.

El developer clásico se encarga de su código, el framework, las reglas de negocio y generar releases. Trabajando en diferentes compañías grandes y chicas como Globant, JPMorgan y WesternUnion he podido notar que los ambientes de desarrollo administrados por los mismos desarrolladores suelen ser un caos completo.

He visto a developers tratando de crear scripts de inicio para sus aplicaciones en bash (con resultados terribles) y también he visto desarrolladores Java tratando de administrar sistemas operativos y middleware con herramientas de distribución como Puppet y ellos carecen del mindset de administración, lo que implica cada una de las capas y el impacto en diferentes ambientes, también les cuesta mucho el concepto de estandarización y son más del tipo «lo ato con alambre».

El developer clásico rara vez tiene acceso al sistema operativo o ha realizado algún tipo de administración o virtualización de ambientes, carece de esa visión. Contrario a esto el Sysadmin que no es experto en un lenguaje sí conoce parte del mindset de un developer dado que tiene que escribir muchos scripts (comparten una base de conocimientos respecto a los conceptos básicos de programación, incluso hasta un nivel intermedio) y además poseen la visión y conocimientos de toda la infraestructura.

Otra cosa importante, es que el developer tiende a solucionar problemas de performance aumentando los recursos de hardware, pocas veces se encarga de realizar la optimización adecuada a su código o a limpiar las direcciones usadas en memoria. Un problema frecuente que tuve que solucionar en distintas empresas era demostrarle a los developers como sus librerías duplicadas y errores en los logs eran cosas que ellos debían arreglar en vez de subir memoria y procesador en los servidores.

La mutación del Sysadmin hacia el desarrollo de software

Básicamente, podríamos decir que un DevOps es más un sysadmin que va mutando hacia conceptos de programación más complejos, webservices y cloud, pero que resultaría más difícil si hicieramos el mismo camino con un developer tratando de ir hacia el camino de la infraestructura.

La realidad es que hoy día no todos van a Cloud. Algunas compañías internacionales del rubro bancario han ido dejando el middleware clásico (Jboss, Weblogic, Tomcat + Apache/Nginx + AMQ, Qpid) tratando de ir hacia cloud con soluciones como Spring BootCloudfoundry, S3Logstash y el desarrollo de microservicios.

Otros bancos que tienen estructuras más monolíticas (Latinoamérica) recién están adoptando el middleware clásico como un acercamiento a la implementación de DevOps y recién comienzan a dejar sus metodologías tipo cascada o proyectos en COBOL, Mainframe, etc… para ir hacia Agile, Java y Middleware clásico.

El impacto organizacional para los bancos es muy fuerte, dado que sus equipos de desarrollo suelen tener personas con más de 40 años,  aplicar metodologías y ceremonias Agile en este tipo de grupos es bastante complicado. También los mismos lineamientos de los bancos no permiten una evolución rápida del DevOps (dada una gran cantidad de restricciones), en este tipo de proyectos el mayor desafío es el mindset organizacional.

En fin, no todos trabajan en bancos y otras empresas suelen ser más flexibles respecto a implementar DevOps e ir a Cloud, por eso la necesidad de más conocimientos de desarrollo. Es aquí donde el Sysadmin, comienza a abandonar el rol de administración de servicios y comienza a surgir la necesidad de manejar más los procesos y reglas de negocio desde el punto de vista de desarrollo lo cual permite formar un rol que pueda hacer troubleshooting.

Suponiendo que en algún momento estuvieramos todos migrados a Cloud, conocer sobre administración de middleware en plataformas como Tomcat, Weblogic o Jboss ya no serían skills tan relevantes. Sin embargo la realidad es otra, Latinoamérica está lleno de empresas que hasta ahora están entrando en la etapa inicial de la implementación DevOps con lo cual el Sysadmin tiene un rol clave si es esto lo que se busca implementar.

Aunque por ahora sigue siendo importante saber de Linux, ser bueno en troubleshooting y tener buenas habilidades de scripting (el pegamento que une todo) es momento de comenzar a conocer más sobre el desarrollo de aplicaciones web en la nube.

Las herramientas del mundo DevOps

Teniendo en cuenta la matriz mencionada realicé este gráfico para ilustrar las necesidades de algunas empresas cuando hacen referencia a DevOps.

Herramientas DevOps

Herramientas DevOps

En la parte superior encontraremos todo lo que es «middleware». Debajo encontrarán las herramientas «DevOps» que suelen requerir las empresas. Cada una en una franja de color dado que son de la misma categoría (a excepción de la última franja).

Por ejemplo, para monitoreo se está usando mucho NewRelic o Nagios. Para versionado las empresas chicas o que se han quedado utilizan subversion, las más innovadoras van por Git y algunas optan por comprar soluciones completas como el combo de Atlassian (Bitbucket, Jira y Confluence). Algunas empresas usan software privativo como RTC de IBM pero este tiene buena integración con Jenkins por ejemplo.

Para la integración continua sin duda Jenkins manda, es lo que más he trabajado y he visto implementado.

Después en herramientas de distribución / virtualización  Vagrant y Terraform están ganando fuerza pero mucho se pide Puppet, Ansible y Chef.

Para el building de software va a depender mucho de lo que trabaje cada compañía sin embargo Maven se menciona mucho (naturalmente integrado con Jenkins al igual que Ant) y en empresas donde se trabaja con Javascript van a ver npm para implementar Grunt.

En las colaborativas Jira está liderando muy bien y por lo general lo vamos a ver de la mano con Confluence, las dos herramientas son muy buenas aunque no hay una integración fácil con herramientas de administración de proyectos como Clarity por ejemplo, aunque ambas tienen APIs y servicios REST no hay un plugin para la conectividad entre ambas herramientas.

En el testing automatizado Selenium es ampliamente aceptado como la solución OpenSource, aunque hay otras soluciones pagas  UFT de IBM o Tosca (me quedo con lo FOSS).

Y en la última franja en unificación de logs está Logstash que tiene un armado de reglas por regex bastante bueno, Docker para armar contenedores (un concepto nuevo y muy distinto a virtualización) npm para repositorios (Javascript) y los muy nombrados webservices de Amazon.

Aunque no está en el gráfico (dado que hay muchísimas cosas más) no podemos dejar de mencionar Jenkins-hub (el código fuente liberado de Blackduck) y Sonar para asegurar mejoras y control en la calidad de código (y auditorías).

Vertical a estas tecnologías vienen nuestras skills de scripting (el pegamento de todo esto) y de forma horizontal dando soporte a todo el ciclo las habilidades de troubleshooting. Finalmente todo será un subconjunto de las buenas prácticas y la metodología Agile.

Para ser un buen DevOps, ser requiere saber mucho y un poco de cada cosa, a mi forma de ver una persona con 2 años de experiencia en desarrollo y 4 años de experiencia en infraestructura puede llegar tener el seniority adecuado para ser DevOps sin importar si conoce o no todas las tecnologías.

Está claro que, nadie puede saberlo todo, por eso insisto que para este perfil lo más importante es:

  • Excelentes conocimientos de Linux (manejo por consola)
  • Muy buen scripting (Bash, Jython, PHP)
  • Buenos conocimientos de virtualización
  • Gran capacidad analítica y de troubleshooting
  • Buenos conocimientos de networking
  • Conocimientos básicos de programación (POO si es posible)
  • Conocimientos de bases de datos básicos (SQL, relacionales y no relacionales)
  • Ser muy proactivo para ganar una visión amplia del negocio (objetivos) y muy buen carisma para acercar a los roles de las diferentes áreas.

Todo lo demás se suele construir partiendo de esa base.