mement délicate . Nous sommes passés de 465 datacenters à seulement six , en économisant au passage près de 200 millions de dollars . Du fait qu ’ un moins grand nombre de datacenters nécessite moins de réseaux , nous avons dégraissé 600 millions de dollars sur nos frais d ' opérateur . L ’ élimination de nombreuses instances SAP nous a permis de dégager environ 100 autres millions de dollars sur le coût des licences . Un milliard de dollars d ’ économies supplémentaires a enfin été réalisé grâce à la rationalisation de notre portefeuille applicatif , passant de 7 000 à 1 800 applications , conjuguée à une réduction des effectifs de 20 000 à 2 000 personnes .
Une simple étape préliminaire
À ce stade , nous étions assez satisfaits de nos progrès . Notre activité reposait sur six datacenters flambant neufs et les coûts semblaient se situer à un niveau gérable . Ce que nous ne savions pas à l ’ époque , c ' est que nous n ' en étions encore qu ' au stade de la simple mise en route .
Au cours des 18 mois nécessaires à la mise en place des nouveaux datacenters , nous avons commencé à rencontrer des problèmes de capacité . Nous avons décidé de combler cet écart avec des EcoPOD , des datacenters modulaires conteneurisés conçus par HPE et délivrant une puissance de 1 mégawatt de capacité en mode autonome . Nous avons positionné un EcoPOD à proximité de chaque datacenter , en prévoyant d ' en ajouter deux par an au cours des cinq années suivantes . Certes , cela représentait une dépense , mais considérablement moindre par rapport à l ’ ajout , voire à la construction de systèmes d ' alimentation et refroidissement pour chaque datacenter existant .
Bien que notre stratégie nous ait permis d ’ atteindre l ’ objectif souhaité et de nous doter de la capacité d ' alimentation en courant continu requise pour rester opérationnels , Meg Whitman , Présidente-directrice de HPE à l ’ époque , nous a interrogés sur notre programme et sur les indicateurs de mesure associés , dont le taux d ’ utilisation des processeurs . À ce stade , celui-ci s ' élevait à environ 10 %, soit un niveau à peine inférieur à la moyenne du secteur . Meg a alors émis le souhait que nous atteignions un taux de l ' ordre de 80 %.
Indubitablement , nous avions du pain sur la planche . En examinant notre environnement , nous avons constaté que près de 10 000 machines virtuelles ( MV ) étaient pratiquement inutilisées . La raison à cela ? C ' est que les développeurs les accaparaient . L ' approbation et la mise en service d ' une MV nécessitait en moyenne un délai de 21 jours . Mais les développeurs ne voulaient pas patienter jusque-là . Ils voulaient disposer de capacités sur place pour pouvoir commencer à travailler immédiatement , comme cela est possible aujourd ' hui dans un environnement PaaS . Ils ont donc commandé des machines supplémentaires et ce , par dizaines .
Cette constatation nous a amenés à réfléchir à la perspective d ’ une transformation encore plus grande .
Passage à l ' étape suivante
La première décision que nous avons prise a été de mettre en place un système apparenté à un cloud , que nous avons appelé un « provisionnement de plateforme hautement automatisé ». Il ne s ’ agissait pas à proprement parler d ’ un cloud . Il n ’ y avait aucune API , juste de l ' automatisation . Les développeurs pouvaient se connecter à un portail et commander des composants tels que des noyaux , du stockage , de la mémoire , un système d ’ exploitation , des bases de données intermédiaires et un équilibrage de charge . Vingt minutes plus tard , ils disposaient d ' un environnement .
Cette approche nous a aidés à gérer plus efficacement notre environnement informatique . Nous avons identifié les MV surprovisionnées , utilisé des outils d ’ automatisation et relevé de 30 % notre taux d ' utilisation . Nous sommes ainsi parvenus à éliminer le recours aux modules EcoPOD et à ramener à quatre le nombre de datacenters .
L ’ étape suivante consistait en une migration dans le cloud . Nous avons commencé par créer un cloud OpenStack sur site pour les projets de développement natifs dans le cloud , à la suite de quoi nous avons négocié le courtage des charges de travail sur Azure . La réponse positive a été immédiate . L ' ancienne méthode consistant à se fier aux ressources informatiques traditionnelles n ' inspirant que de la lassitude , nous avons entrepris de transformer la majorité de nos charges de travail .
Notre plan initial prévoyait leur dissémination des charges de travail entre quatre compartiments principaux : informatique traditionnelle , cloud privé OpenStack , cloud public et SaaS . Le premier hébergerait environ 10 % de nos applications , à savoir les ressources informatiques traditionnelles telles que les instances SAP HANA , les grands systèmes HP-UX sur lesquels tourne notre plateforme EDW , et un système mainframe IBM devant être maintenu sur site . Tout le reste serait confié au cloud OpenStack ( 10 %), au cloud public ( 60 %) et à des applications SaaS ( 20 %).
Au final , nous avons fait migrer davantage de charges de travail vers nos solutions de cloud sur site ( environ 50 %) et beaucoup moins vers le cloud public ( 10 %). Le problème résidait dans l ' absence de plan de gestion des coûts tout au long de ce processus . Les coûts du cloud public commençaient à gonfler et nous ne désactivions pas assez rapidement nos machines virtuelles pour récolter les économies qui nous permettraient de passer rapidement au stade des déploiements du cloud public . Par crainte de l ' échec , nous avons donc revu à la baisse nos efforts en matière de cloud .
34 | THE DOPPLER | ÉTÉ 2018