Cloud Strategie
Wir freuen uns, unsere Erfahrungen und Best Practices mit Ihnen zu teilen. Sie erfahren, wie Sie das richtige SAP BTP-Setup wählen und wie Sie sichere und skalierbare Anwendungen auf der SAP BTP als Einzel- oder Mehrmandantenversion erstellen können.
Mit der zunehmenden Nachfrage nach Geschwindigkeit und Skalierbarkeit in der heutigen Geschäftslandschaft ist eine Cloud-Strategie unerlässlich geworden. Sie kann nicht länger ignoriert oder hinausgezögert werden, da sie notwendig ist, um Ihre Produkte oder Landschaften schnell skalieren zu können.
Wir sind davon überzeugt, dass Sie Ihre Ziele schneller und einfacher erreichen können, wenn Sie sich an bewährte Verfahren halten und die richtige SAP BTP-Einrichtung nutzen.
Wir werden diesen Blog-Beitrag in mehrere Abschnitte unterteilen, die die wesentlichen Aspekte eines erfolgreichen Starts mit der SAP BTP abdecken:
- Wie können Sie mit der SAP BTP starten
- Was ist zu beachten und wo können Sie Informationen über Kosten und Dienstleistungen finden
- Verstehen der verschiedenen Terminologien und Bezeichnungen im Zusammenhang mit der SAP BTP
- Gewährleistung von Sicherheit und Migrationsrisiken
- Auswahl der richtigen Architektur
- Entwerfen Ihrer zukünftigen Landschaft
Wie können Sie mit der SAP BTP starten
Als Unternehmen haben Sie mehrere Möglichkeiten, mit der SAP Business Technology Platform (BTP) zu beginnen und ihre Möglichkeiten zu erkunden. Eine beliebte Wahl ist das Pay-As-You-Go (PAYG)-Modell, das es Ihnen ermöglicht, Ihr BTP-Konto zunächst einzurichten und die meisten Dienste bis zu einer bestimmten Grenze kostenlos zu nutzen. Dies ist eine ausgezeichnete Option für erste Experimente und den Einstieg in die SAP BTP. Für SAP-Partner gibt es darüberhinaus auch andere Preise als für Endkunden.
Alternativ können Sie eine kostenlose Testversion von der BTP aktivieren, für die keine Bankkarte oder Zahlungsinformationen erforderlich sind. Die Testversion bietet Zugang zu fast allen Diensten zu Testzwecken und ist nicht für den produktiven Einsatz gedacht. Darüber hinaus werden einige Komponenten, wie z. B. die SAP HANA-Datenbank, täglich über Nacht heruntergefahren, und das Konto kann deaktiviert oder gelöscht werden, wenn über einen längeren Zeitraum keine Aktivitäten erfolgen.
In unserem Unternehmen nutzen wir die Testversion häufig, um neue Funktionen zu testen und auszuprobieren. Es ist eine gute Möglichkeit, praktische Erfahrungen mit BTP zu sammeln, ohne sich für einen kostenpflichtigen Plan zu entscheiden.
Nachstehend finden Sie die Links zu den jeweiligen Plattformen:
Was ist zu beachten und wo finden Sie Informationen über Kosten und Dienstleistungen
Bevor Sie mit der Gestaltung Ihrer endgültigen Landschaft beginnen, müssen Sie prüfen, welches BTP-Zahlungsmodell für Sie am besten geeignet ist. Derzeit sind 2 verschiedene Modelle verfügbar, wenn man von der Testversion absieht.
Cloud-Plattform-Unternehmensvertrag (CPEA)
Pay-As-You-Go (PAYG)
Das CPEA Modell ist ein kommerzielles Modell, das von Cloud-Anbietern angeboten wird, um Unternehmen bei der Verwaltung ihrer Cloud-Kosten zu unterstützen. Das CPEA wird häufig von größeren Unternehmen mit komplexen Cloud-Anforderungen genutzt, da es ihnen ermöglicht, ihre Cloud-Ausgaben zu konsolidieren und ihr Budget effektiver zu verwalten.
PAYG ist ein verbrauchsabhängiges Geschäftsmodell, das häufig im Cloud Computing eingesetzt wird. PAYG wird häufig von Unternehmen mit unvorhersehbaren oder schwankenden Arbeitslasten bevorzugt, da es ihnen erlaubt, ihre Cloud-Nutzung je nach Bedarf zu erhöhen oder zu verringern und nur für die verbrauchten Ressourcen zu zahlen. Dies kann zu Kosteneinsparungen und größerer Flexibilität führen, da die Unternehmen ihre Cloud-Ausgaben an ihre wechselnden Bedürfnisse anpassen können.
Um Informationen über die Kosten eines Services oder auch einen detaillierten Serviceüberblick zu erhalten, stellt die SAP ein sehr detailliertes und gut erklärtes SAP Discover Center zur Verfügung, in dem Sie alle benötigten Informationen finden können.
Verständnis der verschiedenen Terminologien und Bezeichnungen im Zusammenhang mit der BTP
Im Zuge der Weiterentwicklung und Erweiterung des SAP BTP-Angebots sind neue Begriffe und Bezeichnungen aufgetaucht, die bei vielen Kunden Verwirrung stiften oder sie im Unklaren lassen, was sie bedeuten. In diesem Abschnitt helfen wir Ihnen, sich in der Fachsprache zurechtzufinden, und geben Ihnen klare Erklärungen zu den einzelnen Begriffen.
Der Global Account ist das Konto der obersten Ebene, das alle Subaccounts innerhalb einer Organisation enthält. S-User werden dem globalen Account zugewiesen, das als zentraler Verwaltungspunkt für alle Subaccounts dient.
Der Subaccount ist ein Konto der zweiten Ebene, das alle Bereiche enthält, in denen Ihre Anwendungen oder Produkte gespeichert werden können. Subaccounts sind eine Schlüsselkomponente der Organisationsstruktur der Plattform und ermöglichen es Ihnen, Projekte, Anwendungen oder Entwicklungsumgebungen zu isolieren.
In einem Multi-Tenant-Szenario sollte jeder angeschlossene Kunde über einen separaten Subaccount verfügen, über den er Ihren Multi-Tenant-fähigen Dienst oder Ihre Anwendung abonnieren kann.
Ein space ist eine Organisationseinheit der dritten Ebene innerhalb eines Subaccounts, mit der Sie Anwendungen oder Umgebungen trennen können. Durch die Erstellung von Spaces innerhalb eines Subaccounts können Sie globale Dienste nutzen, die mit dem Subaccount verbunden sind, was die Verwaltung Ihrer Ressourcen erleichtert. Beachten Sie jedoch, dass Dienste, die sich direkt in einem Bereich befinden, nicht automatisch aufgerufen werden können und möglicherweise eine zusätzliche Konfiguration erfordern.
Gewährleistung von Sicherheit und Migrationsrisiken
Die Entwicklung und Architektur eines Cloud-Systems unterscheidet sich erheblich von der eines On-Premise-Systems. In der Welt der On-Premise-Systeme sind die Systemumgebungen in der Regel vom Internet getrennt, wobei ERP, Backend-Dienste und andere Komponenten hinter DMZs, Proxies oder anderen Kapselungsmethoden gesichert sind. Dies macht es viel einfacher, Lösungen zu entwerfen und aufzubauen, da man sich auf interne Sicherheitsmaßnahmen verlassen kann. Die IT-Abteilung kann sich um die Proxy-Einstellungen, den Cloud Connector oder die PI-Schnittstelle kümmern, so dass sich die Entwickler auf die interne Nutzung des Systems konzentrieren können.
Mit dem Cloud ändert sich jedoch alles. Die Entwickler müssen nun bedenken, dass die von ihnen erstellten Anwendungen oder Dienste für jedermann und die ganze Welt zugänglich sind, sofern keine angemessenen Sicherheitsmaßnahmen ergriffen werden. Wird die Sicherheit vernachlässigt oder falsch konzipiert, kann dies zu einem offenen Zugang zu sensiblen Informationen führen.
Was können Sie also tun, um unbefugte Zugriffe auf Ihren Dienst oder Ihre Anwendung zu verhindern? Zunächst sollten Sie dafür sorgen, dass Dienste, auf die nicht direkt zugegriffen werden soll, nicht im Internet veröffentlicht werden. Dies können Sie direkt in der SAP BTP tun, indem Sie Ihren Dienst auf "nur intern" einstellen.
Der Zugriff auf Ihre Anwendung oder Ihren Dienst in der Cloud erfordert eine sorgfältige Prüfung Ihrer Architektur und der Frage, wer welche CRUD-Rechte haben sollte. Eine mögliche Lösung besteht darin, eine SAP iAS-Instanz zu erstellen und diese per XSUAA an einen Approuter zu binden. Setzen Sie alle Routen innerhalb des Approuters auf "auth required" und nur der Approuter wird vom Internet aus zugänglich sein und als Proxy für Ihren Service fungieren. Definieren Sie alle Routing-Endpunkte für Ihre Anwendung innerhalb des Routers und leiten Sie alle Routen entsprechend um. Alle nicht explizit definierten Routen werden zurückgewiesen. Diese Einrichtung stellt die erste Sicherheitsschicht und einen sicheren Zugangspunkt zu Ihrem Dienst dar.
Wenn es darum geht, eine sichere Verbindung zu einer Hana Datenbank herzustellen und Client-, Anwendungs- oder Servicedaten in verschiedenen HANA-Schemata getrennt zu halten, gibt es einige Dinge zu beachten. Es ist wichtig, von Anfang an ein solides Schema-Layout und Migrations-Setup zu entwerfen. Darüber hinaus ist es wichtig, vorausschauend zu denken und zu überlegen, wie sichergestellt werden kann, dass keine Datenverluste auftreten, falls Sie das Datenbanklayout ändern müssen, nachdem ein Kunde eine Anpassung verlangt.
Unser letzter Tipp ist, bei der Anbindung von Diensten oder APIs das Rad nicht neu zu erfinden. Verwenden Sie stattdessen Tools wie OpenAPI oder nutzen Sie speziell für SAP CAP die Destinationen und das SAP Cloud SDK für die Verbindung. Achten Sie außerdem darauf, keine API-Schlüssel oder andere sensible Daten in Ihrem Code oder in Dateien zu speichern, die an das Versionskontrollsystem (z. B. Git) übermittelt werden. Verwenden Sie stattdessen Destinationen auf der BTP-Seite oder Umgebungsvariablen, die später in Ihrer bereitgestellten Anwendung auf der SAP BTP angepasst werden können. Wenn Sie diese Praktiken befolgen, können Sie eine bessere Sicherheit gewährleisten und potenzielle Risiken auf dem Weg dorthin vermeiden.
Die Wahl der richtigen Architektur
Lassen Sie uns in das Thema der Auswahl der geeigneten Architektur für Ihr Projekt oder Produkt eintauchen, um Stabilität und Skalierbarkeit zu gewährleisten. Die North Star-Architektur von der SAP ist ein optimaler Ansatz für die Gestaltung komplexer Systemlandschaften, Modulen, Anwendungen, Backends und anderer Komponenten. Aber warum ist das so?
Zunächst einmal ist es wichtig, das Konzept der North Star-Architektur zu verstehen. Im Wesentlichen handelt es sich dabei um einen ereignisgesteuerten Microservices-Ansatz.
Aber was genau bedeutet das?
In der Praxis bedeutet dies, dass Sie Ihre Anwendung in verschiedene Dienste aufteilen, die jeweils über ein eigenes Datenbankschema und API-Endpunkte verfügen, um unterschiedliche Datentypen zu speichern. Dieser Ansatz ermöglicht es Ihnen, jede Komponente mühelos zu skalieren, sie mit neuen Versionen zu aktualisieren, sie in anderen Bereichen wiederzuverwenden oder sie in mehrere Szenarien zu integrieren.
Die ereignisgesteuerte Architektur führt eine weitere Schicht ein, die Ereignisse automatisch verarbeitet, das so genannte EventMesh. Dieser Ansatz ist für Ihre Architektur von entscheidender Bedeutung, da er es Ihnen ermöglicht, Dienste zu erstellen, die Ereignisse auslösen, und andere Dienste, die diese konsumieren oder abhören, vollständig zu entkoppeln.
Nehmen wir zum Beispiel an, ein Automobilhersteller implementiert eine ereignisgesteuerte Architektur. Es gibt mehrere Microservices für verschiedene Teile des Autokonstruktionsprozesses, z. B. einen Service für den Motor, einen für die Karosserie, einen für die Reifen und so weiter. Jeder Dienst hat sein eigenes Datenbankschema und seine eigenen API-Endpunkte.
Wenn nun ein Auto gebaut wird, können Ereignisse von verschiedenen Diensten ausgelöst werden, z. B. vom Motordienst, wenn der Motor gebaut wird, oder vom Reifendienst, wenn die Reifen montiert werden. Diese Ereignisse können von anderen Diensten genutzt werden, z. B. vom Montagedienst, der auf diese Ereignisse hört und die Endmontage des Fahrzeugs auslöst, sobald alle Teile fertig sind.
Entwerfen Sie Ihre zukünftige Landschaft
Nun sollten Sie mit den grundlegenden Kenntnissen und Werkzeugen vertraut sein, um mit der Verlagerung einiger Ihrer Prozesse auf die SAP BTP oder einen der anderen Hyperscaler zu beginnen. Es gibt mehrere Faktoren zu berücksichtigen und mehrere Möglichkeiten, Ihr Ziel zu erreichen, aber letztlich sind die wichtigsten Aspekte eine sichere und geschützte Umgebung, ein stabiles und gut organisiertes System zur Fehlerbehandlung und -berichterstattung sowie Überwachungsfunktionen z.B. per SAP CloudALM oder ähnlichen Tools.
Nachfolgend finden Sie ein typisches Systemlandschaftsdesign für eine Dreisystemlandschaft, das Ihnen dabei hilft, Ihre Microservices oder Produkte in die SAP BTP einzubringen und ein S/4HANA System sowie Services von Drittanbietern zu integrieren. Jede Landschaft hat ihre eigenen Anforderungen und Komplexitäten, daher ist es wichtig, eine maßgeschneiderte Landschaft auf der Grundlage Ihrer spezifischen Anforderungen und Ziele zu entwerfen.