En 2021, el portal Allied Market Research estimó el valor del mercado de DevOps en unos 7 mil millones de dólares y predijo que crecería hasta los 58 mil millones de dólares en 2030. Un ingeniero DevOps capaz siempre es muy demandado, independientemente de los altibajos económicos; por eso, aprender la metodología parece una inversión razonable.
Nuestro colega Danylo Buriak, de Lublin, se pasó de Sysadmin a DevOps. Basado en su experiencia personal, Danylo analiza si DevOps es un paso adelante natural para un administrador de sistemas, qué hay que aprender primero y cómo trabajan juntos los antiguos administradores y desarrolladores en equipos DevOps.
¿Administradores o desarrolladores?
Los ingenieros de DevOps se dividen en antiguos administradores de sistemas y desarrolladores por igual. Sin embargo, el lado de las operaciones también puede incluir ingenieros de QA que vienen a través de la posición de un TestOps: estos son los dos caminos principales. Nunca juzgaría qué camino es mejor. Pero en mi humilde opinión, un DevOps es realmente un administrador de sistemas actualizado, aunque también necesitará conocimientos de codificación en algún punto.
Por supuesto, depende de tu interés que la transición a la nueva tecnología se produzca sin problemas. No obstante, hay un montón de cosas básicas que los desarrolladores deben aprender para unirse a cualquier proyecto como DevOps: generalmente, no profundizan demasiado en networking o seguridad ya que no lo necesitan.
Los desarrolladores podrían mencionar cosas en las que los administradores tienen menos experiencia y también estarían en lo cierto. Pero las habilidades de operaciones pueden ser más difíciles de obtener.
Ningún curso puede darte conocimientos de resolución de problemas. Puede que tengas fuertes habilidades de pensamiento lógico, seas muy atento y sepas concentrarte. ¿Pero qué pasa si un contenedor Docker sigue sin arrancar? Un administrador de sistemas suele conocer los sistemas Unix y puede distinguir un error típico de Linux de manera inmediata. En cambio, otros deben buscar en Google qué está pasando (lo que lleva mucho más tiempo).
Un antiguo desarrollador también adquirirá esa experiencia, pero ya como DevOps, lo que puede ralentizar su carrera en las primeras etapas. Mi transición de trainee a Middle DevOps me llevó solo un año. No obstante, ya tenía una experiencia sostenible creando cosas desde cero como administrador.
Mi historia como administrador
Empecé a trabajar en el centro de llamadas de un proveedor de Internet como estudiante. Siempre me gustó la parte técnica del soporte, trabajar con configuraciones de red, ayudar a la gente con problemas de Windows, etc. El administrador de sistemas parecía el siguiente paso natural, y encontré una vacante de asistente en una fábrica de torniquetes de metro. Di mis primeros pasos en IT hace seis años y, desde el principio, me di cuenta de lo que más me gustaba (y no era el salario).
El dinero era necesario, pero no crucial; ya que también disfrutaba de sentirme realizado al cumplir una tarea. Al principio, puedes lograrlo resolviendo los problemas de la gente. Luego, lo mejor era tener más y querer hacer que las cosas funcionaran mejor. La parte más emocionante de ser Sysadmin siempre ha sido la automatización de las cosas: la limpieza de las rutinas diarias y las copias de seguridad. Supe que quería convertirme en DevOps muy temprano.
Seguí trabajando como admin en una cadena de restaurantes, mientras empezaba a estudiar la metodología DevOps y a investigar el desarrollo de mi carrera. El mejor consejo que encontré en ese momento fue conseguir un trabajo en una empresa de IT para aprender sobre proyectos, procesos y equipos de desarrollo.
Cuando me metí en Clouds, estudié algunas herramientas DevOps en mi tiempo libre. Luego, en 2018 me uní a DataArt para asegurarme que era totalmente diferente de mi experiencia anterior. La automatización y el soporte en una empresa de IT demostraron estar en otra capa de complejidad. Esta es la escuela que recomiendo a cualquier administrador interesado en flotar hacia DevOps.
Cuando la pandemia de Covid-19 golpeó, terminé los cursos de Docker y Terraform y me sentí listo para un desafío. Con las oficinas cerradas, los sysadmins tenían mucho menos que hacer; y yo buscaba unirme a un proyecto como un trainee de DevOps. DataArt me apoyó y me permitió trabajar 4+4: mitad del día como administrador y mitad del día como DevOps. Me cambié por completo al nuevo puesto cuando todos estuvieron seguros de que podía manejarlo.
Todo esto sucedió sin problemas y de forma natural, y quiero destacar que aprender DevOps es un paso perfecto para los administradores de sistemas que echan de menos proyectos más grandes con resultados claros.
¿Cuándo estás preparado?
Si tienes unos dos años de experiencia como Sysadmin, puedes empezar tu formación en DevOps. En este punto, deberías tener algo de experiencia con networks, sistemas operativos, etc. Esta es la parte única del trabajo de administrador en DevOps; así que una vez que te sientas lo suficientemente seguro, ve a por ello.
Nunca he encontrado una lista fiable de herramientas esenciales que necesitarás al comienzo de tu carrera en DevOps. Pero hay algunas cosas que necesitas saber: metodologías de desarrollo específicas, como Agile, son probablemente el mejor ejemplo.
CI/CD (integración continua/entrega continua) es el núcleo de DevOps, su idea principal, y necesitas conocerla desde el principio. Sin embargo, si estás leyendo esto, es posible que ya utilices este enfoque como administrador de sistemas. El desarrollo tiene que ser rápido y fluido, así que comprueba si ya tienes proyectos orientados a ello en tu puesto actual.
Tal vez realices un complicado trabajo de fondo para que un desarrollador sólo tenga que pulsar un botón para que algo funcione. Sin embargo, incluso si automatizas algo con CI/CD como administrador de sistemas, normalmente gestionas infraestructura local en lugar de nubes, que necesitarás para la mayoría de los proyectos de los clientes.
Cuando empecé como DevOps, no tenía experiencia en programación aparte de algunos cursos básicos de C# y HTML en la universidad. Y honestamente, mientras eres un trainee, incluso este nivel no es realmente necesario. Pero a medida que creces, llegarás a un problema que no se puede resolver sin escribir un script.
La primera vez que me topé con un problema fue con el servicio de autenticación de AWS Cognito. Tuve que escribir una función lambda para establecer qué dominios estaban autorizados a registrarse en nuestro servicio, y ahí fue cuando llegué a Python. Empecé principalmente con guías de Google, pero si puedes entrenar scripting -como Python o Bash- de antemano, eso te ayudará.
En algunos casos, puede que necesites otros lenguajes de programación. Aun así, si sabes manejarte en Jenkins, puedes lidiar con herramientas CI/CD. Estoy bastante seguro de que un Senior Sysadmin tendrá casi todos los conocimientos para convertirse en un ingeniero DevOps; sólo tiene que llenar los espacios en blanco desde el lado del desarrollo.
Por otra parte, los desarrolladores que no se limitan a escribir código también encontrarán su camino en DevOps. Recuerdo mi primer proyecto DevOps: un desarrollador senior de Python de mi equipo se interesó por la parte operativa del proceso. Más tarde, se pasó con éxito a DevOps. Es una forma para devs que quieren entender y manejar por completo la infraestructura.
Checklist para un principiante
Para trabajar en DevOps, tienes que entender cómo funciona la arquitectura. Sin embargo, inicialmente no debes profundizar en los detalles. Es posible que no sepas cómo funciona tu aplicación, qué hay en el código y cómo se conectan las bibliotecas.
En una posición inicial, la mayoría de las veces pones el código en un contenedor de acoplamiento y lo ejecutas. Por supuesto, en etapas posteriores, deberás aprenderlo todo; algunos proyectos requieren un ingeniero senior de DevOps para ayudar a los desarrolladores.
La metodología es la clave, ya que estableces todo el proceso de desarrollo y necesitas cierta comprensión del mismo. Yo diría que el conjunto fundamental con el que debes familiarizarte es el siguiente:
- Herramientas CI/CD: Jenkins, TeamCity, GitHub Actions, Azure Pipelines.
- Git: GitHub, GitLab, Bitbucket.
- Al menos una nube: AWS, GCP y Azure, como las más grandes, serán las más útiles.
- IaC: Terraform (bastante universal y más valioso), AWS CloudFormation, Azure Blueprints.
- Herramientas de orquestación: Ansible, Chef.
- Herramientas de monitorización: Grafana, Zabbix, Prometheus.
- Logging: ELK stack, Datadog, Graylog.
- Contenedores: Docker.
- Orquestación de contenedores: Kubernetes, Docker Swarm.
- Lenguaje de programación de script: Bash, Python, Perl, PowerShell.
- Estrategias de ramificación Git: Estrategia GitHub, Trunk Based Development, Atomic pull requests.
- Al menos una herramienta de automatización de construcción: Make, Gradle, Maven Build.
- Argo CD.
Nunca aprenderás todas las herramientas, pero DevOps consiste -en primer lugar- en comprender la metodología. Las herramientas de cada categoría tienen principios similares y sus detalles específicos son relativamente fáciles de aprender.
Por ejemplo, yo trabajo con Jenkins y TeamCity, pero puedo cambiar rápidamente a GitHub Actions si es necesario. Principalmente se diferencian en la interfaz de usuario, además de algunas peculiaridades técnicas (cómo funcionan los agentes, etc.). Lo mismo para la infraestructura como código: si has trabajado con mi favorito -Terraform- puedes aprender CloudFormation o Azure Blueprints bastante rápido, ya que sólo se diferencian en la sintaxis. Funciona para todos los grupos de instrumentos: necesitas una idea general y experiencia con una herramienta, y tienes a Google para el resto.
Incluso, funciona para muchas entrevistas de proyectos. Si CloudFormation no es el núcleo formador del proyecto, aún puedes conseguir el empleo si solo has trabajado con Terraform pero has demostrado entender cómo funciona. De todos modos, es mucho mejor que mentir sobre tu experiencia.
Entrevistas y trabajo diario
Mi primera entrevista para un puesto de DevOps se centró principalmente en el proyecto al que me iba a unir. El experto me hizo algunas preguntas básicas del campo Sysadmin (solución de problemas, Linux) y luego fue todo sobre DevOps (Jenkins, Terraform, y todo lo que puedes encontrar en la lista anterior).
Yo diría que la mayoría de las entrevistas tienen una estructura muy similar: en primer lugar, algo relativamente simple del lado de la operación y luego es todo acerca de las herramientas utilizadas en un proyecto. A los expertos les gusta preguntar sobre habilidades prácticas, como las tareas de prueba durante los cursos. Normalmente, hay un proyecto de prueba que demuestra si estás preparado para convertirte en DevOps. He tenido muchas entrevistas después, y así es como suele ocurrir.
En cuanto a tus responsabilidades diarias, la principal diferencia es que no tienes ningún trabajo físico ni interacción con el hardware. Siempre he odiado esa parte del trabajo de administrador de sistemas, pero sé que a algunos administradores les gusta. En mi caso, DevOps eliminó lo peor, dejando sólo la parte dulce de automatizar procesos.
Mi parte favorita es la infraestructura como código, y Terraform es la herramienta que más me gusta. Ahí es donde puedes programar algo de lógica, que es totalmente diferente del trabajo del Sysadmin. Esta parte creativa es refrescante e inspiradora: a veces, te sientes como un genio. Normalmente, como administrador de sistemas no puedes tener esta sensación.
Trabajar juntos
Cuando trabajas con otro DevOps, puedes distinguir entre administradores y desarrolladores. Al menos, eso funciona para Juniors y Middles. Tuve a ambos en mi último equipo y pude decirlo desde el principio. Primero y principal, recogen diferentes tareas cuando hay una opción: uno prefiere profundizar en la lógica del código y el otro se dedica más a configurar copias de seguridad o a supervisar la seguridad.
Estoy seguro de que una combinación así, enriquece a todo el equipo. La metodología DevOps abarca un amplio abanico de herramientas que un solo ingeniero nunca podría cubrir. Personas de distintos ámbitos, familiarizadas con distintos enfoques, siempre saben más juntas y tienen un valor excepcional para cualquier proyecto. Trabajar con gente que tiene experiencia en desarrollo fue muy útil para mí.
En primer lugar, podíamos intercambiar tareas. Siempre estoy encantado de llevar cualquier cosa en Terraform, pero al inicio podía tener problemas con un script de Python. Esto hizo que nuestro trabajo fuera más eficiente y rápido, y que los resultados fueran de mejor calidad. Pero también podíamos sincronizarnos y hacer una tarea juntos para intercambiar esta experiencia.
DevOps está en el límite de dos prácticas de ingeniería, lo que lo hace tan genial, ninguna es menos importante. Esto hace que sea difícil encontrar DevOps adecuados y, en este sentido, tiene una repercusión directa en sus ingresos.
