S’adosser à plusieurs plateformes cloud a bien des avantages, mais cela peut aussi être très coûteux. Une appréciation minutieuse des coûts de chaque fournisseur est donc nécessaire. Toutefois cela passe également par la conception de l’application.
Aujourd’hui presque toutes les entreprises, grandes, moyennes ou petites, déploient ou déploieront leurs applications dans le cloud. Les plus grandes d’entre elles, surtout celles dont les opérations sont géographiquement distribuées, sont même enclines à utiliser plusieurs services de cloud public. Dans certains cas, cela peut conduire à des coûts exorbitants.
Le multicloud au sens large définit l’utilisation de plusieurs clouds, qu’il s’agisse de clouds uniquement publics ou d’un mix intégrant des clouds privés. Les clouds privés sont des offres d’infogérance qui consistent à héberger des machines virtuelles sur des serveurs physiques dédiés à une entreprise et, le cas échéant, uniquement accessibles via le réseau privé de l’entreprise, la plupart du temps via un accès VPN.
Le cloud privé n’est généralement pas facturé comme le cloud public, à savoir à l’utilisation des machines virtuelles. En effet, la souscription à un cloud privé consiste plutôt en une location à prix fixe des machines physiques et des services activés dessus. De fait, les informations de cet article concernent plutôt la subtilité des coûts entre plusieurs clouds publics.
Pour contrôler les coûts d’un déploiement sur plusieurs clouds, il faut donc comprendre ce que facturent les fournisseurs. La facture repose généralement sur les ressources CPU, le stockage, l’accès aux données et aux services. Toutefois, si les grilles de tarification étaient identiques, les entreprises ne verraient que peu de différences. Malheureusement, ce n’est pas le cas. En cause : les coûts liés au stockage et l’accès aux données. Si vous prévoyez de mettre en place un programme de gestion de coûts pour plusieurs clouds, ces deux composantes sont à examiner de près.
La pile des coûts
L’accès aux données ainsi que le trafic entrant et sortant de l’application cloud sont les 2 plus importants indicateurs à suivre lorsqu’on calcule des modèles de coûts dans un environnement multicloud. Déplacer une application ou un composant d’une plateforme A vers une plateforme B implique généralement de tendre un flux entre 2 clouds. Une transaction peut démarrer d’un utilisateur vers un cloud A, d’un cloud A vers un cloud B, et du cloud B de nouveau au cloud A, puis vers l’utilisateur de départ. Ce workflow peut ainsi faire doubler la facture en matière d’accès aux données.
Les coûts imputés au stockage peuvent eux aussi être sujets à une forte augmentation, entraînant avec elle l’augmentation des coûts liés à l’accès aux données – toujours dans un environnement à cheval entre plusieurs clouds. Si la même application tourne sur deux clouds différents, et que chacun de ses composants doit accéder aux données, le choix est difficile. Si vous hébergez la base de données dans votre datacenter, ou sur un seul cloud, vous n’aurez qu’à payer cet accès. En revanche, si la base doit aller chercher des données sur plusieurs clouds, cela nécessitera le déplacement de beaucoup de données – et donc une augmentation de la facture. L’autre option est d’héberger une copie de la base de données sur tous les clouds, mais du coup, cela contribuera à augmenter les coûts de stockage, et créera des problèmes de synchronisation.
Distribuer une application sur plusieurs clouds peut aussi augmenter des coûts de CPU. La raison : un problème d’économie d’échelle ; plus le niveau d’usage est élevé, moins la facture sera élevée. L’autre raison est que les entreprises investissent dans des instances dédiées, et dans un scénario multicloud, elles se retrouvent souvent sous-utilisées.
Le coût de la mise en réseau entre clouds
Une stratégie multicloud permet d’accéder à un large éventail de services de cloud computing et de réduire le risque de dépendance vis-à-vis des fournisseurs. Pour maîtriser les coûts, les équipes informatiques doivent aussi comprendre les exigences des applications et suivre les tendances en matière d’utilisation des données et de mise en réseau. Elles doivent également tenir compte d’obligations plus larges telles que la sécurité et la conformité.
Par exemple, disons qu’une entreprise exécute une application dans AWS qui génère des données de transaction. Ensuite, l’entreprise déplace ces données vers Google Cloud pour entraîner des modèles d’apprentissage automatique. Dans ce scénario, de nombreux facteurs pourraient affecter, et finalement augmenter, les coûts, notamment :
- le fait que les données de transaction soient stockées à la fois sur AWS et Google Cloud ;
- les pratiques de gestion du cycle de vie des données entre les clouds ;
- les configurations actuelles du réseau, ainsi que les exigences en matière de bande passante et de latence ; et
- les contrôles d’accès et les mesures de prévention des pertes de données pour protéger les données dans chaque cloud, ainsi que les données en transit.
Lorsque les entreprises ont des services en contact avec la clientèle qui génèrent des données, ou qu’elles accumulent des données pour l’analyse, elles doivent prêter une attention particulière aux coûts de stockage entre plusieurs clouds. Par exemple, stockez plutôt les données de transaction et les snapshots qui vont de pair, à proximité des services qui les utilisent. Cela réduit la latence et améliore les performances. Pour atténuer le risque de défaillance des services, les équipes peuvent également stocker des copies des données dans différentes régions du cloud ou zones de disponibilité.
À l’inverse, stockez les anciennes données de transaction qui ne sont pas fréquemment consultées dans des services de stockage moins coûteux, tels que les archives. Ces services ne doivent pas nécessairement vivre sur la même plateforme de cloud que celle qui héberge l’application générant les données.
Utilisez ensuite des services de gestion des politiques et de migration des données, pour déplacer automatiquement les données des systèmes de stockage à faible latence et à coût élevé vers des systèmes de stockage à moindre coût. Ces systèmes moins coûteux peuvent fournir une sauvegarde à long terme et servir de référentiel pour l’analyse des données et l’apprentissage automatique. Demandez-vous si des copies de données dans un seul service de stockage en nuage à long terme et à faible coût sont suffisantes, ou si des copies seront nécessaires dans plusieurs nuages.
La synchronisation entre clouds a elle aussi un coût
La synchronisation des données est un autre facteur qui joue dans l’optimisation des coûts du multicloud. Les bonnes pratiques mentionnées ci-dessus sont utiles pour les opérations de stockage à long terme. Lorsque les équipes informatiques doivent synchroniser les modifications apportées aux données entre les clouds, et le faire avec une latence minimale, elles doivent adopter d’autres approches.
Par exemple, une application hébergée dans un cloud qui traite des transactions financières peut avoir besoin d’envoyer des données à un service de détection des fraudes qui fonctionne dans un autre cloud. Il faut donc un service fiable pour recevoir les données et les mettre en mémoire tampon jusqu’à ce que le service de détection des fraudes puisse les traiter. Les équipes informatiques pourraient utiliser un service de file d’attente de messages, tel que Amazon Simple Notification Service ou Google Cloud Pub/Sub, pour ingérer et stocker les données jusqu’à leur traitement.
Tenez compte des exigences de fiabilité des services intercloud. Le système ou la charge de travail pourrait-il fonctionner avec des données manquantes ou retardées ? Si ce n’est pas le cas, une fiabilité élevée et une faible latence sont nécessaires, et les équipes informatiques devront peut-être déployer des services de mise en réseau supplémentaires pour répondre à ces exigences.
Si une durée et une disponibilité moindres sont tolérables, envisagez des services de mise en réseau tels que Google Cloud Platform Pub/Sub Lite. Ces services coûtent moins cher que la version complète du service mentionné ci-dessus, et ils contribuent à l’optimisation des coûts du multicloud.
La sécurité et la conformité ont des coûts en plus en multicloud
Lorsqu’il s’agit d’optimiser les coûts d’un déploiement à cheval entre plusieurs clouds, la protection des données et la conformité ne sont pas toujours les premiers éléments qui viennent à l’esprit des équipes informatiques. Mais un manque d’attention aux exigences de sécurité et de conformité peut entraîner des dépenses importantes.
Lorsque l’on utilise des données sur plusieurs clouds, la sécurité devient complexe. Le temps et les efforts nécessaires pour sécuriser les données dans un cloud peuvent doubler lorsque les administrateurs doivent prendre des mesures similaires dans un second cloud. Pour réduire le travail redondant, utilisez un service d’authentification unique qui permet de fédérer les identités. Attribuez des attributs aux identités, telles que les utilisateurs et les comptes de service. Cela détermine les privilèges dont ils disposent. Utilisez des outils de gestion des identités et des accès pour vous aider dans cette tâche. Unifiez la gestion des identités et les politiques d’autorisation afin de réduire les opérations de gestion de la sécurité redondantes entre les clouds.
En outre, lorsque vous copiez des données d’un cloud à un autre, utilisez des services de prévention des pertes de données pour analyser et expurger les données protégées qui ne sont pas nécessaires aux services exécutés dans le second cloud.
Concevoir un programme de gestion des coûts
Il peut être difficile de prévoir et de contrôler les coûts, si le déplacement d’applications d’un cloud à l’autre s’effectue de façon dynamique. Mais des mécanismes peuvent être mis en place pour contrôler l’évolution des coûts.
Un programme de gestion des coûts du cloud commence par un mapping des traitements et des flux de données. Chaque composant a ses propres entrées/sorties et accès aux bases de données ainsi que des fonctions spéciales. Ce n’est pas chose facile, et les graphiques ainsi produits risquent d’être difficiles à analyser. Mais c’est un bon moyen pour démarrer une gestion des coûts du multicloud et cartographier ces relations pour toutes les applications éligibles au cloud. Cela vous aidera également à identifier les éventuelles « frontières » dans vos déploiements.
Ce plan des workflows révèle souvent une forme de réalité : les développeurs conçoivent les applications en couches distinctes. Le plus haute est le front-end et gère l’interface graphique et le support d’autres outils. Cette couche transmet des informations à une couche intermédiaire qui quant à elle ajoute une couche de données (editing par exemple), qui à son tour, transmet l’information à une autre couche, plus transactionnelle. Connaître la structure d’une application peut ainsi générer une économie de coûts dans un déploiement sur plusieurs plateformes cloud.
Dans votre programme de gestion des coûts, il convient de ne pas négliger les éventuels problèmes d’intégration et de gestion du cycle de vie.
La couche front-end est relativement simple à distribuer sur plusieurs clouds car elle n’implique généralement pas une connexion à une base de données. Elle est conçue pour être plusieurs fois instanciée. La déployer sur plusieurs clouds peut certes permettre de réaliser des économies, mais pas d’impacter les coûts du stockage ni d’accès aux données.
Certaines applications couplent bases de données et composants middleware. Dans ce cas, il ne faut pas oublier le coût lié à la réplication des données à travers les plateformes cloud. Plus le processus lancé sur cette couche est complexe, plus la distribution de cette couche sur plusieurs plateformes sera difficile.
En revanche, il est recommandé d’éviter de distribuer la couche inférieure de l’application – celle qui gère le traitement des requêtes et les transactions – sur plusieurs clouds, car celle-ci nécessite de nombreux accès à la base de données en temps réel. Beaucoup d’entreprises gardent cela en interne.
Enfin, dans votre programme de gestion des coûts, il convient de ne pas négliger les éventuels problèmes d’intégration et de gestion du cycle de vie. S’il existe de bonnes raisons d’opter pour le multicloud, cela comporte également des risques.
Article publié le 8 septembre 2017, mis à jour le 11 mai 2022.
Pour approfondir sur Administration et supervision du Cloud
