Planifier ses coûts Azure

Il est plutôt « facile » de répondre aux questions techniques de sécurité, de performance, d’accès …etc. Il est également possible de répondre aux questions que l’on se pose en termes de sizing, de charge. Facile ne veut pas dire que cela se fasse rapidement et sans préparation. Mais plutôt que les données à exploiter pour arriver à obtenir les bons éléments de réflexion sont des données très concrètes et que l’on peut transposer de son informatique existante à son informatique portée sur le Cloud Azure.

Que l’on déplace son environnement existant dans un mode 1 pour 1 (Lift-and-shift) ou que l’on décide de redéployer en adaptant son environnement aux services Azure, une photo de l’existant et une vue de ce que l’on souhaite après migration sont les deux éléments nécessaires à la préparation.
Les données de départ nécessitent une bonne connaissance de son architecture complétées par l’utilisation des outils d’évaluation / inventaire. Par exemple, Azure Migrate qui est un outil gratuit de simplification à la migration. Si le choix est de redéployer, il faudra également se pencher sur les modèles de référence Azure pour porter ses applications et son infrastructure sur un modèle Cloud.

Voilà (très schématiquement) une façon classique d’aborder le sujet. Au final, toutes ces données sont très factuelles, elles sont mesurables puisqu’elles s’appuient souvent sur des métriques et on se retrouve rassuré par ces étapes de préparation.
Les services de départ sont clairement identifiés, les services équivalents ou complémentaires Cloud également, que reste–il à faire si ce n’est migrer ?
Il reste à chiffrer et à évaluer la dépense à venir.

Le « Combien cela va-t-il me coûter ? » est sans conteste la question pour laquelle il est plus difficile de répondre avec exactitude. Elle est pourtant et heureusement au cœur de la réflexion. Il existe quelques bonnes pratiques pour que cette estimation soit la plus précise possible.

Quelles étapes pour affiner le besoin ?

Première étape, certainement la plus importante après l’identification d’un service, son niveau de performance / fonctionnalité.

• Performance 

Le niveau de performance de ma machine ou de ma base de données est à X, quel coût pour un même niveau de performance sur Azure.

Ici, la calculatrice est l’outil indispensable pour cette évaluation. Calcul, mise en réseau, base de données, identité, tout est passé en revue.

Par exemple, quel coût pour une machine 4 vCPU, 16 Go de ram sur système d’exploitation Windows.

Calculatrice Azure pour une machine virtuelle

• Fonctionnalité 

L’exercice est un peu plus complet. Un service peut-être dispensé avec des fonctions simples dans son SKU (sa référence ou édition de niveau) la plus basique et offrir des fonctionnalités ou des performances complémentaires dans sa version la plus évoluée. Cette étude doit être menée en s’appuyant sur les tableaux comparatifs des SKU. Par exemple, le service IoT Hub n’autorise pas l’utilisation du calcul de périphérie Edge ou limite les débits dans les versions les moins coûteuses.

Accélération / limitation des débits selon le SKU

La puissance et les modèles disponibles n’ont (presque) pas de limite, attention à ne pas tomber dans l’excès. Se faire plaisir peut avoir un surcoût non négligeable.

Dernière recommandation, certains modèles de base ne supportent pas d’évolution de niveau. Il sera, par exemple, impossible de choisir un niveau de fonctionnalité plus élevé. Ce qui oblige à détruire puis reconstruire. La lecture attentive des documentations SKU évitera ce genre de cas.

Le niveau choisi ne prend pas en charge la mise à niveau

Seconde étape, son niveau d’élasticité. L’élasticité est la capacité à adapter sa charge de travail. A la hausse comme à la baisse, l’adaptation des ressources a un lien direct et extrêmement fort avec les coûts. Le mécanisme du paiement à l’utilisation propre aux solutions Cloud offre la possibilité de baisser les coûts sur des créneaux où le besoin de puissance est peu élevé, voire inexistant. Par exemple, une base de données peut disposer d’une puissance X en journée et d’une puissance X / 2 en cours de soirée ou de nuit. Mieux même, une machine virtuelle peut être stoppée hors heures de bureau.
Cette facilité de mise à l’échelle doit être intégrée lors du calcul des coûts. Cet exercice est à réaliser à la hausse comme à la baisse. On ne taille plus son environnement sur son besoin maximum, mais sur un besoin instantané. Ma machine est choisie pour un besoin qu’elle va couvrir 90 % du temps (ni plus, ni moins) et est adaptée pour les besoins exceptionnels. Par exemple, ma base utilise 16 cœurs 99 % du temps, mais 32 cœurs 2 jours dans l’année pour une consolidation. Passer du temps sur ces calculs est une garantie de facturation homogène avec son besoin.

Troisième étape, son niveau d’engagement. Le niveau d’engagement est la capacité à utiliser des machines éphémères ou des machines sur la durée. Que se passe-t-il pour une machine de test, machine éphémère par excellence ? Elle est utilisée quelques jours, semaines, puis attend un nouveau test pour être réutilisée. C’est une machine jetable.

Au contraire d’une machine qui héberge l’application majeure de l’entreprise et qui est amenée à durer. Cette notion d’engagement de durée a aussi un impact fort sur les coûts. Une machine jetable se paye à l’utilisation au prix fort. C’est à dire sans possibilité de réduction. Cloud oblige, elle n’est plus facturée dès qu’elle est détruite.

Une machine utilisée durablement dans le temps voit son prix réduit de façon très significative. Jusqu’à 70 % de réduction pour un engagement à trois ans. La machine D4dsV4 choisie plus haut affiche une réduction de 62 % sur la calculatrice Azure si la durée d’engagement est de trois ans.

Réduction importante pour des engagements de longue durée

Là aussi, même si l’exercice demande du temps, il est indispensable ! C’est un peu la chasse au gaspillage et au rapport coût / performance adapté aux besoins. Voilà de quoi voir beaucoup plus clair dans ses coûts pour ne pas partir à l’aventure.

Pourquoi il est important de « se faire la main » ?

Malgré toute cette préparation, il est possible et important de se faire la main. Les tests techniques sont indispensables et sont, je pense, systématiquement mis en place en entreprise.

Les tests de maitrise et compréhension des coûts le sont beaucoup moins (pas du tout ?). Pourtant, ce sont des éléments qui participent à la réussite d’une migration. Il y a beaucoup à apprendre !

Microsoft Azure offre une enveloppe de 170 € pour explorer Azure.

Que faire avec cette somme ? Déployer quelques ressources Azure (base de données, machines virtuelles …etc.), les utiliser puis … lancer le menu d’analyse des coûts.
Ici, à l’échelle d’un abonnement de test, quels sont les services qui me coûtent, sont-ils nécessaires ? Bien répartis ?

Répartition des coûts

Que va-t-il se passer si je conserve ces ressources ? Quels coûts à venir ? Le  déploiement d’un nouveau service génère un coût important et une projection des coûts à venir. Ce surcoût a-t-il été anticipé, est-il réellement nécessaire ? Le service doit-il être rendu à ce prix ?

Projection et courbes des dépenses J + 15

Ces deux compteurs sont utilisés pour d’éventuelles actions de corrections.

Pour terminer, il faut utiliser Azure Advisor, outil intégré de recommandations. Il affichera les machines / services sous utilisées -és pour lesquels il est possible de réaliser des économies. Advisor s’appuiera sur les métriques constatés pour guider et aider à la mise en place d’actions correctives.
Au final, une belle liste d’outils de contrôle.

En résumé ! voici les 3 étapes à retenir : 

1. Il existe un grand nombre de ressources et d’outils pour piloter ses coûts Azure.
2. Adapter son niveau de performance et de fonctionnalité au plus proche des besoins a un impact fort sur le montant de sa facturation.
3. La projection des dépenses est utilisée pour piloter le montant des factures à venir