© Excellent backgrounds/Shutterstock.com
Teil 3: Anwendungsarchitektur für die Cloud im Enterprise-Umfeld

Von der Theorie in die Praxis


Die Architektur klassischer Anwendungen im Enterprise-Umfeld ist bekannt: Diese werden auf Grundlage von 3-Tier-Architekturen entwickelt, üblicherweise mit Enterprise-Frameworks wie Java EE oder Spring. Der Betrieb erfolgt auf Anwendungsservern im klassischen Rechenzentrum. Aber wie sieht eine Architektur für Anwendungen in der Cloud aus? Diese müssen den hohen Anforderungen an die Änderbarkeit, Skalierbarkeit und Verfügbarkeit gerecht werden, die die Systems of Engagement (SoE) an sie stellen.

Bevor wir uns in die Architektur einarbeiten, schauen wir uns die neue Rolle des Architekten an (Kasten „Der agile Architekt“). Die Anwendungen für die Systems of Record (SoR), die wir bisher entwickelt haben, haben wir auf dedizierten Servern in einem Rechenzentrum betrieben. Auf diesen lief ein Java-EE-Server, zum Beispiel WebSphere oder Tomcat, in dessen Container wir unsere Anwendung als Monolithen, in Form eines EAR oder WAR ausgeliefert haben. Bei Bedarf wurde die Laufzeitumgebung horizontal skaliert, indem mehrere Server zum Einsatz kamen. Die Last wurde dann über einen vorgeschalteten Reverse Proxy, der als Load Balancer fungierte, auf diese verteilt.

Diese Laufzeitumgebung kann die geforderten hohen Anforderungen nicht ausreichend erfüllen. Eine automatische horizontale Skalierung ist damit nicht möglich, da die Anzahl der Server fest vorgegeben ist. Eine Änderung der Anwendung ist mit einer Änderung der Anwendungsinstallation auf dem Java-EE-Server und somit mit dem Ausfall der gesamten Anwendung verbunden. Auch die Verfügbarkeit der Anwendung ist mit einem oder ein paar Servern nicht gerade gut.

Eine neue flexible Laufzeitumgebung musste her: die Cloud. Es gibt mehrere Organisationen, die versuchen, die Architekturen und Technologien des Cloud Computings zu standardisieren. Denn derzeit gibt es unterschiedliche Ansätze, wie man diese Laufzeitumgebung aufbaut. Eine dieser Organisationen ist die Cloud Native Computing Foundation (CNCF) [5]. Schaut man sich den dort beschriebenen Ansatz des Cloud Computings etwas genauer an, kann dieser auf drei Schichten abstrahiert werden. Die erste Schicht besteht aus den Maschinen, die CPU und Speicher bereitstellen. Die zweite Schicht besteht aus Containern, die einer Anwendung ein Betriebssystem zur Verfügung stellen und diese von anderen Anwendungen auf derselben Instanz der ersten Schicht isolieren. Die dritte Schicht bilden die Microservices, mit denen eine Anwendung aufgebaut wird.

Diese Architektur erfüllt die Anforderungen an die Laufzeitumgebung viel besser. Durch die mehrfache Instanziierung der Maschinen und Container kann die Laufzeitumgebung wesentlich besser skaliert werden. Eine bessere Änderbarkeit wird dadurch erreicht, dass die Anwendung auf mehrere Microservices verteilt wird. Somit können Teile der Anwendung geändert werden, ohne dass die gesamte Anwendung ausfällt. Auch die Verfügbarkeit ist wesentlich besser, da die Anwendung auch dann noch verfügbar ist, wenn Teile davon nicht funktionieren.

Allerdings erhalten wir mit der Flexibilität der Laufzeitumgebung eine höhere Komplexität. Die Architektur einer Cloud entspricht der Architektur eines hochverteilten Systems, dessen heftige Herausforderungen hinlänglich bekannt sind. Hinzu kommt, dass wir eine Menge an Infrastrukturtechnologie benötigen, um diese Laufzeitumgebung aufzubauen: Wir benötigen eine Komponente zum Managen der Maschinen, eine andere Komponente zum Managen der Container oder eine dritte Komponente für ein intelligentes Load Balancing des eingehenden Traffics, das den aktuellen Zustand der Laufzeitumgebung berücksichtigt.

Es stellt sich nun die Frage, ob wir ein solch hochverteiltes System selbst aufbauen und betreiben oder ob wir eine bereits vorgefertigte Lösung einkaufen. Im Enterprise-Umfeld ist es sinnvoll, eine vorgefertigte Lösung einzukaufen, da das Kerngeschäft nicht der Aufbau und Betrieb einer Cloud ist, sondern die Bereitstellung von fachlichen Anwendungen.

Das Produkt von Pivotal, die Pivotal Cloud Foundry (PCF), bietet genau eine solche Lösung an, basierend auf der Open-Source-Software Cloud Foundry. Pivotal spricht dann von einer Cloud-Native Platform [6]. Das Management der Maschinen übernimmt Bosh [7]; das Management der Container übernimmt Diego [8]. Das intelligente Routing übernimmt der (Go) Router [9]. Eine komplette Übersicht der gesamten Cloud-Native-Plattform zeigt Abbildung 1.

schaefer_cloud_1.tif_fmt1.jpgAbb. 1: Übersicht der Cloud-Native-Plattform

Natürlich wird der Architekt am Ende des Tages die Laufzeitumgebung, in unserem Fall PCF, einfach nur verwenden, ähnlich wie er es bei einem Java-EE-Server getan hat. Allerdings ist es wichtig, die beschriebene Architektur zu kennen, um später die Anwendung optimal für die Laufzeitumgebung auszulegen.

Applikationen in der Cloud entwickeln

Die Cloud-Native-Plattform bietet die zwei Konzepte Apps und Services, die für die Entwicklung von Anwendungen in der Cloud wesentlich sind. Schauen wir zunächst auf die Apps. Diese sollten nicht mit den Apps verwechselt werden, die man aus dem Apple App Store oder dem Google Play Store auf seinem Smartphone installieren kann. Apps stellen im hier beschriebenen Kontext fachliche und technische Funktionen in der Cloud bereit, vergleichbar mit den Servlets oder EJBs im klassischen Enterprise-Umfeld. Es gibt allerdings einen wesentlichen Unterschied: Servlets und EJBs laufen in einem Java-EE-Server; Apps hingegen müssen ihre Server selbst mitbringen. Apps, die beispielweise mit Spring Boot implementiert sind, bringen ihren eigenen Tomcat oder Jetty mit. Das erscheint auf den ersten Blick wie eine Verschwendung von Ressourcen. Aber Apps unterstützen damit die Prinzipien der Self-Contained-Systems, die das Ziel haben, die Komponenten vollständig autonom zu machen. Damit können Apps in beliebigen Sprachen, mit unterschiedlichen Technologien und in unabhängigen Teams entwickelt werden. Eine App läuft in ein...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang