Guía para cambiar de carrera hacia Cloud & DevOps (sin título en informática)

Hace dos años era profesor de inglés en Lyon. Tenía una pizarra, treinta adolescentes que no querían estar ahí, y la vaga sensación de que mi vida profesional merecía menos tablas de conjugación.

Hoy despliego infraestructura con Terraform, depuro clústeres de Kubernetes y discuto sobre rangos CIDR en revisiones de código. Sin título en informática. Sin bootcamp. Sin ningún tío trabajando en AWS.

No soy un caso especial. Mucha gente ha hecho esta transición — desde marketing, contabilidad, logística, enseñanza, enfermería. El camino existe. Pero también es más largo y más desordenado de lo que sugieren las historias de éxito en LinkedIn. Esta es la versión honesta.

Por qué Cloud & DevOps es inusualmente bueno para quienes cambian de carrera

La mayoría de los roles tech tienen un problema de gatekeeping. Las entrevistas de desarrollo de software todavía te piden invertir árboles binarios en una pizarra. Ciencia de datos quiere un máster y tres años de Python.

Cloud y DevOps es diferente, por varias razones estructurales.

La escasez de talento es real. Las empresas necesitan ingenieros cloud más rápido de lo que las universidades los producen. Un informe de Gartner de 2025 mostró que hasta 2028, más del 70% de las empresas tendrán dificultades para cubrir roles relacionados con cloud. Esa escasez no se fija en tu título universitario.

La contratación basada en habilidades realmente está pasando aquí. Más que en otros campos tech, los roles cloud se filtran por certificaciones y proyectos demostrables. Una certificación AWS Solutions Architect con un portfolio sólido en GitHub te hará pasar filtros que un título universitario solo no superará.

Remoto por defecto. La infraestructura cloud, por definición, no está en tu oficina. La mayoría de los roles cloud y DevOps eran remotos antes de la pandemia y así se quedaron. Eso es una ventaja enorme para quienes cambian de carrera y no necesariamente viven cerca de un hub tecnológico.

Los resultados son tangibles rápido. A diferencia de pasar seis meses con algoritmos antes de construir algo, puedes levantar infraestructura real desde el primer día. Ese ciclo de retroalimentación te mantiene motivado durante los meses difíciles del medio.

El calendario honesto (6 a 12 meses)

Aquí es donde pierdo a algunos. A los que venden “conviértete en ingeniero cloud en 30 días” no les va a gustar.

Un calendario realista para alguien que estudia a tiempo parcial mientras trabaja:

Meses 1-3: Los cimientos. Bases de Linux, fundamentos de redes, los servicios principales de un proveedor cloud. Aquí es donde construyes el piso. No es emocionante. Hazlo de todos modos.

Meses 4-6: Primera certificación + proyectos prácticos. Presenta tu primer examen. Construye dos o tres proyectos reales. Empieza a hacer que tu GitHub parezca el de alguien que realmente hace esto.

Meses 7-9: Habilidades más profundas + segunda certificación. Infraestructura como código (Terraform), pipelines CI/CD, contenedores. Tu segunda certificación debería ser más especializada.

Meses 10-12: Búsqueda de empleo + seguir construyendo. Postula mientras sigues aprendiendo. Nunca te vas a sentir listo. Postula de todas formas.

Algunos van más rápido. Otros más lento. Yo tardé unos diez meses, estudiando dos horas la mayoría de las noches entre semana y bloques más grandes los fines de semana. El punto es: no es un proyecto de fin de semana, pero tampoco es una carrera universitaria de cinco años.

Qué aprender primero (y qué ignorar)

La trampa más grande para quienes cambian de carrera es la espiral de “aprenderlo todo.” Abres un roadmap de cloud, ves 47 servicios y te paralizas.

Este es el orden que me funcionó a mí y a la mayoría de las personas con las que he hablado:

Empieza aquí:

• Línea de comandos de Linux. No nivel experto. Navegar directorios, editar archivos, leer logs, entender permisos. Dos semanas de práctica constante.
• Fundamentos de redes. Direcciones IP, subredes, DNS, HTTP/HTTPS, puertos. No necesitas un CCNA. Necesitas entender qué pasa cuando escribes una URL en un navegador.
• Un solo proveedor cloud. Elige AWS, Azure o GCP. Yo recomendaría AWS porque tiene la mayor cuota de mercado y más recursos de aprendizaje. No intentes aprender los tres.

Si buscas un punto de partida estructurado, esta guía recorre los fundamentos desde cero.

Luego agrega:

• Infraestructura como código (Terraform o CloudFormation)
• Contenedores (Docker primero, luego Kubernetes básico)
• CI/CD (GitHub Actions o GitLab CI — construye un pipeline real)
• Fundamentos de monitoreo (CloudWatch, Prometheus o similar)

Ignora por ahora:

• Kubernetes avanzado (lo aprenderás en el trabajo)
• Arquitectura multi-cloud (nadie contrata juniors para esto)
• Serverless a fondo (útil después, no es prioridad de contratación)
• MLOps (especialización, no fundamento)

Certificaciones: ¿sí o no?

Sí. Enfáticamente sí — pero por la razón correcta.

Las certificaciones no prueban que puedas hacer el trabajo. Los reclutadores lo saben. Lo que hacen es pasar tu CV por el primer filtro. Cuando estás cambiando de carrera sin experiencia laboral relevante, una certificación es la señal de credibilidad más rápida que puedes conseguir.

Empieza con: AWS Cloud Practitioner o AZ-900 (Azure Fundamentals). Baja dificultad, cobertura amplia, te familiariza con los formatos de examen.

Después: AWS Solutions Architect Associate o AZ-104 (Azure Administrator). Esta es la que realmente abre puertas. Le dice a los empleadores que entiendes cómo diseñar y desplegar infraestructura real.

Opcional pero valioso: Terraform Associate, Kubernetes (CKA), o una certificación específica de DevOps.

¿No sabes qué camino tomar? Esta ruta de certificación te ayuda a elegir la correcta para tu situación.

Un punto en el que insisto: no colecciones certificaciones como estampillas. Dos o tres certs bien elegidas más trabajo real en proyectos le gana a seis certs con un GitHub vacío.

Construye tu portfolio: tres proyectos que realmente importan

Tu portfolio necesita responder una sola pregunta: “¿Puede esta persona construir y mantener infraestructura real?”

Aquí tienes tres proyectos que lo demuestran, en orden de complejidad:

Proyecto 1: Sitio estático con pipeline CI/CD completo. Aloja un sitio estático en S3 (o equivalente), pon CloudFront delante, usa GitHub Actions para desplegar en cada push. Bonus: agrega un dominio personalizado con Route 53 y SSL. Esto demuestra que entiendes almacenamiento, CDN, DNS, automatización y control de versiones. Además es genuinamente útil — puedes usarlo como tu sitio personal.

Proyecto 2: Aplicación conteneurizada en infraestructura cloud. Toma cualquier app web simple (una lista de tareas está bien, a nadie le importa la app en sí), conteneurízala con Docker, despliégala en ECS o EKS, pon un balanceador de carga delante. Define todo en Terraform. Esto muestra contenedores, orquestación, infraestructura como código y networking.

Proyecto 3: Monitoreo y alertas. Agrega dashboards de CloudWatch (o Prometheus/Grafana) al Proyecto 2. Configura alarmas para CPU, memoria, tasas de error. Crea una notificación SNS cuando algo se rompe. Esto muestra que piensas en operaciones, no solo en despliegue.

Documenta cada proyecto en el README de tu GitHub. Explica qué construiste, por qué tomaste esas decisiones y qué mejorarías. Esa documentación importa más de lo que crees.

Tu carrera anterior es un activo (no una debilidad)

Esta es la parte que quienes cambian de carrera más subestiman.

Cada trabajo enseña habilidades transferibles. Cloud y DevOps resulta que valora muchas de ellas:

• Enseñanza → Sabes explicar sistemas complejos a personas no técnicas. Eso es raro y valioso.
• Gestión de proyectos → Entiendes plazos, dependencias y alcance. Eso es literalmente planificación de infraestructura.
• Contabilidad/finanzas → Captas la optimización de costos de forma intuitiva. La gestión de costos cloud es una especialidad real.
• Marketing → Piensas en métricas y resultados. El monitoreo y los SLA te parecerán naturales.
• Sector salud → Estás acostumbrado a procesos críticos y cumplimiento normativo. Bienvenido a los entornos cloud regulados.

En las entrevistas, no te disculpes por tu trayectoria. Enmárcala. “Pasé cinco años gestionando la logística de una cadena de distribución, lo que significa que he manejado sistemas complejos, plazos ajustados y cosas rompiéndose en producción — solo que no la versión digital.”

La búsqueda de empleo: dónde postular y cómo presentar tu CV

Dónde buscar:

• LinkedIn con alertas para “Junior Cloud Engineer,” “DevOps Junior,” “Ingeniero Cloud.”
• Portales especializados en remoto: We Work Remotely, Remote OK, Getonbrd.
• Las ofertas de los proveedores cloud: AWS, Azure y GCP contratan ingenieros de soporte cloud. Son excelentes primeros puestos.
• Consultoras y MSP (Managed Service Providers). Siempre están contratando y te expondrás a muchos entornos diferentes rápidamente.

Consejos de CV para quienes cambian de carrera:

• Empieza con un resumen que asuma la transición: “Antes [rol], en transición hacia ingeniería cloud. Certificado AWS Solutions Architect Associate. Construyó y desplegó [X] en [Y].”
• Pon las certificaciones arriba, no enterradas al final.
• Lista tus proyectos como experiencia laboral. Cada uno lleva un título, fecha y viñetas describiendo qué construiste y qué herramientas usaste.
• Tu carrera anterior va en una sección llamada “Experiencia complementaria.” Mantenla en dos o tres líneas enfocadas en habilidades transferibles.

El plazo que debes esperar: Desde las primeras postulaciones hasta la primera oferta, cuenta con uno a tres meses de búsqueda activa. Las primeras veinte postulaciones duelen. Eso es normal. Sigue adelante.

FAQ

¿De verdad no necesito un título en informática?

De verdad. Un informe de LinkedIn Workforce de 2025 mostró que más del 40% de los profesionales cloud contratados ese año no tenían un título tradicional en informática. A los empleadores les importa lo que puedes hacer. Una certificación más un portfolio de proyectos reales habla más fuerte que un diploma de hace diez años. Eso sí, necesitas aprender los fundamentos — redes, Linux, scripting básico. Solo que no necesitas una universidad para eso.

¿Cuánto cuesta realmente el cambio de carrera?

Menos de lo que piensas. El Free Tier de AWS cubre la mayoría de lo que construirás en los primeros seis meses. Los exámenes de certificación cuestan entre 100 y 300 dólares cada uno. Los recursos de Linux y redes son gratuitos en línea. Presupuesto realista total: 300 a 800 dólares en todo el período de transición. Compara eso con un bootcamp (10.000 dólares o más) o un título universitario (40.000 dólares o más). El verdadero costo es el tiempo, no el dinero.

¿Debería renunciar a mi trabajo para estudiar a tiempo completo?

No lo recomendaría. La mayoría de las personas que conozco que hicieron este cambio con éxito lo hicieron a tiempo parcial. Dos horas al día entre semana, cuatro a seis los fines de semana. Renunciar añade presión financiera que hace más difícil aprender bien y más difícil tener paciencia durante la búsqueda de empleo. Si puedes reducir tus horas o pasar a medio tiempo en tu trabajo actual, ese es el punto ideal.

¿Y si no soy lo suficientemente “técnico” para esto?

Estás confundiendo “técnico” con “experimentado.” Cada ingeniero cloud empezó sin saber qué era una subred. Si puedes seguir instrucciones, resolver problemas y tolerar la incomodidad mientras aprendes, tienes las habilidades básicas. Lo técnico se aprende. La disciplina para seguir adelante cuando todo es confuso — ese es el verdadero filtro, y quienes cambian de carrera a menudo tienen más de eso que los recién graduados.

¿Listo para planificar tu cambio de carrera hacia el cloud? Empieza con SkillRealm Learn →