Containervirtualisierung
SAP braucht mehr als Linux
Den meisten SAP-Bestandskunden ist mittlerweile bewusst, dass Open Source viel mehr als Linux ist. IBM hat vor vielen Jahren Red Hat nicht übernommen, um ein weiteres Betriebssystem im Angebot zu haben, sondern weil zahlreiche Open-Source-Werkzeuge eine neue Organisation und Architektur der Enterprise-IT ermöglichen. SAP-Bestandskunde Henkel errichtet gemeinsam mit Red Hat eine neue IT-Infrastruktur, die mehr Flexibilität und Resilienz bringen wird.
On-premises vs. Cloud
Aus Sicht einer Open-Source-Community erscheint die Diskussion „On-premises vs. Cloud Computing“ als sehr akademisch und artifiziell. Würde doch eine Containervirtualisierung von S/4 diesen Diskurs beenden: Ob nun Docker und Kubernetes und weitere Komponenten im eigenen Rechenzentrum bei einem Hoster oder Hyperscaler zur Verfügung stehen, könnte im ersten Ansatz für die S/4-Container belanglos sein.
Docker und Kubernetes
Ein Gespräch am runden Tisch bei Red Hat zeigt, dass Anwender und SAP-Bestandskunden mitunter weiter sind als einige Anbieter. SAP-Bestandskunde Henkel baut gemeinsam mit Red Hat eine IT-Infrastruktur mit Cloud-Funktionalität und wird eigene Applikationen als Container betreiben. Durch diese Containervirtualisierung auf Basis von Kubernetes will Henkel größtmögliche Unabhängigkeit, Flexibilität und Resilienz erreichen.
Virtualisierung
Viele Jahre war VMware mit seiner Virtualisierungstechnik dominierend in der SAP-Community. Fast jeder CIO folgte dem Aufruf: konsolidieren, harmonisieren und virtualisieren. SAP selbst arbeitet intensiv mit VMware zusammen, weil die Technik eine nie gekannte Flexibilität in die ERP-Welt brachte. Virtualisierung wurde durch das SAP’sche Cloud Computing abgelöst und offenbar erkannte niemand die Synergie dieser Techniken. Die Open-Source-Community hat mit dem Containerkonzept gezeigt, dass es auch anders geht.
S/4-Container
Hat SAP durch Ignorierung der Containertechnik eine Jahrhundertchance vertan? Der erste Schritt mit Hana auf Linux und die Kooperation mit Suse und Red Hat waren gut und richtig. Es folgten der Einsatz und die Evaluierung weiterer Komponenten aus dem Open-Source-Portfolio. Eine grundlegende Umstellung der ERP-Architektur auf Containervirtualisierung wurde offensichtlich nie in Betracht gezogen. Aus aktueller Sicht hätte ein S/4, abgepackt in zahlreiche Container, die leidige Diskussion um Cloud first, Cloud only, Private, Public und Hybrid-Cloud eventuell hintanhalten können.
Vielleicht ist es auch kein technischer Diskurs, sondern eine Generationsfrage und mentale Einstellung. Als ich Informatik studierte, gab es auf der Universität nur Großrechner mit Lochkarten, aber noch kein Linux. Somit bin ich Open-Source-Lehrling und hoffe auf mehr Wissen und Einsicht bei SAP.
SAP setzt intern schon seit langem auf Container. Zum Beispiel ist Hana Cloud im Wesentlichen eine Container-Lösung.
Containerisierung ist aber nur eine Zwischenstufe. Wenn sowieso alle die gleiche Applikation in der SAP Cloud laufen lassen, warum 100'000 Container Instanzen starten? Auch Container benötigen Wartung.
Auf S/4Hana übertragen würde das bedeuten, dass es weltweit eine einzige Installation gibt, die von SAP, und jeder der hunderttausend Kunden ist nur ein Mandant im ERP System. Das wäre super, es ist aber offensichtlich, dass das nicht funktionieren kann, weil eben nicht jeder Kunde identisch ist. Nicht in der ERP Welt.
Und darum wären für SAP und Kunden eine Containerlösung auch meiner Meinung optimal.
Beispiel: Wenn ich ein UI für Hana entwickle, starte ich einen Container: OnPrem erfolgt das per "docker run -d -p 80:8080 rtdi/appcontainer:latest-hana" und schon ist die Software installiert. In einem Rechenzentrum werden die Container per Kubernetes gestartet. Bei den Hyperscalern gibt es schöne UIs um Container zu administrieren.
Keine zeitraubende XSA Installation, kein riesiges Konglomerat von Services, kein Unterschied zwischen OnPrem, eigene Cloud, Hyperscaler, ... alles sehr einfach und schnell.
Könnte SAP auch so machen. Man möchte aber lieber die Lösung, wo alle die selbe Installation verwenden. Das Problem mit den Unterschieden löst man, indem man jedem Kunde sagt: "Keep the core clean". Ist für SAP billiger.
Hallo und vielen Dank für den Hiweis zu Hana Cloud und die Erinnerung an: Keep the Core clean!
SAP beschäftigt sich sicherlich recht gründlich mit Containern und Kubernetes. So ist z.B. das OpenSource Projekt Gardener (https://gardener.cloud/) von SAP initiiert und hilft Kubernetes Cluster zentral über die Grenzen von Hyperscalern und on Premise hinweg zu verwalten. Auch Entwickler finden hier etwas passendes: Kyma (https://kyma-project.io/). Damit werden verschiedenste Projekte, die für eine vernünftige Kubernetes Umgebung benötigt werden zusammengestellt und in der BTP auch Supported.
Für ABAP Entwickler gab es bis zum 18.01.2022 auch eine Docker Image mit dem ABAP Applikationsserver (https://hub.docker.com/r/saplabs/abaptrial). Container sind also auch mit ABAP möglich. Neben dem ABAP Image steht leider auch das Docker Image für HANA Express (https://hub.docker.com/r/saplabs/hanaexpress) nicht mehr zur Verfügung. Also das Know-How für Container wäre da. Leider aktuell alles nicht mehr extern nutzbar.
Hallo! Ja, richtig - mein Einwand betraf weniger die operative und technisch Ebene, sondern, ob auf Vorstandsebene bei CTO Jürgen Müller und Thomas Saueressig das Thema Open Source auch als strategische und visionäre Komponente mental wahrgenommen wird?
SAP hat mannigfaltige Probleme mit Business ByDesign. Warum diesen Code nicht der Open-Source-Community übergeben und schauen, was passiert? Ein echtes Open-Source-ERP neben einem Open-Souce-CRM wie SugarCRM (bis Ver. 6) wäre einen Versuch wert.
Was passiert in Walldorf? 3000 Mitarbeiter werden entlassen und etwa 1000 Techniker werden von HCL Technologies angemietet, um unter anderem den Support für das abgekündigte Business ByDesign zu gewährleisten. Macht das Sinn? Also: SAP Business ByDesign sollte Open Source werden …