Le sujet de la “transparence” des tarifs pratiqués par les plates-formes d’hébergement cloud avait déjà été abordé dans le cadre de nos précédents articles sur les enseignements à tirer de l’incident qui, en début d’année, avait privé de nombreux clients d’OVH de leurs données, de l’accès à leur site, voire de leurs données – pour un temps limité ou, malheureusement pour certains d’entre eux, de manière définitive. Relire notre article “Incident OVH de début d’année: comment éviter que cela vous arrive?”.

Le problème? Un manque de transparence dans la formulation de certains contrats, dans l’explication des tarifs (réellement) appliqués et des services qu’ils impliquent.

C’est là problème qui dépasse largement le seul contexte de l’hébergement et de la disponibilité de sites Internet. L’engouement pour le cloud, les solutions “as a service” et la virtualisation/déportation des infrastructures fait évidemment les choux gras des plates-formes et prestataires de services cloud. Certaines pratiques sont de véritables pièges pour les sociétés qui misent sur le cloud pour leur procurer puissance de calcul et espaces de stockage pour des utilisations intensives – comme c’est le cas, par exemple, pour de l’analytique complexe ou des projets de data science.

Le manque de transparence, la variabilité des tarifications que pratiquent certains, parfois jusqu’au paroxysme pour rentabiliser les services offerts et créer un effet de lock-in, a inspiré l’article qui suit à Frank Vanden Berghen, directeur général de The TIMi Company. Véritable “os à ronger” qui ne peut que pousser à la réflexion…

L’art de la variabilité

Comment est-il possible que des géants de l’informatique, tels qu’Amazon ou Microsoft Azure, puissent encore en 2021 appliquer une tarification tellement opaque qu’il est nécessaire d’employer des solutions tierces pour contrôler le « coût du cloud« ? La demande pour une plus grande transparence est pourtant énorme. Pour preuve, une recherche rapide sur Google sur les termes « manage cloud cost » retourne 983 millions de résultats !

Dans le contexte de projets de type data science (la spécialité de TIMi), ces coûts explosent littéralement dès que vous passez en production. En effet, il n’est pas rare de faire un petit POC pour un coût cloud de quelques milliers d’euros. Mais, ensuite, lorsqu’on passe en production sur une volumétrie réelle, les coûts grimpent sans surprise rapidement à 300.000 euros ou 500.000 euros (car la data science implique presque systématiquement des volumétries importantes). 

Fausses promesses et vrais coûts

Au cours de ces quelques dernières années, les coûts horaires des machines cloud ont gagné en transparence. On appréciera en particulier les grilles de prix mensuels donnés pour une machine avec des caractéristiques hardware précises.

Les grilles de prix qui sont par contre à éviter sont les prix “par minutes/par heure/par jour”. Les consultants “innocents” commencent toujours par expliquer que les machines qu’ils utilisent resteront éteintes pendant la nuit et que donc, aucun coût, ne sera payé pour les heures nocturnes. En pratique, ces arguments sont faux 99% du temps.

En effet, en data science, les machines qui manipulent des données (les bases de données ou les clusters Hadoop/Spark) ne peuvent pas être facilement “éteintes” sans risquer une perte possible (et presque certaine dans le cas de Hadoop/Spark) des données qui y sont stockées (seule exception à cette règle: … TIMi).

Aucun gestionnaire de service informatique ne prendra le risque important d’une perte de données et il faut tabler sur le fait que ces machines resteront allumées en permanence.

Beaucoup d’adeptes du cloud se polarisent sur les coûts horaires des machines cloud. Grâce au jeu de la concurrence, ces coûts ont bien chuté ces dernières années, même si on n’explique pas encore les différences de prix, qui vont du simple au triple (voir au quadruple) pour le même serveur entre OVH et Amazon… Plus de détails à ce sujet ici. 

Bizarrement, personne ne s’intéresse au coût de la bande passante, qui est tarifée à un coût exorbitant chez Amazon.

L’objectif de ces coûts élevés est évidemment de vous imposer un lock-in artificiel car il vous sera impossible (ou alors très, très coûteux) d’utiliser une infrastructure cloud qui est répartie entre plusieurs prestataires, à cause des coûts de transferts des données (c’est-à-dire des coûts de bande passante) entre prestataires qui sont prohibitifs. 

Pour vous donner une idée du coût de la bande passante chez Amazon, mon expérience personnelle est qu’un petit serveur à 70 euros par mois qui héberge une petite base de données PostgreSQL coûtera typiquement plus de 230 euros par mois en bande passante (pour un total de plus de 300 euros par mois) pour un projet data science qui en est encore à ses débuts.

De plus, ce coût est condamné à augmenter exponentiellement quand vous passez en production. Le prix de la bande passante n’est donc vraiment pas négligeable (il multiple votre estimation de prix par 4) et il est donc important d’en tenir compte dans vos analyses. La politique de prix de Amazon relative à la bande passante est tellement obscure que je connais personnellement plusieurs toutes petites sociétés qui se sont laissées “surprendre” par des factures mensuelles inattendues de plusieurs dizaines de milliers d’euros.

Frank Vanden Berghen (The TIMi Company): “Le prix de la bande passante n’est donc vraiment pas négligeable (il multiple votre estimation de prix par 4) et il est donc important d’en tenir compte dans vos analyses.”

De ce point de vue, il est donc conseillé de favoriser une solution plus “transparente”, comme OVH ou Hetzner, qui n’impose pas de coût lié à la bande passante (la bande passante est typiquement illimitée chez OVH et Hetzner).

Les politiques de prix de Amazon/Azure sont tellement obscures que je connais personnellement quatre start-ups qui ont coulé juste parce que leur facture Amazon était trop élevée. Les fondateurs de ces start-ups ont re-vendu jusqu’aux moindres meubles de leur maison ou de leur appartement pour pouvoir continuer à payer Amazon, sans succès. D’autres start-ups, plus chanceuses, sont passées près de la faillite à de nombreuses reprises avant de pouvoir trouver les ressources pour effectuer une migration vers une autre infrastructure.
Le gros problème ici est la grille de prix de Amazon/Azure qui impose des prix variables. Cette grille a été pensée et conçue de façon à ce qu’elle soit (1) pratiquement incompréhensible et (2) qu’il soit pratiquement impossible de contrôler les coûts. L’objectif est, bien sûr, de vous « pousser à l’erreur » pour pouvoir, en toute impunité, vous envoyer une lourde facture pratiquement incontestable.

Notre conseil est de favoriser un prix mensuel fixe, comme pour le serveur « Game 2 » de OVH ou le serveur AX101 de Hetzner.

Effets pervers des coûts variables 

Dans le domaine de la data science, en plus des douleurs accusées par votre porte-monnaie, les coûts variables ont un second effet pervers moins flagrant.

Je fais ici référence aux « offres cloud » utilisées pour faire de la data science. En effet, une propriété inhérente à ces offres est le coût variable lié à chaque question analytique. En fait, cette propriété est même le Key Selling Point des offres cloud: “Vous ne payez que ce que vous utilisez”. 

Un data scientist motivé sera à l’origine de coûts variables très élevés car il fera un usage intensif du “cluster cloud” pour essayer de comprendre au mieux les données et d’y trouver la perle rare.

Au contraire, un data scientist « proche de la retraite » et/ou moins motivé occasionnera des coûts variables bien moins importants. Il n’est pas rare à la fin du mois que le data scientist motivé soit réprimandé par le directeur financier tandis que le data scientist « proche de la retraite » sera félicité pour son “usage parcimonieux” du cluster cloud.

Comme c’est une situation qui arrive tout le temps, il existe maintenant une pléthore d’outils spécialisés de monitoring du cloud qui permettent de sanctionner et de couper l’accès aux ressources de calculs à tous les data scientists un tant soit peu motivés. Dans ces conditions, on comprendra tout de suite que garder la motivation des data scientists risque d’être difficile…

En résumé, un outil cloud de data science qui fonctionne en « coût variable » a pour effet de pénaliser, réprimander, décourager et finalement empêcher vos meilleurs éléments de travailler.

Frank Vanden Berghen (The TIMi Company): “Il existe maintenant une pléthore d’outils spécialisés de monitoring du cloud qui permettent de sanctionner et de couper l’accès aux ressources de calculs à tous les data scientists un tant soit peu motivés.”

Éviter une situation de lock-in

Si vous êtes en lock-in dans une technologie, le vendeur de cette technologie est dans une situation telle qu’il peut vous imposer n’importe quel prix (et en particulier les plus élevés). 

Certains choix technologiques sont peu importants. Par exemple, le choix du fournisseur de votre plate-forme de gestion d’email est de peu d’importance. Au contraire, le choix du fournisseur pour votre plate-forme de gestion des données est cruciale pour la survie de votre société.

Crédit: Steve Buissine

En effet, il n’y a aucun effet de lock-in possible auprès d’une plate-forme de gestion d’e-mail. Plus précisément, il n’y a pratiquement rien qui vous empêche de passer d’un fournisseur à l’autre: vous pouvez passer de Gmail à Office365 sans grande répercussion. 

Par contre, il est pratiquement impossible (sauf à dépenser de très fortes sommes, souvent dans les millions d’euros) de changer le système central de gestion des données de votre entreprise. Ce phénomène de lock-in est particulièrement présent en data science. Il est commun de voir des data scientists développer des systèmes de traitement de données qui ne fonctionnent uniquement que sous SAS, sous Oracle, sous MS SQL-Server, sous Azure, sous Amazon, etc. et nulle part ailleurs.

Le remplacement de ces systèmes par un système concurrent est typiquement tellement onéreux que la situation de lock-in s’installe de par elle-même. 

Les géants du cloud font tout pour pousser les data scientists à utiliser leur services “uniques” pour créer la situation de lock-in tant recherchée par eux. Un bon exemple est le discours marketing de Amazon relatif aux infrastructures serverless. Voici un extrait (traduit en français) de la page Amazon relative à ce sujet (URL de cette page)

“Les applications « modernes » sont construites serverless-first, une stratégie qui donne la priorité à l’adoption de services serverless, afin que vous puissiez accroître l’agilité de l’ensemble de votre pile applicative. Nous avons développé des services pour les trois couches de votre pile : calcul, intégration et stockage de données.”

En d’autres termes, et de façon plus claire, voici une “traduction” de ce même texte en langage plus compréhensible (et moins marketing):

Les applications « modernes » ne sont pas conçues pour fonctionner sur un système d’exploitation ouvert comme Linux ou Windows, mais sur les trois couches d’abstraction spécifiques à AWS : calcul, intégration et stockage de données. Cela signifie que, si vous changez de fournisseur cloud, vous devez re-créer l’ensemble du code qui gère vos données dans votre entreprise et perdre ainsi des millions d’euros et des dizaines d’années-homme de travail.

Lors de notre carrière de maintenant près de 20 années dans le domaine de la data science, nous avons constaté à maintes reprises (plusieurs dizaines d’occasions) des situations de lock-in qui permettait au fournisseur de service d’imposer de façon arbitraire ses prix à ses clients.

Quand cela arrive, le mot qui vient directement à l’esprit est le mot extorsion. Le dernier exemple d’extorsion le plus flagrant qui me viennent à l’esprit est la promotion d’une technologie nommée « Data Vault », malheureusement promue par quelques sociétés belges (avec l’aide de Amazon). Plus de détails sur ce sujet ici.

Ce phénomène de lock-in, exploité par des personnes sans éthique, est tellement présent et récurrent en data science qu’il mérite qu’on s’y attarde. Par ailleurs, l’existence de ce phénomène est une des raisons fondamentales qui nous ont amené à la création de la société TIMi. Avec la solution, TIMi nous tentons d’apporter une solution à ce problème épineux. Plus de détails sur l’approche éthique de TIMi ici.

Vous trouverez d’autres exemples de lock-in dans le contexte de fournisseurs cloud dans ce document.

En résumé, pour éviter d’être victime d’extorsions, il est impératif, avant de choisir une technologie cloud (ou pratiquement toute autre technologie de gestion des données), de vous poser la question suivante: “Est-ce que j’ai confiance dans l’éthique de ce vendeur ou va-t-il tenter de profiter de la situation de lock-in qui va immanquablement apparaître dès le moment où j’utilise sa technologie?”. En particulier, posez-vous cette question face aux géants américains du cloud, dont l’objectif est le profit maximum.