Problema

Los estudiantes y desarrolladores que están aprendiendo a orquestar microservicios suelen terminar con un clúster local (por ejemplo, kind) y preguntarse cómo trasladar esa arquitectura a la nube sin que la factura se dispare. El reto típico incluye:

  • Cinco servicios Node.js empaquetados como contenedores.
  • Bases de datos PostgreSQL dedicadas por servicio, además de Redis y Kafka.
  • Pilas de observabilidad (Prometheus, Grafana, Loki, Alloy) desplegadas mediante Helm.
  • Necesidad de automatizar la provisión con Terraform para poder crear, grabar demos y destruir el entorno rápidamente.

En entornos reales, los equipos deben equilibrar tres variables: coste, complejidad operativa y alineación con prácticas de producción. La pregunta central es cuál es la combinación de servicios gestionados y auto‑gestionados que permite mantener el gasto bajo y, al mismo tiempo, demostrar habilidades que interesen a reclutadores.

Causa

Los principales factores que influyen en el coste y la complejidad son:

  1. Elección del tipo de clúster – Un clúster gestionado (EKS, GKE) incluye control plane gratuito o de bajo coste, pero cada LoadBalancer externo y cada nodo adicional generan cargos. Un clúster “bare‑metal” en una única VM reduce los cargos de red, pero transfiere la carga de mantenimiento del control plane al usuario.
  2. Persistencia de datos – Ejecutar PostgreSQL, Redis o Kafka dentro del mismo clúster que los microservicios implica usar volúmenes persistentes. En la nube, los discos de bloques y los snapshots son facturables por GB‑mes y por IOPS.
  3. Ingress y balanceo – Los proveedores de nube cobran por cada LoadBalancer tipo Classic/Network. Cuando la arquitectura usa el Gateway API, cada Gateway suele crear un LB externo, lo que puede elevar la factura rápidamente.
  4. Escalado automático – Sin políticas de auto‑escalado, los nodos permanecen activos aunque la carga sea mínima, desperdiciando recursos.
  5. Licencias y cuotas de servicios gestionados – Algunas ofertas (por ejemplo, Amazon MSK) tienen precios mínimos que superan el presupuesto estudiantil.

Solución

Una estrategia que equilibra coste y realismo profesional combina:

  • Clúster gestionado ligero – Usa EKS Fargate o GKE Autopilot con un único nodo de trabajo (t2.micro / e2-micro). El control plane es gratuito o muy barato, y el nodo se paga por segundo.
  • Ingress económico – En lugar de un LoadBalancer por cada Gateway, despliega AWS ALB Ingress Controller o GCP HTTP(S) Load Balancer una sola vez y enruta todo el tráfico interno mediante IngressClass que apunte al mismo LB. Alternativamente, usa NGINX Ingress Controller con Service type=ClusterIP y expón el LB solo en el puerto 80/443.
  • Persistencia externa mínima – Para la demo, emplea Amazon RDS Free Tier o Cloud SQL Free Tier para una única instancia PostgreSQL y comparte la base entre los servicios (con esquemas separados). Redis y Kafka pueden ejecutarse en el clúster usando StatefulSets y EBS gp3 de 5 GB; el coste mensual es < $5.
  • Infraestructura como código – Un módulo Terraform que:
    1. Crea el clúster gestionado.
    2. Provisiona los recursos de red (VPC, subredes, SG).
    3. Configura un único LoadBalancer.
    4. Despliega Helm charts para observabilidad y para cada microservicio.
  • Auto‑escalado agresivo – Configura Cluster Autoscaler con min_nodes = 1 y max_nodes = 2. Cuando la demo termina, ejecuta terraform destroy para eliminar todo en segundos.

Paso a paso resumido

  1. Terraform – Define provider, VPC y EKS (o GKE) con un nodo t2.micro.
  2. Helm – Usa charts oficiales: 
    helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack
helm install grafana grafana/grafana
helm install loki grafana/loki-stack
  3. Ingress – Instala NGINX Ingress Controller y crea un único Ingress que apunte a los servicios internos.
  4. Bases de datos – Si decides usar RDS, crea la instancia con Terraform y conecta los pods mediante Secret y Service.
  5. Kafka – Despliega Strimzi Operator y una única KafkaCluster con 1 broker; el almacenamiento se asigna a un PVC de 5 GB.

Cuándo aplicar esta solución

  • Presupuesto limitado – Cuando el gasto mensual debe permanecer bajo $20.
  • Necesidad de demo rápida – Cuando el objetivo es crear y destruir entornos en minutos.
  • Aprendizaje de prácticas de producción – La combinación de recursos gestionados y auto‑gestionados refleja lo que se ve en empresas medianas.
  • No es adecuada si la carga de trabajo es crítica, requiere alta disponibilidad multi‑AZ o necesita cumplimiento normativo estricto; en esos casos se opta por clústeres multi‑nodo y servicios totalmente gestionados.

Código

# terraform/main.tf (fragmento esencial)
provider "aws" {
  region = "us-east-1"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  name    = "demo-vpc"
  cidr    = "10.0.0.0/16"
  azs     = ["us-east-1a"]
  public_subnets  = ["10.0.1.0/24"]
  private_subnets = ["10.0.2.0/24"]
}

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "demo-eks"
  cluster_version = "1.30"
  subnets         = module.vpc.private_subnets
  node_groups = {
    demo = {
      desired_capacity = 1
      max_capacity     = 2
      min_capacity     = 1
      instance_type    = "t2.micro"
    }
  }
}

resource "aws_lb" "ingress" {
  name               = "demo-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = module.vpc.public_subnets
  security_groups    = [aws_security_group.alb.id]
}

Verificación

  1. Ejecuta terraform apply y confirma que el clúster y el ALB aparecen en la consola.
  2. Verifica que los pods de observabilidad están Running con kubectl get pods -n monitoring.
  3. Accede a http://<ALB-DNS> y comprueba que la página de Grafana se muestra.
  4. Usa kubectl exec -it <pod> -- psql -h <rds-endpoint> -U <user> -d <db> para validar la conexión a PostgreSQL.
  5. Genera tráfico con hey -n 1000 -c 10 http://<ALB-DNS>/api/health y observa métricas en Prometheus.

Notas adicionales

  • Credenciales – Almacena tokens de GHCR y credenciales de RDS en AWS Secrets Manager y referencia los secrets desde los pods mediante envFrom.
  • Límites de free tier – En AWS, el free tier de RDS cubre 750 horas de db.t2.micro; en GCP, Cloud SQL Free Tier ofrece 1 GB de almacenamiento. No excedas esos límites o la factura aumentará.
  • Persistencia efímera – Para la demo, los volúmenes de Kafka y Redis pueden ser emptyDir y perder datos al destruir el clúster; eso reduce costes y simplifica el teardown.
  • Coste de logs – Loki almacena logs en S3/GS; configura una política de retención de 7 días para evitar cargos inesperados.
  • Reutilización de módulos – Guarda los módulos Terraform en un repositorio propio; así puedes replicar la arquitectura en diferentes cuentas o regiones con un solo git clone.