Le Cloud est devenu aujourd’hui un élément incontournable pour accompagner la croissance des entreprises et leur permettre de répondre rapidement à leurs besoins d’agilité et de scalabilité.
Grace au Cloud, il est devenu facile pour nous de créer des infra complètes en deux clics trois mouvements, cependant, si nous ne restons pas vigilants à ce que nous faisons, nous risquons vite d’exploser le compteur et de nous retrouver avec le contrôle de gestion sur le dos nous demandant des explications sur des factures poivrées de consommation Cloud. Ceux d’entre vous qui sont déjà passés par là se souviennent sans doute de la solitude qu’on ressent à ces moments-là 🙂
Comment faire alors pour optimiser ses coûts sans déroger un instant à la qualité de nos livrables ? Grande question mais totalement à notre portée !
Je vais vous illustrer dans cet article comment nous pouvons réduire considérablement le coût de nos environnements de test en mettant en œuvre le principe d’Infrastructures éphémères.
Stack Techno
Pour cette illustration, nous allons être sur une Stack Microsoft (ma préférée 🙂 et nous allons mettre en œuvre un pipe de déploiement et de test auto en employant la stack suivante :
L’idée est simple ; Partant du principe qu’un environnement des tests automatisés n’est sollicité qu’au moment d’un merge de code pour jouer les tests de non-régression (voire d’autres types de tests en fonction des besoins de chaque équipe), nous allons tenter de le créer uniquement pendant ces exécutions (directement depuis la pipe d’intégration) et de le détruire une fois le travail terminé.
Cela réduit la consommation Cloud à la seule durée des tests, on sera donc sur des ratio imbattables.
Imaginez une Feature Team standard (4/5 peoples) qui gère une ou plusieurs applications aux architectures non-complexes (Appli de gestion, Micros Service…), cette équipe merge son code 3 fois par jour et lance une batterie de tests automatisés à chaque intégration, imaginons que chaque exécution des scénarios de tests dure 20min > Notre solution va réduire la durée de vie des environnements de tests à (3 x 20min = 1h) contre 24 heures sur des environnements dédiés.
Le calcul est simple : Vous allez diviser votre facture de conso sur vos environnements de tests par 24 et cela fera sans doute des heureux !
Use Case
Pour les besoins de cet article, nous allons opter pour un exemple d’API très simple, cela nous permettra de nous concentrer sur le cœur du sujet à savoir, le provisionning éphémère de nos environnements de test.
Partons sur l’exemple fourni par défaut par Microsoft pour la création de tout nouveau projet API ; il s’agit d’une API Météo assez simple incluant une seule route GET /weatherforecast et qui retourne une réponse JSON indiquant la météo des 5 prochains jours.
Mise en œuvre
Bootstrappez le projet ASP.NET WebAPI
D’abord nous allons commencer par créer cette API, pour cela, nous allons initialiser un nouveau projet ASP.NET Webapi en utilisant VSCode.
Pour les besoins de l’exercice, créez sur votre disque l’arborescence suivante :
Le dossier app contiendra le code applicatif de l’API Weather Forecast
Le dossier infra contiendra le code de déploiement Terraform
Le dossier tests contiendra le projet de test xUnit
Infras éphémères pour les tests avec Terraform et Azure DevOps
Le Cloud est devenu aujourd’hui un élément incontournable pour accompagner la croissance des entreprises et leur permettre de répondre rapidement à leurs besoins d’agilité et de scalabilité.
Grace au Cloud, il est devenu facile pour nous de créer des infra complètes en deux clics trois mouvements, cependant, si nous ne restons pas vigilants à ce que nous faisons, nous risquons vite d’exploser le compteur et de nous retrouver avec le contrôle de gestion sur le dos nous demandant des explications sur des factures poivrées de consommation Cloud. Ceux d’entre vous qui sont déjà passés par là se souviennent sans doute de la solitude qu’on ressent à ces moments-là 🙂
Comment faire alors pour optimiser ses coûts sans déroger un instant à la qualité de nos livrables ? Grande question mais totalement à notre portée !
Je vais vous illustrer dans cet article comment nous pouvons réduire considérablement le coût de nos environnements de test en mettant en œuvre le principe d’Infrastructures éphémères.
Stack Techno
Pour cette illustration, nous
allons être sur une Stack Microsoft (ma préférée 🙂 et nous allons mettre en
œuvre un pipe de déploiement et de test auto en employant la stack suivante :
provider 2.31.1
Principe
L’idée est simple ; Partant
du principe qu’un environnement des tests automatisés n’est sollicité qu’au
moment d’un merge de code pour jouer les tests de non-régression (voire
d’autres types de tests en fonction des besoins de chaque équipe), nous allons tenter
de le créer uniquement pendant ces exécutions (directement depuis la pipe
d’intégration) et de le détruire une fois le travail terminé.
Cela réduit la consommation Cloud
à la seule durée des tests, on sera donc sur des ratio imbattables.
Imaginez une Feature Team
standard (4/5 peoples) qui gère une ou plusieurs applications aux architectures
non-complexes (Appli de gestion, Micros Service…), cette équipe merge son code
3 fois par jour et lance une batterie de tests automatisés à chaque
intégration, imaginons que chaque exécution des scénarios de tests dure 20min
> Notre solution va réduire la durée de vie des environnements de tests à (3
x 20min = 1h) contre 24 heures sur des environnements dédiés.
Le calcul est simple : Vous
allez diviser votre facture de conso sur vos environnements de tests par 24 et
cela fera sans doute des heureux !
Use Case
Pour les besoins de cet article,
nous allons opter pour un exemple d’API très simple, cela nous permettra de
nous concentrer sur le cœur du sujet à savoir, le provisionning éphémère de nos
environnements de test.
Partons sur l’exemple fourni par
défaut par Microsoft pour la création de tout nouveau projet API ; il
s’agit d’une API Météo assez simple incluant une seule route GET /weatherforecast
et qui retourne une réponse JSON indiquant la météo des 5 prochains jours.
Mise en œuvre
Bootstrappez le projet ASP.NET WebAPI
D’abord nous allons commencer par
créer cette API, pour cela, nous allons initialiser un nouveau projet ASP.NET
Webapi en utilisant VSCode.
Pour les besoins de l’exercice,
créez sur votre disque l’arborescence suivante :
A vous de jouer !
Articles récents
Archives