Durante años, la forma tradicional de desplegar aplicaciones fue sencilla en apariencia: un servidor, un sistema operativo, dependencias instaladas a mano y una aplicación corriendo “directamente” sobre el host. Este enfoque funciona, y sigue funcionando, pero empieza a mostrar grietas cuando el sistema crece, cambia o necesita escalar.
Este artículo es una actualización de «Cuanto mejora el desempeño aplicar técnicas de contenedorización (Docker, Swarm, Kubernetes) a aplicaciones frente a instalaciones unitarias de la misma?» publicado en 2023.
La contenedorización —con Docker como estándar de facto y Kubernetes como orquestador dominante— no surge para hacer que el código “vuele” más rápido por sí mismo, sino para hacer que el sistema completo sea más eficiente, gobernable y resiliente.
La pregunta clave no es solo si mejora el desempeño, sino qué tipo de desempeño mejora realmente.
Instalaciones unitarias vs contenedorización: una diferencia de enfoque
En una instalación unitaria, la aplicación depende fuertemente del entorno: versión del sistema, librerías, configuración, variables, parches. El servidor se convierte en una “pieza única”, difícil de replicar con exactitud.
En la contenedorización ocurre lo contrario:
la aplicación incluye su entorno, se vuelve portable y reproducible. Esto cambia por completo la forma de desplegar y operar software.
Aquí aparece la primera aclaración importante:
Los contenedores no aceleran el CPU.
Aceleran la capacidad de cambiar, escalar y recuperarse.
Qué métricas sí mejoran con contenedores
Cuando hablamos de desempeño en este contexto, hablamos de métricas sistémicas:
- Tiempo de despliegue: pasar de horas o días a minutos.
- Utilización de recursos: mayor densidad de aplicaciones por nodo.
- Escalabilidad: capacidad de absorber picos de carga automáticamente.
- Disponibilidad: reinicio automático ante fallos.
- Consistencia: mismo comportamiento en desarrollo, pruebas y producción.
- Costo operativo: mejor uso de infraestructura, menos intervención manual.
Estas métricas no siempre se reflejan en un benchmark aislado, pero sí en la operación diaria.
Docker hoy: el estándar de empaquetado, no el orquestador
Docker sigue siendo una pieza fundamental, pero su rol está mucho más claro que hace algunos años.
Docker es, sobre todo:
- Una herramienta para construir imágenes reproducibles.
- Un estándar de facto para el desarrollo local y CI/CD.
- El lenguaje común entre desarrolladores y plataformas.
Un ejemplo mínimo de Dockerfile ilustra esta idea:
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "app.py"]
Aquí no hay magia:
la aplicación, sus dependencias y su forma de ejecutarse quedan definidas en un artefacto inmutable. Ese artefacto puede ejecutarse igual en un portátil, un servidor on-premise o en la nube.
Docker resuelve el qué se ejecuta.
Pero no resuelve el cómo se opera a escala.
Docker Swarm: un poco de contexto histórico, no foco actual
Docker Swarm fue una solución de orquestación integrada que cumplió un rol importante como tecnología de transición. Permitió dar los primeros pasos en clústeres de contenedores con relativa simplicidad.
Sin embargo, el ecosistema evolucionó:
- Kubernetes se convirtió en estándar abierto.
- Los proveedores cloud apostaron por Kubernetes.
- Las herramientas, extensiones y comunidad crecieron alrededor de Kubernetes.
Hoy, Swarm tiene valor principalmente histórico o en entornos muy específicos. Para producción moderna, Kubernetes es la referencia.
Kubernetes: cuando el despliegue se vuelve declarativo
Kubernetes no es simplemente “correr contenedores”. Es un cambio de modelo mental.
En lugar de decir qué pasos ejecutar, se declara qué estado se desea. Kubernetes se encarga del resto.
Un Deployment básico lo deja claro:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: gcr.io/my-project/myapp:v1
ports:
- containerPort: 8000
Aquí no se habla de scripts, reinicios ni balanceadores manuales.
Se declara que la aplicación debe existir, siempre, en tres instancias.
Si una falla, Kubernetes la reemplaza.
Si se actualiza la imagen, el despliegue es progresivo.
Si algo sale mal, se puede hacer rollback.
Eso impacta directamente en:
- Downtime
- Confiabilidad
- Velocidad de cambio
El verdadero salto: Kubernetes gestionado en la nube
Administrar Kubernetes “a mano” es posible, pero costoso. La gran adopción llegó cuando las plataformas cloud ofrecieron Kubernetes como servicio administrado.
En Google Cloud Platform (GKE), por ejemplo, crear un clúster es tan directo como:
gcloud container clusters create my-cluster \
--zone us-central1-a \
--num-nodes 3
Luego se obtienen las credenciales:
gcloud container clusters get-credentials my-cluster \
--zone us-central1-a
Y el despliegue se vuelve trivial:
kubectl apply -f deployment.yaml
A partir de ahí, GCP se encarga del control plane, actualizaciones, integración con red, balanceadores y escalado de nodos. El equipo puede concentrarse en la aplicación, no en la infraestructura.
Entonces… ¿mejora el desempeño?
La respuesta madura es:
- El rendimiento del código suele ser similar.
- El rendimiento del sistema completo mejora significativamente.
Contenedores y Kubernetes permiten:
- Escalar cuando se necesita, no antes.
- Recuperarse automáticamente de fallos.
- Reducir tiempos muertos en despliegues.
- Optimizar costos según carga real.
Eso no es un micro-benchmark.
Es una ventaja estructural.
Cuándo NO usar contenedores o Kubernetes
También es importante decirlo claramente:
- Aplicaciones muy simples, estáticas o de bajo cambio pueden no justificar la complejidad.
- Equipos sin madurez operativa pueden sufrir más que beneficiarse.
- Kubernetes no es un requisito, es una herramienta.
La clave está en el contexto, no en la moda.
La contenedorización no reemplazó a las instalaciones unitarias porque sea más rápida, sino porque es más gobernable en un mundo cambiante.
- Docker resolvió el problema del empaquetado.
- Kubernetes resolvió el problema de la operación a escala.
- La nube resolvió el problema del mantenimiento pesado.
El resultado no es solo mejor desempeño técnico, sino mejor desempeño organizacional: sistemas que cambian sin romperse, escalan sin pánico y se recuperan sin intervención manual.
Ese, al final, es el verdadero avance.
De la teoría a la práctica: Kubernetes en un entorno interactivo
Hablar de contenedores y Kubernetes tiene sentido solo si el lector puede experimentarlo directamente. Una de las barreras históricas para aprender Kubernetes ha sido la infraestructura necesaria para comenzar: clústeres, nodos, redes, certificados.
Hoy esa barrera prácticamente ha desaparecido.
En Academia Desarrollo Web hemos creado entornos interactivos en Killercoda que permiten trabajar con Kubernetes real desde el navegador, sin instalaciones previas. Uno de estos escenarios es un clúster de Kubernetes de un solo nodo, ideal para comprender los conceptos básicos de despliegue y operación.
Al iniciar el entorno, el usuario ya tiene acceso a un clúster funcional:
controlplane:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
controlplane Ready control-plane 17d v1.34.3
Desde este punto, el ejercicio natural es listar los pods, comprender su estado y avanzar hacia un primer Deployment. No se trata de aprender comandos de memoria, sino de observar cómo Kubernetes describe el estado del sistema y cómo reacciona ante cambios declarativos.
Este tipo de práctica guiada transforma a Kubernetes de un concepto abstracto en una herramienta concreta, observable y manipulable.
Comprender Kubernetes no empieza creando clústeres complejos, sino observando cómo un sistema sencillo mantiene su estado. Un nodo basta para aprender una idea que escala a miles.
Save as PDFAbout the Author
