Il y a quelques mois, pour les besoins d'un client, j'ai effectué un POC du service AWS FSx for NetApp ONTAP. C'est un plutôt bon service de stockage basé sur NetApp ONTAP, en revanche, quand on se penche sur son modèle de facturation, il y a de quoi s'arracher les cheveux.
Pour bien comprendre le problème, faisons d'abord un petit tour d'horizon des fonctionnalités de la solution.
FSx for NetApp ONTAP permet de créer des volumes partagés que l'on peut monter via NFS ou SMB. Il supporte aussi l'iSCSI. La particularité de la solution est qu'elle dispose de 2 types de stockage:
Le stockage primaire est performant et alloué de façon statique. Il se repose sur des disques SSD haute performance.
Le second stockage est appelé capacity pool. Il est moins performant mais moins coûteux et élastique c'est à dire qu'il n'y a pas besoin d'allouer l'espace préalablement.
Maintenant penchons-nous sur le modèle de facturation de la solution et vous comprendrez qu'il est impossible d'estimer à l'avance combien nous coûtera le service.
Pour commencer il faut déterminer le volume que l'on souhaite stocker. Pour le moment, pas de difficultés. Disons 2To.
Ces 2To seront répartis sur les 2 classes de stockage et pour faire une estimation financière il faudrait savoir comment les données sont réparties. Mais c'est impossible de le savoir avec précision car des mécanismes internes déplacent les données d'un stockage à l'autre en fonction de la fréquence d'accès. Donc nous sommes obligés de faire une première hypothèse.
▶️ Hypothèse 1: Prenons la valeur proposée par la calculette AWS soit 20% sur du SSD, 80% en capacity pool.
Ensuite il faut déterminer quel pourcentage les mécanismes de déduplication et de compression des données nous permettent de gagner en terme d'espace. Là encore, impossible de le savoir à l'avance. Nous devons faire une deuxième hypothèse.
▶️ Hypothèse 2: La calculette nous aide un peu et nous propose 65% d'espace économisé grâce à la déduplication et la compression des données.
En ce qui concerne le stockage primaire (SSD), une partie de la facturation se base sur le nombre d'IOPS provisionnés. Le montant facturé qui en dépend est prévisible. Tout comme la capacité de bande passante allouée au filer. Pas de surprise là-dessus.
Attention, ça se corse. Le mode de facturation du stockage en capacity pool se base sur le volume consommé mais aussi sur le nombre de requêtes d'écriture et le nombre de requêtes de lecture. Déjà, on est en droit de se demander à quoi cela correspond. Est-ce que si je lis/écris un fichier ça correspond à une lecture/écriture? Ou bien plusieurs requêtes sont nécessaires pour lire/écrire un fichier donné quelque soit sa taille?
▶️ Hypothèse 3: Une lecture/écriture correspond à une lecture/écriture de fichier.
Combien de lecture/écriture y aura-t-il sur nos volumes? Impossible de le savoir.
▶️ Hypothèse 4: XX lectures
▶️ Hypothèse 5: YY écritures
Passons maintenant aux backups. Ils sont facturés en fonction de leurs tailles. A priori c'est simple mais est-ce qu'il faut prendre la taille du backup avant ou après déduplication et compression?
▶️ Hypothèse 6: Prenons la taille après déduplication et compression (mais à vrai dire il faudrait creuser plus ou demander à AWS)
Comme nous sommes sur du backup incrémental, il faut estimer le taux de changement effectué par jour.
▶️ Hypothèse 7: Prenons 3% de taux de changement sur le filer
Cela ne fait pas moins de 8 paramètres à considérer pour obtenir une estimation pour lesquels 7 hypothèses ont dû être faites. C'est impossible d'avoir une estimation fiable dans ces conditions. Et je ne prends même pas en compte les coûts liés au transit (VPC, Direct Connect ...). C'est d'autant plus dommage que le service est fait pour l'optimisation des coûts (grâce aux 2 classes de stockage).
Ce genre de modèle de facturation trop complexe joue sur la capacité des entreprises à adopter certains services car pour beaucoup d'entre elles la prédictibilité des coûts est un des critères les plus importants.
Le modèle pay-as-you-go n'aurait-il pas des limites? Est-il vraiment adapté à tous les services? Ce que je pense c'est que plus le service combine de paramètres qu'il n'est pas possible de prévoir précisément et moins ce modèle profite aux clients qui ont besoin de visibilité d'un point de vue financier.
Imaginez-vous que le premier service proposé par AWS ait eu une complexité de facturation comme celle de FSx for NetApp ONTAP. Il y a fort à parier que le cloud n'aurait pas eu le succès qu'il a aujourd'hui.
Cela dit je vois tout de même un avantage à ce mode de facturation. C'est qu'il est le reflet de la complexité de la solution. Facturation complexe == Produit complexe. On peut donc craindre que la gestion opérationnelle le sera elle aussi. On a donc une idée dès l'étude financière du niveau d'investissement humain à mettre en œuvre pour une mise en place et un maintien en condition opérationnelle maîtrisés de la solution.
Comments