A maioria das categorias de produto começa com alguém acreditando que há mercado. Esta começou com alguém dizendo que não havia.

Fim de 1995: dez clientes no mundo

O LocalDirector foi concebido por John Mayes e Robert Andrews no fim de 1995, durante uma reunião de pré-aquisição com Andrews na condição de webmaster da Netscape. Andrews disse a Mayes que existiam provavelmente dez clientes no mundo com problema de balanceamento de carga.

A decisão de começar o desenvolvimento foi tomada por causa daquela conversa. Não apesar dela - por causa dela. 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 aquele problema.

A Cisco entregou o LocalDirector ao primeiro cliente em abril de 1996, quatro meses depois de o desenvolvimento começar, chegando ao mercado um ano inteiro antes de F5 e HydraWeb. Ele foi construído sobre a tecnologia de tradução de endereços que a Cisco adquiriu com a Network Translation Inc - a mesma aquisição que produziu o firewall PIX, que rodava um derivado do sistema operacional Finesse do LocalDirector. O primeiro produto de firewall e o primeiro balanceador da Cisco vieram da mesma compra e dividiam um sistema operacional, o que é uma ilustração limpa de quão próximas as duas funções de fato são.

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. Passou mais de um ano construindo antes de ter o que vender, precisando reequipar o time e refazer o desenvolvimento depois de uma primeira tentativa fracassada, e levou o BIG/ip ao mercado em julho de 1997.

A receita do primeiro ano foi de 200 mil dólares. Os concorrentes eram a Cisco, então uma empresa de cinco bilhões, e a Nortel - as duas com organizações de distribuição e marketing que a F5 não tinha como se aproximar.

A F5 ganhou aquele mercado assim mesmo, e a razão é a lição mais reaproveitável deste artigo. A Cisco chegou primeiro e nunca liderou a categoria: depois das aquisições, o desenvolvimento desacelerou, o produto seguinte ficou congelado no conjunto de recursos do ano 2000, e uma empresa com toda vantagem estrutural perdeu um mercado que ela mesma inventou. Ser o primeiro é uma posição, e não uma vantagem. O que se acumula é continuar desenvolvendo.

A F5 acrescentou o 3DNS Controller em setembro de 1998, para balancear entre sítios em vez de dentro de um; virou F5 Networks em abril de 1999; e abriu capital em junho, a dez dólares por ação.

A categoria, e o que a renomeação fez

Ao longo do fim dos anos 1990 o campo encheu: Alteon WebSystems, Foundry com o ServerIron, ArrowPoint que virou o CSS da Cisco, HydraWeb, e depois NetScaler na Citrix e Radware. Quase todas foram fundadas ou abriram capital entre 1995 e 2000, e a maioria foi comprada na década seguinte.

Em algum ponto dos anos 2000 o termo mudou de balanceador para controlador de entrega de aplicação. A renomeação foi em parte honesta e em parte não. Honesta, porque a caixa de fato acumulou funções - terminação de TLS, compressão, cache, reescrita de conteúdo, monitoração de saúde, persistência e, por fim, firewall de aplicação web. Não honesta, porque a leitura cética se sustenta: chamar de controlador de entrega de aplicação não muda que aquilo continua sendo primariamente um roteador balanceador e proxy reverso com verificação de saúde, e os fundamentos de balanceamento nas camadas 4 e 7 quase não se moveram desde por volta de 2002.

As duas coisas são verdadeiras. A função se estabilizou cedo; o que mudou foi quanta coisa a mais foi pendurada no mesmo ponto do caminho.

Para que o equipamento serve, de fato

O algoritmo de balanceamento é a parte menos interessante, e a parte em que toda introdução gasta mais tempo. Rodízio, menos conexões, variantes ponderadas - a escolha entre eles raramente decide um desfecho.

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

Verificação de saúde. O trabalho real de um balanceador é saber quais membros conseguem atender. Uma verificação que só confirma que a porta responde vai alegremente continuar mandando usuários para um processo que aceita conexões e devolve erro, que é como um parque serve falhas com todos os monitores verdes.

Persistência. Aplicações que guardam estado num servidor precisam que o mesmo usuário volte para lá, e todo mecanismo para arranjar isso - endereço de origem, cookie, identificador de sessão - é um compromisso com o próprio modo de falha. A persistência por endereço de origem desaba atrás de endereços compartilhados, e a persistência por cookie exige ler tráfego que talvez você não possa ler.

Estar no caminho. Todo o resto decorre de o equipamento terminar conexões. Ele consegue inspecionar, reescrever, assumir a criptografia e aplicar política porque é parte da conversa - e vira gargalo, lugar de texto em claro e ponto único cuja falha é total, exatamente pela mesma razão.

Os cargos e as práticas

Esta família produziu um especialista que fica entre duas tribos organizacionais. O balanceador não pertence nem ao time de rede nem ao de aplicação, e conhecer os dois é o que o papel exige: servidores virtuais, pools, monitores, perfis e persistência de um lado; como a aplicação guarda estado e o que o endpoint de saúde dela de fato prova, do outro.

Ele também produziu um hábito de prática característico. Drenar em vez de desabilitar - tirar um membro do rodízio sem matar as sessões estabelecidas - é disciplina inventada aqui, que depois virou normal em ferramenta de implantação em toda parte. A página de manutenção como destino roteado, e não como mudança no servidor. E a discussão operacional permanente sobre o que um monitor de saúde deveria testar, que na verdade é uma discussão sobre quanto a rede tem direito de saber sobre a aplicação.

As empresas

O primeiro mercado foi Cisco, F5, Alteon, Foundry, ArrowPoint e HydraWeb. A consolidação levou quase todas: Alteon para a Nortel e depois para a Radware, Foundry para a Brocade, ArrowPoint para a Cisco, NetScaler para a Citrix e de novo para fora, como empresa própria.

Hoje são F5 e Citrix no topo do mercado corporativo, Radware e A10 ao lado, os balanceadores próprios dos provedores de nuvem, e a linhagem aberta - HAProxy, NGINX, Envoy -, que hoje move mais tráfego que os fabricantes de appliance e não custa nada.

Para onde vai

A função se dissolveu na plataforma. Controladores de entrada do , sidecars de malha de serviço e balanceadores de nuvem fazem esse trabalho, configurados como parte da implantação da aplicação em vez de solicitados a um time de rede. Para boa parte das cargas novas não há appliance nem conversa.

As partes difíceis não se dissolveram. Verificação de saúde que reflita de fato a prontidão da aplicação, persistência para aplicações que não deveriam precisar dela, e drenagem graciosa são os mesmos problemas numa malha e num chassi, e continuam sendo de onde vêm as quedas.

O equipamento está virando ponto de política. Onde o appliance permanece, ele sobrevive menos por balancear e mais pelo que consegue fazer estando no caminho: terminar criptografia, rodar firewall de aplicação web, autenticar, e ser o único lugar onde o tráfego pode ser visto.

E o cético de 1995 estava aritmeticamente errado e direcionalmente interessante. Não havia dez clientes com problema de balanceamento; no fim havia todos. Mas a observação por baixo se sustenta - o mercado era minúsculo no momento em que a decisão tinha de ser tomada, e quem construiu assim mesmo o fez por um julgamento sobre para onde a web ia, e não por uma contagem de compradores.

Fontes