Achim Müller msg-systems AG

Die hohen Anforderungen Änderbarkeit, Skalierbarkeit und Verfügbarkeit, die an die Anwendungsarchitektur in der Cloud gestellt werden, bringen für den Architekten, der bisher im Enterprise-Umfeld unterwegs war, große Veränderungen.

Michael Schäfer msg-systems AG

Wir bevorzugen eine monolithische UI und eine monolithische Datenbank.

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.

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.

Der agile Architekt

Große Unternehmen wie Allianz, VW oder SBB gründen derzeit Labs oder Start-ups und bilden damit eine dezentrale und agile Organisationsstruktur im Unternehmen ab. In diesen arbeiten Produktteams, in denen der agile Architekt unterwegs ist. Das ist durchaus eine Veränderung für den Architekten, der bisher im großen Enterprise unterwegs war. Er besitzt nicht mehr eine solch exponierte Position im Team – es geht raus aus dem Elfenbeinturm. Natürlich gelten die Regeln für eine gute Architektur weiterhin, daran wird sich nichts ändern. Allerdings ändern sich grundlegende Prinzipien, die auf das Vorgehen und die Rolle des Architekten einen wesentlichen Einfluss haben. Beispielsweise orientiert sich der agile Architekt an den Prinzipien aus dem Agilen Manifest. Er ist sehr stark auf eine funktionierende Lösung fokussiert und geht dabei in kleinen Schritten inkrementell vor. Er ist Bestandteil des Produktteams, entwickelt aktiv mit und sieht sich als Unterstützer des Teams. Wer tiefer in das Thema einsteigen möchte, findet in „Agile Architecture Is Not Fragile Architecture“ oder „Lean Architecture: for Agile Software Development“ eine detaillierte Beschreibung. Auch der ISAQB e.V. hat sich dieses Themas angenommen und bietet als Erweiterung des Foundation Level das Modul AGILA „Agile Software Architecture“ im Advanced Level an. Unabhängig davon, welche Quellen angezapft werden, wichtig ist, dass der Architekt ein Bewusstsein für die Veränderung entwickelt, sich in diese Richtung verändert und die Rolle aktiv lebt.

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 durchaus unterschiedliche Ansätze, wie man diese Laufzeitumgebung aufbaut. Eine dieser Organisationen ist die Cloud Native Computing Foundation (CNCF). 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.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 9.16 - "Entwickler an die Macht!"

Alle Infos zum Heft
254471Cloud Application Architecture auf Enterprise-Ebene
X
- Gib Deinen Standort ein -
- or -