A maioria das categorias de produto nasce de alguém que acredita que existe mercado. Esta nasceu de alguém dizendo que não existia.

Fim de 1995: dez clientes no mundo

O LocalDirector foi concebido por John Mayes e Robert Andrews no fim de 1995, numa reunião pré-aquisição em que Andrews estava no papel de webmaster da Netscape. Andrews disse a Mayes que provavelmente havia dez clientes no mundo com um problema de balanceamento de carga.

Foi por causa dessa conversa que se decidiu começar o desenvolvimento. Não apesar dela: por causa dela. Eram dez clientes com um problema que ninguém mais tinha notado, exatamente no momento em que a web estava prestes a fazer todo site grande ter esse mesmo problema.

A Cisco entregou o LocalDirector ao primeiro cliente em abril de 1996, quatro meses depois do início do desenvolvimento, e chegou ao mercado um ano inteiro antes da F5 e da HydraWeb. O produto foi construído sobre a tecnologia de (network address translation) que a Cisco adquiriu junto com a Network Translation Inc, a mesma aquisição que deu origem ao firewall PIX, cujo código o LocalDirector compartilhava em grande parte. O primeiro produto de firewall e o primeiro load balancer (balanceador de carga) da Cisco vieram da mesma compra e compartilhavam o sistema operacional, o que mostra bem como as duas funções são próximas, na prática.

De 1996 a 1997: o concorrente sem dinheiro

A F5 Labs foi constituída em fevereiro de 1996 por Jeffrey Hussey, em Seattle, e começou a operar em abril. A empresa passou mais de um ano desenvolvendo antes de ter algo para vender: uma primeira tentativa fracassou, e foi preciso remontar a equipe e refazer o desenvolvimento. O BIG/ip chegou ao mercado em julho de 1997.

A receita do primeiro ano foi de 200 mil dólares. Os concorrentes eram a Cisco, na época uma empresa de cinco bilhões de dólares, e a Nortel, as duas com estruturas de distribuição e de marketing que a F5 não tinha como alcançar.

Mesmo assim, a F5 ganhou esse mercado, e o motivo é a lição mais aproveitável deste artigo. A Cisco chegou primeiro e nunca liderou a categoria: depois das aquisições, o desenvolvimento desacelerou, o produto seguinte ficou, na prática, congelado com os recursos que tinha no ano 2000, e uma empresa com todas as vantagens estruturais perdeu um mercado que ela mesma tinha inventado. Chegar primeiro é uma posição, não uma vantagem. O que rende, como juros compostos, é continuar desenvolvendo.

A F5 lançou o 3DNS Controller em setembro de 1998, para balancear entre vários sites, e não dentro de um só; mudou o nome para F5 Networks em abril de 1999; e abriu o capital em junho daquele ano, a dez dólares por ação.

A categoria e o efeito da troca de nome

No fim dos anos 1990, o mercado se encheu de concorrentes: a Alteon WebSystems, a Foundry com o ServerIron, a ArrowPoint, que virou o CSS da Cisco, a HydraWeb e, mais tarde, o NetScaler na Citrix e a Radware. Quase todas foram fundadas ou abriram o capital entre 1995 e 2000, e a maioria foi comprada na década seguinte.

Em algum momento dos anos 2000, o nome mudou de load balancer para application delivery controller (o ). A troca de nome foi em parte honesta e em parte não. Honesta porque o equipamento de fato acumulou funções: terminação de TLS, compressão, cache, reescrita de conteúdo, monitoração de saúde, persistência e, mais tarde, um web application firewall (). Não tão honesta porque a leitura cética se sustenta: chamar o equipamento de application delivery controller não muda o fato de que ele continua sendo, antes de tudo, um roteador que balanceia carga e um proxy reverso com health checks (as verificações de saúde), e os fundamentos do balanceamento nas camadas 4 e 7 pouco mudaram desde mais ou menos 2002.

As duas coisas são verdade. A função se estabilizou cedo; o que mudou foi a quantidade de coisas a mais penduradas no mesmo ponto do caminho.

Para que serve o equipamento, na prática

O algoritmo de balanceamento é a parte menos interessante, e é justamente nela que toda introdução ao assunto gasta mais tempo. Round robin, least connections, variantes com peso: a escolha entre eles raramente decide o resultado.

As partes que decidem o resultado são três:

Health check. O trabalho de verdade de um load balancer é saber quais membros estão em condições de atender. Um health check que só confirma que a porta responde vai continuar, todo contente, mandando usuários para um processo que aceita conexões e devolve erro, e é assim que um ambiente inteiro entrega falhas com todos os monitores verdes.

Persistência. Aplicações que guardam estado num servidor precisam que o mesmo usuário volte para esse servidor, e todo mecanismo para garantir isso (endereço de origem, cookie, identificador de sessão) é um meio-termo, cada um com o seu jeito de falhar. A persistência por endereço de origem desaba atrás de endereços compartilhados, e a persistência por cookie exige ler um tráfego que talvez você não consiga ler.

Estar no caminho. Todo o resto decorre do fato de o equipamento terminar as conexões. Ele consegue inspecionar, reescrever, fazer o offload da criptografia e aplicar políticas porque participa da conversa; e, exatamente pelo mesmo motivo, vira um gargalo, um ponto onde o tráfego fica em texto claro e um ponto único cuja falha é total.

Os cargos e as práticas

Essa família de produtos criou um especialista que fica entre duas tribos da empresa. O load balancer não pertence nem ao time de rede nem ao time de aplicação, e a função exige conhecer os dois lados: virtual servers, pools, monitors, profiles e persistência de um lado; do outro, como a aplicação guarda estado e o que o endpoint de health check dela prova de verdade.

Ela também criou um hábito de trabalho bem característico. Drenar em vez de desabilitar (tirar um membro do rodízio sem derrubar as sessões já estabelecidas) é uma disciplina que nasceu aqui e depois virou padrão nas ferramentas de deploy de todo lugar. A página de manutenção como um destino roteado, e não como uma mudança no servidor. E a eterna discussão operacional sobre o que um health monitor deveria testar, que no fundo é uma discussão sobre quanto a rede tem o direito de saber sobre a aplicação.

As empresas

O primeiro mercado era formado por Cisco, F5, Alteon, Foundry, ArrowPoint e HydraWeb. A consolidação levou a maioria delas: a Alteon foi para a Nortel e acabou na Radware, a Foundry foi para a Brocade, a ArrowPoint para a Cisco, e o NetScaler foi para a Citrix, onde hoje faz parte da unidade de negócios Citrix do Cloud Software Group.

Hoje, no topo do mercado corporativo, estão a F5 e a Citrix; ao lado, a Radware e a A10, os load balancers dos próprios provedores de nuvem e a linha (HAProxy, NGINX, Envoy), que já movimenta mais tráfego do que os fabricantes de appliance e não custa nada.

Para onde isso vai

A função se dissolveu na plataforma. Ingress controllers do , sidecars de service mesh e load balancers de nuvem fazem esse trabalho, configurados como parte do deploy da aplicação, e não pedidos a um time de rede. Em boa parte dos workloads novos, não há appliance nem conversa.

As partes difíceis não se dissolveram. Um health check que reflita de verdade se a aplicação está pronta, a persistência para aplicações que nem deveriam precisar dela e a drenagem sem trancos (graceful draining) são os mesmos problemas numa service mesh e num chassi, e continuam sendo a origem das quedas.

O equipamento está virando um ponto de aplicação de políticas. Onde o appliance continua existindo, ele sobrevive menos pelo balanceamento e mais pelo que consegue fazer por estar no caminho: terminar a criptografia, rodar um WAF, autenticar e ser o único lugar onde dá para ver o tráfego.

E o cético de 1995 errou na conta, mas apontou numa direção interessante. Não eram dez clientes com um problema de balanceamento de carga; com o tempo, passaram a ser todos. Mas a observação por trás disso continua de pé: o mercado era minúsculo no momento em que a decisão precisava ser tomada, e quem construiu mesmo assim fez isso com base numa avaliação de para onde a web estava indo, e não numa contagem de compradores.

Fontes