La facture cloud public, variable par nature

Avec le cloud, beaucoup d’entreprises découvrent des évolutions et des fluctuations surprenantes de leurs factures. Pour une société habituée aux lignes budgétaires fixes et aux amortissements liés aux investissements programmés, la comptabilité du cloud public est déstabilisante, au point d’oublier les raisons de ce choix technologique, comme l’exploitation de tout le potentiel de l‘infrastructure, avec plus de granularité et l’amélioration de la rentabilité. Avec le cloud et, contrairement aux hébergements dit « traditionnels », l’entreprise dispose de services en haute disponibilité, de mécanismes de remédiation automatique, de l’autoscaling¹, et des bases de données managées. Et, à n’en pas douter, bien peu de développeurs ayant migré vers le cloud souhaiteraient revenir aux modèles traditionnels.

Parce qu’elle s’adapte aux fluctuations, la facturation du cloud provider est fortement corrélée à l’activité sur la plateforme. En toute logique, la facture d’un cloud provider doit augmenter si la croissance est au rendez-vous. Ainsi et par exemple, plus le e-commerçant vend, plus sa consommation cloud s’accroît. C’est un indicateur pertinent de l’état de santé d’une société. Une note relativement stable, au contraire, laisserait entendre une stagnation du chiffre d’affaires.

S’il est donc bien un aspect sur lequel les entreprises sont alertées quand elles décident d’opter pour le cloud public, c’est la spécificité de sa facturation. Elle sera variable, c’est l’essence du cloud public. Pay as you use, la maxime du cloud gravée au fronton de son temple, n’est cependant pas toujours bien assimilée. Pour nombre d’entreprises encore aujourd’hui, d’anciennes habitudes ont la vie dure. Il n’est pas rare d’oublier le décommissionnement d’instances non-utilisées qui alourdissent inutilement le prix à payer.

Quelques notions derrière le facturable

La flexibilité du cloud public a l’avantage d’avoir un socle très fin et modulaire. Ainsi, il est possible d’agir sur de nombreux leviers techniques. Reste que tout est facturable. C’est une particularité qui peut surprendre et fausser l’analyse.

En voici deux exemples caractéristiques : les infrastructures sont réparties sur plusieurs sites du cloud afin d’assurer leur résilience. C’est à ce titre que les flux internes au réseau du cloud provider sont facturés. C’est aussi la relative méconnaissance de l’existant qui empêche, au moins en partie, de connaître le prix exact du ticket d’entrée dans le cloud. Basé au départ sur une estimation, le montant n’est confirmé qu’au moment de la facturation. Voilà pourquoi il est indispensable de tenir à jour son inventaire, de dépiler, de révéler chaque couche d’infrastructure de façon à faire apparaître les redondances et les instances éphémères et permanentes.

Outre l’architecture et les usages, des éléments externes peuvent également impacter la facturation. Le trafic généré par les bots en est un. Quelques fois illégitimes, les bots peuvent représenter jusqu’à 40% du trafic.

Le processus FinOps, continu, itératif et complexe

L’objectif FinOps, bien au-delà d’établir une ventilation des coûts par « business ou operation unit » et par environnement (ce qu’il fait également), est de déterminer les moyens disponibles pour contrôler ou réduire les coûts induits par la consommation du cloud. Il s’agit d’une démarche d’ingénierie. Elle vise à explorer l’ensemble de l’architecture existante et est capable, d'établir le degré de verbosité des technologies exploitées, de mettre en exergue les dérives de consommation, d’en expliquer les raisons et de préconiser de nouvelles solutions techniques répondant aux exigences fonctionnelles et surtout business.

On comprendra aisément que FinOps est un processus. Il est continu, itératif et peut devenir complexe avec le temps. Son caractère continu tient à la nature du cloud et à sa consommation, qui sont évolutives par nature. Seuls les résultats de l’évaluation des effets d’un changement conditionnent les étapes suivantes.

C’est aussi pourquoi le processus est itératif. Il permet d'isoler avec précision les services les plus impactants.

Complexe, le processus FinOps est appelé à le devenir s’il n’y a pas un juste équilibre entre les bénéfices financiers et la prise de risque technique et/ou de temps hommes. Quelques exemples devraient éclairer ce concept.

Les mesures, entre économies et risques

L’absence d’une gouvernance spécifique au cloud est certainement un des premiers écueils à corriger. Son impact sur la consommation est décisif, sans entraîner de prise de risque particulière.

C’est en somme un panel de bonnes pratiques dont l’entreprise doit disposer. Parmi elles, se trouvent les décisions à prendre comme les délais de conservation et de récupération des backups, ou encore la granularité idéale déterminée en fonction des environnements.

Pour aller encore plus loin, il faut savoir tirer profit de la guerre des prix entre cloud providers et rendre une partie de son architecture déplaçable d’un cloud à l’autre. Mais attention, l’interruption de connexion impacte la production, la source de revenus en d’autres termes. Le degré de complexité de chaque action à mettre en œuvre doit être regardé en fonction de son coût et des économies engendrées.

Ainsi, le « refactoring »² de code, aussi efficace qu’il puisse être, n’est pas toujours une bonne opération. A l’inverse, sachons nous méfier d’une technologie au faible coût d’entrée si son impact majeur sur le trafic en annule les avantages obtenus à l’achat. Les préconisations FinOps ont justement pour but d’éclairer la DSI sur les arbitrages à opérer. Le cloud public offre de nombreux leviers et sa versatilité permet de déplacer le curseur, entre performance, haute disponibilité et économies aussi souvent que de besoin, au rythme voulu. Aborder le cloud sous l’angle FinOps revient à exploiter pleinement cette technologie en la comprenant jusque dans ses moindres détails.

Par Thomas Labarussias, ingénieur FinOps chez Claranet

¹ Autoscaling : service de dimensionnement automatique permettant d’identifier les ressources sous-utilisées et de réduire les coûts du cloud public.
² Refactoring : Modifier un code source de façon à en améliorer la structure, sans que cela modifie son comportement fonctionnel.