Cómo saber si enfocarse solo en on‑prem Kubernetes sin AWS/Azure perjudica tu carrera DevOps

Problema

Muchos ingenieros junior dedican su tiempo a montar clústers de Kubernetes en servidores propios, usando herramientas como K3s, Cilium, ArgoCD o Longhorn. La inquietud surge cuando el mercado laboral pide experiencia en los grandes proveedores de nube (AWS, Azure, GCP). La pregunta central es si una carrera centrada exclusivamente en infraestructura on‑prem puede quedar rezagada frente a perfiles que manejan servicios gestionados en la nube, y cómo equilibrar ambos mundos sin perder profundidad técnica.

Causa

1. Demanda de habilidades híbridas – Las empresas que migran a la nube o mantienen entornos mixtos buscan profesionales que comprendan tanto la gestión de recursos físicos como la orquestación de servicios en la nube. Un curriculum que solo muestra “todo en casa” puede percibirse como limitado.

2. Visibilidad de los conceptos – Herramientas como Terraform, GitOps o CNI son idénticas en su API, pero los proveedores de nube añaden capas de abstracción (EKS, AKS, GKE, RDS, etc.). Si nunca se ha interactuado con esas capas, el candidato puede tardar más en adaptarse a los flujos de trabajo de la nube.

3. Ecosistema de certificaciones y pruebas técnicas – Los procesos de entrevista frecuentemente incluyen preguntas sobre IAM, VPC, balanceadores de carga gestionados o políticas de seguridad específicas de AWS/Azure. La falta de exposición directa genera incertidumbre en la entrevista.

4. Cultura de “managed services” – En entornos cloud‑first, la expectativa es delegar la operación de bases de datos, almacenamiento y networking a servicios gestionados. Un perfil que solo ha usado Longhorn o CloudNativePG en VMs necesita demostrar que entiende la lógica detrás de los servicios gestionados para ser considerado.

Solución

Adoptar una estrategia de aprendizaje incremental que combine la profundidad on‑prem con experiencias controladas en la nube. Los pasos clave son:

1. Mapear conceptos comunes

Crea una tabla mental (o física) que relacione cada componente on‑prem con su equivalente gestionado:

Al identificar los pares, queda claro que la mayoría de los conocimientos (pods, control plane, RBAC, Helm) son transferibles; solo cambian los puntos de integración.

2. Ejecutar laboratorios “cloud‑lite”

Utiliza la capa gratuita de los proveedores para crear recursos mínimos que reproduzcan tu stack on‑prem:

• Kubernetes gestionado – Lanza un clúster EKS con 2 nodos t2.micro. Conecta ArgoCD y despliega la misma aplicación que tienes en K3s. Observa diferencias en networking (AWS VPC CNI) y en los permisos de IAM para los nodos.
• Base de datos gestionada – Provisiona una instancia PostgreSQL en RDS. Conecta CloudNativePG como cliente y compara latencias y configuraciones de backup.
• Almacenamiento – Crea un PersistentVolume usando el CSI de EBS y monta un PVC idéntico al de Longhorn.

Estos laboratorios no requieren gran inversión y permiten validar que los patrones de GitOps, Helm y políticas de seguridad siguen funcionando.

3. Extender Terraform a la nube

Si ya usas Terraform contra infraestructura local, agrega un provider de AWS o Azure a tu mismo proyecto. Un ejemplo mínimo:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "local" {}
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_vpc" "demo" {
  cidr_block = "10.0.0.0/16"
}

Mantén los módulos on‑prem y cloud separados pero reutiliza variables y outputs. Así el mismo código base sirve para ambos entornos, lo que refuerza la idea de “infraestructura como código” universal.

4. Certificaciones focalizadas

No es necesario obtener la certificación completa de AWS Solutions Architect de inmediato. Un curso corto de “AWS Certified Cloud Practitioner” o “Azure Fundamentals” brinda vocabulario de IAM, VPC y costos, suficiente para conversar en entrevistas y entender la documentación de los servicios gestionados.

5. Mostrar el combo en el CV

En la sección de experiencia, lista cada herramienta con su contraparte cloud. Por ejemplo:

• Kubernetes (K3s) – implementación de clústeres on‑prem y pruebas de migración a EKS (AWS)
• Cilium – configuración de políticas de red, comparada con AWS VPC CNI
• ArgoCD – pipelines GitOps en entornos híbridos (on‑prem + EKS)

Esto comunica que posees la base y la capacidad de adaptarte.

Cuándo aplicar esta solución

• Entornos híbridos – Empresas que operan tanto en data‑center propio como en la nube. La solución permite alinear procesos y reducir fricción entre equipos.
• Transiciones a la nube – Cuando el proyecto está en fase de migración y necesita validar que los artefactos on‑prem funcionan en la nube.
• Entrevistas técnicas – Si el proceso incluye pruebas de arquitectura cloud, la exposición a laboratorios “lite” brinda ejemplos concretos para discutir.

No es necesario cuando:

• El puesto es exclusivamente on‑prem – Algunas organizaciones (banca, telecom) siguen sin usar cloud y valoran solo la experiencia física.
• Se busca una especialización profunda en hardware – Roles de “bare‑metal engineer” pueden requerir más conocimiento de firmware que de servicios cloud.

Código

# Terraform init y apply contra AWS (solo VPC)
terraform init
terraform apply -auto-approve

Verificación

1. Conexión al clúster – Ejecuta kubectl get nodes contra el clúster EKS y verifica que los nodos aparecen como “Ready”.
2. Despliegue ArgoCD – Accede a la UI de ArgoCD y confirma que la aplicación sincroniza sin errores.
3. Persistencia – Crea un PVC usando el StorageClass de EBS, escribe un archivo y reinicia el pod. El archivo debe permanecer, demostrando que el CSI funciona como Longhorn.
4. Política de red – Aplica una NetworkPolicy en Cilium y verifica que el mismo comportamiento se reproduce con la política de seguridad de VPC en AWS.

Notas adicionales

• Costos ocultos – La capa gratuita tiene límites (por ejemplo, 750 h de t2.micro). Monitorea el uso para evitar sorpresas en la factura.
• IAM vs. sudo – En on‑prem sueles usar root o sudo. En la nube, los permisos se gestionan con roles IAM. Practica crear un rol con permisos mínimos para el nodo de EKS y asignarlo al nodo.
• Logs centralizados – Si ya usas Loki o Elastic on‑prem, prueba la integración con CloudWatch Logs o Azure Monitor; la lógica de recolección es la misma, solo cambia el endpoint.
• Backup – Los snapshots de EBS son equivalentes a los backups de Longhorn, pero se gestionan mediante la API de la nube. Prueba a crear un snapshot y restaurarlo para entender el flujo.

Adoptar una visión híbrida permite mantener la profundidad on‑prem que tanto disfrutas y, al mismo tiempo, abrir la puerta a oportunidades que exigen al menos un nivel básico de cloud. La clave está en mapear conceptos, ejecutar laboratorios controlados y reflejar esa versatilidad en tu perfil profesional. Con esa combinación, el riesgo de quedar “encajonado” desaparece y tu valor en el mercado se multiplica.