La migration vers le Cloud, c’est à dire sur les infrastructures proposées par les Hyperscalers (AWS, Google GCP, Microsoft AZURE) et vers son modèle à la consommation impose aux DSI une nouvelle gouvernance des coûts. C’est la démarche FinOps qui, pour être pleinement efficiente, doit conjuguer design d’architecture et optimisations permanentes. Une approche qui s’étend aujourd’hui aux environnements SAP.
Les études sont formelles : si les DSI se tournent assez massivement vers le Cloud, ils sont nombreux à s’inquiéter des dérives de coûts qu’ils constatent avec ce nouveau modèle de consommation des ressources IT. « Le Cloud doit s’accompagner d’un changement de comportements, résume Jérôme Mollier-Pierret, directeur infogérance SAP de PASàPAS. On passe à un modèle à la consommation, comme avec le réseau d’eau. Or, si on oublie de fermer le robinet, la facture grimpe très vite. Pour les DSI, habitués à l’infogérance et à ses coûts connus d’avance, c’est un nouveau point d’attention. » La remarque vaut aussi pour les équipes d’architecture, habituées à surdimensionner les infrastructures pour diminuer les risques pour les solutions SAP souvent critiques pour la survie de l’entreprise.
D’autant que le modèle à la consommation possède ses caractéristiques propres, qu’il faut appréhender. Notamment car les bases de la facturation – on parle d’inducteurs, qui servent de paramètres de calcul – changent en fonction de la nature des services. « Il faut comprendre les concepts manipulés par les prestataires et, ensuite, appliquer une gouvernance stricte », reprend Jérôme Mollier-Pierret. S’y ajoute, dans le cas d’un service de bout en bout, le découplage entre les infrastructures, facturées par le prestataire de Cloud, et les services managés opérés sur ces infrastructures. C’est en tout cas le modèle que privilégie PASàPAS, pour donner davantage de flexibilité aux entreprises (même si le prestataire sait aussi gérer des contrats globaux). « Dans l’infogérance, les volets infrastructures et maintien en conditions opérationnelles sont imbriqués » explique Brian Passante, le CTO Infogérance de la société.
Jouer sur la durée d’engagement, faire des avances de trésorerie
Avec ce modèle, pour ne pas voir la facture s’envoler, la DSI doit apprendre à changer de pratique, à utiliser pleinement les capacités du Cloud. « Aborder le Cloud comme une commodité conduit invariablement à un accroissement des coûts par rapport à une infogérance classique, dit Jérôme Mollier-Pierret. Les microservices sont associés à des inducteurs de coûts très différents de ceux proposés dans l’infogérance, avec une facturation à l’heure, voire à la minute. Il faut savoir profiter de cette flexibilité. Et il est aussi possible d’optimiser les coûts en jouant sur la durée d’engagement ou en consentant des avances de trésorerie aux fournisseurs, qui gagnent ainsi en visibilité et accordent en conséquence des tarifs avantageux ». C’est l’enjeu le plus évident de la démarche FinOps : instaurer une gouvernance financière des opérations sur les infrastructures proposées par les Hyperscalers.
Mais ce n’est pas le seul. Les FinOps ne se limitent pas à l’optimisation et à la surveillance financière des opérations, car la facture dépend aussi largement du design des microservices composant les architectures et de la manière d’opérer. Il s’agit ici notamment d’arrêter de façon automatisée et industrielle les systèmes dormants ou encore de profiter de la haute disponibilité proposée par les fournisseurs pour alléger l’existant, en conservant quasiment le même temps de réponse qu’avant. « Dans le Cloud, plus besoin d’aligner un système de secours dimensionné au niveau de la production. Car l’ajout de capacité en cas de sinistre est disponible immédiatement, illustre Brian Passante. La règle, c’est qu’il ne faut rien acheter en surplus ! ». Si la direction est claire, s’y tenir reste complexe car il faut réunir une expertise technique, une expertise technico-financière et gagner en expérience sur les différentes plates-formes des Hyperscalers. « Or, il n’existe pas de recettes de cuisine qu’on peut appliquer en l’état, reprend Brian Passante. Même si des outils de suivi financier existent, parfois proposés par les opérateurs du Cloud eux-mêmes, ces abaques doivent être contextualisés en fonction de chaque cas –applicatif ou organisationnel, ce qui nécessite une expertise pointue. »
Arrêter 30% de ses instances la nuit suffit
C’est évidemment le cas avec les environnements SAP. Les applications de l’éditeur d’ERP, assez statiques, n’apparaissent pourtant pas comme les meilleures candidates pour un hébergement de type Cloud.
S’engager sur la durée permet d’optimiser les coûts, c’est évidemment le cas avec les environnements productifs SAP. Mais c’est sans compter sur les environnements de développement, de tests, de mise en qualité, mais aussi parfois de formation qui accompagnent les systèmes en production qui peuvent être optimisés autrement. « Sur une infrastructure SAP classique – un paysage, cette duplication des environnements mobilise typiquement de 3 à 5 instances. Si, sur le Cloud, on parvient à en arrêter 30% durant la nuit, l’équation économique est au rendez-vous », explique Jérôme Mollier-Pierret. A cette première optimisation, s’ajoute la possibilité d’exploiter les services que les principaux fournisseurs mettent à leur catalogue.
AWS, AZURE et GCP peuvent ainsi offrir jusqu’à 5 types de stockage différents. Une opportunité pour sélectionner le service le plus optimisé – dans le respect des abaques de l’éditeur -, afin d’alléger la facture. Par exemple, en optant pour un disque à bas coût pour sortir les sauvegardes avant de les basculer sur un autre service Cloud. « S’y ajoute l’apport technologique de PASàPAS, notamment la déduplication des backups pour limiter un peu plus la consommation de stockage », glisse Brian Passante.
Dans les environnements SAP aussi, la démarche FinOps vise bien à jeter ce pont entre l’architecture IT et la vision économique, la capacité à dimensionner la solution au plus juste. Deux dimensions dont il faudra évidemment assurer le suivi, pour vérifier l’adéquation dans le temps de la solution aux besoins. « En complément, il faut toujours garder à l’esprit les questions de RPO (Return Point Objective, l’objectif en termes de restauration) et de RTO (Return Time Objective, durée maximale d’interruption admissible), car l’assemblage des services de base doivent être pensés dans cette optique. Des compétences spécialisées sur les opérations sont ici nécessaires », reprend le responsable.
PASàPAS : le choix du multicloud
PASàPAS a fait le choix d’étendre sa démarche FinOps aux différentes plates-formes des Hyperscalers. « Notre conviction, être résolument multicloud – pour garantir notre indépendance, proposer le meilleur à nos clients et préparer l’avenir -, nous impose de disposer d’expertises sur chacun des différents opérateurs du marché, note Jérôme Mollier-Pierret. Ce qui nous permet d’exploiter les meilleurs services sur chaque plate-forme. » Le prestataire spécialiste de SAP aligne ainsi déjà des références en production sur chacun des trois grands Opérateurs du marché (AWS, Azure et GCP). Et tous les outils que PASàPAS développe sont, de ce fait, agnostiques vis-à-vis de ces grandes plates-formes. Constat qui vaut tant pour les outils techniques que ceux dédiés au suivi financier. Le prestataire, qui propose déjà des éclatés des factures des grands fournisseurs de Cloud, prévoit de fournir davantage de services sur l’analyse et le suivi temps réel de la consommation.
PASàPAS www.pasapas.com
