In SAP neue Dinge auszuprobieren, kann schwierig sein. Das liegt u. a. daran, dass Teams häufig in gemeinsam genutzten Entwicklungs- und QA-Umgebungen mit einer gemeinsamen Codebasis arbeiten.

Manchmal gibt es eine Sandbox. Mitunter steht für die Projektarbeit auch ein N+1- oder N+2-Pfad zur Verfügung. In der Regel müssen jedoch alle zur gleichen Zeit am gleichen Ort arbeiten und darauf achten, dass die laufende Arbeit der anderen dabei nicht beschädigt wird. In einer Zeit, in der man schnell auf Kunden reagieren und geschäftlich agil sein muss, ist das keine sehr flexible Methode.

Dafür gibt es eine Reihe wichtiger Gründe. Erstens war jede „Box“ früher genau das, was das Wort eigentlich bedeutet: physische Hardware, die nicht schnell, einfach oder kostengünstig repliziert werden konnte. Zweitens war es alles andere als trivial, diese unterschiedlichen Systeme miteinander zu verbinden, selbst wenn man über die Ressourcen für ihre Ausführung verfügte.

Tools wie ActiveControl mit ihren Funktionen wie der Überhol- und Regressionsanalyse, dem automatisierten Befördern von Transporten, dem automatischen Zusammenführen von Code, benutzerdefinierbaren Transportpfaden usw. bieten eine Lösung für den letztgenannten Punkt. Das erste Problem bleibt jedoch bestehen: Wenn Sie agile Teams für die SAP-Entwicklung einsetzen möchten, müssen Sie geeignete Umgebungen bereitstellen, in denen die Teams ohne permanente Konflikte autonom arbeiten können. Aber wie bewerkstelligen Sie das?

Manche Unternehmen sehen in der agilen Entwicklung bereits einen Schritt, der so essenziell ist, dass sie das Problem nach der Brute-Force-Methode angehen – indem sie ihren Teams mehrere „altmodische“ Entwicklungsboxen bereitstellen (ein Kunde von Basis Technologies hat das für ein N+10-Setup getan). Für die meisten ist das jedoch nicht praktikabel.

Zugegebenermaßen ist das ein Bereich, in dem Cloud-Hosting sehr geholfen hat. Plattformen wie AWS bieten ein erheblich höheres Maß an Skalierbarkeit und Elastizität als früher, aber die Bereitstellung eines neuen Systems erfordert nach wie vor einen beträchtlichen Aufwand. Ein Entwickler kann das definitiv nicht auf Knopfdruck bewerkstelligen – wie es außerhalb von SAP häufig möglich ist. Jetzt steht jedoch eine (relativ) neue Technologie zur Verfügung, die den Prozess noch stärker vereinfachen kann: Container.

Was ist ein Container?

Kurz gesagt, soll ein Container sicherstellen, dass Software zwischen verschiedener Hardware oder verschiedenen Umgebungen – oder sogar VM-Umgebungen – migriert werden kann, ohne dass man sich Gedanken darüber machen muss, ob die Unterschiede zwischen ihnen die ordnungsgemäße Funktion der Software beeinträchtigen – oder genauer gesagt, ihre konsistente Ausführung verhindern. 

Dafür enthält ein Container alles, was eine Softwareanwendung für die Ausführung benötigt: Bibliotheken, Binärdateien und Konfigurationsdateien. Docker, eines der Unternehmen, das Pionierarbeit in der Containertechnologie geleistet hat, bietet folgende Definition an: „Ein Container ist eine Standardeinheit mit Software, die Code und alle seine Abhängigkeiten zu einem Paket schnürt, damit die Anwendung auch bei Wechsel der Rechnerumgebung schnell und zuverlässig ausgeführt werden kann.“

Häufig wird dabei der Vergleich mit herkömmlichen Transportcontainern gezogen, mit denen auf der ganzen Welt Waren bewegt werden. Es spielt keine Rolle, was sich in ihnen befindet – sie passen auf jedes Schiff, können von jedem Kran angehoben und ohne Kompatibilitätsprobleme auf jeden LKW oder Zug verladen werden.

Warum Container verwenden?

Die Tatsache, dass Container nicht von der Infrastruktur abhängen, ist für viele schon Grund genug, sie zu nutzen. Neben ihrer konsistenten Performance und der Möglichkeit, überall problemlos ausgeführt zu werden (auf unterschiedlichen Betriebssystemen, auf VMs, auf konventionellen Servern, lokal, in der Cloud usw.), bieten Container noch weitere Vorteile.

Standardisiert: Container selbst sind standardisiert (auch wenn es viele Container-Management-Tools gibt). Zu verdanken ist dies zum großen Teil der Open Container Initiative, die eine Governance-Struktur für die Erstellung offener Container-Standards bereitstellt und von vielen großen Namen in der Tech-Welt unterstützt wird. Darüber hinaus lässt sich jeder Container aus einem vorlagenbasierten Image erstellen – und dadurch einfach sicherstellen, dass alle Container gleich konfiguriert sind.

Isoliert: Anwendungen, die in Containern ausgeführt werden, sind voneinander isoliert und werden nicht direkt auf dem Host-Betriebssystem (OS) ausgeführt. Das schafft eine zusätzliche Sicherheitsebene und ermöglicht es Ihnen, Ressourcen effektiver zu verwalten, indem Sie für jede Ressource explizite Grenzwerte festlegen.

Schlank: Weil Container kein eigenes Betriebssystem benötigen, sondern den Systemkernel des Host-Computers mitnutzen, sind sie in der Regel klein und benötigen nur eine entsprechend kleine Menge an Systemressourcen. Für Sie heißt das, dass Sie entweder mehr Anwendungen auf derselben Hardware ausführen oder Ihre Server- und Lizenzkosten senken können. 

Unterstützung der modernen Entwicklung: Dank ihrer Portabilität, schlanken Auslegung und vorlagenbasierten Struktur lassen sich Container extrem schnell und einfach „aufsetzen“ und entsorgen. Das ist ideal für moderne Entwicklungsansätze wie Agile und DevOps, bei denen verteilte Teams u. U. an eigenständigen Entwicklungen arbeiten, die häufig in kleinen Schritten bereitgestellt werden. 

Modular und effizient: Die Möglichkeit, eine einzelne Anwendung von nahezu jeder Größe in einem einzigen Container auszuführen, macht sie zur perfekten Wahl für einen modularen Softwareentwicklungsansatz, der eine effizientere Nutzung physischer Systemressourcen ermöglicht. Und besser noch: Sie eignen sich ideal für eine Microservices-Architektur, bei der eine monolithische Anwendung in eine Reihe vieler kleiner Dienste aufgeteilt ist. 

Container und VMs im Vergleich 

Wenn Container nun zum neuen Mittel der Wahl aufgestiegen sind, da sie keine dedizierte Hardware benötigen, waren VMs (Virtual Machines) zumindest früher ganz nah dran. Container mögen viele Vorteile haben, dennoch lässt sich mit Recht sagen, dass es sowohl für sie als auch für VMs einige Für und Wider gibt. Worin unterscheiden sich die beiden?

Grundsätzlich benötigt jede VM ein eigenes Betriebssystem, ein Container hingegen nicht. VMs können also viel mehr Systemressourcen belegen und sind sicherlich mühsamer zu konfigurieren. Google versucht das mit folgendem Diagramm zu veranschaulichen:

SAP in Containern

Das ist ja alles sehr interessant, aber ist es für die SAP-Welt überhaupt relevant? Warum sollten wir uns für Container interessieren?

Es stimmt, dass die Ausführung von containerisierten SAP-Anwendungen für die meisten eine ziemlich ungewohnte Vorstellung ist. Schließlich geht es hier um ECC oder S/4, und damit ist es eher unwahrscheinlich, dass es sich um ein kleines System handelt. Und aufgrund der Eigenschaften von SAP kann es auch nicht einfach in einzelne Teile zerlegt werden.

Aus internen Untersuchungen bei Basis Technologies und Gesprächen mit unseren aufgeschlosseneren Kunden geht jedoch hervor, dass Container bereits das Potenzial haben, auch bei der Entwicklung einer noch so monolithischen SAP-Anwendung Vorteile zu bieten.

Größe und Geschwindigkeit der Bereitstellung: Gut, Sie werden die Größe Ihrer SAP-Datenbank nicht reduzieren können, aber wenn Sie sie in einem Container ausführen, brauchen Sie nicht viel mehr. Weil in Containern kein Betriebssystem läuft, ist jedes System viel kleiner und einfacher zu erstellen. Bei Basis Technologies sind wir in der Lage, in wenigen Minuten ein betriebsbereites containerisiertes Entwicklungssystem aufzusetzen, das nur rund 40 GB Speicherplatz benötigt.

Agile Entwicklung: Wie eingangs erwähnt, eignen sich Container ideal für die agile Entwicklung. Und dieser Ansatz wird von immer mehr SAP-Teams verfolgt. Sie ermöglichen die dynamische Größenanpassung von Entwicklerteams über mehrere Sprints hinweg, weil sie sicherstellen, dass neue Systeme je nach Größe, Volumen und wechselseitigen Beziehungen der einzelnen in Arbeit befindlichen User Stories einfach erstellt oder außer Betrieb genommen werden können.

Flexible Qualitätssicherung: Vielleicht benötigen Sie gar nicht mehrere Entwicklungssysteme. Oder Sie haben bereits genug davon und die Möglichkeit, schnell weitere hinzuzufügen, bringt Ihnen gar nicht viel. Selbst dann kann ein flexiblerer QA-Prozess von Vorteil sein. SAP-Teams, mit denen wir sprechen, beklagen sich häufig über die Unmöglichkeit schneller Tests in einem QA-System – ein echter Engpass für Entwickler. Aber wie wäre es, wenn sich ein neues QA-System – basierend auf einem „idealen“ Image – bei Bedarf einfach aufsetzen und damit Ihre Standard-QA-Box erweitern ließe? Genau das macht einer unserer Kunden in einer agilen Umgebung, um das Testen zu beschleunigen und die Softwarequalität zu verbessern. 

Verteilte Entwicklung: Noch radikaler als die agile Methodik (die gar nicht mehr so neu ist) ist das Konzept der verteilten Entwicklung mit abapGit. Eine ausführlichere Erläuterung dessen würde den Rahmen dieses Beitrags sprengen. Wenn es Sie interessiert, lesen Sie diesen Blog. Die Grundidee ist jedoch, dass jeder Entwickler unabhängig an seiner eigenen Version des SAP-Quellcodes arbeitet und jederzeit auf jede frühere Version zugreifen kann. Das bedeutet jedoch, dass jeder seine eigene SAP-Umgebung benötigt, in der er arbeiten kann. Container bieten eine ideale Möglichkeit, diese Systeme schnell und einfach bereitzustellen. 

Glänzende Aussichten

Bei Basis Technologies arbeiten wir mit SAP-Anwendern auf der ganzen Welt zusammen, um sie bei der Transformation und Verwaltung ihrer SAP-Systeme zu unterstützen. Das heißt, wir halten immer nach neuen Technologien Ausschau – wie z. B. Container –, mit denen sich die Agilität, Geschwindigkeit und Effizienz von SAP erhöhen lässt. Wenn Sie mehr darüber erfahren möchten, wie unsere DevOps- und Testautomatisierungssoftware Ihnen dabei helfen kann, effizienter mit SAP zu arbeiten, können Sie gern Kontakt mit uns aufnehmen.