Controladores de entrada: Novo nome, função familiar

Coloquialismos. Essas são palavras e frases que têm um significado exclusivamente local e que podem confundir aqueles que não são nativos da área. Por exemplo, quando estou fora de casa e com sede, procuro um borbulhador. Você provavelmente (imaginando que não seja um 'Sconnie) procura um bebedouro. Em Wisconsin, medimos distâncias pelo tempo, não por milhas. Os semáforos são luzes do tipo “pare e siga”. Porque é isso que você faz.

A frase favorita do meu marido (ele não é nativo) para rir é "Venha cá uma vez". Não tentarei explicar além do que faz sentido para mim e para as crianças com quem o uso. E entendemos inerentemente que “Up North” não é uma direção, mas um lugar cuja localização pode ser específica para o falante, mas carrega uma conotação comum a todos os nativos de Wisconsin que descrevem “aquele lugar para onde vamos para escapar de tudo”.

Você provavelmente tem sua própria lista, já que cresceu em outro lugar. Mas este é meu blog, então posso usar o meu.

O ponto hoje não é, no entanto, uma lição de semântica em si, mas mais sobre sua aplicabilidade a um fenômeno mais localizado, bem no seu quintal. Se o seu quintal fosse a sua organização, pelo menos.

O surgimento dos contêineres e seus sistemas de controle de agrupamento automatizados bastante necessários (frequentemente chamados de orquestração) teve a consequência não intencional de forçar coloquialismos de um lado da fronteira estadual para o outro. A propósito, isso é desenvolvimento de aplicativos em TI propriamente dito.

O curioso caso dos coloquialismos de contêineres

Muitas das funções necessárias para atingir a flexibilidade e a confiabilidade da escala exigida significaram a migração de certos serviços anteriormente somente de produção para o “ambiente” de contêiner. Essas funções estão ostensivamente "incorporadas" nesse ambiente agora, usando integração leve (APIs e enfileiramento de mensagens) para alcançar o que até então só poderia ser alcançado em um ambiente de computação em nuvem totalmente implementado: aplicativos de alta disponibilidade e dimensionamento automático.

Ao fazer isso, as funções de balanceamento de carga são nativas dos pods/nós por meio de pequenos serviços semelhantes a daemons. Embora não sejam muito avançados (estamos falando de capacidades um pouco acima do balanceamento de carga de rede), eles fazem o trabalho para o qual foram projetados. Esses serviços podem ser (e são) plugáveis, se preferir, permitindo outros projetos (de código aberto e fornecidos por fornecedores) que desbloqueiam recursos mais avançados (e, espera-se, algoritmos).

Mas, por si só, essas funções de balanceamento de carga não permitem a escala e a alta disponibilidade que buscamos (e precisamos, em ambientes de produção). Eles também não são capazes de rotear APIs – que exigem inteligência HTTP (L7). Precisamos disso se quisermos escalar com eficiência aplicativos modernos apoiados por microsserviços e liderados por fachadas de API. Precisamos de uma solução mais robusta.

É aí que os controladores de entrada entram em cena. Esses são os “balanceadores de carga” que dissecam e direcionam o tráfego de entrada com base em URIs e cabeçalhos HTTP para permitir o roteamento e a escalabilidade da camada de aplicação.

O que aconteceu é que os desenvolvedores que criaram (e posteriormente usam) controladores de entrada basicamente recriaram o que nós (em netops) chamaríamos de gerenciamento de tráfego, ou entrega de aplicativos, ou comutação/roteamento de conteúdo. Usamos muitos termos diferentes ao longo dos anos em netops, assim como em dev(ops). Roteamento de aplicativo e roteamento de página também são termos usados pelos desenvolvedores para descrever o roteamento L7. O conceito não é desconhecido para nenhum dos grupos. Mas os termos – os coloquialismos – são.

Um controlador de entrada é responsável por rotear solicitações para o serviço (virtual) apropriado dentro do cluster de contêineres. Esse serviço pode ser outro proxy de balanceamento de carga ou pode ser uma construção específica do sistema de contêiner. Em ambos os casos, a função do controlador de entrada é rotear o tráfego com base nos valores da camada 7 (HTTP) dentro dos cabeçalhos HTTP de uma solicitação HTTP. Normalmente, esse é o URI, mas pode ser o nome do host ou algum outro valor personalizado (como um número de versão ou chave de API).

Depois que o controlador de entrada extrai o valor do cabeçalho, ele usa políticas descritas pelos arquivos de recursos para determinar como distribuí-lo. Ele pode distribuir igualmente ou enviar 75% para uma versão do serviço e 25% para outra. É bem flexível dessa forma. O controlador de entrada também tem responsabilidades de monitoramento (saúde e status) e precisa ter muito cuidado para não distribuir uma solicitação para um serviço “inativo”.

Parece familiar, netops? Deveria, porque essas são basicamente as funções de um proxy inteligente (compatível com L7) (como o BIG-IP).

Agora que você sabe por que elas são iguais, deixe-me garantir que há algumas diferenças. Notavelmente, um controlador de entrada é configurado declarativamente. Ou seja, sua configuração é determinada por uma descrição em um arquivo de recurso fora do próprio controlador. Isso não é como os proxies inteligentes tradicionais que controlam e direcionam o tráfego de entrada. Proxies inteligentes tradicionais são fontes confiáveis do ambiente. Um controlador de entrada não é. Ele procura isso em outro lugar, em arquivos que atuam como uma espécie de “camada de abstração” que permite flexibilidade nas implementações. Isso significa que ele (ou um componente complementar) precisa lê-lo, interpretá-lo e criar a configuração apropriada para essa descrição. E tem que mantê-lo atualizado. Embora a variabilidade no controle de entrada de um ambiente em contêiner seja menor do que a mais profunda no sistema, ela ainda muda e precisa ser observada.

Quando tudo estiver dito e feito, o controlador de entrada será responsável pelo roteamento da camada de aplicação de solicitações de fora para o recurso apropriado dentro do ambiente em contêiner. O que é praticamente a definição de um balanceador de carga inteligente.

O nome pode ter mudado, mas as funções permanecem praticamente as mesmas.