O Novo AAA: APIs, Autenticação e Disponibilidade

Você deve ter percebido que sim, eu sou uma dessas pessoas que jogam Pokémon Go. Ou, como tem acontecido frequentemente ultimamente, não jogar Pokémon Go. Isso é ruim, porque também significa que nosso filho mais novo não está jogando, porque descobrimos que nós dois estamos usando contas do Clube de Treinadores Pokémon (PTC) para jogar, não contas do Google, e não conseguimos entrar.

Isso é significativo, porque enquanto nós dois estamos frustrados por nossa incapacidade de "autenticar" e fazer login para jogar, meu marido escolheu usar sua conta do Google e, bem, ele não está tendo os mesmos problemas.

O que me fez investigar algumas preocupações técnicas que realmente devem repercutir em todas as empresas, independentemente do aplicativo que estejam lançando. Essa preocupação gira em torno do novo AAA – APIs, Autenticação e Disponibilidade.

Curiosamente, essa busca começou quando eu estava lendo um artigo na Forbes sobre como rastrear Pokémon no Pokémon Go. Sim, Forbes. É tão grande. De qualquer forma, isso levou a outro artigo e outro, com um deles especulando que o motivo pelo qual o rastreamento foi (pelo menos inicialmente) interrompido foi devido a uma atualização do jogo na qual uma chave de API foi inadvertidamente deixada de fora das chamadas de rastreamento para os servidores da Niantic.

Seja esse o caso ou não, tal gafe, de fato, quebraria as APIs. Mas o que eu sempre pensava era que, se eu não conseguia fazer login na minha conta PTC e jogar, por que eu podia mudar para minha conta Google e entrar no jogo tão fácil e rápido?

A conexão de autenticação da API

Bem, isso me fez vasculhar o GitHub e as APIs do Pokémon Go (eu prefiro Java , mas Python também está disponível, enlouqueça) e isso finalmente fez a luz do "aha" acender. Veja, quase todas as chamadas de API nesses repositórios lidam com a mesma exceção: LoginFailedException . 

Em outras palavras, até mesmo uma simples chamada para encontrar Pokémon próximos pode resultar em uma LoginFailedException .

O que não é nada surpreendente. Veja, aplicativos web monolíticos geralmente rastreiam usuários autenticados por meio de sessões, o que geralmente significa um cookie que contém um ID de sessão ou algum outro token que o aplicativo verifica antes de realmente fazer qualquer outra coisa (essa é uma arquitetura com estado , para quem está acompanhando). As APIs não são muito diferentes, pois cada chamada de API precisa ter uma maneira de garantir que o aplicativo que faz a chamada (o usuário) esteja realmente autorizado a fazer a chamada em primeiro lugar. Eles precisam estar “logados”.

Agora, as APIs geralmente usam chaves de API para conseguir isso. A chave geralmente é verificada em relação a um perfil de usuário para garantir que a chamada seja autorizada. Cada chamada (em uma arquitetura sem estado ). Há vários motivos para tal decisão, incluindo a capacidade de limitar a taxa de chamadas. O que é muito importante. Estado das APIs da Apigee 2016 O relatório observou que 68% das APIs estavam aproveitando o gerenciamento de cotas (que também é conhecido como limitação de taxa, medição, etc.). Para fazer esse truque técnico, é preciso primeiro saber quantas chamadas foram feitas no último minuto/hora/dia e, portanto, elas devem ser rastreadas em algum lugar seguro (para que os usuários não possam manipulá-las e enganar o aplicativo para permitir mais chamadas por período de tempo).

Em outras palavras, as APIs podem ser muito desgastantes para a infraestrutura de autenticação porque precisam verificar o status, a autorização e, potencialmente, aplicar limitação de taxa. Isso dá muito trabalho.

No entanto, nossas mentalidades de arquitetura de aplicativos, muitas vezes ainda tradicionais, não consideram o impacto dessas chamadas extras na capacidade. Essas chamadas extras para verificar e autorizar, mesmo que feitas periodicamente para “atualizar” uma sessão, colocarão um estresse considerável na infraestrutura de autenticação. A mesma infraestrutura de autenticação que dá suporte ao login. É o mesmo tipo de estresse que vimos quando as limitações do navegador em conexões por usuário foram aumentadas de 2 para 8. Um único usuário agora consumia 8x mais recursos para acessar um aplicativo. Da mesma forma, ao considerar as necessidades de capacidade de um aplicativo que depende de autorização por chamada de API, é preciso fazer algumas contas e descobrir quantos Xs a mais aquele usuário individual irá consumir.

Não fazer isso leva a, bem, crianças de 8 anos furiosas (e Loris também, por falar nisso) quando serviços de login sobrecarregados são o que está entre elas e aquele Pikachu que elas querem desesperadamente capturar.

Dimensionamento de ID e um fator crítico para disponibilidade

Identidade e acesso são serviços essenciais do aplicativo . Vimos sua importância aumentar em nossas pesquisas sobre o estado da entrega de aplicativos nos últimos dois anos e, sem revelar muito, já estamos vendo aumentos em nossos dados de 2017 para federação de identidade e controle de acesso a aplicativos. E não é só por causa dos aplicativos, é por causa das coisas também, e da crescente necessidade de escalar toda a infraestrutura de serviços de identidade para dar suporte a mais coisas, mais usuários, mais aplicativos usando APIs para interagir com aplicativos de back-end.

A disponibilidade geralmente é baseada apenas em uma medida de tempo de inatividade. Se os servidores estiverem funcionando corretamente, eles estarão disponíveis. É uma perspectiva de dentro para fora. Mas, assim como a segurança, precisamos inverter essa medição e vê-la de fora para dentro. A capacidade conta, e apenas estar “pronto” e “disponível” não é suficiente. Os serviços precisam estar “disponíveis” e “disponíveis” para todos que desejam consumi-los. Isso significa escalar tão rápido quanto seus scripts Python podem ser executados.

Isso também significa entender o relacionamento entre os vários serviços de back-end que realmente implementam a funcionalidade apresentada pelas suas APIs. Os serviços de identidade e acesso são tão essenciais para a disponibilidade quanto o próprio aplicativo. A disponibilidade, assim como a segurança, é tão boa quanto seu elo mais fraco. E se seus serviços de identidade não forem tão escaláveis (ou mais escaláveis se seu modelo for autenticação por chamada de API) quanto o restante do seu aplicativo, você descobrirá que a disponibilidade é um problema significativo, mesmo que todos os seus painéis mostrem "verde" por dentro.

Porque de fora, estamos vendo “vermelho”. Literalmente e figurativamente.