¿Tu startup realmente necesita una infraestructura cloud compleja?

¿Realmente necesitas una infraestructura cloud compleja?

• Al escuchar lo que Pieter Levels comentó en el podcast de Lex Friedman, surgieron muchas reflexiones
• Pieter opera sus aplicaciones en un solo servidor y construyó un exitoso negocio de micro SaaS
• Es importante evitar la complejidad de la infraestructura cloud y enfocarse en el product-market fit
• Puede que no aplique a todas las startups, pero hay que evitar la complejidad por la complejidad misma

Observaciones recientes

Proyecto 1: sobrecarga de Lambda

• Operación de varios servicios con 20-30 funciones Lambda
• Tareas en segundo plano usando SQS y Lambda
• Logs dispersos en CloudWatch

Resultado: depurar es difícil, hacer cambios cuesta y el despliegue es complejo. Se podría haber simplificado con un solo contenedor de NodeJS o una app en Python Flask/FastAPI y Redis

Proyecto 2: caos de microservicios

• Operación de 7 pequeños microservicios en Kubernetes (EKS)
• Servicios separados para CRUD y lógica de negocio

Resultado: se invierte más tiempo en administrar la infraestructura. Queda la duda de si realmente hacía falta ese nivel de separación

El poder de una configuración con un solo servidor

• Los servidores modernos son potentes. Hetzner y latitude.sh ofrecen VMs potentes a bajo costo
• Las VMs de GCP y las instancias de EC2 también tienen precios razonables
• Ofrecen gran poder de cómputo, con 40 GB de RAM y múltiples núcleos
• Todo está centralizado, así que es más fácil de administrar
• El problema de escalar a millones de QPS puede resolverse después

Lo necesario para una configuración con una sola VM:

1. Una máquina potente (EC2, GCP VM, Hetzner, etc.)
2. Acceso seguro (HTTPS, SSH restringido por IP o SSM)
3. CI/CD para despliegues sin downtime
4. Configuración de DNS
5. Backups regulares de la base de datos
6. Redundancia con una VM en espera

Docker Compose

• Docker Compose es excelente para desarrollo local
• Permite administrar varios servicios con un solo comando
• Se usa menos en producción
• Puede haber downtime durante las actualizaciones

Docker Compose Anywhere: proyecto de fin de semana

• Docker Compose Anywhere fue desarrollado durante un fin de semana
• Ofrece las siguientes funciones:
  • Configuración de servidores Linux con un clic mediante GitHub Actions
  • Despliegues sin downtime con GitHub Container Registry y Docker Rollout
  • Gestión de variables de entorno y secretos (considerando usar age o sops)
  • Backups automatizados de Postgres mediante GitHub Actions
  • Soporte para múltiples apps en una sola VM
  • SSL automático con Traefik y Let's Encrypt

Algunas consideraciones

Por seguridad:

• Configurar reglas de firewall estrictas (abrir solo los puertos necesarios)
• Proteger las claves SSH (en AWS se prefiere SSM, en GCP el CLI)
• Usar un bastion host para reforzar la seguridad
• Considerar la protección de secretos y el uso de WAF o Cloudflare

Protección de datos:

• Enviar backups cifrados de la base de datos a un almacenamiento cloud seguro (por ejemplo, S3)
• Crear snapshots de disco regularmente para mayor redundancia
• Implementar políticas de retención para backups y snapshots

Resumen de GN⁺

• Este artículo enfatiza que las startups deberían evitar una infraestructura cloud compleja y enfocarse en el product-market fit con una configuración simple
• Presenta las ventajas de una configuración de servidor único y un método sencillo de despliegue usando Docker Compose
• Es importante no desperdiciar tiempo administrando infraestructura compleja y concentrarse en desarrollar el producto principal
• Proyectos con funciones similares incluyen Heroku y DigitalOcean

[GN⁺]

Opinión de Hacker News

• En muchos proyectos, los equipos que intentan usar tecnología de punta suelen terminar entregando resultados de baja calidad

  • Hay equipos inmaduros que intentan usar Kubernetes sin entenderlo
  • Construyen procesos automatizados con Puppet para ejecutar servicios de Docker o levantar backends en Python en varias VM
  • Las startups gastan mucho dinero en la nube y aun así producen resultados peores que los pioneros de DevOps de 2017
  • Entrada de blog relacionada: The Emperor's New clouds

• En una startup pequeña, operan nginx, webapp, postgres, redis, etc. en una sola VM

  • Los desarrolladores pueden trabajar en local con la misma configuración, lo que facilita el debugging
  • Se puede escalar verticalmente, así que es adecuado en la etapa inicial

• Un SaaS empezó en un solo servidor y luego escaló a varios servidores

  • Operan una base de datos distribuida sin usar Kubernetes
  • Usan servidores bare metal más potentes que las máquinas virtuales de los proveedores de nube
  • Administran los servidores con ansible y terraform como herramientas de automatización

• Las funciones clave de Kubernetes, como despliegues, servicios de pods y despliegues blue-green, son útiles

  • En un entorno cloud-native, usar varios sistemas open source puede volverse complejo

• Mucha gente construye infraestructura compleja para aprender Kubernetes

  • Puede ser útil al escalar hacia clientes grandes
  • Puede ser menos útil para un fundador o CTO

• Incluso los libros sobre microservicios recomiendan "primero construye un monolito"

  • Al inicio, usar un monolito facilita el debugging
  • Usan Docker para simplificar la etapa inicial
  • Cambian a Kubernetes según las necesidades del negocio

• No se recomienda elegir frameworks complejos desde el principio

  • Usar herramientas propias no siempre es más eficiente
  • Usar herramientas estándar puede ser más eficiente a largo plazo

• En la nube solo usan VM, almacenamiento en bloques y blobs, DNS, IdP y registrador de dominios

  • Servicios como FaaS son complejos y difíciles de depurar
  • Una sola VM y una base de código monolítica son lo ideal

• Han operado un proyecto durante 6 años en un solo VPS de $10/mes

  • La tecnología de VPS ha avanzado muchísimo y es muy confiable
  • La infraestructura cloud se usa por sus funciones de colaboración y gestión operativa

• Prefieren soluciones basadas en la nube, pero las usan de forma selectiva

  • Usan Google Cloud Platform (GCP) para reducir costos
  • No usan Kubernetes
  • Usan Docker para simplificar los despliegues
  • Los servicios administrados de GCP les ahorran tiempo