Coverstory 1812 MAG 1812

Kraftfeld Hybrid Cloud

[shutterstock.com: 310826756, a-image]
[shutterstock.com: 310826756, a-image]

Der Trend bei der Nutzung von SAP-Infrastrukturen geht klar in Richtung hybride Betriebsmodelle mit On-premise- und Private-Cloud-Umgebungen gepaart mit Public-Cloud-Services. SAP-Kunden profitieren von zahlreichen gewinnbringenden Anwendungsszenarien, ausgeführt auf der Google Cloud Platform.

Bereits seit geraumer Zeit forciert SAP die Bereitstellung von cloudbasierten Lösungen. Mehr noch mittlerweile. Verfolgt wird eine sogenannte Cloud-First-Strategie, die sich beispielsweise dadurch ausdrückt, dass Neuerungen oder Innovationen im Business-Suite-Nachfolger S/4 alle drei Monate zuerst in der Variante SAP S/4 Hana Cloud bereitgestellt werden. Konsolidiert stehen sie dann alle zwölf Monate in der S/4-On-premise-Ausprägung zur Verfügung.

Derzeit bevorzugen SAP-Kunden im Rahmen ihrer Cloud-Adaption, die eng in Verbindung mit Digitalisierungsvorhaben stehen, ein Sowohl-als-auch denn ein Entweder-oder.

Nur wenige SAP-Kunden haben im Blick, ihre On-premise-SAP-Landschaft(en) vollständig in die Cloud zu verlagern. Insbesondere mittelgroße und große Unternehmen mit mehreren Tausend Mitarbeitern verfolgen eher weniger eine „Cloud Only“-Strategie. Vielmehr wird ein gemischter SAP-Betrieb oder SAP-Einsatz in Form von unterschiedlichen Hybrid-­Cloud-Szenarien angestrebt.

Dabei werden Teile der Applikationslandschaft On-Premise, andere wiederum in eine Public Cloud transferiert oder darüber betrieben. Wobei auch im Fokus steht, On-premise-­Umgebungen in Richtung Privat Cloud umzubauen.

Etwa durch eine Transformation in Richtung Software Defined Infrastructure (SDI) auf der Grundlage von Cloud-native-Lösungen wie etwa Open­Stack, um relativ starre Silos aufzubrechen und agiler sowie flexibler und kostenadäquat auf Geschäftsanforderungen reagieren zu können. Dies allerdings mit dem Ziel einer Hybrid-Cloud-Nutzung. Wobei SAP übrigens eine ähnliche Vorgehensweise präferiert.

Achim-Zimmermann

Dass sich das Hybrid-Cloud-Computing zu einer Art Richtschnur oder Kraftfeld beim gesamten Cloud-Computing entwickelt, belegen nicht nur Marktzahlen, sondern auch die stark gestiegenen Kundenanfragen an Q-Partners/Devoteam aus der SAP-Community.

Es zeigen sich höchst unterschiedliche Fragestellungen sowie die Tatsache, dass praktisch jeder SAP-Bestandskunde eine gewisse eigene Agenda verfolgt. Vorneweg marschiert aktuell beim gesamten Thema Cloud-Computing insbesondere das Themenfeld Infrastructure as a Service (IaaS) mit dem Bezug von Infrastrukturdiensten auf der Grundlage festgelegter SLAs von einem von der SAP zertifizierten Public-Cloud-Services-Provider, so etwa von Google auf der Basis der Google Cloud Platform (GCP).

Plan, Build, Test and Run

Offene Fragen: Welche SAP-Cloud-Anwendungsszenarien zuerst angehen, welche versprechen den größten Nutzen? Wie ist es um die Kosten konkret bestellt – kurzfristig und langfristig? Welche organisatorischen Belange müssen berücksichtigt werden?

Wie ist es um die Security bestellt? Was muss getan werden, um einem möglichen Verlust von Daten vorzubeugen, die sich in einer Public Cloud befinden? Oder, oder, oder.

Tatsache ist, dass es noch nie so einfach war, entsprechende Hana-Infrastruktur­ressourcen oder -kapazitäten inklusive der Betriebssystemplattform Suse Linux Enter­prise Server (SLES) for SAP bei einem Pu­blic-Cloud-Service-Provider schnell aufzusetzen beziehungsweise zu buchen sowie zu betreiben (mehr zu Suse Linux Enterprise ­Server for SAP Applications und Hybrid-­Cloud-Computing im Suse-Linux-Beitrag auf Seite 48 dieser Ausgabe).

Einen er­heblichen Anteil daran hat auch SAP, die Verfahren und Techniken entwickelt hat sowie bereitstellt (etwa SAP CAL), um Public-­Cloud-Services in Verbindung mit SAP-Lösungen in kurzer Zeit und relativ unkompliziert zu verwenden.

Gleichwohl sind vor der eigentlichen Cloud-Services-Nutzung Planungs- oder gewisse Konfektionierungsarbeiten notwendig. Ebenso Testphasen, nebst individuellen Detailarbeiten. Ähnlich dem guten alten vereinfachten Projekt-Lifecycle „Plan, Build, Test and Run“.

Jens-Gleichmann

Dabei nimmt die Planungsphase erfahrungsgemäß in aller Regel den größten Raum ein. Durch das Miteinander von Kunden und qualifizierten Cloud-Architekten werden individuelle Hybrid-­Cloud-Lösungskonzepte für das Build sowie für das nachfolgende Run erstellt.

Hierbei werden auch verschiedene mögliche Anwendungsszenarien der Public-Cloud-Nutzung diskutiert oder arrondiert. Und zwar unter Einbeziehung der existierenden On-pre­mise-SAP-Umge-bung.

Welche Anwendungsszenarien respektive Hybrid-Cloud-­Nutzungsmodelle samt Public-Cloud-Services-Bezug dann konkret bei einem Unternehmen zum Einsatz gelangen, wird hier wohlgemerkt ebenfalls fixiert.

Über mittlerweile Klassiker – nämlich für Dev-, QA- oder Test-Systeme auf einer Pu­blic Cloud zu nutzen oder dort Hana-Ressourcen zu buchen – hinaus bieten sich folgende Anwendungsszenarien (Use Cases) an: beispielsweise die Google Cloud Platform dazu zu verwenden, um Hochlastszenarien (Peaks) abzudecken, etwa bei Jahresabschlüssen, monatlichen Konsolidierungen oder gewissen „Peak-Hochzeiten“.

So möglicherweise bei einem Retailer („Black Friday“). Weniger oft benötigte Rechenpower wird bei Bedarf einfach via Public Cloud gebucht respektive hinzugeschaltet. Bei der Rechner- und Server-Nutzung auch von Relevanz:

Durch die IaaS-Ressourcen-Verwendung werden üblicherweise anfallende „Sizing-Verschnittkosten“ eliminiert (Stichwort: Soda-Kosten oder Kosten, die latent existieren).

Ein anderer gewinnbringender Use Case ist, mittels eines Sekundärsystems via Public Cloud die High Availability durch den Einsatz der Hana-System-Replication (HSR) in Verbindung mit Suse SLES HAE zu erhöhen. Oder eine kostengünstige Verwendung eines Near Zero Downtime Patchings mit dem Aufsetzen einer Hana-System- Replication und via DBSL-Suspend- Verfahren das Hana-Patching inklusive Suse SLES for SAP Applications umsetzen.

Nach der Realisierung ist es anschließend möglich, die „überflüssige“ Instanz einfach wieder zu deaktivieren oder zu löschen. Ebenso kann als Szenario angestrebt werden: ehe ein OS- oder ein Hana-Patching durchgeführt wird, dieses mit einer temporären Instanz auf der Public Cloud zu testen (Capture und Replay). Um etwa die Vorher- Nachher-Performance zu testen, um etwa mögliche Fehler zu identifizieren, um Parameteroptimierungen zu realisieren und anderes mehr.

Kostengünstige Use Cases

Ferner die Realisierung via Google Cloud Platform von Sandboxen oder Schulungssystemen. Zunehmend gibt es den Wunsch von Fachbereichen oder SAP-Anwendern, Business-Funktionen zu testen oder zu evaluieren oder schnell ein Trainingssystem verwenden zu können – was aber in aller Regel ein Sandbox-System sowie eine Art Extra-System mit aktuellen Daten erforderlich macht.

Die Lösung: mittels HSR oder Back­up und Restore eines Prod-Systems eine temporäre GCP-Instanz kreieren und als Sandbox- oder Schulungssystem einsetzen. Auch hier können die Systeme schnell und einfach wieder getilgt oder „entsorgt“ werden, nachdem sie nicht mehr benötigt werden.

Außerdem gilt es, schon an morgen zu denken. Insbesondere bedeutet das für SAP-Bestandskunden, bei denen SAP Leonardo auf der Agenda steht, die Verwendung vieler neuer Systeme. Man muss kein Prophet sein: Um IoT, KI, Big Data oder Blockchain sinnvoll einzusetzen, werden viele neue zusätzliche Systeme benötigt oder vorhandene Systeme sind auszubauen.

Und dabei will man auf neue Anwendungsmöglichkeiten selbstverständlich schnell zurückgreifen können und nicht eine aufwändige wochenlange Beschaffungs- und Installations-Rallye über sich ergehen lassen. Hier ist die Lösung ebenso: via Public Cloud Systeme im bedarfsgerechten Subskriptionsangebot buchen oder mieten.

Ist die Plan-Phase abgeschlossen, wird das dort Festgelegte im Build umgesetzt. Auch eventuelle organisatorische Changes respektive Änderungen und Neuerungen, die die SAP-Basis oder den SAP-Systembetrieb betreffen.

Dabei ist zu berücksichtigen, dass jeder Cloud-Service-Provider sozusagen eigene Spezialitäten aufweist, über die jeweiligen wählbaren IaaS-Subskriptions-Packages (Node-Größe, CPU oder Storage-Arten und Größen) hinaus.

Von Erfahrungen profitieren

Die Zusammenarbeit von Devoteam und Google in Verbindung mit der GCP hat im SAP-Umfeld exklusiven Charakter. Das heißt auch, dass Devoteam via eigener Google Cloud Professional Architects wiederum Google bei der Bereitstellung von SAP-IaaS-Services in vielfältiger Art und Weise unterstützt oder unterstützt hat.

Insbesondere, was die Notwendigkeiten für einen möglichst optimalen SAP-Betrieb durch Q-Partners betrifft und gleichzeitig heutzutage schon umsetzt. Natürlich haben SAP und Google mit der Ankündigung und Verfügbarkeit von „SAP auf der GCP“ im Rahmen der Sapphire 2017 intensive Entwicklungsarbeiten getätigt.

Seit Längerem forciert Google das Themenfeld SAP. Und: Bereits heute stellt Google ebenso hohe maximale von SAP zertifizierte VM-OLTP- und VM-OLAP-Node-Größen auf der GCP bereit wie etwa Amazon auf AWS und mehr als Microsoft auf Azure.

Angestrebt werden auf Sicht Hana-Node-Größen von etwa 18 TB (mehr dazu auf Seite 50 dieser Ausgabe). Durch die Zusammenarbeit mit Google konnten Q-Partners als SAP Gold Partner und Devoteam als Google Cloud EMEA Services Partner of the Year 2018 wertvolles Know-how und Erfahrungswissen speziell bei der IaaS-Nutzung auf der GCP sammeln, von denen SAP-Kunden in Projekten profitieren – sowohl beim Plan und Build als auch beim Test and Run.

https://e-3.de/partners/q-partners-gmbh/

Download Coverstory

Über den Autor

Jens Gleichmann, Q-Partners

Jens Gleichmann ist SAP Technical Lead Consultant bei Q-Partners

Hinterlassen Sie einen Kommentar

AdvertDie Meinung 2