Cloud : le métier crée le coût, le réseau le propage

En découvrant le cloud public y a quelques années, j'ai rapidement été attiré par tous les problèmes autour des coûts engendrés par les choix métiers des clients, des stratégies de migration et des méthodes de développement.

Tous les clients des clouds, quelle que soit la taille de leurs entreprises, qu'ils aient démarré en cloud native ou aient migré sur un public cloud font part aujourd'hui de leurs incompréhensions en lisant leurs factures cloud qui listent les coûts opérationnels.

Plus on utilisera les services d'un provider et plus il y aura d'interconnexions entre ces services. Il sera alors extrêmement complexe de comprendre l'origine d'une augmentation de coût sur la partie opérationnelle.

Des SaaS spécialisés dans la gestion des coûts existent aujourd'hui par centaines. Ils mettent à disposition de leurs clients des métriques et statistiques de très hautes performances et précisions. Ils se basent essentiellement sur les APIs de coût des providers et d'algorithmes développés en interne pour proposer des alternatives aux dashboards des cloud public.

Aujourd'hui, ces SaaS permettent d'alerter les clients sur le "gaspillage" de ressources alloués inutilement, qui représente une majorité des coûts cloud. Mais aucun d'entre eux (pour en avoir fait le tour) n'est capable de remonter l'origine d'un coût. Un coût qui proviendrait par exemple du résultat d'une requête SQL non optimisée dans un microservice communiquant avec d'autres microservices sauvegardant le traitement de ces résultats dans un service de stockage. Ces SaaS remonteront alors que le service de stockage coûte cher mais aucun ne dira que c'est ce microservice en particulier qui est à l'origine du coût et quel niveau de coût il a engendré sur toute la chaîne d'appel. (Si vous en connaissez un, je veux bien en faire de la pub).

Il existe des outils permettant de remonter des métriques sur l'usage des ressources cloud (RAM, CPU, network I/O...) par des microservices mais sans croisements avec les coûts...

Ces 3 schémas résument cet exemple :

Cost per feature

Le concept de cost per feature est simple, il part du constat que le code source métier est l'initiateur du coût et le réseau sera celui qui va le propager.

"Si on peut comparer, c'est tout le défi des systèmes de santé dans le monde. Celui de pouvoir remonter la chaîne de transmission pour retrouver l'agent contaminant, pouvoir l'isoler et retrouver son lieu de contamination."

L'optimisation du coût doit donc se focaliser sur la fonctionnalité métier et qui mieux qu'un développeur pour s'en charger ?

Par contre, le cost per feature ne couvre que la phase d'exploitation d'une fonctionnalité. Le cycle de vie d'une fonctionnalité en comprend quatre étapes supplémentaires :

conception,
développement,
test,
exploitation,
maintenance.

Deux autres concepts à celui du cost per Feature sont à prendre en considération pour couvrir toutes les phases

Cost value

L'objectif de la cost value est tout simplement de challenger la business value d'une fonctionnalité. Il intervient à la phase de la conception de la fonctionnalité. De la rédaction du backlog à la sprint Review.

Cost test

L'objectif des cost tests est de s'assurer que le coût que créera la fonctionnalité ne dépassera pas les seuils qu'on aura déterminé ou fixé en entrée et en sortie. Il intervient lors des phases de développement / maintenance et de tests. On pourrait imaginer bloquer le déploiement de la fonctionnalité en production si les tests ne passent pas.

Conclusion

Ces trois concepts réunis pourraient nous permettre non seulement d'encourager le développement de fonctionnalités métiers très optimisées mais aussi de réduire les coûts en conséquence.

Les avantages sont nombreux. On pourra refacturer au centime prêt l'utilisation d'une fonctionnalité par un fournisseur qui consomme notre API. Être capable de connaître le coût d'une fonctionnalité sur toute la chaîne de consommation, même dans un environnement multicloud. Les achats pourront enfin calculer le gain ROI par rapport à leur investissement en budget cloud.

Je n'ai pas parlé de solutions implémentant ces trois concepts car ils n'en existent pas encore sur le marché. Cependant, je n'imagine pas d'implémentations simples si les fonctionnalités ne sont pas déployées dans des environnements isolés, dans un conteneur ou du serverless, car le besoin de contrôler l'entrée et sortie est nécessaire pour simuler le coût afin d'estimer la cost value, et les informations nécessaires pour écrire les cost test et calculer le coût engendré par une fonctionnalité métier.