- 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
Aún no hay comentarios.