L’évolution des prix de l’énergie, qu’on l’analyse ponctuellement à l’aune de l’actualité ou dans une perspective moyen terme, doit interroger les acteurs de la Tech.
Un article de Capital intitulé “Inflation : les data-centers vont aussi augmenter leurs prix, victimes d'une "cloud-flation" “me semble assez bien poser dans sa conclusion un des enjeux auquel nous devons répondre :
“Les experts plaident désormais pour un usage plus "vertueux" des clouds (...)”.
On observe pourtant couramment des pratiques opposées à ce postulat : que penser d’une architecture informatique qui va réveiller ses services sur le cloud à intervalles réguliers ; quand il n’y a pas de trafic le justifiant ; juste pour garantir ses performances au cas où.
Le coût de l’énergie, un puissant levier.
Les fortes augmentations des prix de l’énergie en Europe en 2022 conduisent déjà les fournisseurs de services dans le cloud - IaaS, PaaS, Saas - à revoir leur politique tarifaire. Plus généralement dans le monde, le coût de l'énergie devient une composante de moins en moins négligeable, et donc de moins en moins négligée, dans la structure de coûts des services numériques.
Les clients de ces services clouds ; qu’ils soient ou non vendor-locked(1) ; vont se retrouver logés à la même enseigne : il n’y aura pas de solution dans la mise en concurrence pour payer moins.
Le respect de la RGPD ne leur permet pas non plus de transférer la plupart de leur activité “cloud” hors zone Europe où les prix de l'énergie seraient plus faibles par exemple.
Pour de nombreuses entreprises (Startup et Scale-up en tête), diminuer l’activité de l’entreprise ne sera pas non plus une solution viable.
Une solution intermédiaire pourra consister à arrêter les services les moins utilisés, à rationaliser les parcours clients (moins de pages, moins d’images par exemple) ou à modifier les offres commerciales pour ne viser que ce qui est vraiment utile.
Il n’en restera pas moins qu’il faudra à un moment se poser la question du coût énergétique et écologique rapporté à la valeur d’usage apportée aux clients; et donc in fine au ROI de ces services.
Penser l’architecture des SI pour optimiser la ressource.
Dès lors, il semble que le seul réel impact massif ne puisse être obtenu qu’en revoyant l’architecture informatique des applications déployées sur les infrastructures cloud.
Il s’agit d’une sorte de retour aux origines des experts de la Tech qui, il y a encore 30 ans, cherchaient à optimiser à tout prix leurs architectures et leur code pour consommer le moins possible de ressources.
A l’époque, il s’agissait surtout de rendre possible les traitements informatiques sur des matériels pas assez puissants, dotés d’une bande passante réseau, une mémoire et un stockage limités.
Cette stratégie d’optimisation continue d’exister mais est aujourd’hui réservée sur la partie logicielle à des niches applicatives : du matériel embarqué, l’optimisation au cœur des matériels et des CPU notamment.
Les fabricants de matériels électroniques et informatiques ont également depuis plusieurs années intégré dans leur R&D le facteur consommation énergétique. Il est par exemple notable que depuis quelques années, les experts ne vont plus noter la seule performance d’un CPU mais sa performance rapportée à sa consommation énergétique.
Il semble donc anormal que le domaine de l’ingénierie logicielle, notamment dans le contexte d’applications métiers, ne se voit pas appliquer une stratégie visant à améliorer l'efficience énergétique de ce qui est développé.
L’explication de cette anomalie apparente est pourtant assez évidente.
La versatilité des clouds a poussé à la consommation.
La performance applicative pour ces applications métier est toujours un enjeu fort, mais jusqu’à maintenant, elle cherchait surtout à garantir un fonctionnement sans panne en forte charge.
Si pour garantir la robustesse d'un SI il fallait utiliser par exemple l’élasticité du cloud pour instancier 100 nouveaux serveurs pour répondre à l’afflux d’utilisateurs, ça n’était généralement pas un problème.
Et ce d’autant plus que de nombreuses architectures informatiques supportées et favorisées par certains cloud providers sont prévues pour ne fonctionner que comme cela.
Pour forcer le trait, un utilisateur équivaut à une (mini) instance de serveur ; et le postulat retenu est que le cloud est capable d’y répondre à un prix satisfaisant.
De plus, le cloud est pensé pour accompagner de manière transparente les besoins en ressources : la facture augmente progressivement au fur et à mesure que le SI est de plus en plus sollicité... et de moins en moins optimisé techniquement.
Il n’y a dans ce modèle pas d’effet de rupture de prix qui imposerait de se poser la question d’une optimisation des consommations en ressources.
Lorsque ce type de questionnement survient, c’est en général parce que la ligne budgétaire associée aux dépenses Cloud devient importante au regard des autres lignes ; indépendamment de toute autre considération.
Ainsi, tant que l’énergie et le matériel informatique sont disponibles à un prix accessible, stable voire orienté à la baisse, le seul questionnement qui se posait était finalement d’ordre éthique et RSE : ce type de choix d’architecture est-il le plus vertueux en termes de consommation de ressources ?
Malgré la prise de conscience sur ces sujets RSE, il reste très rare qu'une décision ne repose que sur ces critères dès lors qu'elle génère un sucoût notable...
L’utilisation vertueuse des clouds sera un enjeu déterminant.
Avec l’orientation à la hausse des prix de l’énergie, la raréfaction de certaines ressources, il semble maintenant essentiel que l’industrie de la Tech, en particulier celles et ceux qui conçoivent les architectures informatiques et développent le code, s’interrogent sur ce que veut dire “un usage plus "vertueux" des clouds” et les impacts sur les choix techniques effectués.
Vertueux renvoie évidemment à des considérations d’ordre éthique et RSE.
Vertueux renvoie également à quelque chose de plus prosaïque :
“combien ça coûte,
est ce que ça ne pourrait pas coûter moins,
est ce que ça ne devrait pas coûter moins ?”
La maîtrise des coûts informatiques, et en particulier de ceux associés aux services consommés sur le cloud, devrait donc prendre encore plus d’importance ; sous la triple dynamique : efficience environnementale / ROI / Positionnement concurrentiel.
Autrement dit, la DSI, les Directions Métiers et la Direction RSE vont être contraintes de s'aligner sur un objectif commun : économiser des ressources informatiques.
Vertueux = économiser les ressources informatiques.
A iso activité, une entreprise ne peut finalement s’appuyer que sur deux axes pour économiser les ressources informatiques :
- L'entreprise compte sur les fournisseurs de service dans le cloud qu’elle utilise pour optimiser ses services.
- L'entreprise fait évoluer et optimiser ses architectures applicatives pour être plus efficientes.
Le premier axe correspond à encourager les entreprises à intégrer dans leurs mises en concurrence un facteur de pondération plus important sur le critère d’évolution de la consommation de ressource par le fournisseur du service.
Ce n’est pas une analyse statique comme on peut l’avoir sur le prix : “combien ça nous coûte maintenant et pour la durée du contrat”.
Il s'agit bien ici d'une approche dynamique : “démontrez moi par des indicateurs mesurés que vous êtes dans une démarche de moindre consommation pour délivrer un service donné.”
Pour autant, faire uniquement peser cette responsabilité sur le fournisseur de service cloud est une erreur qui risque de peser lourd.
En effet, le plus gros impact sur la consommation de ressources cloud réside dans la manière dont il est utilisé ; et il n'y a pas de débat à ce sujet !
S'il y a débat, c'est bien sur les choix d'architecture informatique à faire, en lien avec ce qui est conseillé par le fournisseur de cloud : faut-il nécessairement suivre le discours technico/marketing environnant ?
Prenons un exemple générique : depuis des années, les clouds providers vantent l’élasticité de leurs services et conseillent des architectures applicatives qui vont favoriser cette élasticité sur leur propre infrastructure.
Suivre ces conseils peut conduire à deux compromis :
- L’architecture retenue est spécifique au cloud provider. On parle de “vendor-locking”.
- Favoriser l’élasticité, c'est favoriser au final la consommation de ressources suivant un pattern qui convient au cloud provider et qui lui permet de facturer simplement ladite consommation.
Ces compromis ne sont en aucun cas ni une fatalité ni une erreur : ils correspondent à un choix à un moment.
Ce qui serait une erreur serait sans doute de ne pas rapidement revoir cet équilibre en considérant avec plus d’acuité ce qui peut être demandé à la DSI vis à vis des architectures applicatives, des technologies et frameworks employés ; non pas uniquement par rapport à ce que tel ou tel fournisseur de cloud conseille, mais de manière plus agnostique, plus générique, plus globale.
Le CTO est le sponsor et le premier responsable d’un SI efficient.
Le CTO porte la responsabilité de cette évolution : il doit contribuer à expliquer à ses équipes la nécessité de revoir certains choix techniques.
Il doit fixer des objectifs mesurables, non liés à des enjeux imposés par des tiers. Par exemple, il vaut mieux fixer un objectif en terme de consommation CPU, réseau, stockage pour un acte de gestion ; que de le fixer en coût in fine pour tel fournisseur de cloud.
En effet, dans ce dernier cas, on ne mesure pas l’efficience de l’application. On mesure en fait l’efficience de l’application vis à vis du pricing, donc du business model du cloud provider. Si ce dernier change, toutes les métriques sont faussées.
Plus concrètement, les CTO devront inciter leurs équipes techniques à moins reposer sur l’élasticité pour assurer un niveau de performance et de robustesse en charge.
Cela revient à les encourager à créer du code intrinsèquement moins consommateur en ressources, mutualisant les traitements et éliminant finalement les traitements inutiles.
Comprendre la différence entre un code/architecture performant et un code/architecture efficient est ici fondamental : la performance brute ne passe pas nécessairement par l’efficience puisque par exemple une architecture scalable sera très performante en mobilisant automatiquement le nombre de serveurs nécessaires !
L’efficience est en effet le fait de limiter intrinsèquement l’usage des ressources pour un niveau de service donné, en s’appuyant par exemple sur des bonnes pratiques adaptées qui sont de plus en plus associées à la notion de green code. Mais une architecture ou un code efficient pourra s’avérer non scalable et donc in fine incapable d’atteindre les objectifs de performance.
Autrement dit, les CTO doivent absolument intégrer à la fois des enjeux de performance et d’efficience dans les consignes qu’ils donnent ; et parfois arbitrer l’un au détriment de l’autre.
Il faudra aussi continuer à renforcer les approches Devops/Gitops ; notamment en mettant au cœur de ces processus des logiques de tests de performances systématiques en tendance qui produisent des indicateurs sur lesquels repose au moins partiellement la décision de passer en Production la nouvelle version applicative.
La formation des équipes techniques est également un puissant levier sur lequel les CTO pourront s’appuyer en favorisant tant en formation continue qu’en formation initiale celles qui intègrent une composante sur l’efficience énergétique des architectures informatiques.
L’émergence de nouveaux métiers comme le FinOps n’est pas un hasard dans cette perspective : la compréhension de la structure de coûts informatiques et liés à l’usage des clouds en particulier, le conseil en investissement dans les infrastructures informatiques opérés dans le cadre d’une démarche FinOps doivent permettre in fine de réduire les consommations énergétiques. Le gain est évidemment financier, il est aussi écologique dès lors que le FinOps a aussi agi sur le coût brut en ressources pour fournir un service donné.
Il est important de ne pas mesurer la performance d’une démarche FinOps uniquement sur le gain financier, mais aussi sur un KPI de type RSE lié exclusivement à du non financier et en particulier aux consommations de ressources énergétiques pour assurer un service fonctionnel donné.
Le sujet peut également être élargi à d’autres acteurs de l’entreprise : un Product Owner doit être conscient que chacune de ses demandes générera de la consommation de ressources. De même, le responsable Marketing doit comprendre que viser un TTM le plus bas possible laisse moins de temps pour optimiser les services créés.
Les comités de Direction doivent également intégrer qu’ils doivent accepter de déplacer du budget lié aux nouveaux marchés et produits, vers un budget d’investissement lié à ces économies de ressources : optimiser un logiciel coûte actuellement plus cher que rajouter un serveur ou s'appuyer sur l'élasticité des clouds providers.
Je terminerai (presque) comme j’ai commencé : nous devons désormais plaider pour un usage plus "vertueux" des clouds en ayant bien en tête que les évolutions que cela implique sur les architectures informatiques nécessitent une démarche proactive, de l’investissement, du temps, de l’expertise et de la ténacité.
Performance et efficience sont maintenant indissociables !
(1) vendor-locked : se dit généralement d’un choix technologique lié à un fournisseur de solutions techniques qui va impliquer qu’il sera coûteux ou difficile de se passer de ce fournisseur.
Concrètement, si une architecture informatique s’appuie sur des spécificités d’un cloud provider, il ne sera plus possible de basculer vers un autre prestataire de cloud.
