zierten sich die Netzwerkgebühren um 600 Mio . USD . Durch den Verzicht auf eine Reihe von SAP-Instanzen konnten wir etwa 100 Mio . USD an Lizenzgebühren einsparen . Weitere Einsparungen von über 1 Mrd . USD ergaben sich aus der Verkleinerung unseres Anwendungsportfolios von 7.000 auf 1.800 Anwendungen und der Reduzierung des IT-Personals von 20.000 auf 2.000 Mitarbeiter .
Das ist erst der Anfang
Zu diesem Zeitpunkt waren wir mit unserem Fortschritt sehr zufrieden . Die Unternehmens-IT lief mit Unterstützung von sechs brandneuen Rechenzentren , und die Kosten bewegten sich anscheinend in einem überschaubaren Rahmen . Das wussten wir zu dem Zeitpunkt noch nicht , aber wir befanden und erst am Anfang .
Innerhalb von 18 Monaten wurde die Kapazität der neuen Rechenzentren knapp . Wir beschlossen , die Lücke mit EcoPODs , d . h . modularen , containerisierten Rechenzentren , zu schließen , die von HPE gefertigt werden , eigenständig sind und Leistung im MW-Bereich abliefern . Jedes Rechenzentrum wurde durch einen EcoPOD unterstützt . Außerdem planten wir , die Kapazität in den nächsten fünf Jahren durch zwei weitere EcoPODs pro Jahr zu erhöhen . Obwohl Kosten entstanden , lagen diese weit unter denen für den zusätzlichen Ausbau und die Kühlung bestehender Rechenzentren oder den Bau neuer Anlagen .
Unsere Strategie , zusätzliche RZ-Kapazität zur Aufrechterhaltung des Betriebs bereitzustellen , zahlte sich aus . Allerdings wollte zu diesem Zeitpunkt auch Meg Whitman – damals CEO bei HPE – Näheres zu unserer Planung und den Kennzahlen erfahren – beispielsweise zur CPU-Auslastung . Zu dieser Zeit lag unsere CPU-Auslastung bei ungefähr 10 Prozent , also etwas unter dem Branchendurchschnitt . Meg Whitman strebte allerdings eine Auslastung von 80 Prozent an .
Es gab einiges zu tun . Ein Blick auf unsere Umgebung reichte aus , um festzustellen , dass wir über fast 10.000 virtuelle Maschinen ( VMs ) verfügten , die praktisch nicht genutzt wurden . Der Grund ? Entwickler hatten einen Sicherheitsvorrat angelegt . Die Genehmigung und Bereitstellung einer virtuellen Maschine dauerte im Schnitt 21 Tage . Unsere Entwickler wollten nicht so lange warten . Sie benötigten Kapazitäten , um direkt mit der Entwicklung loszulegen , was heute dank PaaS kein Problem mehr ist . Was lag näher , als zusätzliche – viele zusätzliche VMs zu horten ?
Das war unser Denkanstoß für eine umfangreichere Transformation .
Der nächste Schritt
Als Erstes richteten wir ein cloud-ähnliches System ein , das wir als hochautomatisierte Plattformbereitstellung bezeichneten . Dabei handelte es sich nicht wirklich um eine Cloud . Es gab keine APIs , nur den Automatisierungsmechanismus . Entwickler konnten auf einem Portal Kerne , Speicherkapazität , Arbeitsspeicher , ein Betriebssystem , Middleware-Datenbanken und Lastenausgleich ordern . Zwanzig Minuten später war die Umgebung startklar .
So ließ sich die IT-Umgebung wesentlich besser verwalten . Wir identifizierten überdimensionierte VMs , setzten Automatisierungstools ein und steigerten die Auslastung um 30 Prozent . Außerdem benötigten wir keine EcoPODs mehr und verkleinerten uns auf vier Rechenzentren .
Das nächste Ziel war der Umstieg in die Cloud . Wir starteten vor Ort mit einer OpenStack-Cloud für cloud-native Entwicklungsprojekte und begannen dann mit dem Workload-Brokering in Azure . Wir erhielten sofort positive Resonanz . Keiner wollte mehr mit den herkömmlichen IT-Ressourcen arbeiten . Daher setzten wir ein Projekt für die mehrheitliche Transformation unserer Workloads auf .
Zunächst mussten die Workloads auf vier zentrale Buckets verteilt werden : traditionelle IT , OpenStack Private Cloud , Public Cloud und SaaS . Auf den ersten Bucket entfielen ca . 10 Prozent unserer Anwendungen – traditionelle IT-Ressourcen wie SAP HANA Appliances , große HPUX-Systeme für unsere EDW-Plattform und ein IBM-Mainframe , der vor Ort betrieben werden musste . Der Rest verteilte sich auf die OpenStack-Cloud ( 10 Prozent ), die Public Cloud ( 60 Prozent ) und SaaS-Anwendungen ( 20 Prozent ).
Am Ende verlagerten wir mehr Workloads in unsere Cloud-Lösungen vor Ort ( etwa 50 Prozent ) und wesentlich weniger in die Public Cloud ( 10 Prozent ). Das Problem bestand darin , dass wir während des Prozesses das Kostenmanagement vernachlässigt hatten . Die Kosten für die Public Cloud stiegen weiter , und wir waren nicht in der Lage , schnell genug VMs abzuschalten , um die Einsparungen in den schnellen Umstieg auf Public Cloud-Bereitstellungen umzulenken . Wir bekamen es mit der Angst zu tun und haben unsere Cloud-Initiative zurückgefahren .
Die Gründe verstehen
In dieser Situation hätte uns das Geschäftsmodell von CTP helfen können . HPE wollte 60 Prozent unse-
34 | THE DOPPLER | SOMMER 2018