La plupart des grands fournisseurs de cloud disposent de plateformes serverless qui offrent des fonctions en tant que service (FaaS). Certains benchmarks récents étudient les différences de performances vis-à-vis du temps d'exécution, des temps de démarrage à froid, des dépendances et de l'allocation des ressources.
AWS Lambda, les fonctions Google Cloud, les fonctions Azure et les fonctions IBM Cloud ont été les fournisseurs serverless testés par Bernd Strehl pour comparer leurs performances. Bien que ces tests, effectués à l'aide de fonctions en Node.js, révèlent certains éléments sur la manière dont ces fournisseurs répondent à des chargements de requêtes variables, la méthodologie de test a été critiquée pour sa taille réduite. Les tests effectués par d'autres équipes ont adopté une approche différente (PDF).
Les fournisseurs serverless facturent non seulement le processeur, la mémoire et le nombre de requêtes, mais également le réseau et le stockage. Les fournisseurs diffèrent dans la manière dont ils ajustent la mémoire pour des besoins spécifiques du processeur. AWS, par exemple, donne plus de cycles de CPU (PDF) aux instances avec plus de mémoire. Google suit une stratégie similaire, tandis que Azure varie dans la manière dont le processeur est alloué aux "machines virtuelles 4-vCPU qui ont tendance à gagner des parts de processeur plus élevées".
Les demandes simultanées modifient le temps de réponse moyen d'une fonction. Pour les demandes non concurrentes, l'allocation des ressources reste presque identique pour tous les fournisseurs, à l'exception de Google, où elle varie d'environ 30%. Le temps de calcul dans AWS a augmenté de 46% pour les demandes simultanées lorsque le même appel a été appelé 50 fois. Pour Google et Azure, il était respectivement de 7% et 3%, alors qu'il augmentait de 154% chez IBM. D'autres tests révèlent que AWS présente les meilleures performances en termes d'exécution simultanée.
Le temps de démarrage à froid est le temps nécessaire pour qu'une fonction serverless réponde à la première demande après avoir été inutilisée pendant un certain temps. Maintenir une performance constante est un défi pour tous ses fournisseurs en fonction des résultats. Un pool de workers (instances) non spécialisés, c'est-à-dire génériques, est maintenu en permanence par le fournisseur de cloud. La première demande entrante le configure pour cette demande et la sert. L'instance est maintenue en vie après la première demande. Cependant, le temps pendant lequel il continue à fonctionner varie d'un fournisseur à l'autre. Mikhail Shilkov, dans son article, mesure ceci comme 20 minutes pour Azure et des heures variables pour Google Cloud Functions. AWS le mentionne officiellement comme 5 minutes, mais en pratique, il est plus long en raison des modifications apportées par son équipe d'ingénieurs. Les démarrages à froid peuvent également se produire lorsque le service doit évoluer horizontalement et que de nouvelles instances doivent être mises en place.
Le choix de l'exécution a également un impact sur les performances. Les applications Node.js n'ont pas besoin de beaucoup de processeur pour démarrer, tandis que le runtime .NET Core nécessite plus de mémoire (dans AWS Lambda). Les temps de démarrage à froid diminuent avec une augmentation de la mémoire allouée. Pour Javascript, les tests révèlent que AWS est le plus rapide au démarrage à froid, suivi par GCP et Azure.