La mayoría de las aplicaciones web podrían ejecutarse simplemente en un solo servidor

Artículo original ↗ Discusión en Hacker News ↗

Muchos desarrolladores sostienen que la mayoría de las aplicaciones web podrían ejecutarse de forma barata en un único VPS modesto, y que el valor por defecto actual de clústeres Kubernetes, microservicios y configuraciones complejas en la nube suele ser innecesario para el tráfico y los requisitos de uptime habituales. Los comentaristas destacan cómo la sobreingeniería está impulsada por la mejora del currículum, los incentivos de los proveedores cloud y expectativas equivocadas de disponibilidad del 100%, mientras añade modos de fallo, coste y carga operativa. Otros señalan que los sistemas de gran escala o altamente regulados sí justifican una infraestructura sofisticada, pero sostienen que esos son la minoría frente a aplicaciones más simples que se beneficiarían de despliegues monolíticos y más ligeros.

Capacidad de un solo servidor y anécdotas del mundo real

  • Muchos comentaristas dicen que un VPS de $4–$10/mes puede manejar miles de solicitudes por segundo o tráfico de portada de HN si la pila es simple y eficiente.
  • Varios informan que ejecutan varias aplicaciones, motores de búsqueda, pequeños mercados o más de 10M de páginas vistas mensuales en una sola máquina modesta con buena ingeniería.
  • Las clásicas “pilas simples” (por ejemplo, LAMP, Go, PHP+Postgres, sitios estáticos con un backend pequeño) se citan repetidamente como suficientes para la mayoría de las cargas reales.

Complejidad, Kubernetes y cultura DevOps

  • Hay una fuerte sensación de que Kubernetes y las pilas modernas “cloud-native” suelen ser innecesarias para aplicaciones pequeñas o medianas y añaden una complejidad frágil.
  • Algunos señalan que k8s se usa simplemente porque un ingeniero quería aprenderlo o seguir “mejores prácticas” percibidas, no porque existan requisitos reales.
  • Otros sostienen que k8s proporciona una API estandarizada entre nubes y es valioso para grandes organizaciones con muchos equipos y servicios.

Tiempo de actividad, redundancia y fiabilidad

  • Hay desacuerdo sobre cuánto uptime necesitan realmente la mayoría de las aplicaciones.
  • Algunos dicen que una caída breve ocasional es aceptable y mucho más barata que configuraciones HA complejas.
  • Otros subrayan que los clientes esperan un uptime cercano al 100% una vez que pagan; entonces la redundancia (2–3 máquinas, failover, multi-AZ) está justificada.
  • Se señala que las arquitecturas multinodo y multirregión añaden muchos nuevos modos de fallo y pueden perjudicar la fiabilidad si no se entienden bien.

Coste, uso de recursos y sobreingeniería en la nube

  • Múltiples anécdotas de tráfico real mínimo frente a configuraciones en la nube/Kubernetes grandes y costosas, con ingenieros dedicando más tiempo a Terraform/IaC que a funciones.
  • Crítica a que el marketing de la nube y la era de capital riesgo de tipos de interés cero fomentaron la sobreingeniería y un OpEx desbocado.

Incentivos profesionales y diseño orientado al currículum

  • Varios argumentan que las arquitecturas sobrecomplejas están impulsadas por incentivos de contratación y carrera: las pilas llamativas, los microservicios y k8s se premian; los monolitos aburridos no.
  • Las soluciones pragmáticas de un solo servidor pueden ser óptimas para el negocio, pero menos valiosas para el currículum de los ingenieros.

Punto intermedio y alternativas

  • Entre las sugerencias figuran: un solo VPS con despliegues automatizados; contenedores sin k8s (Docker/Swarm/Podman); failover activo-pasivo simple; pequeños clústeres k3s/k0s.
  • Tema general: empezar extremadamente simple, escalar y añadir complejidad solo cuando la carga real, los requisitos de uptime o el tamaño de la organización lo exijan.