The Doppler Quarterly (FRANÇAIS) Édition spéciale 2019 - Page 94

datacenters nécessite moins de réseaux, nous avons dégraissé 600 millions de dollars sur nos frais d'opérateur. L’élimination de 100 instances SAP nous a permis de dégager environ 100 mil- lions de dollars sur le coût des licences. Un milliard de dollars d’économies supplémentaires a enfin été réalisé grâce à la ratio- nalisation 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 de notre fab- rication qui délivrent une puissance de 1 mégawatt d’alimentation chacun. 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. Cette dépense certes conséquente était toutefois bien inférieure à celle de l’acquisition de nouveaux datacenters. Nos équipes étaient satisfaites de notre stratégie, contrairement à notre directrice. Meg Whitman, la PDG de HPE de l’époque, a remis en cause notre plan et ses éléments de mesure, comme l’utilisation des processeurs. À ce stade, celle-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'or- dre de 80 %. Indubitablement, nous avions du pain sur la planche. En exam- inant notre environnement, nous avons constaté qu’environ 10  000  machines virtuelles (MV) étaient pratiquement inutil- isées. La raison à cela ? C'est que les développeurs les accapara- ient. L'approbation 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 pou- voir commencer à travailler immédiatement, comme cela est pos- sible aujourd'hui dans un environnement PaaS. Ils ont donc com- mandé 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’exploita- tion, 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 envi- ronnement informatique. Nous avons identifié les MV surprovi- sionné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 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 sur site n'inspirait que de la lassitude, et nous avons donc entrepris de déplacer la majorité de nos charges de travail vers le cloud. Notre plan nécessitait la dissémination des charges de travail en quatre niveaux. Le premier hébergerait environ 10 % de nos appli- cations, à savoir les ressources informatiques traditionnelles telles que les instances SAP HANA et les mainframes IBM, qui devaient être maintenues sur site. Tout le reste serait confié aux MV du cloud OpenStack (10 %), au cloud public (60 %) et à des applica- tions SaaS (20 %). Au final, nous avons fait migrer bien plus de nos charges de travail vers OpenStack (environ 50 %) et beaucoup moins vers le cloud public (10 %). Le problème résidait dans l'absence de plan de ges- tion 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. Compréhension des causalités C’est là que le modèle économique de CTP aurait pu être utile. 92 | THE DOPPLER | ÉDITION SPÉCIALE 2019