Bonnes pratiques

Introduction

De nombreux éléments ont été mis en place tout au long des précédents chapitres. Ils l’ont été dans le respect des bonnes pratiques Azure.

Respect d’une convention de nommage, étiquetage des ressources, choix des composants, etc. Mais il n’est pas facile de garder le contrôle de tout ce qui est fait sur son Cloud et il est également important de retravailler régulièrement sur les ressources existantes. Quelques points de contrôle sont obligatoires pour garantir le cycle de vie des ressources, et ce pour plusieurs raisons.

Tout d’abord, parce que ce qui a été pensé à la conception, il y a quelques mois, n’est peut-être plus adapté à la situation actuelle. L’application qui, au départ, ne nécessitait qu’une base de données aux performances standard est devenue une application majeure dont il faut retravailler les ressources.

Ensuite, parce qu’une machine virtuelle déployée pour un besoin particulier n’est finalement plus nécessaire ou que son utilisation n’est pas continue et qu’elle pourrait rentrer dans un cycle d’arrêt automatique et de démarrage à la demande. Il faut se souvenir que le coût d’une machine est lié à son temps d’utilisation et qu’il est facile de réaliser des économies.

Au-delà de ces points, il va être nécessaire, voire obligatoire de faire évoluer quelques composants parce qu’ils sont mis à jour par l’éditeur Microsoft Azure. Là aussi, un exemple récent est celui du passage d’une génération 4 à une génération...

Azure Advisor

Advisor est intégré et gratuit. Il s’agit d’une liste d’informations mais surtout de suggestions et de solutions qui traite les cinq points suivants :

Ressources orphelines

Comme précisé en introduction, la ressource orpheline ne sert généralement plus. Il n’y a pas de raison de conserver cette ressource, elle est facturée et supervisée inutilement.

Azure propose Explorateur Azure Resource Graph, une fonctionnalité d’analytique dédiée aux ressources qui vient en complément d’outils comme Advisor pour "traquer" les ressources. Ce très puissant explorateur de ressources s’appuie sur le langage Kusto. Des requêtes sont fournies de base pour utiliser le service sans connaître le code. Ce sont des actions de visualisations, il n’y a pas de risque d’utilisation, si ce n’est de déclencher une erreur à l’affichage.

Beaucoup d’autres utilisations sont possibles mais les exercices qui suivent donnent une idée de ce dont est capable l’explorateur. Dans le premier exercice, une requête disponible par défaut est utilisée pour afficher les groupes de sécurité réseau qui ne sont pas associés.

Stratégies Azure (Azure Policy)

Azure Policy est le terme couramment utilisé par les administrateurs Azure. L’appellation Stratégie, elle, peut porter à confusion. Ici, le terme stratégie utilisé est celui qui apparaît dans les menus du portail.

La stratégie est une évaluation de condition. Cette évaluation construit ensuite un tableau de bord. Ce tableau de bord donne un taux de conformité. Simple et efficace.

La Policy est une liste de points, appelée Définitions. Il existe des définitions intégrées (built-in) utilisables en l’état. Si les définitions existantes sont insuffisantes, des définitions personnalisées sont possibles.

Il en existe six au total dont voici la liste :

Certaines Policy portent plusieurs effets (celui souhaité doit alors être précisé lors de la mise en place), d’autres n’en portent qu’un.

Dans la pratique, la Policy est assignée à un scope avec ou sans activation de la stratégie. L’effet désiré est un paramètre d’attribution de Policy tout comme la tâche de correction qui n’est pas obligatoire. Tous ces paramètres seront revus dans les exercices afin de bien comprendre le fonctionnement global.

Pour aller plus dans le détail, il y a deux types de définitions : les Policy qui sont utilisés unitairement et les Initiatives qui sont un ensemble de définitions adressant le même thème et qui sont complémentaires. Une initiative est donc constituée de deux (ou plus) Policy.

Sous cette apparente complexité se cache une très belle fonctionnalité mise en œuvre dans les nombreux exercices qui suivent. Azure Policy est une fonctionnalité clé de la gouvernance d’Azure, il ne faut pas hésiter à passer du temps sur ce sujet afin de garantir la conformité de son environnement Cloud.

Dans les exercices qui suivent, la différence entre Définitions et Initiatives est exposée, puis une Policy d’audit est mise en place. Le menu conformité est utilisé pour vérifier ces premières étapes. La mise en œuvre...

Communiquer pour optimiser ses coûts

Il s’agit d’un sujet toujours très commenté dans les environnements Cloud. Comment faire pour que l’équation coûts/performances soit au meilleur niveau ?

Les points précédents donnent déjà de très nombreuses pistes, entre le traitement des ressources orphelines, le suivi des recommandations Advisor ou les contrôles de stratégie. Le chapitre Pour aller plus loin met en avant l’utilisation des Blueprints qui sont aussi un bon moyen de contrôler ce qui peut être consommé. Le chapitre Les coûts donne également bon nombre d’informations sur les contrôles de budgets, les mécanismes d’économies (durée d’engagement, utilisation des licences de l’entreprise, etc.).

Suivre toutes ces recommandations, c’est déjà l’assurance d’avoir une facturation cohérente et une expérience réussie. Que reste-t-il à mettre en œuvre ? Existe-t-il d’autres bonnes pratiques sur le sujet ?

Assurément oui. Un vrai "ça marche" supplémentaire est la communication autour de ce sujet. Les outils vont loin dans le suivi et l’extraction des coûts est une science très fine sur Azure ; chacun doit donc être informé et sensibilisé...