© Excellent backgrounds/Shutterstock.com
Java Magazin
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.

Michael Schäfer, Achim Müller


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 funktion...

Java Magazin
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.

Michael Schäfer, Achim Müller


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 funktion...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang