Usa un solo servidor grande (2022)

• La esencia del debate no es monolítico vs. microservicios, sino si un sistema distribuido vale la pena frente al overhead de desarrollo/operación
• Un servidor moderno por sí solo tiene decenas a cientos de núcleos, memoria de nivel TB y E/S de decenas a cientos de Gbps, con margen de rendimiento suficiente para soportar la mayoría de los servicios web
• Benchmarks reales muestran que con un solo servidor es posible lograr Nginx 500 mil RPS, PostgreSQL 70 mil IOPS, NoSQL 1 millón de IOPS, codificación 4K a 75 FPS, es decir, procesamiento de alto rendimiento
• Usar la nube mejora la conveniencia y la disponibilidad, pero su prima de costo es considerable, por lo que hay que evaluar la eficiencia de la inversión
• Solo cuando el patrón de uso es extremadamente variable una arquitectura cloud-native o serverless ofrece ventajas de costo
• Sin embargo, la prima de costo de serverless/mini-VMs es alta, y si la carga es continua o predecible, el escalado vertical resulta más económico
• La disponibilidad puede resolverse en gran medida con redundancia principal/secundario (o 2×2) y combinaciones de hardware distintas, y una estrategia razonable es distribuir solo CDN y backups

---

Panorama general: el valor de “un solo servidor grande” frente a los sistemas distribuidos

• El punto central del debate “monolítico vs. microservicios” es decidir si vale la pena el gasto real de tiempo de desarrolladores y costos que implica adoptar sistemas distribuidos
• El software moderno funciona sobre virtualización de servidores y varias capas de abstracción; incluso “serverless” o “bare metal” al final se construyen sobre recursos de servidores físicos
• Los servidores actuales tienen una muy alta eficiencia costo-rendimiento más allá de lo que solemos imaginar
  • Frente al pasado, las especificaciones de los servidores han mejorado drásticamente en cantidad de núcleos, ancho de banda de memoria, líneas PCIe y almacenamiento NVMe, y muchos servicios pueden alcanzar su QPS objetivo sin distribución

El potente rendimiento del hardware de servidores

• Un servidor de ejemplo de Microsoft Azure cuenta con 2 CPU de servidor AMD de 3.ª generación, para un total de 128 núcleos y 256 hilos
• En un solo servidor se puede alcanzar un rendimiento de cómputo de alrededor de 4 TFLOPs, superior al de las supercomputadoras de principios de los 2000
• Con 16 ranuras de RAM DDR4-3200 por socket, se logra escalabilidad de hasta 8 TB de memoria; incluso en opciones de compra prácticas se admite 1 TB de memoria
• Con un total de 128 líneas PCIe Gen4, 30 SSD NVMe y tarjetas de red de 50~100Gbps, es posible construir almacenamiento y conectividad de red de alto rendimiento

Qué se puede hacer con un solo servidor así (benchmarks citados)

• Es posible alcanzar 400–800 Gbps de transmisión de video, NoSQL 1 millón de IOPS, PostgreSQL 70 mil IOPS y Nginx 500 mil RPS
• También muestra alto rendimiento en tareas intensivas en CPU, memoria y E/S como compilar el kernel de Linux en 20 segundos o codificar x264 4K a 75 FPS

Comparación de costos de renta y compra de servidores

• OVHCloud: se puede rentar un servidor de 128 núcleos / 512GB RAM por alrededor de $1,318 al mes
• Hetzner: ofrece un servidor de 32 núcleos / 128GB RAM por €140 al mes, con distintos rangos de precio según el tamaño
• AWS m6a.metal: un servidor de 96 núcleos físicos / 768GB RAM cuesta $8.29 por hora, o alrededor de $6,055 al mes, lo que implica una fuerte prima de nube
• Comprar directamente a Dell un servidor de especificaciones similares cuesta unos $40,000, por lo que frente a la nube la inversión podría recuperarse en unos 8 meses
• Asumiendo el mismo rendimiento con serverless, se estima una prima de costo de 5.5 veces frente a instancias y de 25 veces frente a hosting económico

Por qué los sistemas distribuidos se volvieron populares

• En el pasado (alrededor de 2010), por las limitaciones de CPU, memoria y almacenamiento, los servicios grandes necesitaban una combinación de varios servidores
• Recientemente, con grandes servidores individuales, SSD NVMe y alto ancho de banda de memoria, el límite de procesamiento por nodo único ha mejorado mucho, pero las unidades de VM y contenedor todavía se diseñan pensando en recursos de servidor pequeños

Cuándo basta con un solo servidor grande

• La mayoría de los servicios web por debajo de 10k QPS pueden funcionar bien con una sola máquina, y los servicios simples incluso pueden llegar a niveles de millones de QPS
• Incluso en streaming de video, es realista que el control plane esté en un solo servidor, y mediante benchmarks y tablas de rendimiento comunes se puede calcular el tamaño adecuado del servidor
• Salvo casos especiales, una arquitectura de servidor principal y servidor de respaldo es suficiente para garantizar la disponibilidad

“Más alto” en lugar de “más ancho”: preferir pocos servidores grandes antes que muchos pequeños

• Incluso si se necesita un clúster, unos pocos servidores grandes tienen menor overhead de coordinación (O(n)) que muchos servidores pequeños
  • Es decir, a largo plazo suele ser más eficiente reducir la cantidad de servidores y aumentar sus especificaciones
• En entornos basados en serverless o contenedores efímeros, la proporción de overhead es especialmente mayor
• La desventaja es el punto único de falla, pero puede mitigarse bastante con una configuración principal/secundario (en distintos DC)
• Para mayor solidez, una configuración 2×2 (2 en el DC principal + 2 en el DC secundario) y hardware/fabricantes distintos ayuda a evitar fallas correlacionadas
• En esquemas de renta, diversificar modelos de servidor puede reducir el riesgo de fallas en cadena de discos o SSD del mismo lote

Ventajas y límites de usar la nube

• La nube destaca por su disponibilidad, velocidad de recuperación y facilidad operativa, y vale la pena pagar su costo premium
  • Permite reiniciar rápidamente dentro del presupuesto sin caídas prolongadas y aprovechar grandes pools de recursos administrados como grid
  • Los proveedores de servidores rentados son más baratos, pero tienen limitaciones en calidad, red y soporte premium
• Sin embargo, la venta de servicios cloud suele recomendar VM con autoescalado, serverless y bases de datos HA administradas, es decir, arquitecturas dependientes del proveedor, por lo que hay que vigilar costos y complejidad
• Procesar tráfico masivo por sí mismo no es la razón principal para optar por cloud-native, y hay muchos casos donde un solo gran servidor puede atender millones de usuarios concurrentes

Costo de carga pico y criterio para cargas bursty

• Alguien tiene que aprovisionar capacidad para el pico, así que al final el costo del pico se cobra en algún punto de la cadena de suministro
• Para trabajos bursty o temporales (por ejemplo, una gran simulación puntual), serverless/autoescalado puede ser económico, pero para cargas continuas y predecibles, operar grandes servidores fijos es más rentable
• Si se aprovechan contratos anuales, spot o negociación comercial, el costo de instancias baja aún más y la prima frente a serverless aumenta

Evaluación cuantitativa de la “prima de nube”

• La computación serverless como AWS Lambda puede implicar una prima de costo de 5 a 30 veces frente a un servidor equivalente
• Suposición: si un servidor de $8.2944/hora ofrece 1k QPS y 768GB RAM, reemplazar ese rendimiento con Lambda costaría unos $46/hora, es decir, una prima de 5.5 veces
• Frente a la renta en OVH, se estima una prima de 25 veces; con solo 5% de utilización, el hosting económico ya resulta más rentable que serverless
  • Si se usan contratos de largo plazo o instancias spot, la diferencia de prima puede aumentar aún más
• Aunque cambie el QPS, si se convierte por memoria-tiempo, el multiplicador de la prima tiende a ser similar; la clave es escalar el servidor al tamaño de la carga

Objeciones y malentendidos comunes

• “En la nube no se necesita personal de operaciones”: el nombre del rol solo cambió a Cloud Ops; siguen siendo necesarias capacidades de documentación, trazabilidad de cambios y respuesta a deprecaciones, lo que puede elevar los costos de personal
• “En la nube no hace falta aplicar actualizaciones de seguridad”: algunas quedan cubiertas, pero solo en áreas fáciles de automatizar; aún se requiere auditoría de librerías y validación de configuraciones
• “La nube da tranquilidad por su diseño de alta disponibilidad”: el aumento de complejidad crea nuevas vulnerabilidades, y la redundancia entre regiones o proveedores tampoco elimina por completo las fallas correlacionadas
• “La nube acelera el desarrollo”: la agilidad inicial sí es una ventaja, así que conviene aprovecharla, pero monitoreando el punto de inflexión de costos para migrar en el momento adecuado
• “Nuestro tráfico es muy bursty”: en ese caso sí encajan serverless y autoescalado
• “¿Y el CDN?”: reducir latencia y ancho de banda es un objetivo indispensable para distribuir, y con los backups pasa igual: son áreas que conviene comprar como servicio

Monolítico vs. microservicios y estructura del servidor

• Un “servidor grande” suele asociarse con una arquitectura monolítica, pero también es posible montar microservicios en forma de varios contenedores dentro de una sola máquina
  • Sin embargo, el overhead de comunicación entre procesos, despliegue y observabilidad sigue pesando incluso en un host único, por lo que el beneficio real de rendimiento frente a la complejidad se reduce mucho
• En etapas iniciales o a escala pequeña y mediana, un monolito o unos pocos servicios suele ser mejor en términos de simplicidad operativa

Conclusión

• En la mayoría de los casos, en lugar de una arquitectura centrada en escalado horizontal o en la nube, elegir escalado vertical (un solo servidor grande) es más simple y más económico
• Si se combina con redundancia principal/secundario, hardware heterogéneo y externalización de CDN/backups, es posible asegurar una confiabilidad práctica, con clara ventaja en costo total de propiedad (TCO) en entornos de carga continua
• Si se cuenta con una estrategia sólida de redundancia de hardware, el enfoque de “un solo servidor grande” puede ser una opción muy adecuada para servicios reales

[GN⁺]

Comentarios de Hacker News

• Uno de los mayores problemas del impuesto de la nube (Cloud Tax) es que termina limitando artificialmente el rango de soluciones que los ingenieros pueden considerar. Por ejemplo, si pagas unos $200/mes en AWS, obtienes un servidor con 4 vCPU y 16GB de RAM, que más o menos equivale a una laptop de desarrollo de hace 5 años. En cambio, en Hetzner puedes rentar por el mismo costo un servidor de 48 núcleos y 128GB de RAM. La diferencia de capacidad de cómputo es enorme. Si tienes 10 veces más capacidad, metodologías suficientemente efectivas dejan de tener sentido en nodos pequeños. A veces estas condiciones también sirven para ahorrar tiempo de ingeniería que se iría en construir sistemas más complejos. Claro, también hay que considerar otras cosas como la durabilidad, pero por otro lado un servidor dedicado te garantiza rendimiento consistente sin preocuparte por noisy neighbors
  • En 2025 ya puedes usar servicios como fly.io para propósitos generales sin tanta fricción ni procesos complejos, y para ciertos frameworks también hay opciones como Vercel (buenas alternativas especializadas en stacks concretos). Si necesitas más que eso, puedes rentar máquinas realmente monstruosas y baratas en OVH/Hetzner/Latitude. Si solo quieres operar un blog, hay muchísimos VPS. La nube tradicional ahora básicamente solo sirve para regulación, procesos internos o ineficiencia. Mi impresión es que tanto la productividad de desarrollo como el costo por máquina son cero. A menos que de verdad seas un equipo sin ninguna restricción al que le gusten los sistemas de aprobación estilo DMV, los nodos Intel ruidosos, los márgenes caros y el soporte pésimo, para la mayoría no tiene sentido
  • Es incluso más que eso: si usas un servidor bare metal, no necesitas lidiar con latencia de red, latencia/contención de ancho de banda de memoria de una VM ni estructuras de caché separadas; por ejemplo, puedes darle muchísima RAM a Postgres y usar solo el caché de disco de Linux. Es mucho más simple y rápido
  • No entiendo por qué hay que irse directo a AWS incluso para servicios pequeños. Yo no hago nada tan complejo como tú, pero un cliente tenía una combinación de pequeña app web en PHP + servidor AWS/SQS/S3 por $100/mes. Lo reimplementé con Python/Django/PostgreSQL (al principio SQLite) y lo moví a un VPS de $25/mes. OCR de PDFs, actualización de precios, búsqueda de productos faltantes, servicio del sitio, todo corre bien con 4 cores y 6GB de RAM. Es una app interna que nunca va a tener mucho más de 100 usuarios, así que aunque crezca algún día, migrarla sería muy fácil. A este nivel no hay motivo para usar un servidor de AWS de $100, al menos hasta que realmente escale en grande
  • Totalmente de acuerdo. Si usas una base de datos embebida como sqlite y optimizas las escrituras por lotes, con Hetzner puedes llegar increíblemente lejos. El argumento de “reservar demasiada capacidad y desperdiciarla” deja de tener sentido apenas sales de AWS (la relación costo-beneficio es abrumadora). De hecho, mientras más complejo es el sistema, muchas veces termina teniendo menos confiabilidad y resiliencia que un solo nodo. Casi nunca pasa que solo una cosa quede aislada y falle
  • Yo pienso más bien lo contrario. Me encanta Hetzner para sitios pequeños, pero en proyectos grandes la nube se siente prácticamente sin restricciones. Si es un proyecto donde mi tiempo vale algo, me da igual si el hosting cuesta $200 o $2000. Tampoco noto tanta diferencia entre el tiempo de desarrollo con AWS CDK/Terraform+GitHub Actions y con Docker/K8s/Ansible+pipeline de CI. No siento que el enfoque bare metal me haya ahorrado mucho más tiempo de ingeniería. IaC con Fargate+RDS también es cómodo. Si de verdad necesitas separar, escalar y volver duradero el almacenamiento de archivos, o integrar varios servicios dedicados de distintas capas de infraestructura como generación dinámica de subdominios, la carga de aprender e integrar nuevos servicios es mucho mayor. De hecho hago esto desde antes de la era cloud, y si el proyecto genera ingresos, creo que el costo de la nube vale la inversión. Si el proyecto siente demasiado ese costo, probablemente es más hobby que negocio. Administrar RAID o varios sistemas de archivos en clúster no es algo que yo quiera hacer con los recursos de una startup/empresa promedio ni con mi tiempo. Lo siento como una preferencia tipo disfrutar moverle a Arch+Emacs versus estar conforme con una MacBook. Si quieres cambiar el scheduler del kernel, te diría que uses Arch; si no, te recomendaría una MacBook. Dicho eso, también he vivido casos donde, si no había presupuesto y el raw throughput importaba mucho, un servidor dedicado era exactamente lo correcto (ahorrando miles de dólares). Si eso hubiera tenido éxito, probablemente después habría escalado verticalmente, pero es un caso raro
• HN (Hacker News) opera con dos servidores: uno para producción y otro de respaldo. Es un patrón útil porque permite hacer failover inmediato si hay problemas de hardware o hace falta una actualización. Eso sí, hay que tener cuidado de que no sean clones completamente idénticos, porque podrían fallar ambos al mismo tiempo
  • No era tan crítico como un SSD, pero también hubo un error curioso en CPUs AMD. Después de unos 1044 días, cierto core se detenía por completo caso de cuelgue en CPU AMD EPYC Rome
  • Me pregunto si hay estadísticas sobre el downtime de HN (Hacker News). En los últimos 10 años solo recuerdo una o dos caídas, así que en la práctica parece tener más de 99.99% de uptime
• Llevo más de 10 años usando una combinación híbrida de colocation + nube pública, y a partir de cierto tamaño siempre ha sido lo mejor para optimizar costos. La eficiencia del hardware también sigue mejorando. Necesitas administradores de red/infraestructura, pero la verdad hoy en día administrarlo es muy fácil y, de todos modos, básicamente también necesitas un administrador de “nube”, así que casi no hay ahorro real en personal. Hay muchas opciones de colocation y los proveedores venden paquetes de ancho de banda. En algún momento operé 8 clústeres Dell VRTX, SAN y más de 500 VM (desde grandes instancias de msSQL hasta kube), y en nube pública, incluso con descuentos por reserva, la factura habría sido de seis cifras. En cambio, el colocation costaba $2,400/mes (principalmente por electricidad). También siempre sorprende la notable degradación de velocidad de los nodos de nube pública (incluso con la misma generación de CPU/vCPU). Hay que entender bien las ofertas de equipos, actualizaciones, licencias y contratos de soporte, pero en la práctica es perfectamente manejable. Y ahora además ya es fácil conectar nube y red: recibes una fibra y la conectas al VPC, y listo
  • Entiendo el colocation como comprar tu propio hardware y solo rentar energía/rack/enlace en el datacenter; me da curiosidad si realmente es así. También me gustaría saber qué ventajas tiene frente a rentar un servidor bare metal común
• Llevo años hablando de este tema con amigos. La mayor desventaja de la infraestructura local es que necesitas personal especializado para operarla bien. El artículo se enfoca en la parte alta de la escala, pero en el segmento inferior, si ya tienes algo de equipo, puedes llegar al punto de equilibrio en un año con un rack pequeño o algo de red. Considerando la prima actual de la nube, incluso contratando a un administrador, la infraestructura local probablemente sigue siendo más económica
• En una empresa donde participé en la fundación, construíamos un motor de automatización empresarial, y el equipo quería desplegar la solución como SaaS para maximizar ingresos. En realidad, con un esquema de base de datos multi-tenant + VPS era más que suficiente, pero el equipo se obsesionó con aprender kubernetes y con el stack cloud native, dedicando un año entero a automatizar entorno de desarrollo y operación. Al final la empresa quebró poco después
  • Pero los ingenieros sí terminaron con experiencia en k8s, así que pudieron buscar nuevos trabajos con eso en el CV
  • Yo también viví algo parecido: perdí demasiado tiempo resolviendo por adelantado problemas que quizá harían falta dentro de 5 años. Para la mayoría de proyectos y startups tempranas, simplemente basta con un PaaS o con algo como nginx+contenedores Docker. Cuando llegue un pain point real, ahí sí vale la pena pensarlo
  • Por eso a mí me gusta simplemente usar PaaS hasta que “la factura de verdad duela”. Pago heroku/render/fly y me concentro en PMF (Product-Market Fit). O también existe la ruta de divertirse con K8s, quemar dinero de VC y luego ir saltando al siguiente empleo repitiendo el ciclo
• Muchos negocios no son tan importantes como creen. Mucha gente se estresa demasiado porque el servicio se cayó, pero en realidad lo que manejan no es tan crítico. Aunque el entorno de producción desaparezca a mediodía, sería molesto, sí, pero el mundo no se acaba. Estas empresas antes funcionaban perfectamente con un simple servidor de oficina para 250 personas y luego migraron a la nube solo para disparar el presupuesto. La nube es excelente para ciertos trabajos, pero para el resto se parece más a marketing inflado. Aun así, muchos ingenieros tienden a obsesionarse con la “escalabilidad perfecta” y buscan solo la arquitectura ideal en lugar de una solución suficientemente buena
  • Un excompañero con el que trabajé solía decir siempre algo así mientras estábamos en el trabajo. Tenía la mentalidad de “al menos si cometemos un error, nadie va a morir, así que no hace falta angustiarse tanto”. Venía de haber trabajado en cosas con muchísima más responsabilidad, y esa forma de pensar ayudaba mucho incluso en situaciones difíciles
• Cuando intentas construir estructuras complejas para alcanzar 100% de tiempo de actividad, muchas veces terminas cometiendo errores que reducen la confiabilidad. La mayoría de negocios en realidad puede tolerar de vez en cuando 1 o 2 horas de caída o incluso pérdida de datos. Si dejas claras esas expectativas desde el principio, puedes hacer ingeniería con una estructura mucho más simple y confiable
  • Y además cuesta mucho menos. Aunque esas expectativas, más que los ingenieros, muchas veces no las aceptan los ejecutivos no técnicos (especialmente la pérdida de datos casi nunca se tolera). Los ingenieros dicen que solo administran el entorno, pero en la práctica no es tan fácil, y si pasa algo puedes terminar viéndote incompetente
• Es un artículo bastante bueno. Si vas a escalar de esta forma (sin nube), también vale la pena considerar agregar un CDN. Con un CDN también obtienes efecto de WAF y failover de DNS. Eso sí, en un enfoque no cloud sí da un poco de flojera tener que operar tú mismo la base de datos. Por eso conviene considerar proveedores que ofrezcan también base de datos en la nube o, si tienes una estructura active/passive, operar el nodo pasivo de forma más barata con una VM en la nube + autoscaling. Hoy rentar servidores es realmente barato: un VPS de 4GB cuesta alrededor de $6, y un bare metal quad-core con 32GB ronda los $90. Usar comparadores como serversearcher.com ayuda bastante
  • Yo subí Postgres a un contenedor Docker y solo hacía respaldos periódicos, y nunca tuve mayores problemas. Operarlo también es simple, así que no hay realmente mucho de qué quejarse
  • En una sola máquina, sqlite puede dar mucho más rendimiento y administración mucho más sencilla que Postgres/MySQL
• Yo también corro servicios en VPS. Dejé la nube hace mucho. Si mis proyectos empiezan a generar dinero, pienso comprar equipo y meterlo en colocation. La nube se sentía como una app de citas: ya se acabó la diversión y ahora quiero hacer algo realmente productivo
  • El colocation también está lleno de problemas. Es bastante común que el hardware muera por fallas eléctricas del datacenter. Paradójicamente, la electricidad de mi casa es más estable. Si no es un negocio donde unos minutos de caída afecten millones en ingresos, para la mayoría no pasa nada por correr el servidor en el sótano. Mucha gente sobreestima brutalmente la necesidad de 99.999% de uptime o de tanto ancho de banda. El colocation tampoco es tan barato como parece. A veces la electricidad en el datacenter sale más cara que la tarifa residencial o comercial común. Lo verdaderamente barato es internet/la fibra, y hoy en muchos países ya puedes tener 5~10Gbit para empresas por 100 euros (antes por 1Gbit te cobraban más de 2 mil euros)
• Más allá del análisis de costos o capacidad, no es fácil ir contra la tendencia de la industria. Sí existe una ventaja real en “no tener que pensar en hardware”. Además, está muy arraigada la idea de que el capex (gasto de capital) debe evitarse a toda costa (el hardware de servidores requiere una inversión inicial grande). Y también existe ese mecanismo donde, si falla una región de AWS, no parece “nuestra culpa”, pero si se cae un servidor interno, sí parece “nuestra culpa”
  • Ese rechazo extremo al capex casi siempre viene de la estructura de inversión VC: si los inversionistas solo exigen crecimiento acelerado, una inversión inicial como comprar servidores no se puede justificar fácilmente. En cambio, un negocio estable sí puede absorber sin problema un pequeño capex cada año
  • Tampoco es obligatorio comprar hardware de servidor: con proveedores como Hetzner rentarlo basta. Me gustaría escuchar más en detalle a qué se refiere exactamente esa ventaja de “no tener que pensar en hardware”
  • Esa forma de pensar para ahorrar capex sí existe. Con saber usar una calculadora basta para ver que hoy el costo de los servidores rara vez es significativo para el negocio completo. Lo caro de verdad es el “espacio” alrededor del servidor, así que normalmente se renta el espacio (rack/energía), no el servidor
  • Al final, por lo que realmente pagan las empresas es por una “abstracción de responsabilidad”. A los ejecutivos de grandes empresas les da tranquilidad elegir soluciones de grandes proveedores como MS o AWS
  • Si rentas un servidor bare metal, tampoco tienes que preocuparte por capex ni por mantenimiento