Après 2 ans d'itération à grande échelle, voici tout ce que nous avons appris sur l'ingénierie de Fluid. La propriété la plus désirable (mais apparemment la plus difficile à atteindre) d'un système informatique est *une performance efficace et prévisible à n'importe quelle échelle*. Le serverless, tel que pionnier par Lambda, avait un ensemble inhabituel de compromis. Il a le potentiel de démarrages à froid en production, ce qui est inacceptable. Ce qui est moins connu, c'est qu'il a résolu le talon d'Achille des serveurs : les voisins bruyants, la congestion et l'équilibrage de charge inadéquat. Il l'a fait à un coût énorme (1 "ordinateur" par requête concurrente), mais c'était glorieux. Je compare parfois cela à vous et votre ami qui quittez le travail pour aller au même restaurant exact, au même moment, mais vous commandez tous les deux des Uber XL. Vous aurez une expérience incroyable, mais c'est du gaspillage. Lorsque nous avons construit Fluid, nous voulions avoir le beurre et l'argent du beurre. Je suis particulièrement satisfait de notre algorithme qui utilise 'chaque siège disponible dans la voiture' (idéal pour les applications d'IA qui attendent beaucoup de jetons), mais qui fait tourner plus d'ordinateurs horizontalement au besoin. C'est quelque chose de très difficile à bien faire, même pour des équipes DevOps expérimentées.