En 2023, la gloria está a solo 11 MB/s de distancia

La verdad sobre los costos de la nube

• Existe la percepción de que los servicios en la nube son baratos, pero en realidad los usuarios podrían estar pagando costos excesivos.
• AWS genera la mayor parte de las ganancias de Amazon, lo que puede significar que los servicios en la nube en realidad son caros.

Cálculos desde primeros principios

• Si quisieras crear uno de los 1000 sitios web más grandes, por ejemplo como businessinsider.com, necesitarías 200M visitantes mensuales y 400M page views.
• Solo con documentos HTML se requieren 30 TB de ancho de banda al mes, pero eso equivale apenas a 11 MB/s, un umbral muy bajo para el hardware moderno.

Entender la latencia

• A la velocidad de la luz, una ida y vuelta hasta el lado opuesto de la Tierra requiere unos 200 ms, pero en la práctica toma alrededor de 300 ms.
• Si usas un CDN para entregar JS, CSS y medios, puedes reducir 300 ms del tiempo de procesamiento del servidor, logrando un efecto similar a poner el servidor al lado del usuario.

Los límites de la tecnología edge

• La tecnología edge no resuelve el problema de la base de datos, a pesar de los avances de la segunda generación de tecnologías serverless.
• La mayoría de las páginas complejas requieren consultas a la base de datos, y eso puede aumentar la latencia.

Consideraciones de costo

• Hetzner.com ofrece costos de servidores y ancho de banda mucho más bajos en comparación con AWS EC2.
• Los proveedores de nube ofrecen muchas cosas gratis al principio, pero al escalar los costos aumentan mucho.

La situación realista

• Salvo casos de uso muy específicos, la mayoría de los sitios web o SaaS pueden ejecutarse en un solo servidor, lo que resulta más barato y más simple de mantener.
• Se puede usar SQLite en local, cachear CSS, JS e imágenes mediante un CDN y mejorar el rendimiento con renderizado del lado del servidor.
• Incluso sin Docker complejo ni virtualización, es posible escalar lo suficiente, con una administración más sencilla y un costo menor.

La opinión de GN⁺

• Este artículo cuestiona la creencia general de que los servicios en la nube son rentables y señala que los usuarios podrían estar pagando más de lo que realmente necesitan.
• Al comparar la estructura de costos de los servicios en la nube, muestra que el hosting tradicional en un solo servidor puede seguir siendo una alternativa válida.
• Destaca que tecnologías como serverless, Docker y la escalabilidad horizontal no son necesarias en todas las situaciones, y que a veces un enfoque más simple puede ofrecer mejor rendimiento y reducción de costos.
• Enfatiza la importancia de la optimización de la base de datos y de la ubicación regional, lo que sugiere que se puede lograr un rendimiento igual o mejor que el que ofrecen los servicios en la nube.
• Entre los aspectos a considerar al elegir tecnologías están evaluar el tráfico real y los requisitos de rendimiento, y considerar el hosting tradicional en servidores en lugar de la nube según la relación costo-beneficio.

[GN⁺]

Opiniones de Hacker News

• Experiencia en el negocio de hosting

  • En el pasado, en el negocio de hosting se ofrecían sistemas complejos según las necesidades de los clientes.
  • Se desarrolló una plataforma de hosting en la nube basada en API para competir con AWS, pero los ingresos alcanzaron su punto máximo en 2012.
  • Los clientes querían soluciones más complejas basadas en AWS y no confiaban en servidores simples.
  • La empresa operaba de forma bootstrappeada y no entendía la necesidad de asumir el riesgo de costos de AWS.
  • AWS es preferido por la "astucia" profundamente arraigada en una generación de desarrolladores de software.

• Errores en el análisis de tráfico

  • El tráfico no se distribuye de manera uniforme, y el ancho de banda requerido en horas pico es mucho mayor que el promedio.
  • En servicios reales, el establecimiento de conexiones TCP y TLS requiere varios viajes de ida y vuelta, y el tiempo de respuesta es importante para la experiencia del usuario.

• Errores del servidor y tráfico

  • Un 500 Internal Server Error indica que el servidor está manejando más tráfico del esperado.

• Enfoque para escalar servicios

  • Es preferible evitar el escalado innecesario y construir solo cuando haga falta.
  • Cuando surjan problemas de rendimiento, es mejor responder en ese momento.

• Ventajas de AWS

  • Usar AWS ofrece margen para justificarse cuando hay una caída del servicio.

• Discusión sobre arquitectura en la nube

  • No se trata de un debate sobre la necesidad de la arquitectura en la nube, sino de un medio para presentar alternativas.
  • Los problemas de disponibilidad cuando un servidor se cae pueden resolverse de otras maneras.

• SQLite y escalado vertical

  • En lugar de SQLite, se puede usar un Postgres autohospedado, aunque eso requiere más esfuerzo de configuración.
  • Es posible una arquitectura que mantenga todo el estado global en memoria y guarde snapshots en disco.

• Combinación de API y base de datos SQLite

  • SQLite puede procesar muchas consultas en un solo hilo.
  • Del lado de la API se puede usar caché en memoria y, para páginas estáticas, omitir la base de datos para mejorar el rendimiento.

• Problemas de disponibilidad de un solo servidor

  • Operar un servicio en un solo servidor puede provocar tiempos de inactividad no planificados.
  • Hay que considerar el tiempo de recuperación de datos y la cantidad de datos perdidos.

• Migración a la nube y disponibilidad

  • Migrarse a la nube a menudo se siente como presión de grupo.
  • En términos de disponibilidad, un solo servidor puede ser riesgoso, y conviene usar una mezcla inteligente de CDN y nube.