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