Si entra en la máquina WABAC y configura el dial para el 31 de enero de 1999 para el Super Bowl XXXIII. Es posible que te encuentres pasando por el espectáculo de medio tiempo (con Big Bad Voodoo Daddy, Stevie Wonder y Gloria Estefan) a favor de esta nueva presentación especial “solo web” en FoxSports.com financiada y producida por Victoria’s Secret. Ah, sí, y presentando a sus modelos vistiendo su “ropa”, tal como son.
Prácticamente rompió Internet.
Y aprendimos mucho.
- ¿Por qué los Applets de Java no ganaron más tracción?
- ¿Cuáles son los problemas típicos de calidad de datos que podrían resolverse con un mejor diseño de formulario de entrada?
- ¿Estamos rompiendo Internet?
- ¿Por qué los sitios web siguen agregando www?
- ¿Cómo es saber que hay una imagen desnuda de ti flotando en Internet?
En ese momento, en Enron Broadband, estábamos ocupados construyendo una red que colocaba servidores de contenido en los nodos principales de nuestros socios ISP. Transmitiría un video desde un origen, no a los usuarios finales, sino a nuestros servidores de nodo perimetral. No fue una idea completamente nueva: me basé en gran medida de la tecnología Black Rocket que usamos en Genuity, con una aplicación liberal de Squid y algunas otras cosas.
No estábamos solos: en Akamai, Dan Lewin (tomado de nosotros demasiado pronto y trágicamente) y su banda de hombres felices estaban haciendo lo mismo. Traté de comprarlos y fallé. Parecía una buena elección de su parte, retrospectivamente.
En ese intervalo, se estaba inventando algo nuevo: redes de entrega de contenido. Redes optimizadas no para la comunicación de correo electrónico entre pares, ni para el intercambio casual de mensajes de texto o incluso la transferencia de archivos. Las redes se diseñaron sabiendo que en el futuro, todo se trataría de medios enriquecidos: video, imágenes gigantes de alta resolución, cosas que aniquilaron por completo la arquitectura central de una red para la cual la “aplicación asesina” era el correo electrónico.
Es bastante estándar en estos días, si tiene algún tipo de sitio web “importante”, o aspira a tener un sitio de este tipo, para construirlo desde cero en torno a dos conceptos clave.
El primero se llama distribución paralela de contenido estático. Su sitio web generalmente está compuesto por dos partes: hay cosas que no cambian (¡o cambian mientras lo usa!) Como HTML, Javascript, CSS, imágenes, videos, etc. Eso se carga una vez y se ejecuta hasta Es reemplazado.
Ahí es donde usa algún tipo de red de distribución de contenido: Akamai, Cloudfront, Cachefly, etc. Sus servidores se conectan a su red, su red se conecta al resto de su red y sus USUARIOS NUNCA se conectan a SU servidor. Se conectan a esta configuración de flota de repositorios distribuidos globalmente de su contenido estático, idealmente geolocalizados desde su dirección IP para ser el repositorio más próximo.
Eso maneja la parte de “cómo puedo minimizar el tiempo de acceso a las cosas y evitar que todo se extraiga de un único servidor de origen”. Pero eso es solo una parte de la ecuación, también tiene que lidiar con contenido dinámico, cosas que solo aparecen cuando se rellena desde una extracción de base de datos basada en alguna combinación de identidad y estado.
Ahí es donde explotas estos días. Descubrimos lo de “no enviar a todos a un solo servidor”, y eso funciona. Pero aún tiene que tener una manera de manejar la naturaleza altamente dinámica de las aplicaciones web modernas (y para el caso, las aplicaciones móviles nativas).
Entonces haces algo llamado Escalado Horizontal. Eso significa que, bajo carga, no explota: agrega más servidores dinámicamente y distribuye la carga sobre ellos. Es mucho más difícil de lo que parece: conduce a decisiones sobre dónde y cómo almacena los datos que indican el estado del usuario y de la página, si se requiere sincronización de estado en tiempo real o si puede salirse con la suya con un “modelo eventualmente consistente”, si usted tiene que ser idempotente y, en caso afirmativo, en qué medida en qué operaciones. Pero si lo logra y utiliza un servicio a pedido administrado por flota como Amazon AWS o Google Compute Platform, por lo que personalmente no tiene que poseer y operar los servidores que no usa la mayor parte del tiempo, funciona Excelente.
Ese es el estado del arte en Internet de hoy. Utiliza CDN para manejar contenido estático y usa escala horizontal para manejar carga.
Por lo tanto, una configuración típica podría ejecutarse en un solo servidor detrás de un equilibrador de carga, con un montón de métricas que saben cuándo activar el siguiente y los que están más allá, con todo el contenido estático en una CDN. Eso es lo que recomiendo a casi todos.
Bien hecho, puede cargarlo hasta que se quede sin dinero en el lado de la escala horizontal. Incluso es bastante resistente a los ataques DDOS (pero puede ser terriblemente costoso mientras intentas apagar a los atacantes).
Solo tiene una tarifa limitada en cuanto a la cantidad de contenido que un usuario puede obtener de su proveedor de CDN, y están motivados económicamente para asegurarse de que tengan un rendimiento ultra alto sin importar la carga (o sangran a los clientes).
Advertencia: mal hecho, todo explota de la caja. Tienes que entender el estado y la idempotencia.
