Mais pourquoi diable la facture de notre fournisseur cloud explose chaque mois alors que les prix qu’il annonce sont si bas ? Nos confrères d’IDG apportent sept réponses à cette question.
Prix cachés, frais généraux, de migration, etc. Nombre d’aspects du cloud peuvent très vite faire grimper la facture. (Crédit : Christopher Alzati / Pixabay)
Y a-t-il quelque chose de plus attrayant que les tarifications du cloud ? Peu d’entre nous sont aujourd’hui assez âgés pour se souvenir d’avoir payé un bonbon à un centime, mais les utilisateurs du cloud bénéficient eux de prix encore plus dérisoires. Le prix de la machine standard N1 de Google est de 0,0475$ de l’heure (0,0421€), mais vous pouvez l’obtenir pour seulement 0,01$ de l’heure pour des besoins de traitement par lots. Les plus dépensiers peuvent passer à la version à processeur pour 0,015 $ de l’heure.
Azure lui fait ses calculs au gigaoctet consommé, avec un prix ridicule de 0,00069€ par gigaoctet pour stocker des données pendant un mois dans son niveau Stockage archive. C’est Amazon, cependant, qui offre les prix les plus bas en facturant un montant infinitésimal de 0,0000002083$ pour 128 Mo de mémoire pour exécuter du code sur Lambda. Ces chiffres sont déconcertants. Les factures d’assurance automobile et immobilier écrasent peut-être le budget, mais quand il s’agit de cloud, il serait presque plaisant de jeter de l’argent par les fenêtres comme des confettis. Parce que justement le prix de ces services cloud est littéralement inférieur au coût d’un bout de confetti… Puis vient la fin du mois, et finalement la facture du fournisseur cloud s’approche de celles qu’ont envoyées les assureurs… Comment ces fractions de centimes s’additionnent-elles si rapidement ? Nos confrères d’IDG ont mis en lumière sept secrets du cloud qui montrent pourquoi des tarifs si bas creusent finalement beaucoup un budget informatique.
Les petits extras cachés
Parfois, les spectacles les plus grandioses sont menés par les figurants qu’on ne remarque pas. Le Glacier S3 d’Amazon possède un niveau « Deep Archive » conçu pour les sauvegardes à long terme, dont le prix est séduisant : 0,00099$ par gigaoctet, soit 1$ par téraoctet par mois. Il est facile d’imaginer de mettre à la poubelle les bandes de sauvegarde pour passer à la simplicité du service d’Amazon. Mais supposons que vous vouliez vraiment examiner ces données. En cliquant sur un deuxième onglet de la feuille de prix, le coût de la récupération s’élève à 0,02$ par gigaoctet. Il est donc 20 fois plus cher de consulter les données que de les stocker pendant un mois. Si un restaurant utilisait ce modèle de tarification, il ferait payer 2€ pour le plat commandé, mais 40 pour les couverts. Ramené aux réalités de la sauvegarde, cette grille reste sensée puisque le produit a été conçu pour permettre un stockage à long terme et non une simple navigation. Pour un accès fréquent aux contenus stockés, il est préférable de souscrire au niveau S3 normal. Mais si l’objectif est d’économiser sur le stockage des archives, il faut comprendre ces coûts secondaires et les planifier à l’avance.
La localisation est importante
Les fournisseurs cloud nous mettent des paillettes dans les yeux avec des planisphères montrant leurs datacenters dans le monde entier, et invitant à placer ses charges de travail là où cela est le plus pratique et sûr. Mais les prix ne sont pas toujours les mêmes. Amazon peut facturer 0,00099$ par gigaoctet dans l’Ohio, mais c’est 0,002$/Go en Californie du Nord. En France, on tombe à 0,0018$/Go au mois. Est-ce à cause du climat ? La proximité de la plage ? Ou simplement le coût de l’immobilier ? Le secret reste ici gardé. Alibaba, de son côté, veut clairement encourager les développeurs à utiliser son cloud dans ses datacenters du monde entier. Les instances bas de gamme commencent à seulement 2,5$ par mois en dehors de la Chine, passent à 7$ par mois à Hong Kong et à 15$ par mois en Chine continentale.
Attention aux transferts des données
Le problème en examinant ces listes de prix et en déplaçant les charges de travail vers les datacenters les moins chers, c’est que les sociétés de cloud computing font également payer ces transferts de données. Ainsi, en faisant des migrations pour faire une estimation des coûts dans tous les sites du fournisseur à la recherche du calcul et du stockage les moins chers, les factures risquent en fait de grimper en flèche. Car les coûts de circulation des données sur le réseau sont étonnamment élevés. Un giga occasionnel ne fera pas trop la différence, mais ce peut être une grosse erreur de reproduire une base de données fréquemment mise à jour à travers le pays toutes les millisecondes, juste parce qu’un tremblement de terre ou un ouragan peut se produire.
La nasse à souris
Ce genre de piège consiste à appâter une souris dans une boite qui se referme une fois que le rongeur a attrapé le bout de fromage, de manière à l’emprisonner sans la tuer. Les utilisateurs d’infrastructures cloud peuvent ressentir la même chose au moment de migrer leurs données. Souvent, les fournisseurs de cloud computing ne font pas payer pour importer des données dans leur système. Dans la vie quotidienne, un magasin ferait-il payer un client à l’entrée ? Mais lorsqu’il s’agit de s’en aller, la facture devient tout de suite infiniment plus élevée.
L’erreur du coût irrécupérable
Il y a toujours un moment où la machine ou une configuration a du mal à fonctionner. Mais en mode cloud, il n’y a qu’à mettre la puissance de calcul à l’échelle et tout ira mieux. Et ceci, seulement pour quelques centimes de plus par heure. Sur une facture déjà à plusieurs dollars de l’heure, on se dit que quelques centimes supplémentaires ne vont pas changer grand-chose. Et les fournisseurs facilitent beaucoup cette transition, en un clic tout est prêt. Les casinos ont la même stratégie pour pousser les joueurs à mettre la main au portefeuille. Mais pour les comptables, ce comportement est une erreur de coûts irrécupérables. C’est-à-dire jeter l’argent par les fenêtres tout simplement. Si l’argent déjà dépensé est quelque chose qui ne reviendra jamais, les prochaines dépenses peuvent, elles, être contrôlées.
C’est cependant un peu différent quand on parle du développement d’un logiciel. Souvent, on ne sait pas la quantité de mémoire ou de CPU qui sera nécessaire à une fonctionnalité. Il faudra augmenter la puissance des machines de temps en temps. Le véritable défi consiste à garder un œil sur le budget et à maîtriser les coûts en cours de route. Il suffit d’ajouter un peu plus de CPU ici ou de mémoire là pour qu’en fin de mois, la facture explose.
Merci les frais généraux
Une machine cloud n’est pas une machine en soi, mais une partie d’une machine physique plus grande qui a été divisée en N portions. Ces tranches, cependant, ne sont pas assez puissantes pour supporter la charge à elles seules, alors il faut déployer des outils comme Kubernetes pour faire fonctionner N portions ensemble. Pourquoi alors découper une grosse boîte en N morceaux juste pour la recoudre ? Pourquoi ne pas se contenter d’une seule machine pour manipuler une seule charge ? Les évangélistes du cloud diront que les personnes qui posent des questions impertinentes comme celles-là ne bénéficient pas des avantages du cloud. Toutes les couches supplémentaires et les copies supplémentaires du système d’exploitation apportent beaucoup de redondance et de flexibilité. Nous devrions être reconnaissants que toutes ces instances se mettent en marche et s’arrêtent dans une danse élaborée et orchestrée.
Mais la facilité de récupération avec Kubernetes encourage une programmation bâclée. Une panne de nœud n’est pas un problème car le pod continuera à naviguer lorsque Kubernetes remplacera l’instance. Les frais généraux sont donc un peu plus chers pour maintenir les couches supplémentaires, afin de pouvoir démarrer une machine propre et fraîche sans problème impromptu.
Vers l’infini et au-delà ?
En fin de compte, le problème délicat du cloud computing est que sa meilleure caractéristique est aussi sa plus dangereuse. Sa capacité à s’adapter à toute demande soi-disant à l’infini est aussi un champ de mines financier. Chaque utilisateur va-t-il disposer en moyenne de 10 gigaoctets de sortie ou de 20 Go ? Chaque serveur aura-t-il besoin de 2 ou 4 Go de mémoire vive ? Au lancement d’un projet, c’est impossible à savoir. La stratégie traditionnelle consiste à acheter un nombre fixe de serveurs mais elle devient moins simple à maintenir lorsque la demande augmente, mais au moins les coûts budgétaires ne montent pas en flèche. Les ingénieurs côté serveurs se plaindront de la surcharge et les utilisateurs de la lenteur de réponse, mais l’équipe comptabilité ne fera pas une attaque en fin de mois.
Car si personne ne remarquera quand les coûts baissent, lorsque le compteur commence à tourner à plein régime, il est probable que le patron commence à faire plus attention à ce que lui coûte son infrastructure informatique. Finalement, le problème de fond c’est que nos comptes bancaires ne sont pas aussi extensibles que le cloud.