"Debemos usar Kubernetes" es una de las frases que más veces hemos escuchado en consultas iniciales con empresas latinoamericanas. Casi siempre va seguida de una conversación donde descubrimos que la empresa tiene tres servicios, cinco desarrolladores y un CTO que leyó sobre K8s en un artículo de LinkedIn. Esta guía es una dosis de pragmatismo sobre cuándo Docker y Kubernetes realmente aportan valor, y cuándo son over-engineering costoso.
Por qué Docker es casi siempre una buena idea
Docker resuelve un problema real: "funciona en mi máquina pero no en producción". Al containerizar tu aplicación, empaquetas el código junto con todas sus dependencias en una imagen reproducible.
Las ventajas concretas:
Ambientes consistentes: El mismo container corre en el laptop del desarrollador, en CI/CD y en producción. Se acabaron las discrepancias de versiones de Node, Python o PHP.
Despliegues más simples: En lugar de configurar cada servidor manualmente, simplemente corres el container. Rollbacks son triviales: vuelves a la imagen anterior.
Aislamiento: Múltiples aplicaciones con diferentes versiones del mismo runtime conviven sin conflictos en el mismo servidor.
Dockerfile para una aplicación Node.js
FROM node:22-alpine AS base
WORKDIR /app
# Instalar dependencias primero (mejor cache de layers)
FROM base AS deps
COPY package*.json ./
RUN npm ci --only=production
# Build
FROM base AS builder
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Imagen final ligera
FROM base AS runner
ENV NODE_ENV=production
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]
Este Dockerfile multi-stage genera una imagen de producción liviana que solo incluye lo necesario.
Cuándo Docker solo es suficiente
Para la mayoría de empresas en crecimiento, Docker + docker-compose para local y un orquestador simple para producción es todo lo que necesitan.
Si tu escenario es:
- Menos de 10 servicios
- Tráfico predecible sin spikes extremos
- Equipo pequeño (menos de 10 desarrolladores)
- Sin requisitos de zero-downtime deployment complejos
Entonces plataformas como Railway, Render, Fly.io o incluso una VPS con Docker compose son la elección correcta. Son órdenes de magnitud más simples de operar.
Cuándo realmente necesitas Kubernetes
K8s aporta valor real cuando:
Necesitas escalar horizontalmente de forma automática: Si tienes servicios que necesitan crecer de 2 a 50 réplicas en minutos (por ejemplo, un e-commerce en una campaña de descuentos), el HPA (Horizontal Pod Autoscaler) de K8s es muy poderoso.
Tienes muchos microservicios: A partir de 15-20 servicios, la gestión manual de donde corre cada cosa se vuelve compleja. K8s proporciona una plataforma coherente.
Necesitas garantías de disponibilidad: Self-healing, rolling deployments, health checks automáticos. K8s maneja esto de forma nativa.
Tu equipo ya tiene experiencia con K8s: Sin esto, el costo de aprendizaje puede dominar el costo de operación por meses.
Los costos reales de K8s
Este punto frecuentemente sorprende a quienes consideran K8s:
Cluster mínimo viable en AWS (EKS)
- 3 nodos t3.medium: ~$100 USD/mes
- Load Balancer: ~$20 USD/mes
- Storage (EBS): variable
- Soporte AWS o Engineer dedicado: $0 si tienes el expertise, potencialmente $3,000-10,000/mes si no
Total mínimo: $120+ USD/mes solo en infraestructura, sin contar el tiempo de operación.
Alternativas por costos comparativos
| Plataforma | Costo mensual aprox. | Complejidad operativa | |------------|---------------------|----------------------| | Railway (2 servicios) | $20-50 | Muy baja | | Render (3 servicios) | $25-75 | Baja | | Fly.io (auto-scaling) | $30-100 | Media | | VPS + Docker | $20-50 | Media | | K8s managed (EKS/GKE) | $150+ | Alta | | K8s self-managed | $50+ | Muy alta |
Para una startup o empresa mediana con menos de $200k ARR, el overhead operativo de K8s raramente justifica sus beneficios.
K8s Managed: EKS, GKE y AKS
Si decides usar Kubernetes, usa siempre una versión gestionada. Operar K8s sin soporte del proveedor de nube es trabajo de un equipo dedicado.
GKE (Google Kubernetes Engine): Generalmente considerado el más maduro y con mejor integración de herramientas. Autopilot mode reduce la complejidad operativa significativamente.
EKS (Amazon EKS): Mejor si ya estás en AWS y usas muchos servicios nativos de AWS.
AKS (Azure): Mejor si estás en el ecosistema Microsoft.
Para LATAM con restricciones de latencia, las regiones us-east-1 (AWS), us-central1 (GCP) o eastus (Azure) son las más cercanas y comunes.
El framework de decisión
Antes de decidir, responde estas preguntas:
- ¿Cuántos servicios tienes ahora? Si menos de 8, probablemente no necesitas K8s.
- ¿Tienes alguien en el equipo con experiencia en K8s? Sin esto, el costo de aprendizaje es enorme.
- ¿Tu tráfico tiene variaciones de 10x o más? Si no, el auto-scaling de K8s no te da valor real.
- ¿Cuál es el costo de una hora de downtime? Si es bajo, las plataformas más simples son suficientes.
Si respondes "sí" a 2+ preguntas de las últimas tres, K8s merece consideración seria.
Conclusión: elige la herramienta correcta para tu momento
Docker es casi siempre la respuesta correcta para containerizar tus aplicaciones. Kubernetes es la respuesta correcta para orquestar esos containers solo cuando la escala y la complejidad lo justifican.
En Alternetica hemos ayudado a empresas a simplificar infraestructuras sobre-ingeniadas tanto como a escalar las que llegaron a sus límites. El criterio no es "qué es más moderno" sino "qué resuelve el problema con el menor overhead operativo".
Si estás evaluando tu infraestructura actual o planificando la arquitectura de un nuevo sistema, contáctanos para una consulta de arquitectura.