Déplacer ses machines Dev / Test dans Azure. Comment calculer le coût et optimiser le tout avec Excel, et un peu de VBA

Azure dispose de 100aines de services. Présenter Azure, c’est comme présenter “l’informatique”.

Parmi cette très longue liste de services, il y en a certain que je nomme “Quick Win”, qui ont pour tous les clients un apport soit financier, soit technique. C’est le cas de sauvegardes, des Plan de Reprise d’Activité, .. mais surtout de la virtualisation de machine “Dev/Test”

Le Dev/Test Azure

Comme vous le savez, la tarification des VMs dans Azure est à la minute d’utilisation, et le prix est en fonction de la puissance de la machine. Ce qui veut dire qu’une machine arrêtée ne coûte que le stockage, c’est à dire quasiment rien. On ne va “payer” ces machines que lorsque l’on va la redémarrer, et donc les utiliser.

Les scénarios de Dev/Test sont donc parfaits pour Azure pour plusieurs raisons :

• Financièrement, vous ne payez qu’à l’usage, et en général au maximum de 9H00 du matin à 18H00 le soir. Pas besoin de garder ce type d’environnement la nuit et le WE, alors on va les arrêter et ne plus payer les machines (mais elles sont au chaud dans les Datacenters de Microsoft).
• Pour les experts techniques, le fait de pouvoir changer en permanence le hardware de la machine (monter ou descendre la puissance, CPU/RAM/Disque) permet d’avoir toujours le “lab de ses rêves”. Ce type de machines puissantes ou très spécifiques ne pourrait être acquis par l’entreprise.
• Pour le chef de projet, savoir que ses experts ont tous les meilleurs composants possibles est une assurance de la qualité pour le  projet lui même. On ne va pas tester sur “les machines dont on dispose dans le Datacenter” (en général d’anciennes machines, pas assez de RAM)… mais bien sur la “bonne” machines, faire des recettes qualitatives, et des tests de performance.

Simuler son environnement dans Azure : prix, optimisation

Dans la mesure ou l’on passe dans Azure à une facturation à la minute, cela nous procure de nombreuses opportunités c’est certain, mais également au début, un peu de complexité au niveau de la simulation.

Je vous propose ici une approche simple, avec Excel, parfois optimisé avec des macros pour faire cette simulation la plus détaillée possible. Cela permet de dégrossir assez vite le projet.

Note : pensez aux équipes partenaires Microsoft ou partenaire, qui font des 10zaines de simulations de ce type par semaine. C’est pour cela que j’utilise des macros.

Etape 1 : les données du lab sur le réseau interne

Il suffit de récupérer les éléments techniques nécessaires à la simulation et les apposer dans un fichier Excel. Ici, on demandera au client la puissance dont dispose chaque machine sur son environnement interne actuel. Nous parlons ici :

• du nom de la machine
• du nombre de cœurs
• de la qualité de RAM
• de la taille du disque
• idéalement une description, permettant de commencer à comprendre son usage et imaginer les optimisations.

Voici un exemple de ce dont nous avons besoin  :

Dans la partie “blanche” les données du client, dans la partie bleu (à droite) ce que nous allons ajouter pour la simulation dans les étapes suivantes.

Etape 2 : Identifier la machine correspondante dans Azure

En effet, dans Azure vous ne choisissez pas les composants de la machine (je veux X cœurs, Y de RAM RAM) mais vous choisissez parmi un large panel de “modèles”.

Il faut donc, ligne par ligne identifier la “bonne” typologie de machine, et de temps en temps faire des arbitrages, plus ou moins de RAM, plus ou moins de CPU.

Quand il y a quelques lignes cela peut se faire à la main, mais lorsqu’il y en a des 10aines, c’est assez rébarbatif et long.

Un astuce est d’alors d’utiliser des macros, et d’utiliser le code pour mettre les bonnes valeurs.

La macro se résume à un ensemble d’hypothèse sur le ratio Cœur/RAM (que nous avons dans le fichier) XLS en colonne C et D.

Voici un exemple de code :

Il faut alors un “IF” par type de machine (ici A2), et l’on combine les hypothèses pour ce type avec un “Or”.

Lorsque la macro aura regardé tous les “IF”, et donc trouvé la bonne correspondance, il suffira alors de mettre à jour le fichier Excel avec ce code :

La colonne dans mon exemple est “I”, et la variable qui représente la ligne en cours de traitement test “i” (I2, I3).

=> Dans l’idéal j’aurais dû appeler la variable “i” avec un autre nom, comme “ligneEnCours” pour la lisibilité. Je vais corriger cela à l’avenir !

Il suffit alors de lancer la macro, elle va balayer les lignes, et mettre par défaut le type de machine que vous souhaitez.

Sur les “hypothèses” qui ne seraient pas dans la macro, pré-charger en début de fonction la variable Hypo avec la valeur “??” permet très rapidement d’identifier les manques. Il suffira alors d’ajouter les hypothèses dans la macro (ou les mettre à la main), de relancer le script et tout est ok.

Etape 3 : Type de machine, prix et description

Même lorsque l’on fait cet exercice souvent, il y a tellement de types de machines (et donc de prix et de caractéristiques techniques) que la aussi on va utiliser une macro pour faire le travail, c’est à dire compléter la colonne description (permettant de voir CPU, RAM, type de disque) mais également le prix (permettant les calculs ensuite).

On peut le faire à la main, mais c’est totalement automatisable.

Toujours dans une macro, la première étape est de charger dans un tableau (MyPricing) la liste des machines, et pour chaque type sa description et son prix :

Ensuite, lorsque l’on va balayer ligne par ligne le fichier XLS, il suffira de “trouver” dans le tableau la bonne ligne, et d’en extraire le prix et la description. Ici une fonction faite pour cela, qui retourne les deux valeurs :

Nous avons donc maintenant un tableau Excel mis à jour. La colonne I a été générée sur la base d’hypothèse, puis avec une autre macro nous avons ajouté la description de la machine et son prix horaire :

Il suffira alors d’ajouter quelques calculs comme “le prix par jour”, ou “le prix par mois” et on aura un coût en 24x7 qui est représenté en bleu ici.

De la même façon, dans l’hypothèse du Dev/Test ou l’on utilise que 8 heures par jour et pas le WE ces machine, une simple adaptation des formules (dans la partie grise) permet de voir l’intérêt de l’exercice.

Remarque sur les Prix

Lorsque l’on regarde de plus près les différents couts d’un lab de test, nous avons évidement la machine elle même, mais aussi le stockage, le monitoring (Log Analytics), les sauvegardes, etc.

Personnellement je ne simule dans un premier temps “que” les coûts principaux (les plus importants) et il s’agit de la VM.

Car ensuite il faudra affiner avant d’aller plus loin :

Valider définitivement le type de machine à utiliser : il y a forcément un débat avec les experts de l’application

Finaliser les optimisations possibles, comme démarrer la machine de 9 à 18H00, ou sur une plus grande plage horaire.

Cet exercice de finalisation du coût “machines virtuelles” est un pré-requis avant d’aller voir les autres coûts, qui sont d’un montant beaucoup plus faible.

Egalement, j’utilisez toujours les prix publics, permettant d’échanger avec les partenaires et le clients (les prix payés par les clients dépendent de leurs contrats) plus facilement.

Conclusions

Les scénarios “Dev/Tests” sont très intéressants dans Azure, tant pour le prix (à la minute) que pour la partie technique (possibilité de changer en permanence la puissance de la machine).

Simuler un coût dans Azure nécessite simplement un exercice de simulation dans Excel.

Lorsqu’il y a beaucoup de machines, ou que l’on fait beaucoup de simulations pour de nombreux clients, l’utilisation de Macros VBA peut nous faire gagner énormément de temps.