Como os contêineres mudam a escalabilidade

O termo "escala de nuvem" é frequentemente usado de forma leviana. É muito usado em marketing para sugerir uma escala REALMENTE GRANDE, em oposição à escala tradicional, que não é tão grande, mas ainda assim é significativa.

Mas assim como há núcleos de verdade escondidos em mitos e lendas, há alguma verdade na maneira como o termo "escala de nuvem" é usado.

A verdade é que a nuvem — e agora os contêineres — mudaram a base da escalabilidade. Essa mudança está enraizada nas diferenças fundamentais entre estratégias de escala vertical e horizontal. Durante a primeira década do século, operamos quase exclusivamente com a noção de que a escala vertical era a melhor maneira de atingir as velocidades e avanços de que precisávamos. Isso significava mais largura de banda, mais computação e mais memória. Mais portas. Maior densidade. Processamento mais rápido.

Mas com o advento da era da nuvem, o foco mudou para a escala horizontal. Ainda precisamos de mais largura de banda, capacidade de computação e processamento, mas aprendemos a distribuir essa necessidade. Ainda precisamos de mais hardware, apenas o montamos a partir de várias fontes, em vez de uma única entidade monolítica.

É a maneira como os recursos são reunidos que muda o jogo. E não se engane, o jogo mudou graças aos contêineres.

A escala hoje depende do plano de controle. A velocidade da API usada para iniciar e desativar recursos talvez seja mais importante do que a velocidade do próprio serviço de balanceamento de carga. A velocidade de descoberta de serviços em um ambiente onde os recursos são iniciados e desativados em questão de minutos se torna fundamental para entregar solicitações a uma instância disponível.

Mais da metade (52%) dos contêineres têm uma vida útil inferior a cinco minutos, de acordo com o Sysdig Container Usage Report 2019 : 

• 22% <= 10 segundos 
• 17% <= 1 minuto
• 15% <= 5 minutos

Quase metade (42%) opera entre 201 e 500 instâncias de contêiner. Para manter a precisão, o plano de controle atualiza os componentes com frequência. Com muito mais frequência do que na nuvem e certamente com muito mais frequência do que em qualquer aplicação monolítica.

A velocidade com que o controlador de entrada (o mecanismo de balanceamento de carga) é atualizado para refletir o conjunto atual de recursos disponíveis torna-se, então, um recurso crítico. Porque se estiver errado, uma solicitação do consumidor pode ser direcionada a um recurso que não existe mais — ou que está hospedando um serviço completamente diferente. De qualquer forma, o resultado é uma resposta mais longa, pois a solicitação é redirecionada para um recurso disponível. O consumidor deve esperar mais tempo por uma resposta e pode optar por ir embora.

Tudo isso aponta para a velocidade do plano de controle como um fator de bloqueio na escalabilidade de aplicativos implantados em um ambiente em contêiner.

Em última análise, isso significa que a escala do plano de controle é um problema. O design da API é um problema. Os mecanismos pelos quais solicitações e atualizações da API são autenticadas e autorizadas são um problema.

O plano de controle está no centro das atenções quando se trata de escalabilidade hoje. Um plano de controle robusto e escalável não é algo bom de se ter. É um RFC OBRIGATÓRIO hoje.