wp-content/uploads/2022/04/server-room-1376349-scaled.jpg
Betriebsanforderungen aus Entwicklersicht

Im vorangegangen Beitrag habe ich auf hoher Ebene drei unterschiedliche Szenarien für den Betrieb einer Webapplikation besprochen. Gegen Ende des Beitrags habe ich das Problem geschildert, dass insbesondere bei der evolutionären Modernisierung von Legacy-Systemen ggf. alle Szenarien erfüllen zu müssen, was scheinbar einander widersprechenden Anforderungen entspricht. Bevor ich weiter ins Details gehe, skizziere ich daher Ansätze für den Umgang mit dieser Herausforderung.

Ich werde mich entlang der zuvor gebildeten Szenarien vorarbeiten:

  1. Traditionelle Anwendungen in einem komplexen Betriebsumfeld
  2. Traditionelle Anwendungen in einem einfachen Betriebsumfeld
  3. Microservice-Umfeld

Die Lösungsansätze werden aufeinander aufbauen und somit geeignet sein, auch mehrere oder alle Szenarien abzudecken. Natürlich muss man diese Flexibilität durch Aufwand bezahlen, daher wird jeweils diskutiert, wann das sinnvoll erscheint.

Szenario 1

Die Anforderung für dieses Szenario ist, die eigene Anwendung in eine Betriebs-Landschaft einfügen zu können. Gerade für ein Produkt mit einem langen Lebenszyklus ist unmöglich abzuschätzen, welche Systeme und Protokolle dafür in Zukunft bedienen werden müssen. Es muss fleixible und einfache Möglichkeiten geben, eine Integrationsschicht zu entwickeln.

Der Schlüssel zu dieser Flexibilität ist die Trennung des Applikationskerns der den Business-Code enthält von Integrations-Code. Eine bildliche Metapher hatten wir in den Illustrationen des letzten Beitrags gesehen, wo die Integrationsschicht wie eine Hülle den Applikationskern umschließt und an die Außenwelt anbindet – gleichzeitig aber klar getrennt ist. Dies ist kein neues Ziel und es gibt seit Jahrzehnten verschiedene Konzepte, dies umzusetzen. Natürlich können in einer Applikation diese Konzepte miteinander kombiniert werden:

  • Verschiedene Frameworks verfolgen dieses Ziel seit 20 Jahren (z.B. trat vor 20 Jahren J2EE mit diesem Ziel an) und haben seither erhebliche Fortschritte dabei gemacht.
  • Eine Möglichkeit ist die Entkopplung der beiden Code-Teile durch Interfaces. Dies ist Gegenstand von Architektur-Mustern, z.B. der sogenannten Hexagonalen Architektur (auch Zwiebel- bzw. Onion-Architektur).
  • Ein anderer Ansatz ist die Aspektorientierte Programmierung.

Es ist jeweils zu bewerten, ob sich die zusätzliche Komplexität lohnt. Insbesondere bei sogenannten CRUD-Services, die sich darauf beschränken, persistierte Daten zu exponieren, ist das Verhältnis zwischen Aufwand und Nutzen kritisch zu hinterfragen.

Das Einführen der beschriebenen Architekturmuster bringt abseits von den Betriebsaspekten einen großen Mehrwert für die Anwendung, kann aber bei einer großen Code-Basis mit erheblichem Aufwand verbunden sein. Um den Kern des Business-Codes von CRUD-Services abzugrenzen ist eine Modularisierung der Anwendung notwendig – hier kann Domain-Driven-Design einen Beitrag (DDD) leisten. Auch wenn Synergien bestehen, ist die Modularisierung und Modernisierung von Legacy-Software ist aber ein Thema, das weit über den hier gesetzten Rahmen hinausgeht und vielleicht mal mit einer eigenen Blog-Serie bedacht wird.

Überblicksebene, wechseln aber vom Problem- in den Lösungsraum.

Szenario 2

Die drei Schichten (Gechäftslogik, Integrationsschicht, Umgebung) werden hier in Form von konzentrischen Kreisen darstellt, wie das bei der sog. Zwiebel-Architektur (Onion-Architecture, aka Hexagonal Architecture) ueblich ist. Austausch der Integrationsschicht erlaubt unter Beibehaltung der Business-Logik die Anbindung einer anderes gestalteten Umgebung. Man sieht, dass der Scope der App im Szenario 1 bis zur Integrationsschicht reicht.

Gerade Rechenzentren, die viele Instanzen einer Anwendung für verschiedene Kunden betreiben, sind auf einen hohen Automatisierungsgrad angewiesen. Dies erfordert, dass unsere Anwendung per Kommandozeile administriert werden kann. Der Einsatz einer Administrationsoberfläche für Betrieb, Migration oder Installation – vielleicht noch als PC-Anwendung – entwickelt sich hier vom Komfort-Feature zum Hindernis. Die Automatisierung erfolgt wahrscheinlich durch den Betreiber selbst, aber als Entwickler müssen wir hier frühzeitig die Anforderungen zuliefern (Konfigurationsparameter, Operator-Handbücher etc.), was gerade in agilen Entwicklungsprojekten herausfordernd ist.

Need to know principle

Navigation