Tendances des coûts sans serveur

Le prix de l'exécution des fonctions sans serveur ne cesse de baisser. Ce n'est pas tout à fait une surprise.

Premièrement, et en général, les technologies de base de l'industrie informatique s'améliorent depuis des années (voir la loi de Moore).

Deuxièmement, le cloud computing est un marché concurrentiel avec de nombreuses offres ; les fournisseurs de cloud sont dans une course pour offrir les meilleurs prix/performances.

Troisièmement, et le plus important à long terme, les fournisseurs de cloud peuvent faire des choses en raison de l'échelle à laquelle ils opèrent. Par exemple, Amazon ou Microsoft ou Google peuvent se permettre de développer leurs propres processeurs adaptés pour bien fonctionner pour des environnements spécifiques tels que les instances Cloud (EC2) et les fonctions sans serveur.

Si nous prenons les améliorations récentes d'Amazon comme exemple, nous avons vu que :

1. Le prix des fonctions Serverless est désormais calculé avec une précision de 1ms au lieu de 100ms. Ainsi, si votre fonction typique consommait 50 ms, vous ne payez désormais que pour ces 50 ms au lieu d'un minimum de 100 ms. En supposant le même prix par ms, votre coût a été divisé par deux.
2. Encore plus récemment, Amazon a annoncé que vous pouvez exécuter des fonctions sans serveur sur le propre processeur d'Amazon, Graviton.

Selon Amazon voici comment procéder. on économise de l'argent :

1. Les fonctions s'exécutent plus efficacement grâce à l'architecture Graviton2.
2. Vous payez moins pour le temps qu'ils courent. Les fonctions Lambda optimisées par Graviton2 sont conçues pour offrir jusqu'à 19 % de meilleures performances à un coût inférieur de 20 %.

La bonne nouvelle pour les utilisateurs de Corticon.js est que les mêmes services de décision sans serveur peuvent désormais fonctionner avec des processeurs x86 ou Arm/Graviton2. sans modifications d'implémentation et sans avoir à régénérer les services de décision.

Comment configurer des fonctions nouvelles et existantes pour qu'elles s'exécutent sur des processeurs x86 ou Arm/Graviton2

Vous ajustez simplement le paramètre d'exécution de la fonction sans serveur. Cela peut être un peu déroutant, car vous pouvez rechercher ce paramètre dans l'onglet de configuration et ne pas le trouver. Dans la console, lorsque vous êtes sur la page principale de votre fonction Lambda, faites simplement défiler vers le bas jusqu'à ce que vous voyiez la section Paramètres d'exécution comme celle-ci :

Cliquez sur Modifier. À partir de là, vous pouvez basculer entre les deux architectures.

Bien sûr, cela aide les services de décision Corticon.js n'ont pas de dépendances à des architectures spécifiques au processeur, ce qui vous permet de basculer très facilement entre les architectures (aucune recompilation ou régénération du code des services ou aucun nouveau regroupement n'est nécessaire).

Futur

Eh bien, il est difficile de prédire l'avenir et comme l'a dit Neil Bohr, « La prédiction est très difficile, surtout s'il s'agit du futur ! » mais cela ne devrait pas nous empêcher de réfléchir et de spéculer un peu.

On peut se demander si la loi de Wright peut être appliquée aux fonctions sans serveur et aux instances EC2.

Note : Ici est un bon lecture sur la loi de Wright et ses différences avec la loi de Moore.

En bref, cette loi stipule que pour chaque doublement cumulé d'unités produites, les coûts chuteront d'un pourcentage constant.

La loi de Wright a fonctionné pour de nombreuses industries et a été jugé plus fiable pour prédire la baisse des coûts que la loi de Moore. Voir ici et ici.

Même si cette loi a été développée et observée dans l'espace de fabrication, elle s'applique peut-être également au Cloud computing. Amazon ou Microsoft ont-ils pu baisser leur prix d'un pourcentage constant pour chaque doublement d'instances ou de fonctions sans serveur qu'ils « fabriquent/instancient » ?

Ou peut-être qu'au lieu de compter les instances, nous devrions compter la capacité de calcul (comme la somme des TeraFlops dans toutes les instances de machines cloud disponibles ?).

 Ceux-ci sont difficiles, voire impossibles, à évaluer de l'extérieur, car nous ne connaissons pas la tarification interne ainsi que la capacité de calcul que les fournisseurs mettent en ligne. Le proxy le plus proche que nous puissions avoir est l'augmentation des revenus du fournisseur de cloud.

Par exemple, ceci montre un doublement tous les 2 à 3 ans, passant à tous les 3 à 4 ans. Et ceci montre un chiffre d'affaires mondial qui a doublé en un an (ou moins). Nous sommes donc toujours sur un marché en croissance assez rapide.

Tout cela peut nous assurer que nous devons nous attendre à ce que le prix des fonctions sans serveur continue de baisser, car la quantité globale de capacités de cloud computing déployées ne cesse d'augmenter.

De plus, il est concevable que les fournisseurs de cloud optimisent les piles utilisées pour exécuter des fonctions sans serveur et en particulier pour des langages comme Python et JavaScript étant donné leur popularité.

Qui sait, verrons-nous une nouvelle architecture CPU dédiée à ces langages et peut-être une nouvelle VM pour exécuter ces langages interprétés plus rapidement et consommer moins de mémoire ? Certes, l'incitation financière et la nécessité de se différencier sont là pour les fournisseurs de cloud.

Conclusion

Il est désormais moins cher d'exécuter les services de décision sans serveur Corticon.js dans AWS Lambda. Vous pouvez immédiatement essayer les services de décision déployés existants. Vous n'avez pas besoin d'apporter de modifications à l'un des services autres que de choisir l'architecture de processeur avec laquelle s'exécuter en tant que paramètre d'exécution. Le choix et la simplicité sont bons.

Faites-nous savoir si vous obtenez de meilleures performances ou des économies sur vos coûts d'exploitation. J'espère que vous obtenez les deux 😊.

En savoir plus sur Progress Corticon