o problema
Um datacenter com dezenas de milhares de máquinas parece um recurso único, mas na prática se fragmenta. Cada time quer previsibilidade, então cada time quer suas máquinas: um bloco para o serviço de busca, outro para o pipeline de log, outro para o time que ainda não sabe quanto vai precisar. O resultado é uma frota inteira com ilhas ociosas ao lado de ilhas saturadas, e ninguém consegue emprestar capacidade de uma para a outra porque a fronteira é administrativa, não técnica.
Junte a isso o descompasso entre o que se pede e o que se usa. Quem dimensiona um serviço pede o pico, com folga, e roda no vale a maior parte do dia. Quem roda batch aceita esperar mas quer tudo que sobrar. As duas cargas se odeiam na mesma máquina: uma tem latência a defender, a outra tem throughput a maximizar. Sem alguém para arbitrar isso, a saída fácil é separar — e pagar a separação em máquinas paradas. Borg é a resposta do Google a esse problema, com dez anos de operação em cima quando o paper saiu, em 2015.
a ideia
Tratar o cluster como um pool único e mudar o que o usuário diz. Em vez de “coloque este binário nesta máquina”, o usuário escreve uma especificação declarativa do job: o que ele é, quantas tarefas, o que cada uma precisa. Onde isso roda é decisão do Borg, e pode mudar. O sistema ainda integra name service, monitoramento em tempo real e ferramentas para analisar e simular o comportamento do próprio escalonador.
Com o controle da colocação nas mãos do gerenciador, a utilização vira um problema de política, e o resumo lista quatro alavancas que agem juntas: admission control decide o que entra, o empacotamento eficiente de tarefas decide como cabe, o over-commitment reconhece que o que foi pedido não é o que será usado, e o compartilhamento de máquina põe cargas diferentes lado a lado, com isolamento de performance em nível de processo segurando o estrago.
A mesma alavanca serve para disponibilidade. Se o Borg escolhe onde as tarefas ficam, ele pode escolher de modo que réplicas do mesmo job não caiam juntas — política de escalonamento que reduz a probabilidade de falha correlacionada — e pode oferecer recursos de runtime que encurtam o tempo de recuperação quando a falha acontece. Alta disponibilidade deixa de ser algo que cada aplicação improvisa e vira uma propriedade que a plataforma oferece.
o que isso custou
Over-commitment é uma aposta: prometer mais recurso do que existe só funciona enquanto os jobs não cobrarem tudo ao mesmo tempo. Quando cobram, alguém é sacrificado, e o isolamento em nível de processo é mais fraco que uma fronteira de máquina virtual — divide CPU e memória razoavelmente bem, divide cache e banda de memória com muito mais dificuldade. É a troca explícita do Borg: overhead baixo em vez de isolamento hermético.
Admission control tem o outro lado óbvio: para o cluster manter utilização alta, ele precisa ter o direito de dizer não, ou de fazer esperar. E um gerenciador central que decide a colocação de tudo vira dependência crítica de todo mundo — o tipo de componente cuja indisponibilidade não tem plano B. A linguagem declarativa, por sua vez, é um contrato: uma vez que milhares de aplicações a escrevem, mudá-la fica caro.
Este verbete foi escrito a partir do resumo do paper. O resumo anuncia análise quantitativa das decisões de política e um exame qualitativo das lições de uma década de operação, mas não as apresenta — as limitações que os autores declaram estão no texto completo, não aqui. Os números, a arquitetura e os experimentos ficam de fora deste verbete de propósito.
onde isso aparece hoje
O modelo declarativo de job, a alocação decidida pela plataforma e o espalhamento de réplicas como política são a herança direta do Borg no Kubernetes, que nasceu dessa linhagem — fato público e assumido pelo próprio Google. A ideia de que você descreve o estado desejado e o cluster converge para ele veio daqui.
A camada também explica o resto da pilha do Google: frameworks de processamento como MapReduce supõem um pool de máquinas onde tarefas aparecem, morrem e são recolocadas sem intervenção humana, e a frota de máquinas comuns descrita em Web Search for a Planet só é utilizável com um gerente desse tipo em cima.
A escolha de isolamento é o ponto onde a indústria divergiu depois. Para carga multi-tenant de terceiros, isolamento em processo não basta, e a resposta foi voltar à máquina virtual com custo de inicialização baixo — o caminho do Firecracker.