Scroll Top

Comment optimiser l’utilisation de vos ressources Azure en développement ?

Le précédent post sur la réduction des couts Azure pour le développement traitait des machines virtuelles.

Ce post, le dernier de la saison, s’occupe donc d’une autre facette de la réduction des couts d’infrastructure de développement. En PaaS, le meilleur moyen de faire des économies est la mutualisation. Attention, on est toujours dans un contexte de développement / prototypage donc sans les contraintes de volumétrie ou de SLA d’une production. 

Je vous propose 3 montages éprouvés du plus évident au plus tordu pour disposer de bonnes fonctionnalités à un cout réduit. Je précise que, parlant de mutualisation, ces recettes ne fonctionnent que si vous avez plusieurs besoins similaires ? 🙂

 Cette fois, on va parler PaaS?!

BASES DE DONNÉES – LE POOL ÉLASTIQUE
  • C’est la solution la plus évidente?: Regroupez vos bases dans un pool élastique. Et ceci est aussi valable en production. Les couts de bases de données peuvent être vraiment réduits. Quand on sait qu’il n’y a pas de mise en pause pour les Azure SQL Database (c’est différent pour les Datawarehouse), c’est d’expérience le point d’économie PaaS le plus important.
WEB APP – EXPLOITER CORRECTEMENT L’APP SERVICE PLAN

Certes il est possible d’héberger gratuitement les WebApps sous Azure mais toutes les fonctionnalités ne sont alors pas disponibles?: Pas d’emplacements de déploiement, pas de jobs continus, pas de SSL… 

Il est en revanche possible de déployer plusieurs Applications Web sur le même Service Plan. Libre à vous donc de déployer un plan «?Standard?» vous ouvrant toutes les fonctionnalités et d’y déployer plusieurs applications…

WEB APP – EXPLOITER CORRECTEMENT L’APP SERVICE PLAN

Tant qu’on est dans les limitations du plan «?Free?», voici mon astuce tordue. Vous avez remarqué le caractère un peu «?paresseux?» des WebJobs quand ils ne sont pas en «?continu?»?(donc pour les plans les moins onéreux) : ils ne bossent que quand on les regarde… Et les messages s’empilent dans la queue. 

Il est en revanche tout à fait possible de déclencher par WebHook n’importe quel job et il tournera dès l’appel?! 

Donc si vous voulez disposer d’un job qui soit déclenchable à une période définie, ou d’autres conditions uniquement supportées par les jobs continus, créez un simple exécutable console et déployez-le comme WebJob, utilisez ensuite comme déclencheur une structure à cout réduit ou gratuit, par exemple en mutualisant un existant?: Automation, Azure Function ou un autre job… Un simple appel http POST suffit à déclencher votre job?!