DEV Community: Norman Torres

El cuello de botella que es la base de datos (1k-10k)

Norman Torres — Thu, 19 Mar 2026 05:01:15 +0000

Esto es fantasía (Parte 3).

Lanzamos el 1 de enero de 2026. En febrero separamos la infraestructura: base de datos en RDS, dos instancias detrás de un load balancer, y el sistema voló. Se sentía como el día del lanzamiento. Para marzo, llegamos a los 10,000 usuarios únicos al mes.

Y entonces la base de datos empezó a arder.

El síntoma

PostgreSQL alcanzaba el 100% de CPU durante horas. La memoria se disparaba sin control. Los queries que antes respondían en milisegundos empezaban a acumular segundos. En horas pico, era una bola de nieve: muchos usuarios generando consultas pesadas al mismo tiempo, cada una más lenta que la anterior, hasta que el sistema colapsaba.

La solución de emergencia: reiniciar la base de datos. Hasta 20 minutos de inactividad total mientras RDS se recuperaba.

La solución de fuerza bruta: escalar la instancia. Funcionó unos días, como siempre. Pero volvíamos al punto de partida porque el problema no era el tamaño del servidor, sino cómo lo estábamos usando.

¿Por qué crecía tan rápido?

Nuestra app tiene una particularidad: un usuario nuevo no empieza en cero. Al registrarse, conecta sus cuentas bancarias y el sistema importa tarjetas, movimientos y balances desde el primer segundo. Un solo registro puede significar miles de inserciones.

Más usuarios → más datos desde el día uno → más presión sobre la base de datos.

Paso 1: Índices

Cuando analizamos los queries lentos, descubrimos algo vergonzoso: solo el id estaba indexado. Pero las búsquedas reales las hacíamos por fecha, email, username y account_id. Sin índices en esos campos, cada consulta hacía un sequential scan — recorría la tabla entera.

Con una base de datos en crecimiento constante, eso es insostenible.

-- Antes: sequential scan en cada consulta
EXPLAIN ANALYZE SELECT * FROM transactions WHERE account_id = 'abc-123' AND date >= '2026-01-01';
-- Seq Scan on transactions  (cost=0.00..45892.00 rows=234 width=128)
-- Execution Time: 1,842.531 ms

-- Después: creamos los índices que faltaban
CREATE INDEX idx_transactions_account_date ON transactions (account_id, date);
CREATE INDEX idx_users_email ON users (email);
CREATE INDEX idx_users_username ON users (username);
CREATE INDEX idx_accounts_user_id ON accounts (user_id);

-- Resultado: index scan
EXPLAIN ANALYZE SELECT * FROM transactions WHERE account_id = 'abc-123' AND date >= '2026-01-01';
-- Index Scan using idx_transactions_account_date  (cost=0.42..18.67 rows=234 width=128)
-- Execution Time: 2.341 ms

De 1,842ms a 2ms. La mejora fue inmediata y brutal.

Lección: Los índices no son una optimización prematura. Son lo mínimo que necesitás para que una base de datos funcione en producción.

Paso 2: Separar lecturas de escrituras

Con los índices resueltos, apareció otro problema. Cuando un usuario se registraba e importaba sus datos financieros, la base de datos se frenaba para todos.

Analizamos el patrón de tráfico y encontramos una proporción de 1:1,000 — por cada escritura, había casi mil lecturas. El problema es que las inserciones no solo escriben datos: también actualizan los índices y ocasionalmente disparan un rebalanceo del B-tree. Mientras eso pasa, las lecturas esperan.

La solución: un cluster de RDS con réplicas de lectura.

                          ┌──────────────────────┐
                          │   RDS Writer          │
                          │   (db.r6g.xlarge)     │
                          │                       │
                          │   INSERT / UPDATE      │
                          └──────────▲─────────────┘
                                     │
                              Replicación
                              asíncrona
                                     │
              ┌──────────────────────┼──────────────────────┐
              │                      │                      │
     ┌────────▼─────────┐  ┌────────▼─────────┐  ┌────────▼─────────┐
     │  Reader 1        │  │  Reader 2        │  │  Reader 3        │
     │  (db.r6g.medium) │  │  (db.r6g.medium) │  │  (db.r6g.medium) │
     │  SELECT (reportes)│  │  SELECT (app)    │  │  SELECT (app)    │
     └──────────────────┘  └──────────────────┘  └──────────────────┘

En la API, la implementación es directa. Dos conexiones, una para cada rol:

// datasource.ts
const writerPool = new Pool({
  host: process.env.RDS_WRITER_ENDPOINT,
  // finanzas-db.cluster-cxyz.us-west-2.rds.amazonaws.com
});

const readerPool = new Pool({
  host: process.env.RDS_READER_ENDPOINT,
  // finanzas-db.cluster-ro-cxyz.us-west-2.rds.amazonaws.com
});

export const db = {
  write: writerPool,  // INSERT, UPDATE, DELETE
  read: readerPool,   // SELECT
};

// Uso en la API
// Lectura → va a las réplicas
const transactions = await db.read.query(
  'SELECT * FROM transactions WHERE account_id = $1 AND date >= $2',
  [accountId, startDate]
);

// Escritura → va al writer
await db.write.query(
  'INSERT INTO transactions (account_id, amount, date) VALUES ($1, $2, $3)',
  [accountId, amount, date]
);

RDS distribuye automáticamente las lecturas entre las réplicas. El resultado: las inserciones masivas de un registro nuevo ya no bloquean las consultas de los 9,999 usuarios restantes.

Paso 3: Connection Pooling

Con más servicios conectándose a la base de datos, empezamos a ver bloqueos que no tenían sentido. El CPU estaba en 20%, la memoria tranquila, pero la base de datos no respondía.

El problema: las conexiones. PostgreSQL crea un proceso por cada conexión. Nuestros servicios abrían conexiones, las mantenían activas mientras procesaban la respuesta HTTP, y las nuevas solicitudes se quedaban esperando porque PostgreSQL había alcanzado su límite de conexiones (max_connections).

Implementamos PgBouncer como connection pooler entre la API y RDS:

┌───────────┐      ┌────────────┐      ┌──────────┐
│   API     │─────▶│  PgBouncer │─────▶│   RDS    │
│ (100 conn)│      │  (20 conn) │      │          │
└───────────┘      └────────────┘      └──────────┘

La API puede abrir 100 conexiones contra PgBouncer, pero PgBouncer solo mantiene 20 conexiones reales contra PostgreSQL. Cuando un proceso termina de usar una conexión, PgBouncer la recicla para el siguiente en la cola.

Menos conexiones activas → menos procesos en PostgreSQL → menos memoria y CPU desperdiciados en overhead de conexión.

El costo del crecimiento

Concepto	Costo mensual (estimado)
2x EC2 t3.small (API)	~$30.00 USD
RDS Writer (db.r6g.xlarge)	~$180.00 USD
3x RDS Reader (db.r6g.medium)	~$135.00 USD
Application Load Balancer	~$20.00 USD
Data Transfer & Storage	~$15.00 USD
Total	~$380 - $400 USD

De $25 a $85 a $400. El salto es grande, pero la alternativa era seguir reiniciando la base de datos en horas pico y perdiendo usuarios.

Lo que aprendimos

Los índices no son opcionales. Si hacés queries por un campo, ese campo necesita un índice. Es así de simple.
Leer y escribir son problemas diferentes. Separarlos te da control sobre cada uno.
Las conexiones son un recurso finito. Connection pooling no es una optimización: es una necesidad a partir de cierta escala.
Escalar verticalmente es un parche. Comprar más CPU aplaza el problema. Entender el problema lo resuelve.

¿Qué sigue?

Con 10,000 usuarios, la base de datos respira. Pero hay algo que no tiene sentido: el dashboard de un usuario muestra los mismos datos todo el día — el balance, las últimas transacciones, los presupuestos — y cada vez que abre la app, le pegamos a la base de datos como si fuera la primera vez. Multiplicá eso por miles de usuarios en hora pico y estamos consultando lo mismo una y otra vez. La base de datos ya no es lenta, pero le estamos pidiendo trabajo que no necesita hacer.

Separando Responsabilidades (100-1,000 usuarios)

Norman Torres — Fri, 20 Feb 2026 05:37:38 +0000

Esto es fantasía (Parte 2).

Lanzamos el 1 de Enero de 2026. Para inicios de Febrero, el crecimiento fue exponencial: llegamos a los 1,000 usuarios únicos al mes.

Cuando teníamos 100 usuarios, nuestra humilde infraestructura (una sola instancia EC2 corriendo todo) soportaba la carga sin despeinarse. Pero al cruzar la barrera de los 1,000, la realidad nos golpeó. La base de datos y la API empezaron a competir salvajemente por la CPU y la RAM de la instancia.

El síntoma: Si un usuario generaba un reporte pesado, la base de datos consumía el 100% del CPU. Resultado: La API dejaba de responder a todos los demás usuarios. Tiempos de respuesta de 200ms pasaron a 15 segundos o timeouts.

Nuestra primera reacción fue "fuerza bruta": escalar verticalmente a una instancia más grande (t3.medium). Funcionó... por tres días. El problema de fondo persistía: acoplamiento de recursos.

Decidimos que era hora de madurar la arquitectura.

Paso 1: Desacoplando la Base de Datos (RDS)

Mover la base de datos fuera de nuestro servidor fue la prioridad. Migramos de un contenedor Docker local a AWS RDS (Amazon Relational Database Service) usando Postgres.

¿Por qué?

Recursos Dedicados: La API ya no pelea por CPU con la DB.
Estabilidad: Si la API crashea por un bug, la DB sigue viva.
Mantenimiento: Backups automáticos y actualizaciones gestionadas por AWS.

El Cambio

En nuestro docker-compose.yml, eliminamos el servicio db y actualizamos la configuración de la API.

# docker-compose.yml (Actualizado)
services:
  api:
    image: turegistro/api:latest
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      # Ahora apuntamos al endpoint de RDS
      - DATABASE_URL=postgresql://admin:password_super_seguro@finanzas-db.cluster-cxyz.us-west-2.rds.amazonaws.com:5432/finanzas
      - PORT=3000
    networks:
      - internal
    # Ya no dependemos de un servicio local 'db'

Paso 2: Alta Disponibilidad (Load Balancer)

Con la DB separada, notamos otro problema: cada vez que hacíamos un deploy o reiniciábamos el servidor, el servicio se caía por completo durante unos segundos (o minutos). Además, si esa única instancia EC2 fallaba, estábamos fuera del aire.

No queríamos soluciones parches como api2.midominio.com. Queríamos transparencia.

Implementamos un Application Load Balancer (ALB).
El ALB funciona como un policía de tráfico: recibe todas las peticiones y las distribuye entre nuestros servidores disponibles.

La Nueva Arquitectura

Ahora tenemos 2 instancias EC2 idénticas (para redundancia) y una base de datos externa.

                                  ┌───────────────────┐
                                  │    AWS RDS        │
                                  │  (PostgreSQL)     │
                                  └─────────▲─────────┘
                                            │
                                     ┌──────┴──────┐
                                     │             │
                    ┌───────────────▶│ Instancia A │
┌──────────┐        │                │ (API Docker)│
│ Usuario  │──HTTPS─┼─▶  ALB  ──────▶└─────────────┘
└──────────┘        │  (Balanceador)
                    │                ┌─────────────┐
                    └───────────────▶│ Instancia B │
                                     │ (API Docker)│
                                     └─────────────┘

Si la Instancia A muere, el ALB automáticamente manda todo el tráfico a la Instancia B. El usuario ni se entera.

Networking y Seguridad (VPC)

Aquí es donde las cosas se pusieron serias. Tuvimos que configurar correctamente nuestros Security Groups para no dejar nada expuesto.

Security Group del ALB:
- Inbound: Permite tráfico 80/443 desde todo el mundo (0.0.0.0/0).
- Outbound: Solo hacia el Security Group de las EC2.
Security Group de las EC2 (App):
- Inbound: SOLO permite tráfico en el puerto 3000 proveniente del Security Group del ALB. Nadie puede conectarse directo a la IP de la instancia (excepto nosotros por SSH).
Security Group de RDS:
- Inbound: SOLO permite tráfico en el puerto 5432 proveniente del Security Group de las EC2.

Resultado: La base de datos es invisible desde internet. Las instancias son invisibles desde internet (solo el ALB les habla).

El Costo del Crecimiento

La "fantasía" de los $25 USD se termina aquí. La redundancia y los servicios gestionados cuestan.

Concepto	Costo Mensual (Estimado)
2x EC2 t3.small	~$30.00 USD
AWS RDS (db.t3.micro)	~$18.00 USD
Application Load Balancer	~$16.00 USD + tráfico
Data Transfer & Storage	~$10.00 USD
Total	~$75 - $85 USD

Pasamos de gastar lo de una cena barata a pagar una suscripción de software empresarial. Pero a cambio, ganamos:

Resiliencia: Podemos perder un servidor y seguir operando.
Escalabilidad: ¿Más usuarios? Agregamos una tercera instancia EC2 al balanceador y listo.
Paz mental: Ya no reiniciamos servidores los domingos a la noche.

Conclusión

Separar responsabilidades es el primer paso real hacia una arquitectura distribuida. Aumentamos la complejidad y el costo, sí, pero compramos estabilidad.

¿Qué sigue? Con 1,000 usuarios, las consultas de reportes siguen siendo lentas aunque la DB esté separada.

El MVP que funciona (1-100 usuarios)

Norman Torres — Thu, 15 Jan 2026 17:40:48 +0000

Esto es fantasía.

El 1° de enero lanzamos una plataforma de gestión financiera personal. Conecta cuentas bancarias, categoriza gastos, establece presupuestos y genera insights. Ese mismo día tuvimos nuestro primer usuario. La meta es llegar a 100 este mes.

Este post es sobre la infraestructura detrás de ese MVP. No sobre código, arquitectura de software, ni patrones de diseño. Sobre servidores, contenedores, costos, y las decisiones pragmáticas que te permiten lanzar algo real con ~$25 USD al mes.

El Stack

Frontend Web:    React
Mobile:          React Native
Backend:         NestJS
Base de datos:   PostgreSQL
Contenedores:    Docker + Docker Compose
Servidor:        AWS EC2 + Nginx

Nada exótico. Tecnologías probadas que cualquier developer puede mantener.

La arquitectura

                            ┌───────────────────────────────────────────────┐
                            │               EC2 t3.small                    │
                            │                                               │
┌──────────┐                │  ┌─────────────────────────────────────────┐  │
│ Usuario  │───HTTPS:443───▶│  │            Docker Network               │  │
│ (Web)    │                │  │                                         │  │
└──────────┘                │  │  ┌───────┐   ┌───────┐   ┌──────────┐   │  │
                            │  │  │ Nginx │──▶│  API  │──▶│ Postgres │   │  │
┌──────────┐                │  │  │  :80  │   │ :3000 │   │  :5432   │   │  │
│ Usuario  │───HTTPS:443───▶│  │  │ :443  │   └───────┘   └──────────┘   │  │
│ (Mobile) │                │  │  └───────┘                              │  │
└──────────┘                │  │                                         │  │
                            │  └─────────────────────────────────────────┘  │
                            └───────────────────────────────────────────────┘

Todo en una instancia EC2, pero cada servicio aislado en su contenedor. Un docker compose up -d y todo corre.

¿Por qué Docker para un MVP?

La respuesta corta: porque facilita la vida.

Beneficios clave

Consistencia entre ambientes: Lo que corre en mi laptop corre igual en producción. Adiós "en mi máquina funciona".
Despliegues rápidos y predecibles: Actualizar la API es un docker compose pull y docker compose up -d. Sin sorpresas.
Aislamiento de servicios: La base de datos no contamina el sistema host. Si algo falla, solo afecta su contenedor.
Escalabilidad futura: Cuando el MVP crezca, migrar a múltiples servidores o servicios gestionados será más sencillo.
Facilidad para nuevos desarrolladores: Un nuevo dev solo necesita Docker y el repo. Nada de instalar PostgreSQL localmente o configurar variables de entorno complicadas.

Docker Compose

# docker-compose.yml
services:
  api:
    image: turegistro/api:latest
    # build: ./api  # Para desarrollo local
    container_name: finanzas-api
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://usuario:password@db:5432/finanzas
      - PORT=3000
    depends_on:
      db:
        condition: service_healthy
    networks:
      - internal

  db:
    image: postgres:16-alpine
    container_name: finanzas-db
    restart: unless-stopped
    environment:
      - POSTGRES_USER=usuario
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=finanzas
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./backup:/backup
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U usuario -d finanzas"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - internal

  nginx:
    image: nginx:alpine
    container_name: finanzas-nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/ssl:/etc/nginx/ssl:ro
      - ./frontend/dist:/var/www/app:ro
    depends_on:
      - api
    networks:
      - internal

volumes:
  postgres_data:

networks:
  internal:
    driver: bridge

Detalles importantes

restart: unless-stopped Si el contenedor crashea, Docker lo reinicia automáticamente. Si yo lo detengo manualmente, no lo reinicia.
depends_on con condition: service_healthy La API no inicia hasta que PostgreSQL esté listo para aceptar conexiones. Evita errores de conexión en el startup.
Volumen para PostgreSQL postgres_data persiste los datos fuera del contenedor. Si recreo el contenedor de Postgres, los datos sobreviven.
Red interna Los contenedores se comunican por nombre (db, api) dentro de la red internal. PostgreSQL nunca está expuesto a internet.

El servidor

Selección de instancia

Instancia:      t3.small
vCPUs:          2
RAM:            2 GB
Almacenamiento: 30 GB gp3
Región:         us-west-2 (Oregón)
SO:             Ubuntu 24.04 LTS

¿Por qué t3.small y no t3.micro?

La micro tiene 1GB de RAM. Docker ya consume ~100MB, PostgreSQL quiere ~256MB para buffers, la API otros ~200MB, Nginx es ligero pero suma. Con 1GB estás en el límite desde el arranque.

Con 2GB hay espacio para crecer, caches, y evitar OOM kills.

¿Por qué instancia "burstable" (t3)?
Las t3 acumulan créditos de CPU cuando están idle y los gastan en picos. Un MVP tiene ráfagas de tráfico, no carga constante.

Nuestro uso promedio es ~8% de CPU. Los créditos se acumulan más rápido de lo que los gastamos.

Costos reales

Concepto	Costo mensual
EC2 t3.small (on-demand)	~$15.00 USD
EBS 30GB gp3	~$2.40 USD
Data transfer (estimado)	~$2-5 USD
Dominio (anualizado)	~$1.00 USD
Docker Hub (free tier)	$0
Total	~$20-25 USD

Optimizaciones que NO hicimos

Reserved Instances: Compromiso de 1-3 años. El MVP puede pivotar.
ECR en lugar de Docker Hub: Más control, pero Docker Hub free tier es suficiente para imágenes privadas limitadas.
Spot Instances: AWS puede terminarlas. No para producción.

Networking y seguridad

Security Groups

Inbound:
  - 22 (SSH)      → Solo mi IP
  - 80 (HTTP)     → 0.0.0.0/0 (redirige a 443)
  - 443 (HTTPS)   → 0.0.0.0/0

Outbound:
  - All traffic   → 0.0.0.0/0

PostgreSQL (5432) NO está expuesto. Solo existe dentro de la red de Docker. Para acceder remotamente:

# Túnel SSH + docker exec
ssh -i ~/.ssh/mi_llave.pem usuario@servidor
docker exec -it finanzas-db psql -U usuario -d finanzas

Variables de entorno

Los secrets no van en el docker-compose.yml del repo. En el servidor:

# /opt/app/.env
DATABASE_URL=postgresql://usuario:password_real@db:5432/finanzas
JWT_SECRET=secret_real

Y en el compose:

api:
  env_file:
    - .env

El archivo .env está en .gitignore. Cada ambiente tiene el suyo.
Por ambiente me refiero a desarrollo local y producción.

Nginx con Docker

Configuración

# nginx/conf.d/default.conf
upstream api {
    server api:3000;
}

server {
    listen 80;
    server_name dominio.com api.dominio.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name dominio.com;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    root /var/www/app;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

server {
    listen 443 ssl http2;
    server_name api.dominio.com;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    location / {
        proxy_pass http://api;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nota: server api:3000 funciona porque Docker resuelve api al contenedor de la API dentro de la red interna.

SSL con Let's Encrypt

Certbot corre en el host (no en contenedor) para simplicidad:

sudo apt install certbot
sudo certbot certonly --standalone -d tudominio.com -d api.tudominio.com

# Copiar certificados donde Nginx los espera
sudo cp /etc/letsencrypt/live/tudominio.com/fullchain.pem /opt/app/nginx/ssl/
sudo cp /etc/letsencrypt/live/tudominio.com/privkey.pem /opt/app/nginx/ssl/

# Reiniciar Nginx para que tome los nuevos certs
docker compose restart nginx

Renovación automática via cron:

# /etc/cron.d/certbot-renew
0 3 * * * root certbot renew --quiet --post-hook "cp /etc/letsencrypt/live/tudominio.com/*.pem /opt/app/nginx/ssl/ && docker compose -f /opt/app/docker-compose.yml restart nginx"

Deploy

Proceso actual

# 1. Build y push de la imagen (local)
docker build -t turegistro/api:latest ./api
docker push turegistro/api:latest

# 2. Build del frontend
cd frontend && npm run build

# 3. En el servidor
ssh usuario@servidor
cd /opt/app

# 4. Pull de la nueva imagen y restart
docker compose pull api
docker compose up -d api

# 5. Actualizar frontend (rsync desde local)
rsync -avz --delete frontend/dist/ usuario@servidor:/opt/app/frontend/dist/

Rollback

Si algo sale mal:

# Ver imágenes disponibles
docker images turegistro/api

# Volver a versión anterior
docker compose down
docker tag turegistro/api:previous turegistro/api:latest
docker compose up -d

Zero-downtime deploy (futuro)

Por ahora hay ~5 segundos de downtime en cada deploy.

Backups

Base de datos

Script de backup que corre dentro del contenedor:

#!/bin/bash
# /opt/app/scripts/backup.sh
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
docker exec finanzas-db pg_dump -U usuario -Fc finanzas > /opt/app/backup/db_${TIMESTAMP}.dump

# Mantener solo últimos 7 días
find /opt/app/backup -name "db_*.dump" -mtime +7 -delete

Cron en el host:

# /etc/cron.d/db-backup
0 3 * * * root /opt/app/scripts/backup.sh

Subir a S3

# Agregar al script de backup
aws s3 cp /opt/app/backup/db_${TIMESTAMP}.dump s3://tu-bucket/backups/

Docker volumes

El volumen postgres_data vive en /var/lib/docker/volumes/. Si el servidor muere, los datos mueren con él. Por eso el backup a S3 es importante.

Monitoreo

Uptime

UptimeRobot (gratis):

Ping a https://api.dominio.com/health cada 5 min
Alerta por email/Telegram si no responde

Logs

Docker centraliza los logs:

# Logs de todos los servicios
docker compose logs -f

# Solo la API, últimas 100 líneas
docker compose logs -f --tail 100 api

# Logs de un período específico
docker compose logs --since 2024-01-15T10:00:00 api

Lo que NO tenemos

Servicio	Por qué no
Kubernetes	Un servidor, tres contenedores. `docker compose` es suficiente.
CDN (CloudFront)	Frontend de ~500KB, usuarios en México. Latencia imperceptible.
Load Balancer	Un servidor. Nada que balancear.
Redis	Sin cache. Queries directas a Postgres. Dataset pequeño.
RDS	Cuesta lo mismo que toda la infra actual.
ECS/Fargate	Overhead de configuración sin beneficio para esta escala.
Terraform	Un servidor, un compose file. Lo documento en el README.
CI/CD	1-2 deploys por semana. El proceso manual toma 3 minutos.

¿Qué va a romper primero?

1. Disco lleno

Logs de Docker crecen. Imágenes viejas se acumulan. Backups suman.

Señales: Alertas de disco >80%, contenedores que no inician.

2. RAM insuficiente

Más usuarios = más conexiones = más memoria por contenedor.

Señales: Contenedores reiniciando (OOM killed), docker stats mostrando >90% de memoria.

3. La DB necesita su propio servidor

Cuando PostgreSQL y la API compiten por I/O.

Señales: Query times subiendo, docker stats mostrando I/O wait.

Solución: Mover el contenedor de Postgres a un segundo EC2, o migrar a RDS.

Comandos útiles del día a día

# Ver estado de los contenedores
docker compose ps

# Reiniciar todo
docker compose restart

# Reiniciar solo la API
docker compose restart api

# Ver logs en tiempo real
docker compose logs -f

# Entrar al contenedor de la DB
docker exec -it finanzas-db psql -U usuario -d finanzas

# Entrar al contenedor de la API
docker exec -it finanzas-api sh

# Rebuild sin cache (cuando algo está raro)
docker compose build --no-cache api
docker compose up -d api

Conclusión

Docker añade una capa, pero es una capa que paga su costo. Deploys reproducibles, ambientes idénticos, y la tranquilidad de que docker compose up -d va a funcionar igual hoy que en 6 meses.

El setup completo: ~$25 USD/mes. Tres contenedores. Un servidor. Cero magia.

La complejidad se agrega cuando duele. Y con Docker Compose en un solo EC2, hay mucho espacio antes de que duela.

Tenemos avances...

Norman Torres — Fri, 10 May 2024 18:32:58 +0000

Ya llevo más de un mes en mi nuevo puesto, y hemos enfrentado numerosos desafíos; estos últimos 15 días han sido especialmente caóticos. No hemos podido avanzar tanto como me gustaría debido a que estamos atascados en una migración de uno de los sistemas vitales de la empresa, que, desde mi perspectiva, ha sido mal implementada. Antes de mi llegada, ya se había intentado realizar esta migración, pero al implementarla en producción, todo falló y tuvimos que revertirla. Esto es preocupante, ya que afecta directamente la generación de solicitudes para nuevos créditos. Además, la plataforma está innecesariamente complicada, con versiones obsoletas de tecnologías y adiciones mal implementadas, como el uso de GraphQL solo por el interés de aprenderlo.

Además, perdí todo un día intentando recuperar una tabla de SQL que uno de los desarrolladores borró por accidente. Afortunadamente, pudimos restaurarla gracias a que teníamos copias de seguridad. Aunque la recuperación y la integración de los datos solo tomaron una hora, el proceso completo nos llevó cerca de cinco horas. Días como ese trastocan todos mis planes, ya que tengo que dedicar tiempo al soporte de la plataforma, a pesar de que no somos un equipo de soporte y no hay nadie más que pueda encargarse de esto.

Lo interesante de estas últimas dos semanas es que logré implementar un despliegue automático. Ahora, cada vez que se sube un cambio a la rama master en GitHub, Jenkins inicia un proceso de construcción y sube los archivos a un bucket de S3, que luego distribuye la información a los usuarios. Esto me ha facilitado mucho el proceso de llevar código a producción sin grandes demoras, permitiéndome hacer entregas más frecuentes. Aunque todavía no tenemos un ambiente de desarrollo ni control de pruebas automáticas, es un gran avance. Logré un hito similar con una plataforma hermana de la empresa, que ahora cambia a un despliegue automático cada vez que se actualiza la rama principal en GitHub.

Para manejar mejor la carga de trabajo, he aplicado una estrategía de planificación de metas. Cada lunes a las 9 am, me tomo unos 15 minutos para definir lo que quiero lograr esa semana. Me propongo tres proyectos fuera de la planificación del equipo, lo que me ayuda a priorizar mejor mis tareas. Continuaré aplicando esta estrategia para mantener un control sobre el progreso semanal. Otro logro reciente fue añadir documentación básica a los proyectos, en forma de archivos README.md, con instrucciones para realizar despliegues, ejecutar el código y las variables importantes para el funcionamiento de los proyectos.

Primeras 3 semanas

Norman Torres — Tue, 23 Apr 2024 00:26:53 +0000

Ya he cumplido mis primeras tres semanas de trabajo, lo cual ha sido bastante pesado, principalmente por el horario. Tener que despertar a las 6:30 a.m. y contar con un hijo que no permite mantener una hora constante para ir a dormir ha creado días en los que apenas logré dormir cuatro horas, pero estos son temas personales.

En el lado del trabajo, se inició un proceso de implementación de buenas prácticas que no se ha podido completar al 100%, ya que existen muy malas prácticas arraigadas que complican y alargan el proceso de deploy. Un día, literalmente nos tomó cuatro horas subir unos simples cambios, y tuvimos un hotfix que terminó afectando tirando producción. Además, enfrentamos un problema con un servidor que alcanzó el 100% de uso de CPU, volviéndose inaccesible y provocando que toda la operación fallara. Esto nos obligó a crear otro servidor y, debido a la falta de buena documentación, el cambio no se pudo realizar correctamente, causando fallos en el sistema para casos particulares.

El principal problema que enfrentamos ahora es la dificultad para subir cambios a producción de manera sencilla, lidiar con variables de entorno o ramas que contienen muchos más cambios de los esperados, y la incapacidad de utilizar completamente los recursos de pruebas debido a un cuello de botella en el ambiente de desarrollo. Además, la presencia de mucho código legacy sin soporte complica aún más la situación. Para terminar de empeorar todo esto, no puedo dedicar todo mi tiempo a resolver estos problemas porque tengo que realizar múltiples actividades, como revisiones de código, escribir el código de las historias de usuario que me corresponden, y apoyar al equipo en sus problemas y a los otros dos equipos que se tienen.

Quisiera llegar a un punto donde los cambios sean tan simple de subir a producción y que no se rompa nada pero aun creo que falta mucho, por lo que voy a iniciar con una serie de actividades que ya estamos haciendo pero que no hemos podido llevar todo a buen puerto:

Sesiones de sincronización diaria de 15 minutos.
Adopción de buenas practicas.
Cultura de revisión de código.
Esfuerzo de documentación: Readme y diagramas.
Entregas continuas y pequeñas para minimizar los riesgos.

Espero que en los siguientes días se vean cambios en la entrega de funcionalidades porque seguimos teniendo problemas con eso.

Nuevo trabajo, nuevos retos

Norman Torres — Thu, 04 Apr 2024 19:53:55 +0000

El 1° de abril de 2024 comencé a trabajar en una nueva empresa. Esta empresa tiene un mercado en expansión, pero su producto tecnológico no está orientado al usuario final, sino a los usuarios internos, lo cual me resulta un tanto curioso, ya que es más sencillo predecir su comportamiento y en caso de fallo, no afecta a tantos usuarios.

Al ingresar a esta empresa, noté que enfrentan numerosos problemas, principalmente en cuanto a buenas prácticas de desarrollo, uso de metodologías ágiles e infraestructura.

Cuando se desea desarrollar algo, el dueño de la empresa indica al equipo qué hacer y se involucra mucho en diferentes partes del proceso, lo que hace que la persona encargada realmente pierda su autoridad. Los desarrolladores prefieren hablar directamente con el dueño, quien deja muchos detalles de lo que se quiere realizar al aire, lo que hace necesario usar la intuición para completar las tareas, con el riesgo de que al final no sean lo que se esperaba. Además, el dueño cambia las prioridades del equipo con mucha frecuencia, lo que lleva a que lo que se planeó trabajar en tres días o menos deje de ser prioritario. Todo debe pasar por su autorización, lo que ralentiza los procesos de implementación de cambios.

El equipo afirma que utilizan Scrum, pero solo llevan a cabo tres de las cinco ceremonias (daily, planning y review), dejando fuera el refinamiento y la retrospectiva. El encargado tampoco tiene una clara comprensión de estas ceremonias, lo que lleva a que las realicen de forma improvisada. Según lo que me han contado y lo que he visto, las dailys parecen más una reunión donde el encargado cambia las prioridades del día, y la review se convierte en una sesión de planificación para ver qué se trabajará en los siguientes 15 días.

El equipo carece de una guía en cuanto a buenas prácticas de desarrollo, lo que hace que cada uno haga lo que cree correcto. Esto resulta en códigos escritos de manera inconsistente en el mismo proyecto, numerosas ramas en el repositorio de git cuyo propósito ya no se recuerda, archivos transpilados en el repositorio y variables de entorno también incluidas, entre otras cuestiones.

En cuanto a la infraestructura, han optado por un enfoque más tradicional, utilizando servidores en AWS para ejecutar sus APIs y entregar el frontend. Sin embargo, cada servidor aloja varios proyectos, lo que significa que si uno falla, todos los proyectos se ven afectados. Sus despliegues consisten en conectarse al servidor, hacer un pull y reiniciar las aplicaciones, lo que puede ocasionar problemas si algún paquete de node en el archivo package.json no está actualizado. También tienen una instancia de base de datos muy grande para sus necesidades (2xlarge), incluso teniendo menos de 100 usuarios, lo que parece deberse a malas indexaciones en las bases de datos. Además, carecen de conocimientos sobre pruebas y de un proceso de CI/CD.

Este es el panorama con el que me encuentro en mi nuevo trabajo. Son muchos desafíos, pero el reto es interesante.

Las primeras acciones que estoy tomando se centran en establecer acuerdos con el Product Owner para adoptar Scrum de manera adecuada y mejorar la elaboración de las historias de usuario. Con el equipo, planeamos realizar una limpieza de los repositorios y aplicar una estandarización en la escritura de código utilizando "Standard.js". Además, estamos explorando extensiones en VSCode para mejorar la claridad en el desarrollo.

En cuanto a la infraestructura, estoy llevando a cabo investigaciones para identificar mejoras que puedan representar cambios significativos pero que sean simples de implementar. La primera acción fue activar el Performance Insights de RDS y realizar la indexación de dos columnas en una base de datos, lo que resultó en una reducción del 50% en el uso de la CPU del servidor.

Tengo previsto implementar un sistema de pull request en GitHub antes de que finalice esta semana, con la esperanza de tener la estrategia "ship-show-ask" en todos los repositorios antes de que termine el año.

Entendiendo DevOps: Más Allá de los Mitos

Norman Torres — Fri, 19 Jan 2024 17:46:24 +0000

DevOps se ha convertido en una palabra clave en el mundo de la tecnología, pero ¿qué significa realmente? Más importante aún, ¿qué no significa? En esta post, vamos a desmitificar DevOps y explorar algunas de las mejores prácticas que pueden ayudar a tu equipo a triunfar.

¿Qué es DevOps?

DevOps es una cultura, un movimiento, una filosofía. Nace de la fusión de 'Desarrollo' y 'Operaciones', enfocándose en la colaboración, automatización, integración continua, entrega continua y monitoreo constante de software a lo largo de todo su ciclo de vida.

Buenas Prácticas en DevOps:

Colaboración Continua: El corazón de DevOps es la colaboración entre equipos. Romper las barreras entre desarrolladores y operaciones es fundamental. La comunicación constante y efectiva mejora la comprensión y eficiencia del equipo.
Automatización Integral: Automatiza todo lo que puedas. Desde pruebas de código, integración, despliegue, hasta monitoreo y retroalimentación. Esto no solo ahorra tiempo, sino que también reduce errores humanos.
Integración y Entrega Continua (CI/CD): Implementa CI/CD para integrar y desplegar código frecuentemente. Esto permite detectar errores temprano y acelera la entrega de nuevas funciones y actualizaciones.
Monitoreo y Retroalimentación Continuos: Monitorea constantemente el rendimiento del software y recoge retroalimentación para mejorar. Esto ayuda a anticipar problemas antes de que afecten a los usuarios.

Lo que DevOps No Es:

No es solo una herramienta: Aunque las herramientas son importantes, DevOps es principalmente una cultura y un conjunto de prácticas. No se trata de comprar la última herramienta de moda.
No es solo para grandes equipos o empresas: DevOps beneficia a organizaciones de todos los tamaños. La clave es adaptar las prácticas a las necesidades y capacidad de tu equipo.
No es una solución mágica: Implementar DevOps no resuelve automáticamente todos los problemas. Requiere compromiso, adaptación y aprendizaje continuo.

DevOps es un viaje, no un destino. Se trata de mejorar continuamente las prácticas de desarrollo y operaciones para ofrecer mejor software, más rápido y de manera más eficiente. Al entender lo que DevOps es y lo que no es, podemos comenzar a implementar prácticas que realmente marquen la diferencia en nuestros proyectos.

Aplicando la Ciencia de Datos en DevOps: La Era del Data-Driven DevOps

Norman Torres — Sun, 02 Jul 2023 01:10:36 +0000

La unión de dos mundos innovadores, DevOps y la ciencia de datos, ha llevado a la creación de un nuevo paradigma en el desarrollo de software: el Data-Driven DevOps. Al aplicar principios de la ciencia de datos a las operaciones de DevOps, podemos obtener una visión más profunda de nuestros procesos de desarrollo y mejorar su rendimiento y eficiencia. En este artículo, exploraremos cómo funciona esto y cómo puedes implementarlo en tus propios proyectos.

La era del Data-Driven DevOps

El objetivo de DevOps es mejorar la colaboración entre los equipos de desarrollo y operaciones para lograr un flujo de trabajo más eficiente y eficaz. Con el advenimiento del Data-Driven DevOps, este objetivo se lleva un paso más allá, utilizando técnicas de ciencia de datos para informar y optimizar los procesos de DevOps.
En la era del Data-Driven DevOps, los datos recopilados a través de diversas etapas del ciclo de vida del desarrollo de software se utilizan para alimentar modelos predictivos y prescriptivos. Estos modelos pueden ayudar a identificar posibles cuellos de botella, predecir problemas antes de que ocurran, e incluso sugerir formas de mejorar la eficiencia del proceso de desarrollo.

Implementando la Ciencia de Datos en DevOps

Para implementar la ciencia de datos en DevOps, es importante empezar por la recopilación de datos. Esta recopilación puede venir de múltiples fuentes, incluyendo registros de sistema, métricas de rendimiento, y registros de errores. El siguiente paso es el análisis de estos datos, que puede implicar técnicas estadísticas, aprendizaje automático, e incluso inteligencia artificial.
Por ejemplo, puedes utilizar el análisis de series temporales para identificar patrones en los registros de sistema, lo que podría ayudarte a predecir cuándo es probable que ocurran ciertos problemas. O puedes utilizar algoritmos de aprendizaje automático para analizar los registros de errores y identificar las causas más comunes de fallos.

Conclusión

El Data-Driven DevOps representa un nuevo horizonte en el desarrollo de software. Al combinar los principios de la ciencia de datos con las prácticas de DevOps, podemos mejorar la eficiencia de nuestros procesos de desarrollo y proporcionar un mejor servicio a nuestros usuarios.
En el futuro, esperamos ver aún más innovaciones en este espacio. Así que si estás en el mundo del desarrollo de software y te interesa tanto DevOps como la ciencia de datos, definitivamente deberías considerar explorar el Data-Driven DevOps.

Monitoreo de sitios web con Upptime

Norman Torres — Fri, 18 Feb 2022 19:36:36 +0000

Hace tiempo en el lugar donde trabajo desarrollamos nosotros una herramienta que nos permitía saber si un sitio estaba disponible o por algún motivo no respondía hasta hora a esta funcionando bien, solo que hemos tenido inconvenientes ya que cuando lo que fallaba era nuestra infraestructura no teníamos forma de saber y llegamos a estar hasta una hora sin darnos cuenta de que no teníamos servicio.
Para resolver ese problema me di a la tarea de buscar algo que fuera y consultara a nuestro sitio y me dijera si tenia respuesta, todo lo que encontraba era de pago o tenia que montarlo sobre nuestra infraestructura lo cual no era la idea, hasta que di con Upptime y es magia lo que hace.

Upptime es un proyecto open source que usa el poder de Github para monitorear los sitios que sean agregados en su archivo de configuración.

Esto me permitió tener un sitio de estatus en menos de 10 minutos con un sistema de envío de mensajes a slack, levantamiento de Issues, notificación al correo de los interesados y historial de tiempos de respuesta.

Todo esto gratis.
En otra publicación are un tutorial de configuración.

Upptime

Pipeline manuales en gitlab

Norman Torres — Sat, 22 Jan 2022 23:22:08 +0000

Esta semana tuve la tarea de modificar los pipelines que usamos en el trabajo para que no se despliegue en cada rama creada una API nueva, lo cual suena muy util pero ya en la practica no era tan redituable ya que no eran muy usadas y provocaban posibles errores en el cluster de K8s.

Al inicio pensé que seria algo simple ya que e podido interactuar con los archivos proporcionados por gitlab con el uso de variables de entorno pero al enfrentarme al problema descubrir que no era el caso ya que agregar una variable mataba todos los reviews lo cual no estaba buscando, entonces cambie mi problema y en lugar de permitirlo con una variable que el programador envié recordé que puedo volver manual la ejecución de alguna tarea en los pipeline dando como resultado el primer ejemplo:

include:
  - template: Auto-DevOps.gitlab-ci.yml
review:
  when: manual

De esta forma todos los review son manuales y no se están desplegando todo el tiempo, pasando ese control al programador.

Hay ocurrió otro problema ya que tenemos el habiente de dev que es llamado como review/dev lo cual hace que te pregunte si lo quieres ejecutar, eso no es le funcionamiento que necesitamos ya que al hacer un merge a dev debería de subir en automático para solucionar eso use otras reglas dando como resultado el archivo final que cumple con todas las expectativas.

review:
    rules:
        - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
          when: never
        - if: '$CI_COMMIT_BRANCH == "dev"'
          when: on_success
        - if: '$CI_COMMIT_TAG || $CI_COMMIT_BRANCH'
          when: manual

Como últimos cambios se agrega que si el pipeline que se correo es la rama por default no se va a ejecutar el trabajo pero si es un Tag o un commit a cualquier rama se cree el trabajo pero se necesite la ejecución manual.