Problema

Muchas empresas y profesionales han construido entornos productivos con CloudFormation y Ansible porque esas herramientas estaban maduras y bien soportadas cuando el proyecto arrancó. Con el tiempo, el mercado laboral y los estándares de la industria han evolucionado: Kubernetes se ha convertido en la plataforma de facto para orquestar contenedores y Terraform es la herramienta de infraestructura como código (IaC) más demandada. El reto surge cuando un ingeniero necesita demostrar que su experiencia con stacks “legacy” es transferible y, además, necesita migrar una infraestructura existente sin interrumpir el servicio.

El patrón típico es: un stack estable (EC2 + S3 + Lambda) gestionado con CloudFormation y Ansible, con cientos de contenedores stateful, y la necesidad de:

  1. Adoptar Kubernetes para futuros proyectos o para alinearse con los requisitos de los empleadores.
  2. Reemplazar CloudFormation/Ansible por Terraform para unificar el flujo de trabajo IaC.
  3. Mantener la disponibilidad y la integridad de los datos durante la transición.

Causa

1. Dependencia de herramientas propietarias

CloudFormation está atado al ecosistema AWS; cualquier intento de portar la infraestructura a otro proveedor o a una capa de abstracción (Terraform) requiere re‑escribir plantillas. Ansible, aunque flexible, se usa mayormente para configuración imperativa y carece de un modelo declarativo de recursos, lo que dificulta la auditoría y la reproducibilidad.

2. Falta de experiencia práctica con Kubernetes

Los conceptos de pods, deployments y StatefulSets son claros en teoría, pero la operatividad (network policies, storage classes, helm charts) solo se consolida con despliegues reales. Sin una base productiva, el ingeniero se siente inseguro frente a entrevistas que exigen “hands‑on” en Kubernetes.

3. Estado de la aplicación

Aplicaciones stateful (bases de datos, caches) no se migran simplemente con kubectl run. Necesitan volúmenes persistentes, estrategias de migración de datos y, a veces, un enfoque híbrido donde parte del stack sigue en EC2 mientras se introduce EKS.

4. Cultura de “tool‑centric” en reclutamiento

Los filtros de CV y los tests técnicos se centran en palabras clave: “K8s”, “Terraform”, “Helm”. La experiencia con CloudFormation y Ansible queda en segundo plano, aunque la capacidad de operar a gran escala sea comparable.

Solución

Una migración por fases permite reutilizar la infraestructura existente, ganar experiencia práctica y presentar un portfolio alineado con las demandas del mercado.

1. Inventario y mapa de dependencias

  • Exporta todas las pilas de CloudFormation (aws cloudformation list-stacks y aws cloudformation get-template).
  • Genera un listado de playbooks de Ansible y los hosts a los que se aplican.
  • Documenta los recursos críticos: bases de datos, volúmenes EBS, buckets S3, endpoints de API Gateway.

Este inventario será la base para crear módulos Terraform y chart de Helm.

2. Adoptar Terraform como capa única de IaC

a) Estructura de proyecto

infra/
├── modules/
│   ├── vpc/
│   ├── ec2/
│   ├── eks/
│   └── s3/
├── environments/
│   ├── prod/
│   │   └── main.tf
│   └── dev/
│       └── main.tf
└── terraform.tfvars

b) Migrar recursos estáticos

Comienza con recursos que no cambian frecuentemente (VPC, subnets, security groups). Usa el comando terraform import para traer recursos existentes al estado de Terraform sin destruirlos.

terraform import aws_vpc.main vpc-0a1b2c3d4e5f6g7h
terraform import aws_subnet.public subnet-0123456789abcdef0

c) Convertir Ansible a Terraform provisioners o a módulos de configuración

Para configuraciones de software (instalación de agentes, ajustes de sysctl) crea módulos Terraform que utilicen remote-exec o, mejor, migra a cloud‑init o EC2 user data para que la configuración sea declarativa.

3. Introducir Kubernetes de forma incremental

a) Desplegar un clúster EKS gestionado

Utiliza el módulo oficial de Terraform terraform-aws-modules/eks/aws. Configura al menos dos node groups: uno con capacidad de cómputo general y otro con discos EBS optimizados para workloads stateful.

terraform init
terraform apply -target=module.eks

b) Migrar workloads sin estado primero

  • Identifica microservicios que pueden correr en contenedores sin volúmenes persistentes.
  • Empaqueta cada uno en una Helm chart mínima (deployment, service, ingress).
  • Despliega en el clúster de prueba y valida con kubectl port-forward o pruebas de integración.

c) Manejar workloads stateful

  • Crea StatefulSets con volumeClaimTemplates que referencien StorageClasses basadas en EBS.
  • Usa Velero para backups de volúmenes antes de la migración.
  • Implementa una estrategia de “blue‑green” donde la versión antigua sigue en EC2 mientras la nueva corre en EKS; sincroniza la base de datos mediante replicación o dump‑restore.

d) Gradual cut‑over

  1. Redirige tráfico de un sub‑dominio a la nueva versión en Kubernetes (CloudFront + Lambda@Edge o Route53 weighted routing).
  2. Monitorea métricas (CPU, latencia, errores 5xx) durante 24‑48 h.
  3. Cuando la estabilidad sea confirmada, apaga la instancia EC2 correspondiente.

4. Documentar y automatizar pruebas

  • Usa Terratest o kitchen‑terraform para validar que los módulos crean los recursos esperados.
  • Integra pruebas de smoke en GitHub Actions o GitLab CI: despliegue de un pod de prueba, verificación de endpoints, rollback automático si falla.

5. Presentar el nuevo stack en tu CV

  • Lista los módulos Terraform creados y los charts Helm publicados en un repositorio público.
  • Incluye métricas de escala (p.ej., “orquesté 3 500 contenedores en EKS con 99.95 % de uptime”).
  • Resalta la migración sin downtime como caso de estudio.

Cuándo aplicar esta solución

  • Síntomas: Necesidad de modernizar la IaC, presión del mercado laboral, o planes de expansión a multi‑cloud.
  • Escenarios válidos: Infraestructura mayormente en AWS, con workloads containerizados, y al menos una parte de la aplicación que pueda migrarse sin estado.
  • No aplica: Cuando la arquitectura es exclusivamente on‑premise sin acceso a servicios gestionados, o cuando la aplicación depende de recursos que no tienen equivalentes en Kubernetes (p.ej., hardware especializado).

Código

# Importar VPC existente a Terraform
terraform import aws_vpc.main vpc-0a1b2c3d4e5f6g7h

# Crear clúster EKS con módulo oficial
module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "prod-eks"
  cluster_version = "1.30"
  subnets         = module.vpc.private_subnets
  node_groups = {
    general = {
      desired_capacity = 3
      instance_type    = "t3.medium"
    }
    stateful = {
      desired_capacity = 2
      instance_type    = "m5.large"
      root_volume_type = "gp3"
    }
  }
}

Verificación

  1. Ejecuta terraform plan y confirma que no se proponen destrucciones inesperadas.
  2. Después del apply, verifica recursos con aws ec2 describe-instances y aws eks describe-cluster.
  3. En Kubernetes, comprueba que los pods estén en estado Running y que los PVC estén bound: 
    kubectl get pods -n app
kubectl get pvc -n app
  4. Realiza pruebas de endpoint desde una máquina externa: 
    curl -s -o /dev/null -w "%{http_code}" https://api.tu-dominio.com/health
    El código debe ser 200.
  5. Monitorea logs de CloudWatch y métricas de Prometheus durante al menos 24 h antes de desactivar la infraestructura legacy.

Notas adicionales

  • Backup antes de migrar: Usa snapshots de EBS y versiones de S3 para evitar pérdida de datos.
  • Gestión de secretos: Reemplaza variables de Ansible por AWS Secrets Manager o HashiCorp Vault, y referencia los secretos en los charts Helm mediante envFrom.
  • Costos: Mantener ambos entornos (EC2 + EKS) duplica temporalmente los gastos; estima el presupuesto y define una ventana de migración corta.
  • Formación: Dedica tiempo a labs de Kubernetes (k8s.io/docs/tutorials) y a los ejercicios oficiales de Terraform (learn.hashicorp.com). La práctica real en un clúster de staging acelera la curva de aprendizaje y genera material tangible para entrevistas.

Con este enfoque por fases, se transforma una infraestructura basada en CloudFormation y Ansible en un stack moderno de Kubernetes y Terraform, se gana experiencia práctica y se alinea el perfil profesional con las expectativas actuales del mercado.