La ruta a DevOps Engineer no arranca en Kubernetes: arranca en Linux, redes y un lenguaje de scripting. La mayoría de las personas que se frustran en el camino lo hacen por saltear esas tres capas y meterse directo en las herramientas de moda. Esta guía ordena el recorrido en cinco etapas, indica qué certificaciones tienen peso real en procesos de selección y cuánto tiempo lleva cada tramo si dedicás entre 10 y 15 horas semanales.

DevOps es uno de los roles con mejor relación entre demanda y cantidad de candidatos preparados en el mercado tech de la región. La razón es simple: no es una tecnología que se aprende, es una intersección. Requiere entender infraestructura, saber programar lo suficiente para automatizarla y tener criterio de operación —qué monitorear, cuándo hacer rollback, cómo diseñar un despliegue que no rompa producción. Ese perfil híbrido escasea, y por eso paga.

Qué hace realmente un DevOps Engineer

Antes del roadmap, conviene desarmar el malentendido más común: DevOps no es "el que maneja los servidores". Un DevOps Engineer construye y mantiene el camino que va desde el commit de un developer hasta la aplicación funcionando en producción, y hace que ese camino sea rápido, repetible y reversible.

En el día a día eso significa cuatro tipos de trabajo:

• Automatizar el ciclo de entrega. Pipelines de CI/CD que compilan, testean y despliegan sin intervención manual.

• Definir infraestructura como código. Que el entorno se pueda recrear desde cero con un comando, no con un documento de pasos.

• Observabilidad. Métricas, logs y trazas que permitan responder "qué se rompió y desde cuándo" en minutos.

• Habilitar al equipo. Buena parte del trabajo es sacarle fricción a los developers: entornos de prueba, permisos, herramientas internas.

Si querés el detalle del rol con foco en tareas y compensación, está desarrollado en DevOps con IA: qué hace un DevOps Engineer, cuánto gana y cómo formarse. Y si todavía dudás entre este rol y el de SRE, la comparación está en DevOps vs SRE: qué son, en qué se diferencian y cuál tiene mejor salida laboral.

La ruta de aprendizaje en cinco etapas

Etapa 1 — Fundamentos: Linux, redes y Git (2 a 3 meses)

Es la etapa que más gente saltea y la que más problemas causa después. Sin estos fundamentos, todo lo que viene se aprende de memoria en lugar de entenderse.

• Linux: navegación de filesystem, permisos, procesos, systemd, gestión de paquetes, variables de entorno. Objetivo concreto: poder configurar un servidor web desde una máquina limpia sin buscar cada comando.

• Redes: DNS, HTTP/HTTPS, TCP, puertos, firewalls, load balancing, certificados TLS. La mayoría de los incidentes de producción son problemas de red disfrazados de problemas de aplicación.

• Git: branching, merge, rebase, resolución de conflictos, pull requests. No alcanza con commit y push.

Etapa 2 — Scripting y automatización (1 a 2 meses)

Un DevOps que no programa es un administrador de sistemas con otro nombre. Necesitás un lenguaje para automatizar de verdad.

Bash es obligatorio para todo lo que sea pegamento entre comandos. Python es la elección más rentable para lógica más compleja: parsear respuestas de APIs, orquestar tareas, escribir herramientas internas. Con eso ya podés reemplazar procedimientos manuales por scripts idempotentes.

Etapa 3 — Contenedores y orquestación (2 a 3 meses)

Acá empieza el DevOps moderno. Docker es hoy la base indiscutida: fue la tecnología con mayor crecimiento interanual en la encuesta de Stack Overflow 2025, con 71% de uso entre desarrolladores y un salto de 17 puntos en un año.

El orden que funciona: primero Docker a fondo —imágenes, capas, multi-stage builds, volúmenes, redes, docker-compose—, después Kubernetes. Invertir el orden es la causa número uno de abandono, porque Kubernetes sin entender contenedores es abstracción sobre abstracción.

Sobre Kubernetes, el mercado ya lo dio por sentado: la encuesta anual de la CNCF de 2025 encontró que el 82% de quienes usan contenedores corren Kubernetes en producción, y que el 77% de las empresas del Fortune 100 lo tienen desplegado. Aprenderlo dejó de ser una apuesta.

Etapa 4 — Cloud, IaC y CI/CD (3 a 4 meses)

Es la etapa que te hace empleable en el rol.

• Un proveedor cloud, en profundidad. Elegí uno y aprendelo bien: cómputo, storage, redes virtuales, IAM, bases de datos gestionadas. AWS sigue liderando el mercado, pero Azure y Google Cloud tienen demanda concreta. Aprender los tres superficialmente es peor que aprender uno bien.

• Infraestructura como código. Terraform es el estándar de facto multi-cloud. El concepto clave que hay que interiorizar es el estado declarativo: describís el resultado, no los pasos.

• CI/CD. GitHub Actions o GitLab CI para empezar. Un pipeline completo: lint, test, build de imagen, push a registry, deploy a staging, aprobación, deploy a producción.

Etapa 5 — Observabilidad, seguridad y automatización con IA (2 a 3 meses)

Lo que diferencia a un DevOps junior de uno que puede sostener producción.

• Observabilidad: Prometheus y Grafana para métricas, un stack de logs centralizado, trazas distribuidas. Definir SLIs y SLOs.

• Seguridad en el pipeline: escaneo de dependencias, análisis de imágenes, gestión de secretos. Nunca credenciales en el repositorio.

• IA aplicada a operaciones: análisis de logs, detección de anomalías, generación de manifiestos y módulos de Terraform. Es el diferencial que hoy más rápido te separa del resto de los candidatos.

Qué certificaciones tienen peso real

En DevOps las certificaciones sirven, pero no todas y no en cualquier momento. Sirven sobre todo cuando no tenés experiencia laboral en el rol y necesitás una señal verificable en el CV.

Un criterio práctico: rendí como máximo dos certificaciones antes de tu primer trabajo. Más allá de eso, cada hora extra rinde más en un proyecto propio que en otro examen.

El proyecto que reemplaza la experiencia que no tenés

La objeción real en una entrevista de DevOps junior no es "no tenés certificaciones", es "nunca operaste nada". La forma de neutralizarla es un proyecto que demuestre el ciclo completo.

Armá esto y documentalo en un repositorio público:

• Una aplicación simple —dos o tres servicios— contenerizada con Docker.

• Infraestructura definida en Terraform sobre el proveedor cloud que elegiste.

• Un pipeline de CI/CD que testea, construye, publica la imagen y despliega automáticamente.

• Kubernetes con manifiestos versionados y un health check funcionando.

• Monitoreo con Prometheus y un dashboard de Grafana con tres métricas que importen.

• Un README que explique las decisiones de diseño y qué harías distinto con más presupuesto.

Ese último punto es el que más impresiona en entrevistas: demuestra criterio, no solo ejecución. La lógica de cómo estructurar un repositorio para que un reclutador lo entienda en tres minutos está desarrollada en Cómo armar un portfolio de programador que consiga entrevistas.

Cuánto tiempo lleva en total

Sumando las cinco etapas, entre 10 y 15 meses con una dedicación de 10 a 15 horas semanales. Si venís de desarrollo, restá la etapa 2 y parte de la 1: quedan 7 a 9 meses. Si venís de soporte técnico o infraestructura, la etapa 1 ya está cubierta y lo que falta es programación y cloud.

El error más costoso es querer comprimirlo a tres meses. DevOps es un rol donde el criterio se construye con horas de práctica sobre sistemas que se rompen, y eso no se acelera con más videos.

Cursos recomendados de Coderhouse

Tres opciones que cubren distintos puntos de la ruta:

• Curso de DevOps & Cloud — el más directo para las etapas 3 y 4. Cubre contenedores, orquestación, infraestructura como código y pipelines de CI/CD, que es exactamente el núcleo empleable del rol.

• Curso de Python — para la etapa 2. Si vas a automatizar infraestructura, necesitás un lenguaje real; Python es el de mejor relación entre esfuerzo y aplicabilidad en operaciones.

• Curso de Cloud Computing con AWS — para profundizar en el proveedor con más demanda del mercado y preparar la certificación de Solutions Architect Associate.

Si además querés incorporar la capa de automatización con IA que hoy funciona como diferencial, el Curso de AI Automation se complementa bien con la etapa 5.

Preguntas frecuentes

¿Puedo entrar a DevOps sin haber trabajado antes como developer o en soporte?

Sí, pero es el camino más largo. Sin base previa vas a necesitar entre 12 y 15 meses de preparación y un proyecto muy sólido, porque compites con perfiles que vienen de desarrollo o de infraestructura. Una alternativa efectiva es entrar primero a un puesto de soporte técnico o de QA con foco en pipeline, y hacer la transición interna: es más rápido en la práctica que buscar un DevOps junior desde cero.

¿Kubernetes es obligatorio para conseguir el primer trabajo?

Para el primer trabajo, no siempre: hay muchas empresas que corren contenedores sin orquestador o con servicios gestionados más simples. Pero es obligatorio para el segundo, y aprenderlo antes te habilita a apuntar a posiciones mejor pagas desde el inicio. Con 82% de adopción en producción entre quienes usan contenedores, el mercado ya lo trata como conocimiento base.

¿Qué proveedor cloud conviene aprender primero?

AWS, por volumen de vacantes y porque los conceptos son transferibles. Una vez que entendés IAM, VPC, cómputo y storage en un proveedor, aprender otro toma semanas, no meses. La excepción es si ya sabés que apuntás a un sector específico donde predomina Azure —banca, seguros, gobierno en varios países de la región—; ahí conviene ir directo a Azure.

¿Certificación o proyecto propio: qué pesa más en una entrevista?

La certificación te consigue la entrevista; el proyecto te consigue el trabajo. Son complementarios y cumplen funciones distintas. Una certificación de AWS o el CKA pasa el filtro automático de reclutamiento; el proyecto es lo que te permite responder preguntas técnicas con ejemplos concretos en lugar de teoría.

¿DevOps va a ser reemplazado por la IA?

La IA está automatizando la parte más mecánica del rol —escribir manifiestos, generar módulos de Terraform, analizar logs— y eso está subiendo la vara de lo que se espera de un DevOps, no eliminando el puesto. Lo que no se automatiza es el criterio: decidir la arquitectura de despliegue, definir qué nivel de disponibilidad justifica el costo, actuar durante un incidente. El perfil que corre riesgo es el que solo ejecuta procedimientos.