o problema
Escalonar jobs é um problema com décadas de literatura, e quase toda ela foi escrita olhando para supercomputadores. A pergunta canônica é a de um centro de computação de alto desempenho: chegam jobs em lote, cada um pede um número de nós e um tempo de parede, e alguém decide a ordem da fila. Em cima dessa pergunta se construiu vocabulário, conferência e uma pilha de trabalhos comparáveis entre si.
Enquanto isso, a infraestrutura da web cresceu por outro caminho e por outro motivo. O resumo deste capítulo abre exatamente com essa constatação: datacenters e clusters da web podem ser maiores que os maiores supercomputadores do mundo, e rodam cargas pelo menos tão heterogêneas e complexas quanto as de hpc. E, ainda assim, pouco se sabe sobre os desafios de escalonamento específicos desses ambientes. O buraco não era de máquina nem de prática — as empresas já operavam esses clusters todo dia. O buraco era de registro público do problema.
a ideia
O movimento aqui é de enquadramento, não de invenção. Cirne e Frachtenberg tratam a infraestrutura web como um domínio de escalonamento por direito próprio, e não como um caso periférico do escalonamento de hpc que ficou grande demais. A consequência é metodológica: se o domínio é outro, as premissas herdadas da fila de supercomputador precisam ser reexaminadas uma a uma antes de serem reaproveitadas.
Comparar um datacenter da web a um supercomputador contando nós é como comparar uma cidade a um prédio contando pessoas — o número pode até bater, mas o que governa cada um dos dois é diferente. A analogia é minha, não dos autores; o que o resumo sustenta é a parte mais forte dela, que é a igualdade de escala convivendo com uma diferença de natureza.
O capítulo declara três entregas, nessa ordem: discutir os desafios de operar infraestrutura web, descrever várias técnicas para endereçá-los e apresentar os problemas que continuam em aberto no campo. É a forma de um texto de referência, e o veículo confirma: saiu em Lecture Notes in Computer Science, volume 7698, em 2013.
o que isso custou
O primeiro custo é o do gênero. Um levantamento não traz um sistema rodando nem uma tabela que diga que a técnica A ganha da técnica B sob a carga C. Quem procura evidência empírica para escolher entre alternativas não vai encontrar aqui a mesma coisa que encontraria num paper de sistema com medição em produção.
O segundo é declarado pelos próprios autores: parte do campo fica em aberto. O texto se propõe a melhorar a situação, não a encerrá-la. Um capítulo que termina listando problemas não resolvidos é honesto, e também é um aviso de que quem quiser resposta operacional vai precisar de outra fonte.
O terceiro é a data. Um mapa de desafios de 2013 é um mapa anterior à consolidação do vocabulário de contêineres e orquestração que hoje é padrão de mercado. Os desafios de fundo envelhecem devagar; a lista de técnicas disponíveis para atacá-los, não.
Vale registrar o limite deste verbete também: ele foi escrito a partir do resumo do capítulo. O resumo anuncia que há técnicas descritas, mas não nomeia nenhuma. Quem precisa saber quais são tem que abrir o original — e é justamente essa parte que o resumo não entrega de graça.
onde isso aparece hoje
A linhagem aqui é temática, não causal: o que veio depois não veio necessariamente por causa deste capítulo, mas ocupa o vazio que ele apontou. Dois anos mais tarde o Google publicou Large-scale cluster management at Google with Borg, que descreve um escalonador de cluster real em operação — exatamente o tipo de documento público que o resumo diz não existir em 2013.
No mesmo ano deste capítulo saiu The Tail at Scale, que trata de outro sintoma do mesmo ambiente: quando muita coisa divide a mesma máquina, o problema deixa de ser a média e passa a ser a cauda. E a descrição da máquina que criou esse mundo já estava em Web Search for a Planet: The Google Cluster Architecture, de 2003, dez anos antes de alguém sentar para escrever como se escalona em cima dela.