Lembrete de lançamento do Pokémon Go Por que ‘Construir para Escalar’ é tão importante quanto ‘Construir para Falhar’
Uma das frases de efeito do DevOps e da nuvem nos últimos, oh, muitos anos tem sido “construir para falhar”. A premissa é que muitas empresas passam por períodos de inatividade dispendiosos e perda de receita (e produtividade) devido a problemas de desempenho relacionados à capacidade, então você deve criar seu aplicativo e infraestrutura "para falhar" para garantir que tais eventos horríveis não voltem para assombrá-lo. Hehe. Viu o que eu fiz ali? Sim, trabalho remotamente em um escritório, sozinho. Às vezes preciso me divertir.
Trocadilhos ruins à parte, o recente sucesso fenomenal do Pokémon Go (você ouviu falar sobre isso, certo?) resultou no que também foi uma experiência fenomenalmente frustrante para muitos. Principalmente pais com filhos super animados que queriam ir AGORA, mas não puderam porque a criação de contas foi temporariamente suspensa e então rigorosamente medida devido à grande demanda.
Agora, alguns podem apontar a oferta do CTO da Amazon, Werner Vogels, de ajudar a empresa a lidar com seus problemas de capacidade como uma implicação de que eles não tinham "ido para a nuvem" em primeiro lugar e que esse era o problema subjacente, mas isso pressupõe que não tenham, o que não está muito claro para mim neste momento. Sério, de acordo com atualizações da Wikipedia sobre o desenvolvedor de realidade aumentada, ele processa “mais de 200 milhões de ações de jogo por dia, enquanto as pessoas interagem com objetos reais e virtuais no mundo físico”. Acho que podemos dar um tempo para eles nisso, ou pelo menos para aqueles de nós que entendem o que isso significa em termos de interações do sistema e envio de pacotes. As atualizações apontaram para “problemas de servidor”, mas, vamos lá, todos nós sabemos que “servidor” é um código técnico para “15 componentes diferentes espalhados pela infraestrutura de aplicativo e rede”.
De qualquer forma, a lição subjacente aqui não é que a nuvem é necessariamente melhor para lidar com sucessos inesperados. Pode até ser, mas não porque seja nuvem. Isso ocorre porque a nuvem não foi criada apenas para falhar , mas também para ser escalável .
Não estou em posição de determinar por que a Niantic Labs não conseguiu atender à demanda. Talvez tenha sido uma falta de capacidade, caso em que a nuvem seria uma boa escolha, e talvez os aplicativos e/ou a infraestrutura não tenham sido desenvolvidos para escalar, caso em que a nuvem pode não ter ajudado em nada. A questão não é realmente cutucá-los (risos) pelo que eles fizeram/não fizeram. A questão é que eles são um exemplo perfeito da realidade de que, em um mundo de aplicativos, as organizações devem estar tão preocupadas em se preparar para o fracasso quanto em se preparar para o sucesso. E não apenas um sucesso gradual, mas um sucesso instantâneo, da noite para o dia, como o do Pokémon Go.
Porque se isso acontecer, você não vai querer que esse fracasso bem-sucedido seja espalhado pela Internet.
Uma fonte comum de problemas de escalabilidade está nas fontes de dados. Usuários experientes do Twitter vão se lembrar que os primeiros dias da mídia social foram atormentados por desafios de escalabilidade de banco de dados. O PayPal foi um dos primeiros e mais ativos defensores da fragmentação como estratégia de dimensionamento para lidar com o desafio em torno da grande escala de usuários, e a técnica foi adotada como geral, aplicável a bancos de dados, serviços de desempenho e aplicativos . O surgimento de fontes de dados NoSQL apregoa como um de seus benefícios a maior escalabilidade do que os bancos de dados relacionais tradicionais.
Outra fonte de problemas de escalabilidade está unicamente nos ombros da infraestrutura. O dimensionamento automático na nuvem depende da capacidade não apenas de adicionar mais computação automaticamente, mas também de aumentar a capacidade do “ponto de extremidade do aplicativo”. Em qualquer arquitetura que dependa de escala para atingir um aumento de capacidade, isso significa um serviço de balanceamento de carga de algum tipo. Quando a computação é aumentada, ela deve ser registrada no serviço de balanceamento de carga. Isso significa o uso de APIs e scripts, automação e orquestração. Esses componentes devem estar prontos antes de serem necessários, ou haverá atrasos caso a demanda exija um aumento na capacidade.
A inclusão de um serviço de balanceamento de carga em qualquer – toda – arquitetura de aplicativo deve ser um requisito. Um serviço de balanceamento de carga não apenas supre a necessidade de “construir para falhar” devido ao seu suporte inerente para failover entre duas instâncias de aplicativo, mas também oferece suporte à necessidade de “construir para escalar” necessária para o sucesso. Mas não pense que é só colocar um serviço de balanceamento de carga na frente de um aplicativo (ou microsserviço, se você preferir). É importante que as operações implementem a automação (scripts) e a orquestração (processo) que permitirão o dimensionamento automático para atender a essa demanda quando ela surgir. Hoje em dia, o dimensionamento tem a ver com arquitetura, não com algoritmos , e é importante considerar essa arquitetura desde o início, antes que a dívida arquitetônica se torne tão restritiva que você fique preso ao que tem.
Honestamente, a Niantic Labs fez um bom trabalho se preparando para o fracasso. Falhas de capacidade eram tratadas com mensagens amigáveis em vez das páginas de código de status HTTP padrão que encontro com frequência. Eles eram engraçados e fáceis para as crianças lerem e entenderem (eu sei, porque meu filho de 8 anos lia para nós a cada 20 minutos). O que eles não planejaram foi o sucesso talvez inesperado com o qual foram recebidos. O que é um bom lembrete para todos de que construir em escala é tão importante quanto construir para fracassar.
Porque quando você não faz isso, a Equipe Rocket vence.