Comment réduire les déchets du cloud : 3 solutions pratiques

Introduction

La plupart des équipes ne dépensent pas trop dans le cloud à cause d’une grosse erreur. Ils dépensent trop à cause de dizaines de petits problèmes que personne ne revient réparer. Un serveur de test a fonctionné pendant un long week-end. Une base de données dimensionnée pour le trafic qui n’est jamais apparu. Un seau de stockage rempli de sauvegardes d’un projet livré il y a deux ans. À eux seuls, aucun de ces éléments n’en vaut la peine. Additionnés sur l’ensemble d’un compte, ils peuvent tranquillement engloutir un tiers de la facture.

Les enquêtes du secteur estiment depuis des années les dépenses inutiles dans le cloud à environ 30 %, et ce chiffre bouge à peine. Ce qui est encourageant, c’est que la plupart reviennent sans migration ni nouvel outil sophistiqué. Cela se résume en réalité à trois habitudes : désactiver ce que personne n’utilise, adapter la taille des ressources à la demande réelle et éliminer les éléments que tout le monde a oubliés.

Ce que signifie réellement le gaspillage du cloud

Le gaspillage du cloud est l’argent que vous dépensez pour des ressources qui n’apportent que peu ou pas de valeur. Ce n’est pas la même chose qu’une facture élevée. Une facture élevée peut être parfaitement juste si l’usage qui la sous-tend est réel. Le gaspillage est l’écart entre ce que vous payez et ce que vous utilisez réellement.

Cela a tendance à se manifester de trois manières :

• Des ressources inactives qui fonctionnent 24 heures sur 24 mais qui ne sont nécessaires que pendant les heures de bureau, voire pas du tout.
• Des ressources surprovisionnées qui ont été dimensionnées pour le pire des cas qui ne se produira jamais.
• Ressources orphelines qui ont été déconnectées de tout ce qui est utile mais qui continuent quand même à être facturées.

Une fois que vous pouvez déterminer dans quelle catégorie se situe un coût, la solution est généralement évidente.

Correctif 1 : désactivez ce que personne n’utilise

La victoire la plus rapide est la planification. La production doit rester stable car les clients en dépendent à toute heure. Mais les environnements de développement, de test, de préparation, de démonstration et d’assurance qualité ne sont généralement touchés que pendant la journée de travail.

Regardez les mathématiques. Un serveur qui n’est utilisé que de 8 heures du matin à 20 heures du soir en semaine est véritablement utile pendant environ 60 heures par semaine. Laissez-le allumé toute la semaine et il facture 168 heures. Donc, environ 65 % du temps, il fonctionne pour rien.

Vous n’êtes pas obligé de tout planifier en même temps. Commencez par les environnements pouvant être interrompus en toute sécurité :

1. Comptez vos environnements hors production. La plupart des équipes sont surprises du nombre dont elles disposent une fois qu’elles ont réellement regardé.
2. Choisissez un horaire par défaut. Allumé à 8 heures du matin, éteint à 20 heures et complètement arrêté le week-end est un début judicieux. Vous pourrez le desserrer plus tard.
3. Automatisez l’interrupteur marche/arrêt pour que personne n’ait à s’en souvenir. Chaque grande plate-forme cloud vous permet de démarrer et d’arrêter des ressources selon une minuterie, et un petit script planifié peut le gérer.
4. Donnez aux gens un remplacement facile. Un ingénieur qui a besoin de l’environnement à une heure impaire devrait pouvoir le réveiller en un clic. Les frictions sont ce qui tue ces politiques, alors éliminez-les dès que possible.

L’habitude qui mérite d’être prise est de considérer « toujours activé » comme un choix que vous devez justifier, au lieu des questions par défaut que personne ne pose.

Correctif 2 : dimensionnez correctement les ressources que vous continuez à exécuter

Les éléments qui doivent fonctionner en permanence sont souvent plus volumineux qu’ils ne devraient l’être. Lorsque quelqu’un fait tourner un serveur, il parie généralement haut, juste pour être sûr. Cette marge de sécurité devient alors permanente et vous la payez toutes les heures.

Le bon dimensionnement signifie simplement adapter les ressources à leur charge de travail réelle plutôt qu’à celle imaginée.

Veuillez examiner l’utilisation réelle sur quelques semaines, pas seulement sur un seul après-midi. Quelques signaux qui pointent vers le gaspillage :

• CPU moyen à un chiffre. Si une machine dépasse rarement 10 à 15 pour cent, elle est presque certainement trop grosse.
• La mémoire allouée est bien supérieure à celle utilisée. Une base de données avec 64 Go de RAM qui ne dépasse jamais 12 Go paie pour une marge dont elle n’aura jamais besoin.
• Les disques rapides restent intacts. Le stockage à grande vitesse est logique pour une base de données chargée, et non pour un volume de journaux sur lequel on écrit de temps en temps.

Le moyen le plus sûr d’y parvenir est de réduire une taille à la fois et d’observer les performances pendant une semaine avant d’aller plus loin. Vous voulez la plus petite taille qui gère confortablement vos vrais sommets. Et ce sont les pics qui comptent, donc une taille adaptée au lundi matin chargé, pas au dimanche soir calme.

Un avertissement mérite d’être dit à voix haute : ne dimensionnez pas la production au cours d’une semaine lente. Vérifiez que votre échantillon couvre réellement vos points forts normaux, sinon vous réduirez la capacité dont vous avez réellement besoin.

Correctif 3 : traquer les dépenses oubliées

C’est la catégorie la moins passionnante et souvent la plus gratifiante. Les ressources orphelines sont celles qui ont été coupées de tout ce qui était utile mais qui n’ont jamais été supprimées. Ils n’ajoutent aucune valeur et ne déclenchent aucune alarme. Ils continuent simplement à facturer.

Les suspects habituels :

• Volumes de stockage non connectés. Vous supprimez un serveur, mais son disque reste en suspens car il n’a pas été configuré pour être supprimé à côté de lui. Maintenant, il reste vide, ce qui vous coûte chaque mois.
• Anciens instantanés et sauvegardes. Les sauvegardes automatisées sont saines. Conserver chaque instantané de chaque projet depuis le lancement de l’entreprise ne l’est pas. Définissez une fenêtre de rétention et respectez-la.
• Équilibreurs de charge inactifs et adresses IP. Ceux-ci entraînent de petits frais horaires, qu’ils soient ou non traversés par du trafic. Quelques restes de projets retirés s’additionnent.
• Environnements de test abandonnés. La preuve de concept construite par quelqu’un pour une démo client il y a deux ans, est toujours en cours d’exécution aujourd’hui car personne n’était sûr qu’elle pouvait être supprimée en toute sécurité.
• Calcul zombie à partir de déploiements ayant échoué. Instances qui se sont produites lors d’un déploiement bâclé et n’ont jamais été nettoyées.

Bloquez une heure une fois par mois pour parcourir le compte et poser une question simple sur chaque ressource : est-ce que quelque chose l’utilise réellement ? Si vous ne pouvez pas dire oui, signalez-le. Une bonne étape intermédiaire consiste à arrêter une ressource plutôt que de la supprimer immédiatement. Si personne ne se plaint dans une semaine ou deux, vous pouvez le supprimer définitivement en toute sécurité.

Le faire tenir

La raison pour laquelle les déchets cloud reviennent sans cesse est que ces correctifs sont traités comme des nettoyages ponctuels. Quelqu’un fait un grand balayage, économise une grosse somme d’argent, et puis la dérive recommence.

Quelques habitudes légères maintiennent les économies en place :

• Marquez tout avec un propriétaire. Lorsque chaque ressource correspond à une personne ou à une équipe, « à qui est-ce ? cesse d’être un mystère et « pouvons-nous le supprimer ? » obtient une réponse plus rapide.
• Présentez la facture aux personnes qui créent le coût. Les ingénieurs prennent de meilleures décisions lorsqu’ils peuvent voir ce que coûte réellement leurs choix.
• Gardez le nettoyage petit et régulier. Une demi-heure mensuelle bat une ruée de panique la fois où les finances demandent pourquoi la facture a augmenté.
• Définir des valeurs par défaut qui expirent. De nouveaux environnements hors production peuvent être créés avec une date d’arrêt ou de suppression automatique, de sorte que les éléments temporaires restent temporaires.

Rien de tout cela n’a besoin d’une refonte radicale. Il s’agit principalement d’un changement dans les valeurs par défaut. Éteint au lieu d’allumer. De bonne taille au lieu de surdimensionné. Supprimé au lieu d’oublié.

Pensées finales

Réduire le gaspillage du cloud ne consiste pas à courir après chaque centime ou à fragiliser vos systèmes. Il s’agit de ne pas payer pour des choses que l’on n’utilise pas. Commencez par un changement à la fois simple et réversible : planifier la fermeture de vos environnements hors production en dehors des heures de travail, et vous le verrez probablement sur la toute prochaine facture.

À partir de là, parcourez la liste. Dimensionnez correctement ce qui reste, balayez les ressources orphelines une fois par mois et donnez à tout un propriétaire afin que la dérive ne réapparaisse pas. Les équipes qui restent maigres ne sont pas celles qui disposent des outils les plus sophistiqués. Ce sont eux qui ont réalisé « Avons-nous encore besoin de ça ? » une question normale à poser.