Pasar de administrar sistemas a cloud engineer transfiere más de lo que parece: redes, identidad, copias de seguridad y diagnóstico valen igual en la nube, con otro nombre. Lo nuevo son tres cosas: la infraestructura declarada como código, Kubernetes como plano de control y el coste por consumo. En España la primera puerta la abre Azure, no AWS.
¿Qué hace un cloud engineer y en qué se diferencia de un sysadmin?
Un cloud engineer diseña, despliega y opera infraestructura en un proveedor de nube, y la declara en un repositorio en vez de configurarla a mano. Ahí está la diferencia. No es el temario. Es dónde vive el estado del sistema.
En un centro de datos propio tú sabes dónde está la máquina: la has montado, le has puesto el sistema operativo y conoces su historia. En cloud la máquina es un recurso que aparece cuando un fichero lo pide y desaparece cuando ese fichero cambia. El servidor deja de ser un objeto que se cuida y pasa a ser la salida de un programa.
Eso cambia el trabajo por debajo. Un sysadmin resuelve incidencias sobre un sistema que existe. Un cloud engineer escribe la definición de un sistema que se va a reconstruir muchas veces, y su incidencia típica no es un disco lleno, sino una diferencia entre lo que dice el código y lo que hay desplegado en producción.
El obstáculo real de la mayoría de los administradores de sistemas que quieren dar el salto no es que les falte temario. Es que su título dejó de publicarse antes que sus skills.
¿Qué parte de tu experiencia on-premise se transfiere?
La mayor parte. De los ocho bloques que sostienen el día a día de un sysadmin, tres se transfieren tal cual, cuatro cambian de nombre sin cambiar de fondo y solo uno exige rehacer el modelo mental desde el principio, que es una proporción muy distinta de la que sugiere cualquier temario de certificación cuando lo abres y ves ochocientas páginas de servicios con nombres que no reconoces.
| Lo que ya sabes | Cómo se llama en cloud | Qué cambia de verdad |
|---|---|---|
| Redes: subredes, routing, DNS, cortafuegos | VPC, security groups, DNS gestionado | Nada conceptual. La consola es otra |
| Diagnóstico bajo presión | Se llama igual | Nada. Es tu mayor activo y no se aprende en un curso |
| Linux y línea de comandos | Se llama igual | Nada. Sigue siendo el suelo de todo |
| Active Directory, permisos, grupos | IAM: roles y políticas | El permiso se concede a un rol, no a una persona, y caduca |
| Copias de seguridad y recuperación | Snapshots, versionado, réplicas entre zonas | El objetivo de recuperación se declara en vez de calendarizarse |
| Scripts de bash o PowerShell | Infraestructura como código | De imperativo a declarativo: describes el estado final, no los pasos |
| Nagios, Zabbix, alertas por umbral | Observabilidad: métricas, trazas y logs | Se instrumenta la aplicación, no solo la máquina |
| VMware, hipervisores, aislamiento | Contenedores y Kubernetes | El aislamiento se entiende igual. El ciclo de vida pasa de años a minutos |
El puente más corto está en la fila del scripting. Si ya has automatizado con Ansible tienes hecha media travesía hacia la infraestructura como código, porque los dos declaran un estado deseado y lo reconcilian contra la realidad. El mercado español tiene una preferencia clara entre ambos: Terraform aparece en 2.463 ofertas activas y Ansible en 968, dos veces y media más, sobre 24.217 ofertas con skills etiquetadas entre el 14 de junio y el 7 de septiembre de 2026 (análisis de mercado de Shakers).
Tu vacante actual ya pide cloud
Esto es lo que casi nadie mide antes de ponerse a estudiar: la transición ya empezó sin pedirte permiso.
De las 17 ofertas activas en España tituladas administrador de sistemas que llevan skills etiquetadas, 15 piden ya AWS, Azure, Google Cloud, Kubernetes, Docker o Terraform (Shakers, septiembre de 2026). Seis de cada veinte lo arrastran al propio título, del tipo administrador de sistemas cloud. Es un censo completo y no una muestra, con n=17: sólido como recuento, frágil como estadística, y con el ruido que mete cualquier etiquetado automático de skills.
El título, en cambio, se está apagando. En inglés, que es como España publica los dos puestos, cloud engineer aparece en 453 ofertas y system administrator en 59, en el mismo análisis de septiembre de 2026. Casi ocho veces más.
Lo que no se apaga es tu stack. VMware sale en 286 ofertas activas y Windows Server en 207. La infraestructura tradicional se sigue pidiendo, solo que con menos frecuencia bajo un puesto propio y con más frecuencia como una skill dentro de un perfil que se llama de otra manera, lo que significa que el mercado no está retirando tu trabajo sino repartiéndolo entre títulos que todavía no figuran en tu currículum. Ese es el paso de los roles a las skills. Medido en el mercado donde trabajas hoy.
¿Qué certificación abre la puerta en España?
Azure. La respuesta intuitiva sería AWS y el mercado español dice otra cosa.
| Certificación | Ofertas que la nombran (Shakers, septiembre de 2026) |
|---|---|
| AZ-104 (por su código) | 63 |
| Azure Administrator (por su nombre) | 52 |
| HashiCorp Terraform Associate | 38 |
| AWS Solutions Architect | 35 |
| Certified Kubernetes Administrator | 29 |
| Associate Cloud Engineer | 28 |
| Google Associate Cloud Engineer | 8 |
AZ-104 se nombra casi ocho veces más que la credencial equivalente de Google, una asimetría que no refleja la cuota global de las tres nubes sino la composición del tejido empresarial español, donde el peso histórico de Microsoft en el puesto de trabajo acaba arrastrando la infraestructura detrás. Y tiene una ventaja añadida para quien viene de on-premise: su temario es administración y no arquitectura. Identidad, gobernanza, almacenamiento, redes virtuales, máquinas y monitorización. Es tu trabajo de ahora con otra consola delante.
Dos avisos antes de que apuntes el número. AZ-104 y Azure Administrator son la misma credencial nombrada de dos maneras, así que sus recuentos no se suman. Y el papel abre la criba sin resolverla.
Sobre las 166 ofertas que nombran alguna de esas seis certificaciones (Shakers, septiembre de 2026), el requisito duro no llega a 24, y no supera 37 ni midiendo con la ventana de texto más laxa. Menos de una cuarta parte en cualquiera de los dos casos. En el resto aparece como se valorará o como plus. Esa proporción es la mejor noticia de la tabla: la certificación te mete en la pila de candidatos, y dentro de la pila decide lo que sabes operar.
¿Cloud engineer, DevOps o SRE?
Tres destinos con tres distancias distintas desde donde estás ahora.
- Cloud engineer es el salto corto. Sigues siendo quien construye y opera infraestructura, y lo que cambia es el sustrato.
- DevOps engineer añade el ciclo de vida del software: integración y despliegue continuos, y una relación diaria con quien escribe el código. Si no lo tienes claro, empieza por qué es DevOps y por cómo GitOps convierte el repositorio en la fuente de verdad del despliegue.
- SRE añade compromiso numérico: objetivos de disponibilidad, presupuesto de error y una guardia con consecuencias contractuales. La comparación está en qué es SRE.
El orden natural desde sysadmin es cloud primero. Las otras dos rutas piden contexto de desarrollo que un centro de datos no te da, y hay una cuarta que se confunde a menudo con ellas: la frontera está en las diferencias entre DevOps y platform engineering.
¿Cuánto tarda la transición?
No hay un número honesto que sirva para todos, y quien te dé uno te está vendiendo un curso.
Sí se puede acotar el marco. Si tu vacante actual ya menciona nube, que es lo probable según el recuento de arriba, el tiempo de exposición no tienes que fabricarlo: ya lo estás acumulando en horario laboral. Lo que falta es formalizarlo y poder demostrarlo.
El factor que más acorta o alarga el proceso no es el estudio. Es tener un entorno donde equivocarte sin romper nada de nadie, porque la distancia entre haber leído cómo se configura una red virtual y haber dejado tu propio laboratorio sin salida a internet durante una tarde entera es la misma distancia que un entrevistador detecta en dos preguntas. Un laboratorio propio con gasto controlado enseña más en un mes que tres meses de vídeos, entre otras cosas porque la factura te obliga a entender el modelo de coste desde el primer día.
¿Qué se aprende de cero y en qué orden?
Cuatro bloques, y el orden importa tanto como el contenido.
- Infraestructura como código, en modo declarativo. Terraform primero, por el dos y medio a uno que marca el mercado español. Si vienes de Ansible el concepto ya lo tienes y lo que cambia es la sintaxis.
- Contenedores, y después el orquestador. Docker antes que Kubernetes, siempre. Saltarse el contenedor para llegar antes al plano de control es la vía rápida a operar algo que no entiendes.
- El modelo de coste por consumo. En cloud una decisión de arquitectura es una decisión de gasto, y esa cuenta no existía en tu centro de datos porque el hardware ya estaba pagado.
- Identidad en la nube, o IAM. Es donde se rompen las migraciones y donde tu experiencia con Active Directory rinde más de lo que esperas.
Nada de esto es un máster. Es el orden en que se pisan las piedras.
Cuando esas skills están verificadas dejan de ser un párrafo de tu currículum y pasan a ser un criterio con el que una empresa te encuentra. Ahí es donde Shakers funciona como infraestructura: acredita el skill, no el título del puesto anterior, y lo conecta con proyectos que lo piden. Colabora por proyecto con Shakers y deja que la acreditación haga el trabajo que hoy hace tu descripción de LinkedIn.
Preguntas frecuentes
- ¿Hace falta saber programar para ser cloud engineer?
Hace falta escribir código de infraestructura, que es otra cosa. Terraform, YAML y Python de automatización, no desarrollo de producto. Si ya mantienes scripts de bash o PowerShell, el salto es de paradigma y no de lenguaje: pasas de describir los pasos a describir el estado final. Nadie te va a pedir que implementes una función de negocio.
- ¿Sirve la experiencia con VMware en un puesto cloud?
Sirve, y además se sigue pidiendo: VMware aparece en 286 ofertas activas en España sobre 24.217 con skills etiquetadas (Shakers, septiembre de 2026). El modelo mental de aislamiento, plantillas y aprovisionamiento se transfiere entero a contenedores. Lo que cambia es la escala temporal, porque una máquina virtual vive años y un contenedor puede vivir minutos.
- ¿AWS o Azure para empezar en el mercado español?
Azure, si el criterio es entrar antes. AZ-104 se nombra en 63 ofertas activas frente a 35 de AWS Solutions Architect (Shakers, septiembre de 2026), y su temario es administración pura, así que solapa más con lo que ya haces. AWS sigue siendo la nube con más cuota global y no es una apuesta perdida, pero como primera puerta en España pesa menos.
- ¿Se puede pasar de sysadmin a cloud engineer sin certificación?
Sí. Sobre las 166 ofertas activas en España que nombran alguna de las seis certificaciones cloud más citadas (Shakers, septiembre de 2026), el requisito duro no llega a 24, y no supera 37 ni midiendo con la ventana de texto más laxa. En el resto figura como se valorará o como plus. El papel te mete en la pila de candidatos; dentro de la pila decide lo que sabes operar.
- ¿Qué diferencia hay entre cloud engineer y arquitecto cloud?
El alcance de la decisión. El cloud engineer construye y opera lo que está definido; el arquitecto define el modelo de referencia, el reparto entre servicios gestionados y propios, y el coste que la empresa va a asumir durante años. Casi nadie llega a arquitecto sin haber operado antes, así que suele ser el paso siguiente y no una alternativa. Los rangos de uno y otro están en el análisis de salario de arquitecto cloud y en el de DevOps engineer.
- ¿Es tarde para hacer esta transición en 2026?
Va con retraso, que no es lo mismo. El puesto de administrador de sistemas se sigue publicando en España, pero de las 17 ofertas activas con ese título y skills etiquetadas, 15 ya piden nube o contenedores (Shakers, septiembre de 2026). La transición está ocurriendo dentro de tu propio puesto. Lo que queda por hacer es nombrarla y acreditarla.
