TCO in der Innovation

Die Verarbeitung der Daten durch In-memory-Computing erfordert für die Hana-Datenbank deutlich mehr Arbeitsspeicher, entsprechende CPUs und Cores sowie sehr schnellen Flash-Speicher.

Die üblichen Mechanismen der Verfügbarkeit in der Virtualisierung stoßen ebenfalls an ihre Grenzen und viele SAP-Bestandskunden müssen sich wieder Gedanken über dedizierte und zertifizierte Appliances machen.

Das heißt, wir bewegen uns technologisch eigentlich wieder weg von der Virtualisierung, welche vor über zehn Jahren seinen Siegeszug hatte – hin zu starren, unflexiblen physikalischen Maschinen.

Hana Data Center Integration

Wer Hana auf seiner bestehenden virtuellen IT-Infrastruktur laufen lassen will, muss die SAP-Vorgaben strikt einhalten und entsprechende dem „Hana Tailored Data Center Integration Guide“ kompatible Hardware wie Server, Storage, Netzwerk und Virtualisierung einsetzen.

Zwar gibt es nun im neuen Hana-­TDI-Guide die Möglichkeit, die CPU-Cores weiter zu reduzieren, und insbesondere kann man durch Virtualisierung die nicht zugeordneten Ressourcen anderweitig verwenden, jedoch ist man immer von der darunterliegenden Hardware abhängig und üb­licherweise sind die Abschreibungen für IT-Hard- und Software auf fünf Jahre festgelegt.

Was nach heutigen Maßstäben und der Innovationsschnelligkeit nach drei Jahren schon ein altes Eisen ist. Wer kann ­heute von sich behaupten, ein Sizing seiner IT-Infrastruktur und SAP-Landschaft für fünf Jahre in die Zukunft zu planen?

IT-Leiter und CIOs haben diese ständige Aufgabe, zwischen Kostenbewusstsein, Flexibilität und Agilität sowie Innovationen auszubalancieren.

Im klassischen Rechenzentrum stoßen immer mehr Kunden an unüberwindbare Grenzen bis hin zu massiven Investitionen, die eigentlich getätigt werden müssten, um die nächste Innovation in der IT zu implementieren, was dann wiederum über mehrere Monate die IT-Mitarbeiter mit Projekten beschäftigt und das Business gegebenenfalls behindert, ein Produkt oder Service einzuführen.

Das Dilemma dabei: Die Fachbereiche wissen mittlerweile, wie man per Kreditkarte Cloud-Services konsumiert, und sie warten nicht, bis jemand einen Server bestellt und eingebaut hat.

Ein Vergleich zum Auto: Eigentlich wollen wir einfach nur Auto fahren und nicht vorher dafür immer neue Straßen, Brücken und E-Ladesäulen zu bauen. Infrastruktur ist notwendiges Übel, aber die eigentliche Innovation und der Mehrwert sollten in der Software (Auto), den Prozessen und dem Wissen der Mitarbeiter liegen und nicht im Blech (Straße). Oder?

Totes Blech versus Cloud

Was hat das alles jetzt mit TCO und SAP on Azure zu tun? Ziemlich viel sogar! In den nächsten Absätzen werden wir beleuchten, warum es wichtig, ist sich aus dem „toten“ Blech hin zu einer Software-Plattform wie Microsoft Azure zu bewegen, und warum dort interessante TCO-Aspekte für den Betrieb und die Integration von SAP-Landschaften liegen.

Wie unterscheidet sich der SAP-Betrieb auf Azure von meinem Rechenzentrum? Der Betrieb und das Hosting können sich von einem klassischen Rechenzentrum zum Vergleich auf der Microsoft-Azure-­Cloud-Plattform nicht unterscheiden.

Aber: Ich deploye über Azure eine virtuelle Maschine mit der notwendigen Größe und SAP-Zertifizierung, ordne ihr entsprechenden Speicher zu, installiere vorher ein virtuelles Netzwerk inklusive VPN-Gateway und fange an, das Betriebssystem, die Hana-­Datenbank und den leeren S/4-Basis-Stack zu installieren.

Idealerweise bin ich in zwei bis drei Tagen fertig und integriere dann noch ein Monitoring, das Backup und händige das System für das dreimonatige Testprojekt aus, um das die Kollegen aus den USA gebeten haben. Haben Sie den Unterschied bemerkt?

Ohne mein Rechenzentrum

Zu keiner Zeit wurde im Rechenzentrum geschaut, ob noch Ressourcen wie CPU, RAM oder Disk vorhanden sind. In diesem Szenario hätten wir jetzt eine Mv2-Maschine mit 12 TB RAM und 416 vCPU installieren können. Wäre das auch in Ihrem Rechenzentrum möglich?

Die nahezu unendliche versprochene Skalierbarkeit gewährleistet Microsoft mit ihren Rechenzentren weltweit. Natürlich müssen wir uns nichts vormachen, auch Microsoft muss diese Systeme irgendwo installieren und vorhalten, aber Sie als Kunde nicht mehr!

Wie schnell hätten Sie in den USA einen Rechenzentrumsprovider gefunden, der Ihnen die VM in der Qualität, SAP-Zertifizierung und Integration in Ihrer bestehenden Microsoft-Landschaft bereitgestellt hätte?

Die meisten Kunden haben bestehende Verträge durch Office 365 und können somit auch die Azure-Plattform nutzen. Wichtig ist hierbei jedoch, die richtige Zielarchitektur (Landingzone) vorab mit einem Dienstleister zu definieren und nicht blind drauflos­zulaufen.

Veränderung von Capex zu Opex und nahezu unendlicher Skalierbarkeit: Durch die exakte Zuweisung von Ressourcen zum aktuellen Bedarf müssen keine leeren Ressourcen vorgehalten und bezahlt werden.

In dem oben genannten Szenario konnten wir für die Kollegen in den USA ein Test­system für drei Monate bereitstellen und mussten keinen Server kaufen oder installieren. Somit sind auch keine Vorlaufzeiten für Einkauf, Versand und Einbau sowie keine Aufwände für die Installation notwendig. Nach drei Monaten löschen wir die Maschine einfach und fahren die Kosten auf null zurück.

Strom, Miete, Wartung, Lizenzen

Vergleicht man klassische Rechenzentren mit Microsoft Azure und kalkuliert wirklich alle Betriebsaufwände und Kosten wie Strom, Kühlung, Miete, Wartung, Hardware, Software, Lizenzen, IT-Dienstleistung und Personal, so ergibt sich aus unserer Erfahrung ein Einsparpotenzial bei hochoptimierten Rechenzentren von üblicherweise um die fünf bis zehn Prozent.

Bei verteilten, inhomogenen und nicht optimierten Rechenzentren ergeben sich dagegen Einsparpotenziale von bis zu 30 Prozent und mehr. In diesem Szenario vergleichen wir eins zu eins, das heißt Lift-&-Shift ohne eine Optimierung der Landschaft oder Veränderung hin zu PaaS und SaaS Services.

Durch die Nutzung von PaaS und Saas Services können hier weitere Optimierungen vorgenommen werden, zum Beispiel die Nutzung von Azure-SQL-Services oder Serverless Computing mit Kubernetes.

Kurzfristige und flexible Zuteilung von IT-Ressourcen: Nutze ich jetzt auch noch das Pay-as-You-Go-Konzept und schalte während der Nacht- und Wochenendzeit das Testsystem ab, kann ich weitere Kosten sparen.

Pay-as-You-Go bedeutet, dass ich nur die Ressourcen zahle, die ich tatsächlich benutze. In diesem Fall wären es die virtuelle Maschine und die inkludierte OS-Lizenz. Für den reservierten Speicher muss ich jedoch weiterhin bezahlen.

Das SAP-System wird samt Datenbank koordiniert und durch eine Automatisierungsengine wie zum Beispiel Ansible abgeschaltet und zum definierten Zeitpunkt gestartet. Durch ein Self-Service-Portal kann ich diese Aufwände und die Komplexität reduzieren und den internen Kunden die Kontrolle übergeben.

Atmende Systeme

Für Projektzeiten und ungewisse Markt­situationen kann ich den Bedarf flexibel erhöhen oder reduzieren und bleibe damit nahe am tatsächlichen Bedarf. Durch die Analyse der Verbrauchsdaten kann eine zukünftige Ermittlung der notwendigen Ressourcen vorgenommen werden und zum Saisongeschäft proaktiv vorab dazugebucht werden.

Es soll jedoch nicht der Eindruck entstehen, dass dies nur für Testsysteme möglich ist. Auch produktive Instanzen könne bei entsprechendem Bedarf flexibel skaliert und auch abgeschaltet werden.

Durch den Einsatz von Self-Service und einer starken Automatisierung kann man die Aufwände im Betrieb von SAP-Systemen weiter signifikant reduzieren. Anfragen nach Systemkopien, Sandbox-Systemen, einem Backup oder virtuellen Maschinen können voll automatisiert bedient werden und mit einer Kostenverrechnungslogik transparent dem Fachbereich in Rechnung gestellt werden. Somit gewinnt die IT wieder Kontrolle über die Operations und die Compliance.

Monitoring und Self-healing

Durch die Koppelung von Monitoring und Automatisierung kann ein Self-healing im Betrieb erreicht werden. Im einfachsten Fall ist dies die Erweiterung einer Festplatte bis hin zum Neustart des fehlerhaften Log-­Backups.

Durch intelligente Automatisierung erreicht man Deployment-Zeiten im Minutenbereich. In unserem Beispiel weiter oben im Text brauchen wir zwei bis drei Tage für die manuelle Installation einer leeren S/4-Hana-Landschaft.

SAP- und Microsoft-­Partner Scheer konnte das Deployment ­einer leeren S/4-Landschaft „from-the-scratch“ durch Automatisierung auf Azure auf wenige Stunden reduzieren. Durch ein Golden Image kann dies sogar auf wenige Minuten weiter reduziert werden.

Im Betrieb kann durch die Kombination von zum Beispiel Ansible und Azure ein nahezu vollständig automatisiertes Patching realisiert werden und damit die Betriebsaufwände weiter reduziert werden. Hier bietet Microsoft Azure verschiedene Tools und Services an, die einem helfen, dies zu orches­trieren.

Der Mehrwert der Azure Cloud für den Fachbereich ist Schnelligkeit und Innovation. Neue Services und Funktionen können koordiniert und gesteuert durch die IT dem Fachbereich zur Verfügung gestellt werden.

Somit reduzieren sich weiter die Aufwände in der IT und die Mitarbeiter können höherwertigen Aufgaben zugeordnet werden. Durch neue Software-Innovation in der Cloud über Nacht kann man diese dem Fachbereich sofort zur Verfügung stellen und muss nicht erst ein Update einspielen.

Mit dem Embrace-Programm von Microsoft und SAP können nun die Azure-Services nahtlos durch die SAP Cloud Platform in den SAP-Produkten, zum Beispiel S/4 oder auch in den Cloud-Produkten wie SuccessFactors, konsumiert werden. Hier entsteht echt Innovation nicht im Server, sondern in Software.

Die Cloud-Plattform Azure bietet neben den eigenen Services einen schier unend­lichen Software-Marktplatz, der die SAP- Landschaft um Services und Funktionalität erweitert und zugänglich macht.

Neben den Plattform-Services bietet Azure eine Programmierplattform für komplexe Software-Projekte, die man dann wiederum nahtlos in SAP integrieren kann. Durch Serverless-Computing mit Kubernetes kann die eigene Softwarearchitektur nahezu unendlich und flexibel deployt und skaliert werden.

Die Herausforderung ist jedoch, das eigentliche Problem durch Technologie zu adressieren und nicht andersherum, dass die Technologie noch die Probleme sucht. Viele Kunden verfolgen den Ansatz einer Multi-Vendor-Strategie zusammen mit Microsoft und SAP, um keinen Vendor-Lock-in zu generieren. Beide Provider sind zumeist bekannt und können sich jeweils gut durch ihr Portfolio ergänzen.

Neben aller Flexibilität, Schnelligkeit und Kostenreduktion gibt es weiche und unsichtbare Effekte, die man erst spürt, wenn es darauf ankommt. Diese monetär zu bewerten ist schwierig, jedoch haben die meisten Kunden enorme Herausforderungen im Budget, wenn es um Security geht.

Service-SLAs und Compliance

Es ist wie mit einer Versicherung, ich brauche sie erst, wenn es schiefgegangen ist. Microsoft gibt pro Jahr circa eine Milliarde Dollar für Security aus und schützt die Azure-­Plattform vor Angriffen und Missbrauch.

Dies bekommen Kunden als inklusiven Service immer mit der Plattform. Zusätzlich können Services wie Azure-Sentinel, Verschlüsselung mit Key Vault und Single-Sign-on mit Azure AD dazugebucht und das individuelle Sicherheitslevel pro Landschaft oder VM definiert werden.

Mit dem Azure-Security-Center können alle sicherheitsrelevanten Parameter und Zugriffe gesteuert und die Compliance überwacht werden. Beispielsweise haben wir für ein Unternehmen, das Kreditkarten verarbeitet, eine komplett geschlossene PCI-DSS-Compliant-Landschaft aufgebaut, die getrennt von der Nicht-Compliant-­Landschaft läuft, und somit gelten die erhöhten Kosten für bestimmte Sicherheitsmaßnahmen nur für diese Systeme.

DR- und HA-Szenarien

Für Single-Instance-VMs bietet Microsoft ein Standard-SLA von 99,9 Prozent Verfügbarkeit pro Monat an, was für die meisten eigenen und Hosting-Rechenzentren ein sehr hoher Wert ist.

Mit Availability-Sets und der Nutzung von weiteren Regionen kann dieser Wert auf bis zu 99,99 Prozent erhöht werden. Auch im DR-Szenario können echte georedundante Architekturen aufgebaut werden.

Aus dem Beispiel eines Automotivkunden konnte eine Always-on- Architektur mit einem HA-Scale-out-Cluster auf Hana mit 6 TB in der Region Amsterdam sowie mit Hana-­Replikation in die Region Dublin realisiert werden.

Die Backups werden ebenfalls nach Dublin repliziert und der Kunde hat eine redundante Netzwerkanbindung in beide Regionen. Diese Architektur deckt sowohl lokale Ausfälle im RZ als auch regionale Ausfälle in Amsterdam ab.

Optional können die Backups verschlüsselt auf einen anderen Kontinent, zum Beispiel in die USA oder nach Singapur, gespiegelt werden.

Weiterhin erhöht sich deutlich die Compliance auf Azure im Vergleich zum eigenen Rechenzentrum und dem Eigenbetrieb von SAP. Über 90 Compliance-Rahmenwerke wurden auf Azure umgesetzt, um es nahezu jeder Industrie zu ermöglichen, ihre Kunden und Daten auf Azure zu verarbeiten.

Nachweislich konnte Scheer Kunden aus der Finanz und Versicherungsbranche mit Bafin-Compliance, aus der Pharmabranche mit GxP-Compliance sowie aus dem Reisesektor mit PCI-DSS-Kreditkarten-Compliance auf die Azure-Plattform mit ihren SAP-Systemen bringen und betreibt diese heute sehr erfolgreich.

Das Beispiel von SAP/Microsoft-Partner Datavard zeigt, wie intelligent die Azure Services HDInsight Hadoop mit Azure Data Lake Store dafür eingesetzt werden können, um „lower value“ und alte nicht mehr benötigte Daten auf günstigen Speicher auslagern zu können, um die Hana-Datenbankgröße zu reduzieren und damit auch wieder die Performance zu steigern.

Die vergangenen zweieinhalb Jahre konnten wir durch diverse Projekte sehen, dass ein ganzheitlicher TCO im Bereich von zehn bis vierzig Prozent möglich ist. Eine hochoptimierte IT-Infrastruktur mit kaum Veränderung und Wachstum wird von der Azure Cloud weniger profitieren als ein sich agil und disruptiv veränderndes Umfeld, das perfekt zu einer Cloud-Plattform passt.

In diesem Umfeld können echte Kosteneinsparungen erzielt und kann gleichzeitig Innovation getrieben werden. Insbesondere konnten wir bei der Einführung von S/4 in einer frühen Assessment-Phase, wenn das Sizing und die Architektur noch nicht klar sind, die besten Mehrwerte und den besten TCO feststellen und daraus ein fertiges „S/4 Project Service“-Paket zu einem attraktiven Preis auf Monatsbasis schnüren.

ROI, aber wann?

Im späteren Betrieb zeigt sich dann wieder der Innovationseffekt einer neuen S/4-­Landschaft und der damit resultierenden Change-Requests aus dem Fachbereich, die auf einer Azure-Plattform sofort und flexibel bedient werden können.

Durch die komplexe neue S/4-Architektur brauche ich teilweise für zusätzliche Produkte und Services immer wieder neue separate Systeme. Sind die Projekttreiber Compliance, Standardisierung und Modernisierung, so sind teilweise ROI-Effekte nach neun Monaten festzustellen.

Zum TCO gehören auch die Migrationskosten, die erstaunlicherweise sehr niedrig ausfallen. Mit Azure-Migrate und -Site-Recovery können virtuelle Landschaften analysiert und zum Beispiel am Wochenende sehr schnell migriert werden.

Im schnellsten Fall konnte eine komplette S/4-Landschaft im validierten Pharmakontext GxP von Projektstart bis Go-live innerhalb von vier Wochen nach Azure migriert werden.

Die Downtime ist in diesem Szenario nur die Zeit für das Aus- und Anschalten sowie die Anpassungen für IP, DNS und Schnittstellen, welche vorab vorbereitet werden können.