AWS Public CloudAchtung Spoiler! Ja.

 

Wir reden oft mit Unternehmenskunden und erfahren so ganz direkt ihre Sorgen und Bedenken bezüglich der Migration von SAP-Workloads in die AWS-Cloud. In dieser Artikelreihe wollen wir uns mit einigen der häufig angesprochenen Themen befassen, die eine genauere Untersuchung wert sind.  Insbesondere wollen wir uns mit Bedenken bezüglich der Migration geschäftskritischer oder älterer SAP-Workloads in die AWS-Cloud beschäftigen.

 

Die Public-Cloud-Plattform

 

Beginnen wir mit der Plattform. Vor ein paar Jahren noch glaubten nur wenige, dass sich die Public-Cloud für das Hosten einer Datenbank eignet, ganz zu schweigen von kritischen Workloads. Es gab viele Fragen und Bedenken bezüglich Leistung, Ressourcen und Zugang.

 

Mit der weiteren Entwicklung der Public-Cloud entwickelten sich jedoch auch unsere Einstellung und unser Zutrauen. Heute kann sich niemand mehr eine Cloud-Plattform vorstellen, die nicht mehrere Datenbanken unterstützt, deren Leistung mit der vor Ort oder in der Private-Cloud erzielbaren vergleichbar ist.

 

Je mehr das Vertrauen in die Public-Cloud stieg, desto größer wurden auch die Bedenken bezüglich Sicherheit und Compliance. Dies war zu erwarten, ist die Public-Cloud doch ein bisschen undurchsichtig. Nur wenige wissen wirklich, wie die AWS-Cloud funktioniert, man weiß nur, dass sie außerordentlich gut funktioniert. Und angesichts dieser Rätselhaftigkeit der AWS-Cloud finden es viele beunruhigend, dass Sicherheit in dieser neuen von vielen bewohnten Hyperscale-Welt buchstäblich neu erfunden wurde.

 

Wo die AWS-Cloud brilliert

 

Die Bereitstellung von Firewalls – die erste Verteidigungslinie bei Installationen vor Ort – wird nun in der Cloud mehr zur Ausnahme denn zur Regel. Wer hat dies vorausgesehen? Es sollte erwähnt werden, dass die Unternehmens-IT die Public-Cloud nicht für alle Workloads vorbehaltlos angenommen hat, da es sich eben um eine gemeinsame genutzte Infrastruktur handelt.

 

So verursacht dies zwar berechtigte Bedenken bezüglich „lauter Nachbarn“ und dem Risiko von Eindring- und DDOS-Attacken, doch ist das auch der Bereich, in dem AWS tatsächlich brilliert. Die AWS-Cloud ist nahezu selbstheilend und bietet über 100 Dienste wie ACLs (Zugriffssteuerungslisten), Sicherheitsgruppen und erweiterte Dienste wie AWS Shield Advanced, mit dem die Infrastruktur sicher mit ihrem virtuellen Netzwerkrand verbunden wird. Was die Compliance anbelangt, so erfüllt AWS fast jeden Compliance-Standard.

 

Neben all diesen Tools, die mit der AWS-Cloud angeboten werden, gibt es noch weitere externe Tools, die bei einer SAP-Bereitstellung in der AWS-Cloud genutzt werden können. Hier kommt der weltweit größte Markt ins Spiel.  Außer einer Kenntnis der AWS-Cloud und des AWS-Markts muss man sich unbedingt auch mit SAP und der Konfiguration von SAP in der AWS-Cloud auskennen.

 

Aufbau von SAP-Lösungen in der AWS-Cloud

 

Wir stellen zum Beispiel SAP in der AWS-Cloud fast ohne Öffnung zum Internet bereit. Wir verriegeln alles und installieren zur Kontrolle Bastion-Hosts, um so die SAP-Umgebung noch weiter abzusichern. Dann setzten wir die besten maßgeschneiderten Überwachungslösungen darauf und entwickeln und installieren Sammler, die eng mit AWS CloudWatch zusammenarbeiten und uns die benötigten Einblicke in die gesamte Infrastruktur verschaffen.

 

Denn nur weil wir keinen Root-Zugriff auf die Hypervisoren haben, heißt dies nicht, dass wir keinen Einblick in die Funktion der zugrundliegenden Infrastruktur brauchen oder haben. Das ist der Unterschied zwischen reaktiver und präventiver Vorgangsüberwachung.

 

So wird AWS zu einer hervorragenden Hosting-Plattform auch für eine knifflige Anwendung wie SAP. Trotz der Leistungsstärke der AWS-Cloud und all unseren speziellen Bereitstellungs-Tools gibt es noch immer ein paar technische Fragen zur Migration von Legacy-Workloads in die Public-Cloud, die wir uns ansehen sollten.

 

Migration von Legacy-Workloads in die Public-Cloud

 

Zunächst einmal eine Begriffsabgrenzung. Wenn wir über Anwendungen reden, die speziell für den Einsatz in der Public-Cloud entwickelt wurden, sprechen wir von „Cloud Native“ oder „in der Cloud geboren“. Damit wird die nächste Generation von Anwendungen beschrieben, die auf Optimierung aller Ebenen und nicht nur der Betriebssystem- und Virtualisierungsschicht ausgerichtet sind.

 

Nur wenige Legacy-Systeme erfüllen (wie der Name schon sagt) dieses Kriterium. Denn die meisten Legacy-Anwendungen wie SAP sind Einzelanwendungen aus der Zeit des Einzelservers. Sie wurden ursprünglich für statische Umgebungen entwickelt und gebaut, und die meisten wurden ursprünglich auf einer eigenen Infrastruktur sowie eigenen Servern oder Anwendungen bereitgestellt. Stabil. Planbar. Isoliert. Aber seit der Virtualisierung ist dieses Modell praktisch Vergangenheit.

 

In den letzten Jahren haben wir eine Verschiebung hin zu einer zunehmenden Unterstützung von Legacy-Anwendungen auf virtuellen Maschinen erlebt, was wiederum die Tür für Virtualisierung damit auch für Public-Cloud-Anbietergeöffnet hat. Was SAP und zuletzt SAP HANA anbelangt, so sind beide nicht nur als virtuelle Maschinen in Ihren Rechenzentren, sondern auch als Bestandteile in der AWS-Cloud zertifiziert.

 

Diese Zertifizierung beweist, dass SAP jetzt vollständig cloudfähig ist. Cloudfähig bedeutet, dass Legacy-Anwendungen, die nicht für die Cloud entwickelt wurden, getestet und sicherheitsgeprüft wurden und in einer Hyperscale-Cloud wie dafür entwickelt funktionieren.

 

Das ist aber noch nicht alles. Das eine ist die Bestätigung, dass SAP cloudfähig ist, etwas ganz anderes ist aber die Zertifizierung von virtuellen Maschinen, Betriebssystemen und Datenbanken. Hier begegnen sich AWS-Cloud und SAP Product Availability Matrix, kurz PAM.

 

Partner bei der Entwicklung einer Schlüsselstrategie

 

Hier kann Ihnen ein Partner, der Sie beim Umgang mit diesen beiden sehr unterschiedlichen Anforderungen unterstützt, helfen, eine Strategie zu entwickeln. So verwendet Oracle z.B. SAP und ist in der AWS-Cloud verfügbar, aber wenn es darum geht zu wissen, welche Betriebssystemversionen hier funktionieren, dann kommt die Kenntnis der AWS-Cloud und von SAP ins Spiel.

 

Das ist die Stärke von POC. SAP funktioniert in der AWS-Cloud und ist dafür zertifiziert. Haken. SAP-unterstützte Datenbanken funktionieren in der AWS-Cloud und sind dafür zertifiziert. Haken. SAP funktioniert/wird unterstützt auf ESX in Ihren Rechenzentren und unseren. Haken.

 

Doch SAP benötigt auch ziemlich viel Fehlerbehebung. Bei der Migration in die AWS-Cloud wäre es sicher gut, schon vorher zu wissen, dass Sie nicht als erstes ein Problem erkannt haben; gut zu wissen, ob die vorhandenen Patches alle auch kleinsten Probleme abdecken, die sich bei Ihrer SAP-Bereitstellung in der AWS-Cloud ergeben könnten; hilfreich, die Kompatibilität zu prüfen und wertvoll, Ihre SAP-Leistung in der AWS-Cloud zu validieren.

 

Hier kann unsere Partnerschaft mit SAP und AWS Ihnen eine Hilfe sein. Lassen Sie uns gemeinsam überlegen, wie wir Ihnen helfen können, ein POC zusammenzustellen, in dem die Infrastrukturkosten und Lizenzgebühren enthalten sind, damit die Migration positiv für Sie verläuft.

 

Die AWS-Public-Cloud ist also fähig, SAP zu hosten. Mit dem richtigen Partner und ein wenig zusätzlicher Unterstützung kann Ihr Weg gut geplant und bewältigt werden.

 

Im nächsten Artikel widmen wir uns der Frage, warum die Migration von SAP in die AWS-Cloud nicht nur planbar und machbar ist, sondern auch in Bezug auf Kosten, ROI und konkurrierender IT-Prioritäten wirtschaftlich sinnvoll ist.  Wir werden untersuchen, wie man ein überzeugendes Szenario entwickelt, und Ihnen dabei helfen, die zeitliche Umsetzung einer Migration entsprechend Ihrer speziellen Umgebung und begrenzten Ressourcen zu planen.