Comment anticiper les coûts sur un cloud public

Comment anticiper les coûts sur un cloud public Face à la complexité des grilles tarifaires des fournisseurs, prévoir le budget pour faire tourner une application dans le cloud peut sembler insurmontable. Mais ce n'est pas impossible.

AWS, Google Cloud Platform, IBM Bluemix, Microsoft Azure... Les grands fournisseurs de cloud ne cessent d'enrichir leurs offres tous azimuts. Ils multiplient les services dans l'infrastructure, le réseau, le big data, l'intelligence artificielle, la sécurité, etc. Cette montée en puissance est naturellement bénéfique pour les entreprises pour qui le cloud n'est aujourd'hui plus une option mais bien une nécessité dans un contexte de transformation digitale. Revers de la médaille : les grilles tarifaires des acteurs deviennent de plus en plus complexes à appréhender... Avec comme conséquence de rendre ardu l'exercice de la prévision des coûts.

"Chaque type de service cloud renvoie à un mode de pricing différent : machine virtuelle, stockage, base de données, CDN (pour Content Delivery Network, ndlr)... Il faut par conséquent être capable d'appréhender de multiples dimensions dans la prévision financière. Sans compter les règles de calcul spécifiques à chaque fournisseur", confirme Franck Greverie, cloud & cyber security group leader au sein de l'ESN Capgemini.

Une matrice de calcul à 4 paramètres

Anticiper le coût d'une mise en production (ou "run" en anglais) sur un cloud public peut ainsi s'avérer extrêmement délicat. Chez Capgemini, une matrice d'analyse a été définie pour relever ce défi. "L'évaluation de la dépense s'effectue selon quatre grands paramètres : l'architecture à mettre en place en termes d'infrastructure et de services cloud, l'usage de l'application cible, les services managés à intégrer, et, enfin, le mode de contractualisation", résume Franck Greverie (voir le détail dans le tableau).

Matrice d’évaluation du coût de mise en production d’une application sur un cloud public
Paramètre Détail Coûts
1. Architecture de l'application Nombre de VM nécessaires, et services cloud à déployer en fonction du projet (DNS, répartiteur, base, CDN...) ..........
2. Usage de l'application Ressources de calcul, de stockage et transit réseau à prévoir d'acheter pour amortir le trafic anticipé. ..........
3. Services managés Services de monitoring à mettre en oeuvre pour contrôler la conformité des engagements de service du cloud. ..........
4. Mode de contractualisation Tarif de base, mode de contractualisation sur 1, 2 ou 3 ans (avec prix dégressifs), achat de surcapacités... ..........
Total   ..........

Et Pascal Deshayes, directeur de l'entité cloud de l'ESN Devoteam, d'insister : "il est important d'avoir en tête que différents modes de contractualisation sont envisageables. En réservant par exemple des ressources sur une période de trois ans, il est possible sur certains clouds de réaliser jusqu'à 50% d'économies." Naturellement, le choix du scénario contractuel dépendra de la durée de vie de l'application et de la capacité à réaliser des prédictions quant au trafic attendu.

"Certains clouds proposent des configurateurs pour évaluer le prix d'une architecture" (Pascal Deshayes - Devoteam)

Existe-t-il des outils pour aider à réaliser ce travail d'évaluation ? "Certains clouds mettent à disposition des configurateurs permettant de calculer le prix d'une architecture en fonction des ressources retenues : CPU, RAM, stockage... Ces dispositifs fournissent un premier niveau d'indicateur", pointe Pascal Deshayes. Des éditeurs tiers proposent également des applications conçues pour comparer les coûts d'une configuration sur différents clouds publics. C'est notamment le cas de l'Américain Turbonomic ou du Français CloudScreener.

"Chez Capgemini, nous avons fait le choix de la solution Cloud Cruiser pour accompagner nos clients dans le pilotage de leurs coûts sur le cloud public. Elle permet de suivre les ressources et services consommés par une application chez tel ou tel fournisseur. Grâce à cet outil, nous sommes à même de faire des préconisations d'optimisation pour des applications en production sur AWS, Microsoft Azure ou Google Cloud Platform", explique Franck Greverie. Puis il précise : "Si une application ou un composant n'est utilisé que la journée, nous pouvons typiquement conseiller d'éteindre les machines virtuelles sous-jacentes la nuit, et les redémarrer le matin pour réduire les dépenses."