"We need to use Kubernetes" is one of the phrases we hear most often in initial consultations with Latin American companies. It is almost always followed by a conversation where we discover that the company has three services, five developers, and a CTO who read about K8s in a LinkedIn article. This guide is a pragmatic dose of reality about when Docker and Kubernetes actually add value, and when they are costly over-engineering.
Why Docker is almost always a good idea
Docker solves a real problem: "it works on my machine but not in production." By containerizing your application, you package the code together with all its dependencies into a reproducible image.
The concrete advantages:
Consistent environments: The same container runs on the developer's laptop, in CI/CD, and in production. Version discrepancies for Node, Python, or PHP are gone.
Simpler deployments: Instead of configuring each server manually, you simply run the container. Rollbacks are trivial: you go back to the previous image.
Isolation: Multiple applications with different versions of the same runtime coexist without conflicts on the same server.
Dockerfile for a Node.js application
FROM node:22-alpine AS base
WORKDIR /app
# Install dependencies first (better layer caching)
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
# Lightweight final image
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"]
This multi-stage Dockerfile produces a lightweight production image that only includes what is necessary.
When Docker alone is enough
For most growing companies, Docker + docker-compose for local development and a simple orchestrator for production is all they need.
If your scenario is:
- Fewer than 10 services
- Predictable traffic without extreme spikes
- Small team (fewer than 10 developers)
- No complex zero-downtime deployment requirements
Then platforms like Railway, Render, Fly.io, or even a VPS with Docker Compose are the right choice. They are orders of magnitude simpler to operate.
When you actually need Kubernetes
K8s adds real value when:
You need to scale horizontally and automatically: If you have services that need to grow from 2 to 50 replicas in minutes (for example, an e-commerce during a discount campaign), K8s's HPA (Horizontal Pod Autoscaler) is very powerful.
You have many microservices: Starting at 15–20 services, manually managing where each one runs becomes complex. K8s provides a coherent platform.
You need availability guarantees: Self-healing, rolling deployments, automatic health checks. K8s handles this natively.
Your team already has K8s experience: Without this, the learning cost can dominate the operational cost for months.
The real costs of K8s
This point frequently surprises those considering K8s:
Minimum viable cluster on AWS (EKS)
- 3 t3.medium nodes: ~$100 USD/month
- Load Balancer: ~$20 USD/month
- Storage (EBS): variable
- AWS support or dedicated engineer: $0 if you have the expertise, potentially $3,000–10,000/month if you do not
Minimum total: $120+ USD/month in infrastructure alone, not counting operational time.
Comparative costs by platform
| Platform | Approximate monthly cost | Operational complexity | |----------|--------------------------|------------------------| | Railway (2 services) | $20–50 | Very low | | Render (3 services) | $25–75 | Low | | Fly.io (auto-scaling) | $30–100 | Medium | | VPS + Docker | $20–50 | Medium | | Managed K8s (EKS/GKE) | $150+ | High | | Self-managed K8s | $50+ | Very high |
For a startup or mid-sized company with less than $200k ARR, the operational overhead of K8s rarely justifies its benefits.
Managed K8s: EKS, GKE, and AKS
If you decide to use Kubernetes, always use a managed version. Operating K8s without cloud provider support is work for a dedicated team.
GKE (Google Kubernetes Engine): Generally considered the most mature with the best tooling integration. Autopilot mode significantly reduces operational complexity.
EKS (Amazon EKS): Best if you are already on AWS and use many native AWS services.
AKS (Azure): Best if you are in the Microsoft ecosystem.
For LATAM with latency constraints, the us-east-1 (AWS), us-central1 (GCP), or eastus (Azure) regions are the closest and most common.
The decision framework
Before deciding, answer these questions:
- How many services do you have right now? If fewer than 8, you probably do not need K8s.
- Does anyone on your team have K8s experience? Without this, the learning cost is enormous.
- Does your traffic have variations of 10x or more? If not, K8s auto-scaling gives you no real value.
- What is the cost of one hour of downtime? If it is low, simpler platforms are sufficient.
If you answer "yes" to 2 or more of the last three questions, K8s deserves serious consideration.
Conclusion: choose the right tool for your moment
Docker is almost always the right answer for containerizing your applications. Kubernetes is the right answer for orchestrating those containers only when scale and complexity justify it.
At Alternetica we have helped companies simplify over-engineered infrastructures as well as scale those that have reached their limits. The criterion is not "what is more modern" but "what solves the problem with the least operational overhead."
If you are evaluating your current infrastructure or planning the architecture of a new system, contact us for an architecture consultation.