Roles de trabajo en la nube

Cuando una sola base de habilidades se convierte en 5 títulos de trabajo

Terminas el dominio de seguridad de este curso con soltura en políticas de IAM y en el modelo de responsabilidad compartida, así que abres un portal de empleos y buscas "cloud". Los resultados te devuelven Cloud Engineer, Cloud Architect, DevOps Engineer, Site Reliability Engineer y Cloud Security Engineer, y la mitad piden los mismos requisitos: AWS o Azure, redes, IAM, algo de scripting. Nada de eso te dice todavía a cuál aplicar.

Las vacantes no se diferencian por qué proveedor o qué servicios mencionan. Se diferencian en 2 cosas: en qué gastas tu día realmente, y cuánta autoridad tienes sobre el diseño completo del sistema. Aprende a leer esas 2 señales y el portal de empleos deja de verse como 5 versiones del mismo puesto.

Cloud Engineer: construye y opera lo que la arquitectura ya definió

Un Cloud Engineer toma un diseño que ya existe, completo o en esquema, y lo construye: aprovisiona cómputo y almacenamiento, arma la red, escribe los scripts de infraestructura como código que ya viste antes en este curso, y mantiene sano el sistema una vez que corre. Suele ser la puerta de entrada más común al trabajo en la nube, porque el día a día es concreto y está pegado a los servicios que ya estudiaste.

Una semana típica se ve así: levantar una VPC nueva con su esquema de subredes a partir de un ticket, revisar por qué un Auto Scaling group no lanza instancias nuevas, o actualizar un script de Terraform para agregar una réplica de lectura a una base de datos. El trabajo es concreto y las decisiones son mayormente locales: cómo implementar una parte del sistema, no si el sistema debería verse así desde el principio.

Cloud Architect: diseña el sistema y carga con los tradeoffs

Un Cloud Architect trabaja un nivel arriba. En vez de implementar una pieza del sistema, decide cómo debería verse el sistema completo: qué servicios encajan con un conjunto de requisitos de negocio, dónde van la redundancia y los tradeoffs de costo, y cómo se conectan las piezas entre sí. Este rol suele llegar después de varios años de experiencia como Engineer, porque el trabajo es anticipar consecuencias que alguien con menos camino recorrido todavía no tuvo oportunidad de ver de primera mano.

Un Cloud Architect se parece al arquitecto de un edificio. El arquitecto dibuja el plano, decide dónde van los muros de carga, que es donde viven las decisiones de redundancia y escalamiento, y elige los materiales, que en un sistema en la nube significa elegir los servicios. El Cloud Engineer es la cuadrilla del contratista: vacía la base, tiende el cableado y construye exactamente lo que el plano indica, y después mantiene el edificio terminado funcionando. La analogía sirve para la división entre diseñar y construir, pero se rompe en un punto: una arquitectura en la nube sigue cambiando después de salir a producción, a diferencia de un edificio terminado, así que un mismo ingeniero suele moverse entre construir y diseñar a medida que el sistema evoluciona. Los 2 roles quedan menos separados en la práctica de lo que están en una obra real.

Frontera: distinguir a un Architect de un Engineer en una vacante real

DevOps Engineer y Platform Engineer: tratar las operaciones como un problema de software

Ya conociste DevOps como práctica antes en este curso: la cultura y las herramientas que cierran la brecha entre escribir código y ponerlo a correr. DevOps Engineer es esa misma idea convertida en un título: alguien que construye y mantiene el pipeline de CI/CD y la automatización de infraestructura como código que permite a otros desarrolladores desplegar sin pasar por un traspaso manual a un equipo de operaciones aparte. Platform Engineer es un título cercano, cada vez más común, para la misma idea de fondo: construir las herramientas internas y los caminos ya pavimentados que dejan a otros ingenieros desplegar de forma segura por su cuenta.

Una tarea concreta se ve así: escribir un pipeline de GitHub Actions que corre las pruebas, arma una imagen de contenedor y la despliega a un entorno de staging automáticamente en cada merge, sin que nadie copie archivos a mano a un servidor.

Site Reliability Engineer: la misma idea, apuntada a la disponibilidad

Google, que acuñó el término, describe la Site Reliability Engineering de forma directa en su propio libro de SRE: "SRE es lo que pasa cuando le pides a un ingeniero de software que diseñe un equipo de operaciones." Un SRE pasa el día construyendo el monitoreo, las alarmas y la remediación automática que ya viste en el dominio de confiabilidad de este curso, los SLI y los SLO que miden si un sistema está sano, y la automatización que arregla una categoría completa de fallas en vez de resolver cada incidente a mano.

Es tentador escuchar "SRE" y asumir que es administración de sistemas con un título más moderno. No lo es. La administración de sistemas tradicional responde a los problemas uno por uno, a mano. SRE responde escribiendo software que previene o resuelve automáticamente toda una categoría de problema, una habilidad genuinamente distinta, construida sobre programación y no solo sobre experiencia operando sistemas.

Cloud Security Engineer: la mitad del cliente en la responsabilidad compartida, hecha trabajo diario

Un Cloud Security Engineer toma el modelo de responsabilidad compartida que viste antes en este curso y lo convierte en trabajo diario: escribir y auditar políticas de IAM, buscar buckets de almacenamiento mal configurados y abiertos al público, revisar la configuración de cifrado de los datos en reposo y en tránsito, y confirmar que los controles de gobernanza y cumplimiento se aplican de verdad, no solo que están documentados. Este rol existe en organizaciones de cualquier tamaño, porque una política de IAM mal configurada o un bucket abierto hacen exactamente el mismo daño en una startup de 3 personas que en una empresa grande.

Cómo se acomodan los 5 roles

La demanda detrás de estos roles

La Oficina de Estadísticas Laborales de Estados Unidos (BLS) no rastrea una ocupación llamada "Cloud Engineer" de forma directa, pero su categoría oficial más cercana, Computer Network Architects, proyecta cerca de 11,200 vacantes nuevas al año durante la próxima década, impulsadas en buena parte por la expansión continua de la computación en la nube y el rediseño de redes que trae consigo. Esa sola cifra se queda corta frente a la demanda real, porque deja afuera por completo a los roles de desarrollo, administración y seguridad enfocados en la nube, pero es una señal conservadora y útil de que la tendencia de fondo es real y está medida por el gobierno, no solo marketing de la industria.

Cómo entrar sin años de experiencia en producción

Es tentador asumir que cada uno de estos roles exige años de experiencia previa on-premises antes de que una empresa te considere para trabajo en la nube. Las vacantes de nivel de entrada en la nube aceptan de forma habitual otro tipo de prueba: trabajo práctico en laboratorios, proyectos personales que puedas describir en una entrevista, y una certificación de nivel foundational. Nada de eso exige tener antes un trabajo pago, que es justo lo que la siguiente lección de este tema te ayuda a construir.

Dónde te deja esto

Los 5 roles parten de la misma base de cómputo, almacenamiento, redes e IAM que construiste a lo largo de este curso; lo que los separa es el alcance (implementar contra diseñar), el método (operación manual contra ingeniería automatizada) y el enfoque (construir, correr o asegurar). Conocer ese mapa te dice a qué vacantes aplicar según en qué quieres gastar tu día. La siguiente lección pasa de conocer el mapa a demostrar que puedes hacer el trabajo, usando práctica gratuita en vez de un empleo pago.