Nous continuons notre série d’articles consacrés au FinOps et à la mise en place d’une culture d’optimisation des achats Cloud. Après une présentation générale des principes du FinOps, un focus sur les parties prenantes du FinOps dans l’entreprise, les différents modèles de facturation des fournisseurs Cloud et enfin le cycle de vie financier des applications Cloud, nous abordons aujourd’hui en détail les bonnes pratiques d’optimisation.

Le schéma suivant synthétise des bonnes pratiques en termes d’optimisation des coûts dans l’esprit de l’axe “Optimisation des Coûts” du Well Architected Framework (WAF) d’AWS. Ces pratiques sont applicables sur n’importe quelle plateforme cloud.

Le dimensionnement optimal des ressources par rapport au SLA 

Le dimensionnement optimal des ressources, c’est bien sûr le dimensionnement des instances EC2. AWS Cloud Advisor et AWS Cost Explorer propose des recommandations dans ce sens. Il est aussi de bon ton d’identifier les instances avec un taux d’utilisation CPU et mémoire inférieur à 50% (attention la surveillance de la mémoire nécessite le déploiement du CloudWatch agent).

Depuis Re-invent 2019, nous avons à notre disposition AWS Compute Optimizer qui permet d’identifier le dimensionnement optimisé par rapport à un workload donné.

Mais dimensionner les ressources, c’est également choisir la bonne classe de stockage requise sur S3 (ou EFS ainsi que le type de volumes EBS) tout au long du cycle de vie de la donnée. L’utilisation de classe “Infrequent Access” ou “Glacier” peut permettre de réduire drastiquement la facture pour des applications qui ne nécessitent pas des performances en IO élevées. La classe S3 Intelligent Tiering permet d’optimiser ses coûts par rapport à des modèles d’accès aux données complexes.

L’ajustement automatique de la capacité à la demande

Un premier ajustement est de ne pas avoir de capacité s’il n’y a pas de demande. Combien d’instances cloud sont activées comme dans un datacenter on premise en 24×7 alors qu’elles sont utilisées en heures ouvrées (8×5)? Le prix d’une VM activée en heures ouvrées représente moins de 25% du prix d’une VM active en 24×7. 

L’infrastructure as code permet de construire et de supprimer un environnement complexe en un temps réduit. C’est par exemple très intéressant pour des environnements de tests qui sont activés à chaque campagne de tests. L’intégration du déclenchement des tests dans une chaîne CI/CD peut permettre d’automatiser : la création de l’environnement, les opérations de chargement des jeux de données, l’exécution des plans de tests, la sauvegarde éventuelle de logs ainsi que la destruction de l’environnement.

L’adaptation de la capacité à la demande se fait en règle général en mettant en oeuvre les fonctions d’auto-scaling offertes par les services clouds. Avec une même architecture, on renforce la disponibilité (en répartissant les noeuds sur plusieurs zones de disponibilité) et on optimise la capacité en activant le nombre d’instances qui est nécessaire pour traiter la demande.

Au delà des VMs, ces principes de scalabilité horizontale peuvent être appliqués à d’autres types de ressources telles que des files d’attente, des instances de bases de données,..

La mise en oeuvre des modèles de réservation de capacité et des plans d’économies

Pour des workloads avec un minimum de capacité en continu en 24×7 et une pérennité de plusieurs années sur l’application, il est intéressant d’activer des modèles de type Savings Plan. Ceci peut être géré pour une application (en utilisant alors un mode EC2 Instance Savings Plan pour une famille d’instances données et sur une région AWS donnée qui donne une réduction maximale), ou mutualisé pour un pool d’applications en tirant partie du mode “Compute Savings Plan” qui donne de la souplesse par rapport aux familles d’instances et aux régions si nécessaire.

Des recommandations sont proposées par AWS sur l’usage des Reserved Instances pour diminuer les coûts ou sur l’usage des savings plan.

La gestion du cycle de vie des ressources

Gérer le cycle de vie des ressources, c’est : 

• provisionner la ressource quand on a besoin de l’utiliser avec de l’automatisation (exemple : provisionner un environnement de test d’intégration avec son outil d’intégration continue)
• faire évoluer la performance quand on a besoin d’un niveau de performance supérieur 
• revenir au niveau nominal voire un niveau plus pas lorsqu’on a besoin d’un niveau plus faible de performance (exemple : utilisation des politiques de cycle de vie S3 avec archivage sur Glacier)
• décommissionner la ressource quand on n’en a plus besoin (c’est également une pratique importante en termes de sécurité)

Cette gestion du cycle de vie doit s’appliquer à tout type de ressources : instances, adresse IP élastique (EIP), stockage (EBS), tables de bases de données, AWS, Account, Identités, clé de chiffrement, secret,…

La définition de tags indiquant la fin de vie d’une ressource peut faciliter l’automatisation du décommissionnement des environnements (en particulier pour des environnements bac à sable ou de POC).

L’évolution de la conception des architectures vers du serverless et/ou du container

Vous tirerez le meilleur parti du cloud (efficacité financière), lorsque la capacité utilisée sera directement alignée avec le besoin de capacité à tout moment de votre workload. L’idéal étant que vous n’ayez pas à vous occuper du paramétrage ou de l’automatisation requise nécessaire pour avoir le bon niveau de capacité au bon moment. 

C’est en quelque sorte le principe du “serverless” : vous définissez votre code, le type d’évènement sur lequel il doit être déclenché et vous n’avez plus à vous occuper que sur certains créneaux horaires, il sera déclenché quelques centaines de fois par seconde et sur d’autre quelques milliers ou millions de fois. C’est AWS qui s’occupe d’aligner les capacités requises.

Ceci justifie le fait que de plus en plus d’applications critiques basculent dans un mode serverless.

Afin de garantir la performance, depuis décembre 2019, AWS propose le dispositif “Provisioned Concurrency” qui permet d’initialiser l’environnement d’exécution des fonctions de manière à assurer immédiatement un temps de réponse optimal lorsqu’elles sont sollicitées. 

Évoluer de services IaaS vers des services managés permet également de dégager des gains en termes de charges nécessaires pour opérer des environnements : par exemple, la bascule de cluster de bases de données SQL déployées sur des machines EC2 vers des services RDS permet de réduire de manière significative les charges d’administration et d’opérations des bases.

Différents moyens permettent également d’optimiser les coûts des clusters Kubernetes sous AWS :

• Auto scaling : les deux dispositifs suivants permettent d’aligner les heures de calcul avec les réels besoin du workload
  • Cluster auto-scaler : 
    • surveille le cluster pour identifier les Pods qui ne peuvent s’exécuter faute de ressources suffisantes.
    • Détecte les noeuds qui ont été sous-utilisés et redémarre les Pods sur d’autres noeuds
  • Horizontal Pod autoscaler (HPA) :
    • Qui permet d’étendre le nombre de Pods sur la base de métriques
• Right Sizing : définition de la capacité des ressources allouées pour les containers dans les Pods. Ces ressources peuvent être ajustés à l’aide du Kube-resource-report.
• Down Scaling : Kub downscaler peut être déployé sur un cluster afin d’ajuster sa taille en fonction de l’heure
• Modèle de prix : Intégrer des instances spots dans un cluster Kubernetes permet d’optimiser de manière significative les coûts

L’optimisation des coûts de licences

Le coût des licences peut impacter largement le business case d’une migration cloud. Dans tous les cas, il est important de comprendre si votre contrat logiciel vous permet de déployer des licences sur le cloud et suivant quelles règles financières. 

Deux modèles génériques sont proposés :

• L’exécution d’instances qui intègrent les licences (frais de licences incluent dans les coûts d’instance)
• L’utilisation de licences que vous avez déjà acquises auprès de votre fournisseur logiciel : mode Bring Your Own License : BYOL).

Les grandes entreprises souhaitent généralement tirer partie des tarifs associés à leurs contrats de licences d’entreprise (ELA : Enterprise License Agreement) et utiliser le mode “Bring Your Own License” du cloud plutôt que d’utiliser des licences fournies par le fournisseur de cloud dans un mode de paiement à l’usage.

Pour les licenses Microsoft sur AWS, les licences Windows d’un contrat d’entreprise ne peuvent être activées que sur des instances dédiées (Pour être éligible, ces licences doivent être achetées avant le 01/10/2019 ou ajoutées en guise d’alignement d’une inscription d’une entreprise active qui était en vigueur avant le 01/10/2019). AWS fournit le service License Manager qui permet d’allouer un pool de licences à déployer sur le cloud et de contrôler la conformité par rapport à ce pool de manière dynamique particulièrement quand on utilise des dispositifs d’autoscaling. Ce dispositif est aussi utilisable pour des licences SQL Server déployées sur des instances dédiées. Les licences SQL Server peuvent également être déployées sur des instances EC2 partagées si vous avez un contrat Software Assurance actif au travers du programme License Mobility. Les produits éligibles à ce programme incluent SQL Server, Remote Desktop Services, System Center, Exchange et SharePoint.

Microsoft, de cette manière, utilise son dispositif “Azure Hybrid Benefits” (qui permet d’obtenir des réductions sur le déploiement de licences Windows Server et MS SQL Server sur Azure) comme un avantage compétitif important.

Concernant Oracle, la politique suivante est appliquée : un cœur virtuel doit être considéré comme un cœur physique pour la gestion des licences de programmes Oracle. Cette politique s’applique à tous les programmes Oracle aux licences accordées par processeur.

Avec Red Hat Cloud Access, vous pouvez utiliser votre contrat existant Red Hat Enterprise Linux Premium sur Amazon EC2.

Dans le cadre du Passeport Avantage, IBM autorise le déploiement de licences sur le cloud sur la base de la politique : IBM Eligible Public Cloud BYOSL.

La plupart des solutions SAP utilise un modèle de type “Bring Your Own SOftware” (BYOS) ou “Bring Your Own License” (BYOL) en termes de gestion de licences. L’utilisation de son contrat SAP existant est soumis à la note suivante. Pour les solutions qui utilisent un modèle de licences basé sur le nombre de CPU, le nombre  de coeurs virtuels EC2 (et non pas le nombre de vCPU EC2) est utilisé pour déterminer le nombre de licences requises.
Le nombre de coeurs virtuels par type d’instance EC2 est décrit dans ce document.

Ceci conclut notre article sur les bonnes pratiques d’optimisation financière sur le Cloud. Dans notre prochain article, nous verrons les outils du marché consacrés à la gestion financière Cloud.