«¿Por qué se ha colgado vuestra página web? ¡Seguro que sabíais que iba a tener mucho tráfico!»
Esto se oye muy a menudo cuando una página web se colapsa en un momento crucial. En las redes sociales se plantean las mismas preguntas, con el mismo tono acusatorio: «Seguro que sabían que iba a haber mucho tráfico. ¿Por qué no pudieron añadir unos cuantos giga-lo-que-sea más?».
Para los usuarios decepcionados, parece obvio que la empresa debería haber adoptado más medidas preventivas antes de que se produjera un gran pico de tráfico, y que lo único que podría haber salido mal fue una mala planificación.
Pero, ¿en qué consisten esas medidas preventivas? ¿Pruebas de carga? ¿Un «servidor más potente»? ¿Quizás más servidores? ¿Y qué tal una de esas nubes «mágicas» y escalables sin servidores…?!
A menudo, la primera vez que nos reunimos con los desarrolladores web de un equipo, se encuentran en una sesión de incorporación a CrowdHandler con el rabo entre las piernas. Sienten que han fracasado. Lo hicieron todo según las normas y, aun así, la página web no se mantuvo en funcionamiento, por lo que ahora, debido a las limitaciones de tiempo, se ven obligados a arreglarla a toda prisa con una página de espera. Los primeros diez minutos de la reunión se dedican a dejar claras las excusas.
Ya lo hemos oído todo. Estáis reconstruyendo la plataforma y la nueva web no tendrá estos problemas. Habéis heredado un código heredado que no podéis modificar. Estáis atascados en una versión antigua del Framework X, que es conocido por sus problemas de rendimiento. Podríais solucionar todos los problemas, claro; solo es cuestión de tiempo.
El motivo de esta situación embarazosa es que la mayoría de los cuellos de botella —los problemas que impiden que los sitios web puedan gestionar miles y miles de usuarios— tienen su origen en el código, del que los desarrolladores se sienten responsables.
Estos cuellos de botella suelen encontrarse en el backend: algo que está detrás de la interfaz de usuario —por ejemplo, un sistema que gestiona la venta de entradas o las citas, o el procesamiento de pagos con tarjeta de crédito—. Pero con la misma frecuencia, los cuellos de botella se encuentran en la propia interfaz de usuario, en el código web, sobre el que los desarrolladores tienen control total.
Escuchar las excusas de los desarrolladores no nos hace sentir presumidos ni superiores. Lo que sentimos sobre todo es empatía. Esta es la verdad: el código de nadie es escalable desde el primer momento, tal y como viene de fábrica, y la mayor parte de lo que te han enseñado sobre cómo escribir código escalable es erróneo.
En un momento te explicaré por qué no es culpa tuya, pero primero quiero presentarte una nueva forma de ver la Sala de Espera.
Instalar CrowdHandler no significa admitir un fracaso. De hecho, podría ser el primer paso para resolver tu problema de escalabilidad. En lugar de considerarlo un parche, me gustaría que pensaras en CrowdHandler como una herramienta de diagnóstico que te servirá de apoyo en tu trabajo y te ayudará a mejorar.
No es culpa tuya
Entonces, ¿por qué no es culpa de los desarrolladores que la página web no pueda soportar el tráfico?
La razón por la que el código convencional está plagado de cuellos de botella relacionados con el código es que los desarrolladores web convencionales no suelen trabajar en sitios web de gran popularidad. Cuando los desarrolladores web se forman y aprenden, su comprensión de la optimización y de cómo escribir código de alto rendimiento es, por lo general, teórica.
Aprender a escribir código escalable en teoría y luego ver cómo cien mil usuarios acceden a tu sitio web en la práctica me recuerda esa cita de Mike Tyson: «Todo el mundo tiene un plan hasta que le dan un puñetazo en la boca». Ahora te han dado un puñetazo en la boca. ¡Deberías estar orgulloso! La gran mayoría de los desarrolladores web nunca trabajan en nada lo suficientemente popular como para saber qué se siente.
Así que a ti —y a tu jefe— me gustaría deciros: es totalmente normal que vuestra página web no pueda adaptarse por arte de magia para gestionar cualquier nivel de tráfico. No deberíais esperar que lo hiciera.
Entonces, ¿cuál es la respuesta?
Por supuesto, quieres que tu sitio web sea lo más eficiente y escalable posible. Sin embargo, muchas de las supuestas soluciones para la escalabilidad, para el tipo de cifras de las que estamos hablando aquí, en realidad no funcionarán.
Puede que te centres en marcos de trabajo y lenguajes que, en teoría, son más rápidos, pero eso apenas supone una diferencia en el contexto general cuando atiendes a miles o millones de usuarios.
¿Sabes qué es lo que realmente marca la diferencia? El almacenamiento en caché. No me refiero al tipo de almacenamiento en caché de objetos preciso que se suele hacer cerca del servidor con Memcached, sino a ese almacenamiento en caché HTTP «sucio» cerca del usuario que parece estar fuera de tu control. Eso sí que mejora el rendimiento, pero es difícil de hacer bien y resulta complicado adaptarlo a marcos de trabajo y sistemas de gestión de contenidos que no lo tienen debidamente en cuenta.
Así que supongo que podrías empezar por las pruebas de carga. Sin embargo, aunque pueda parecer controvertido, no creo que las pruebas de carga rutinarias te sirvan de mucho. Según mi experiencia, suelen ser una costosa pérdida de tiempo.
¿Por qué? Porque el comportamiento real de los usuarios es complejo. Es posible que configures recorridos de usuario básicos para tus pruebas de carga en los que los usuarios naveguen por una página, seleccionen un producto, lo añadan al carrito y finalicen la compra, pero eso no es lo que ocurre en el mundo real. Allí, los clientes van y vienen, analizan todas sus opciones, cambian de opinión, se detienen durante largos periodos antes de recargar las páginas y, a continuación, abren cuatro pestañas con diferentes productos para compararlos. Podrían estar produciéndose miles de estos recorridos complejos al mismo tiempo, consultando las mismas entradas de la base de datos de formas impredecibles.
Así que podrías realizar una serie de pruebas de carga en el entorno de pruebas que provoquen el colapso de la web al alcanzar los dos millones de usuarios y declarar que dos millones es el número mágico. Pero, ¿hasta qué punto son realistas esos dos millones de recorridos de usuario? ¿Realmente reflejan dos millones de experiencias auténticas y funcionales en el entorno de producción? ¿O se habría colgado el sitio web en producción mucho antes, cuando los usuarios hubieran empezado a comportarse de forma realista? (Por no hablar del momento en que alguien decide generar un informe de ventas exhaustivo durante la propia rebaja… ¿Ah, que no estás probando eso?)
No olvidemos que las pruebas de carga también requieren muchísimo tiempo. Incluso con un guion simplificado del recorrido del usuario, tendrás que repetir las pruebas una y otra vez, corrigiendo los problemas de configuración hasta que funcionen. Y luego, cuando funcionen, tendrás que ejecutarlas hasta que el sitio web deje de funcionar. Puede ser un ciclo interminable. Muchos de nuestros clientes simplemente no consiguen que sus herramientas de pruebas de carga generen la cantidad de tráfico que esperan ver en el mundo real, o les resulta prohibitivamente caro hacerlo.
Por último: el tipo de pruebas de carga que estamos describiendo es un proyecto de gran envergadura. Conozco muchas empresas que realizan una gran prueba de carga una vez al año. Sin embargo, implementan código nuevo en producción varias veces a la semana. Es perfectamente posible que una sola línea de código colocada en el lugar equivocado invalide todo ese esfuerzo dedicado a las pruebas de carga y altere por completo las cifras en las que te basas. Ahora estáis incorporando código al entorno de producción mediante integración continua. Ojalá hubiera alguna forma de realizar una prueba de carga continua…
La prueba de carga continua
Me gustaría que consideraras CrowdHandler como una alternativa mucho más productiva y asequible a las pruebas de carga tradicionales. ¿Por qué? Porque CrowdHandler proporciona información continua y realista sobre el rendimiento, basada en el sitio web que protege, y te permite trabajar de forma más eficiente y iteriativa.
Durante una venta, tu panel de control muestra el tiempo que tarda en cargarse cada página y resume el rendimiento general de las mismas. En tiempo real, la función de ajuste automático de CrowdHandler analizará la velocidad de las páginas, hará un seguimiento del número de usuarios y determinará el volumen óptimo de nuevos usuarios que tu sitio web puede gestionar.
En otras palabras, se trata de una prueba de carga continua en tu entorno de producción, realizada con usuarios reales y que ajusta los resultados en tiempo real.
Pero, a diferencia de una prueba de carga clásica, cuenta con una válvula de seguridad integrada: la propia sala de espera. Si las cifras resultan estar muy lejos de lo previsto, lo peor que puede pasar no es que la web deje de funcionar, sino que la cola sea más larga.
Y además, aunque la gente tenga que hacer cola un poco más de lo que te gustaría, puedes observar y aprender del comportamiento real del sistema. Puedes ver qué páginas son especialmente lentas, lo que te permite detectar los cuellos de botella de tu aplicación, mientras que el ajuste automático gestiona la cola y mantiene una experiencia de usuario positiva. Puedes ver en qué partes del sitio tendrás que centrarte a la hora de optimizarlo para la próxima vez, observando los datos de una venta real.
Sin una sala de espera, si tu aplicación sufriera un cuello de botella desconocido, sería muy poco probable que pudieras diagnosticarlo o incluso observarlo, ya que tu sitio web estaría inoperativo y estarías intentando frenéticamente aplicar medidas de mitigación de emergencia. Incluso si pudieras recuperar los datos de diagnóstico más tarde, es poco probable que una emergencia de carga en espiral, agravada por un tráfico descontrolado, te permita obtener una imagen clara de la causa raíz.
Y por eso hablo de CrowdHandler como una parte esencial de tu conjunto de herramientas, en lugar de como un simple parche. Al elegir nuestra sala de espera, no estás tirando la toalla ni recurriendo a una solución rápida: estás incorporando una herramienta de diagnóstico adicional que puede ayudarte a mantener la cabeza fría y a mejorar continuamente tu rendimiento, al tiempo que reduces las críticas en las redes sociales.
Así que, si te estás planteando utilizar CrowdHandler, por favor, no vengas a nosotros con el rabo entre las piernas. ¡Mantén la cabeza bien alta! Eres desarrollador web. Trabajas en proyectos de gran popularidad y te comprometes a mejorar aún más las cosas. Lo estás haciendo todo bien.