Após 2 anos de iteração em grande escala, aqui está tudo o que aprendemos sobre engenharia do Fluid. A propriedade mais desejável (mas aparentemente mais difícil de alcançar) de um sistema computacional é *desempenho eficiente e previsível em qualquer escala*. O Serverless, como pioneirizado pelo Lambda, teve um conjunto incomum de compensações. Ele tem o potencial para arranques a frio em produção, o que é inaceitável. O que é menos conhecido, no entanto, é que ele resolveu o ponto fraco dos servidores: vizinhos barulhentos, congestionamento e balanceamento de carga inadequado. Ele fez isso a um custo tremendo (1 "computador" por solicitação concorrente), mas foi glorioso. Às vezes, comparo isso a você e seu amigo saindo do trabalho para ir ao mesmo restaurante exato, na mesma hora, mas ambos pedindo Uber XLs. Você terá uma experiência incrível, mas é desperdício. Quando construímos o Fluid, queríamos ter o bolo e comê-lo também. Estou particularmente satisfeito com nosso algoritmo que usa 'cada assento disponível no carro' (ótimo para aplicativos de IA que esperam muito por tokens), mas ativa mais computadores horizontalmente conforme necessário. Isso é algo extremamente difícil de acertar, mesmo para equipes de DevOps experientes.
Vercel
Vercel29/07, 07:16
O Fluid torna possível enviar cargas de trabalho de IA e backend sem as armadilhas do serverless. Ele previne arranques a frio, adiciona suporte a streaming e computação pós-resposta, e melhora imensamente a eficiência de custos. Aqui está como o engenheiramos.
57,9K