Les coûts du Cloud - comment mieux faire ?

Les Coûts du Cloud - 

comment mieux faire ? 



Les entreprises ont massivement migré vers le Cloud, même si en Europe on est a peu près au milieu du gué. Les modèles de tarification sont évidemment très différents de ceux qui étaient en vigueur "on premise". 

La promesse est à la maîtrise des coûts, mais bien souvent les mauvaises surprises s’accumulent.  C’est souvent faute d’une bonne compréhension des choses que les factures s’envolent. Ainsi 50 % des entreprises dépensent plus de 1,2 million de dollars par an en services Cloud avec un taux de croissance de 20 % (Editor's Choice / Gartner). Nous en verrons la mécanique ci-après.  Mais il y a quelques raisons de se réjouir !  

- La première bonne nouvelle, c’est que finalement les offres de stockage AWS, Azure ou GCP ont des modèles de tarification qui sont maintenant largement harmonisés.  Ainsi, une fois familiarisé avec ces modèles, il sera plus simple d’évaluer la valeur ajoutée de chacun d’entre eux. Dans les exemples ci-après, nous évoquerons le cas de Azure. 

- La deuxième bonne nouvelle, c’est que les systèmes sont engorgés de données qui ne servent pas, ou plus, ce qui a des conséquences sur les coûts directs, mais aussi sur les sommes astronomiques qui sont dépensées en maintenance vs le développement au service du business.


Les postes de coûts de stockage dans le Cloud 

_______________________________________


- Le stockage : en général, ces coûts sont exprimés en Go / To par mois ou pas an. Chaque provider offre des niveaux de stockage avec des niveaux de coût par rapport aux performances et la disponibilité  qui diffèrent.

- Les opérations de stockage : généralement, ce n’est pas conséquent, sauf évidemment quand les objets sont nombreux, avec de nombreux workloads. 

- Le download : ces frais basés sur les Go lus varient en fonction des niveaux de stockage et à l’activité sur le réseau lors du download de données.


Le stockage : 

Il est commun d’avoir des niveaux de remise sur le volume en lien avec les niveaux de performance : ci-après le modèle de Azure.  




Les opérations de stockage : 

Le déplacement des données n’est pas nécessairement cher : lecture, hiérarchisation, récupération des propriétés… Néanmoins ça peut vite augmenter, notamment sur certaines offres. 


On peut constater que les niveaux de coût de stockage inférieurs ont les coûts d'activité les plus élevés, puisque ces niveaux ne sont pas conçus… pour avoir de l’activité, CQFD ! 

La modélisation des frais de stockage peut être délicate car il faut comprendre ce que fait une application avec les données pour pouvoir modéliser ces coûts. 

Avec des fichiers plus petits mais plus nombreux (IoT, mails…), et c’est le véritable vecteur de l’inflation des systèmes, les opérations peuvent être multipliées et les coûts également. Il faut partir du principe que chacun d’entre eux fait l’objet de 4 opérations d’écriture et de 2 opérations de lecture ! 




La facturation peut s’envoler !


Le download :

La récupération des données est facturée dans le coût de stockage, quand le téléchargement hors de la région Cloud représente un "coût de transfert" lié à de la bande passante.  

Le download dans la région Cloud : 

Les coûts de transfert de données de récupération ne représentent pas souvent des sommes importantes.  Par exemple, pour Azure, l’accès à n'importe quelle quantité de données à partir de Hot n'a aucun coût de transfert. L'accès à 5 To coûterait environ $50 s’il était récupéré à partir de Cool, ou $100 s'il était accessible à partir d'Archive.

Le download hors de la région Cloud : 

Là, ce n'est pas la même histoire... 





Comme indiqué, les coûts de download peuvent devenir énormes : 

- Lors de la création d’instances dans une région Cloud distincte, 
- Si toute l’entreprise se met à faire de la data science sur des données en local, et c’est de plus en plus fréquent ;-)


Des systèmes qui grossissent continuellement, avec un impact fort ! 

______________________________________



Comme nous l’avons vu, les coûts du Coud repose sur le stockage, les opérations de stockage, et le download. 

Quand on sait qu’une très large proportion des données n’a pas d’usage, il n’est pas inutile de faire du nettoyage en continue. 

Forester indique qu’entre 60 et 73 % des données d’une entreprise n’ont pas d’usages pour l’analytics. Et les data center ont un lourd impact sur l’environnement. À l’heure actuelle, les serveurs consomment déjà 1,5% de l’électricité mondiale… IDC prédit une augmentation massive à du volume stocké à 175 zettabytes soit une croissance de 300% par rapport à aujourd’hui. Jusqu’à où irons nous ? 


Détecter et mettre de côté ce qui ne sert pas dans les systèmes. 

_______________________________________

  • {openAudit} va récupérer certains logs dans les bases d’audit qui renseignent sur l’usage ou pas d’une données : est-elle présente dans un dashboard, est-elle requêtée par tel ou tel outils ? Ces informations sont identifiables dans le Stackdriver de Google Cloud Platform, dans Cloudwatch de AWS, ou Monitor for Azure.  

  • Au départ des données utilisées, openAudit va déconstruire les flux jusqu’aux sources opérationnelles (= data lineage), et ainsi identifier les « branches vivantes » du système. Et par déduction, les branches mortes.  Il ne restera qu’à les décomissionner en continu pour garder un système à sa juste proportion 


 Conclusion

_______________________________________

Les tarifications du Cloud sont une véritable nébuleuse, mais cela tend à s'harmoniser. 

Et chaque besoin aura sa réponse, avec ses forces et ses limites. Ce qui est certain, c’est que les coûts explosent pour la simple et bonne raison que les volumétries s’accroissent continuellement. 

Nous pensons qu’un des sujets essentiels sera de contenir la taille des systèmes, voir de les faire décroître en détectant et en écartant continuellement la matière morte. 

{openAudit} peut permettre ce mouvement vertueux. 



 













Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Le data lineage, l’arme idéale pour la Data Loss Prevention ?