Recordatorio del lanzamiento de Pokémon Go: ¿Por qué es tan importante «construir para escalar» como «construir para fracasar»?
Una de las frases clave de DevOps y la nube durante los últimos años ha sido “construir para fallar”. La premisa es que muchas empresas experimentan costosos tiempos de inactividad y pérdida de ingresos (y productividad) debido a problemas de rendimiento relacionados con la capacidad, por lo que debe diseñar su aplicación e infraestructura "para que fallen" y así garantizar que eventos tan espantosos no vuelvan para atormentarlo. Je. ¿Ves lo que hice allí? Sí, trabajo remotamente en una oficina, solo. A veces tengo que divertirme.
Dejando de lado los malos juegos de palabras, el reciente éxito fenomenal de Pokémon Go (¿has oído hablar de eso, no?) resultó en lo que también fue una experiencia fenomenalmente frustrante para muchos. Especialmente padres con niños hiperemocionados que querían ir AHORA, pero no pudieron porque la creación de cuentas se suspendió temporalmente y luego se midió estrictamente debido a la abrumadora demanda.
Ahora bien, algunos podrían señalar la oferta del CTO de Amazon, Werner Vogels, de ayudar a la empresa a lidiar con sus problemas de capacidad como una implicación de que no habían "pasado a la nube" en primer lugar y que ese era el problema subyacente, pero eso supone que no lo hubieran hecho, lo cual no me queda del todo claro en este momento. En serio, según las actualizaciones de Wikipedia sobre el desarrollador de realidad aumentada, procesa “más de 200 millones de acciones de juego por día mientras las personas interactúan con objetos reales y virtuales en el mundo físico”. Creo que podemos darles un poco de respiro en esto, o al menos aquellos de nosotros que entendemos lo que eso significa en términos de interacciones del sistema y envío de paquetes podemos hacerlo. Las actualizaciones apuntaban a “problemas con el servidor”, pero vamos, todos sabemos que “servidor” es un código técnico para “15 componentes diferentes distribuidos en la aplicación y la infraestructura de red”.
En cualquier caso, la lección subyacente aquí no es que la nube sea necesariamente mejor para lidiar con el éxito inesperado. Bien podría ser, pero no porque sea una nube. Esto se debe a que la nube no solo está diseñada para fallar , sino también para escalar .
No estoy en condiciones de determinar por qué Niantic Labs no pudo satisfacer la demanda. Tal vez fue una falta de capacidad, en cuyo caso la nube sería una buena opción, y tal vez fue que las aplicaciones y/o la infraestructura no estaban diseñadas para escalar, en cuyo caso la nube podría no haber ayudado en absoluto. El punto realmente no es criticarlos por lo que hicieron o no hicieron. La cuestión es que son un ejemplo perfecto de la realidad de que, en un mundo de aplicação , las organizaciones deberían preocuparse tanto por construir para el fracaso como por construir para el éxito. Y no un éxito gradual, sino instantáneo, de la noche a la mañana, como en Pokémon Go.
Porque si sucede, no quieres que ese fracaso exitoso se muestre por todo Internet.
Una fuente común de problemas de escalabilidad son las fuentes de datos. Los usuarios experimentados de Twitter recordarán que los primeros días de las redes sociales estuvieron plagados de problemas de escalabilidad de bases de datos. PayPal fue uno de los primeros y más vocales defensores de la fragmentación como estrategia de escalamiento para lidiar con su desafío en torno a la escala masiva de usuarios, y la técnica ha sido adoptada como una técnica general, aplicable a bases de datos, servicios de rendimiento y aplicações por igual . El auge de las fuentes de datos NoSQL promociona como uno de sus beneficios una mayor escalabilidad que las bases de datos relacionales tradicionales.
Otra fuente de problemas de escalabilidad recae únicamente en la infraestructura. El escalamiento automático en la nube depende de la capacidad no solo de agregar automáticamente más procesamiento, sino también de aumentar la capacidad del “punto final de la aplicación”. En cualquier arquitectura que dependa de la escala para lograr un aumento en la capacidad, eso significa un servicio de equilibrio de carga de algún tipo. Cuando se incrementa el cómputo, se debe registrar en el servicio de equilibrio de carga. Esto significa el uso de API y scripts, automatización y orquestación. Estos componentes deben estar en su lugar antes de que sean necesarios, o habrá demoras si la demanda requiere un aumento en la capacidad.
La inclusión de un servicio de equilibrio de carga en cualquier arquitectura de aplicación debería ser un requisito. Un servicio de equilibrio de carga no solo satisface la necesidad de "construir para fallar" debido a su soporte inherente para la conmutación por error entre dos instancias de aplicação , sino que también respalda la necesidad de "construir para escalar" necesaria para el éxito. Pero no pienses que se trata simplemente de poner un servicio de equilibrio de carga delante de una aplicación (o un microservicio, si eso es lo tuyo). Es importante que las operaciones implementen la automatización (scripts) y la orquestación (proceso) que permitirán el escalamiento automático para satisfacer esa demanda cuando surja. Hoy en día, escalar es una cuestión de arquitectura, no de algoritmos , y es importante tener en cuenta esa arquitectura desde el principio, antes de que la deuda arquitectónica sea tan restrictiva que uno se quede con lo que tiene.
Honestamente, Niantic Labs hizo un buen trabajo preparándose para el fracaso. Las fallas de capacidad se resolvieron con mensajes amigables en lugar de las páginas de códigos de estado HTTP predeterminadas que suelo encontrar. Eran divertidos y fáciles de leer y entender para los niños (lo sé porque mi hijo de 8 años nos los leía cada 20 minutos). Lo que no planearon fue el éxito quizás inesperado con el que se encontraron. Lo cual es un buen recordatorio para todos de que construir a escala es tan importante como construir para fracasar.
Porque cuando no lo haces, el Equipo Rocket gana.