In den letzten Jahren wurde die nächste Evolutionsstufe im Bereich der Anwendungsarchitekturen eingeläutet. Anstatt komplette Server zu virtualisieren, lassen sich einzelne Services mit Hilfe von sogenannten Containern abbilden. Diese Container sind unabhängig von der Hardware, auf der sie laufen sollen und auch unabhängig vom Betriebssystem der Hardware, auf der sie betrieben werden.

Die Informationstechnik war schon immer eine Disziplin des stetigen Wandels, dies kann man ganz massiv im Bereich der Individualsoftware beobachten. Erste Dialogsysteme wurden mit zentralen Programmen auf Großrechnern oder auch Midrange-Systemen erstellt, die mit Hilfe von Terminals bedient wurden. Später entwickelten sich Programme, die monolithisch direkt auf dem Endgerät, typischerweise ein PC, lauffähig waren und speziell für die Geschäftswelt gab es Client-Server-Systeme, die es ermöglichten, dass die auf mehreren Clients installierten Programme eine zentrale Datenbasis nutzten.

Der folgende Evolutionsschritt führte eine dritte Ebene ein, indem Datenbankserver, Applikationsserver und Front-end getrennt wurden. Hierbei wurde das Frontend, der früher typische FAT-Client, im Laufe der Zeit durch den Web-Browser als Client für die grafische Benutzeroberfläche ersetzt. So entstanden umfassende und sehr leistungsfähige Frameworks für das Backend, um vor allem die Kommunikation mit der Datenbank zu leisten, und das Frontend. Parallel zu dieser Entwicklung erlaubte im Bereich der Infrastruktur die Virtualisierung der Server, dass auf einer leistungsfähigen Hardware mehrere Applikations- oder Datenbankserver laufen konnten.

In den letzten Jahren wurde die nächste Evolutionsstufe eingeläutet. Anstatt komplette Server zu virtualisieren, lassen sich einzelne Services mit Hilfe von sogenannten Containern abbilden. Diese Container sind unabhängig von der Hardware, auf der sie laufen sollen und auch unabhängig vom Betriebssystem der Hardware, auf der sie betrieben werden.

Die grundlegende Idee besteht darin, Applikationen in ihrem Aufbau so zu abstrahieren, dass sie nahezu beliebig verteilt auf geeigneter Infrastruktur betrieben werden können. Durch dieses Konzept eignen sich containerisierte Applikationen besonders gut für Server-Cluster und so-mit für die Cloud. Die Skalierung erfährt hierdurch zusätzliche Möglichkeiten. Zudem eignet sich das zumeist kleinteiligere Splitten von Applikationsteilen sehr gut für die modernen Ansätze der agilen Software-Entwicklung. Der Durchbruch speziell im Bereich der Individualsoftware-Entwicklung ist sehr eng mit dem immer stärkeren Verlagern von IT-Systemen in die Cloud verbunden und ist insbesondere dort State of the Art.

Theoretisch können bestehende Anwendungen auch 1:1 von einem klassischen Application-Server in einen Container umziehen, allerdings ist ein „kleinteiliges“ Vorgehen mit einer Aufteilung in eigenständige und idealerweise für verschiedene Applikationen verwendbare Microservices Best Practice. Hierbei sollte es eine feste Zuordnung der jeweiligen Entwicklerteams zu den Microservices geben. Die Services kommunizieren via http (REST) und es werden keine Sonderprotokolle genutzt, wie es in der Kommunikation zwischen einem Java-Front- und Backend der Fall ist. Bei der Entwicklung sollten Services immer gut skalierbar sein. Die klassische Aufteilung zwischen den Tiers Datenbank, Backend und Frontend fällt weg. Alle Services sind quasi in einer Zone.

Zum Containerisieren wird typischerweise das System Docker genutzt. Um schlussendlich die Prinzipien moderner agiler Softwareentwicklung umzusetzen, wird zur Orchestrierung solcher auf Containern basierter Anwendungen, zumeist Kubernetes, zur automatisierten Bereitstellung, Skalierung und Verwaltung genutzt. Im Zuge dessen spielen auch Tools eine entscheidende Rolle, um die agile Software-Entwicklung zu unterstützen. Hierbei stehen folgende Themen im Vordergrund:

  • Versionierung,
  • Entwicklung bzw. Unterstützung automatisierter Tests,
  • Automatisierung der Deployments sowie
  • Code-Analyzer für die Qualitätssicherung.

Speziell in der Cloud ist Containerisierung State of the Art und das ist ein weiterer zentraler Grund, warum vermehrt Lösungen in klassischer 3-Tier-Architektur auf Containerisierung und im Zuge dessen auch auf moderne DevOps Pipelines umgestellt werden.

Die richtigen Tipps zur Vorgehensweise und zur Vermeidung von „Stolperfallen“ im Zuge der Umstellung gilt es zu beachten. Dazu gehören:

  • Infrastructure as a Code ist von großer Bedeutung – durch die Aufteilung in mehrere Container sind verteilte Deployments notwendig. Um diese automatisiert durchführen zu können und um die Auslieferungen zu versionieren beziehungsweise Fehler im Prozess zu vermeiden, ist eine sehr gute deklarative Dokumentation von entscheidender Bedeutung. Es muss beschrieben werden in welcher Hierarchie die Module einer Applikation aufgebaut sind und welche Abhängigkeiten die einzelnen Module zu-einander haben. Deployments müssen reproduzierbar sein, sodass eine Auslieferung einer Entwicklungsumgebung auf eine Staging-Umgebung später bei der Auslieferung auf die Produktionsumgebung automatisiert erfolgen kann.
  • Security – eine stärkere Verteilung auf Microservices führt zur mehr Flexibilität bei den Deployments und den eingesetzten Technologien, erhöht aber auch die Ansprüche an die Security. Ein Security-Fehler muss so eventuell in mehreren Containern behoben werden. Hier bietet sich ein gemeinsamer Basiscontainer für eine Gruppe, wie etwa Java-basierte Anwendungen, an.
  • Monitoring & Logging – auch die Ansprüche an Monitoring und Logging werden durch die Containerisierung komplexer. Daher ist es zumeist sinnvoll hierfür zusätzliche Infrastruktur vorzusehen.
  • Dokumentation – wie bereits bei dem Thema Infrastructure as a Code erwähnt, ist in modernen containerisierten Systemen eine aktuelle und gepflegte Dokumentation essenziel, um den Einstig für neue Teammitglieder zu erleichtern. Die Wissensbasis im Team muss kontinuierlich aufgebaut werden, da sich die Technologien schnell entwickeln. Durch den Anspruch, dass Container autark funktionieren und idealer-weise auch für verschiedene Anwendungen nutzbar sein sollen, ergibt sich eine höhere Komplexität im Vergleich zu „alten“ 3-Tier Ansätzen. Die technischen Möglichkeiten sind deutlich heterogener. Dieses Szenario bietet eine Menge neuer Möglichkeiten und Vorteile, aller-dings muss mehr Zeit in Dokumentation und Wissensaufbau investiert werden, um zu vermeiden, dass man sich anhand der neuen Möglichkeiten verzettelt. Es ist schwieriger geworden den Überblick zu behalten, da die Szenarien schnell unübersichtlich werden können. Das gilt insbesondere dann, wenn man hochkomplexe Altapplikationen im Rahmen eines Refactoring in eine neue containerisierte agile Welt überführt.
  • Zusammenhang von agilem IT-Management und Architektur – der Teamaufbau und das Vorgehensmodell des Software-Engineering bedingen laut dem Gesetz von Conway im hohen Maße die Architektur eines IT-Systems. Gewissermaßen führt der agile und iterative Ansatz via Scrum & Sprints zu Containern und umgekehrt. Dieser modulare Aufbau ermöglicht sequenzielles Ausphasen, sprich das Redesign oder die Neuentwicklung von Funktionen in Form von Microservices, wenn die Schnittstellen zwischen den Services sauber definiert sind.
  • Business drives IT – es muss nicht immer alles schön und neu gemacht werden. Eine hybride Architektur aus containerisierten und klassischen Applikationen ist vor allem in der Migrationsphase sinnvoll, solange es die Anforderungen der Anwender erfüllt. Es macht keinen Sinn mit der Brechstange alles zu containerisieren. Mehrwerte für den Fachanwender erzielt eine neue Architektur vor allem dann, wenn es häufige Anpassungen und Erweiterungen gibt, weil sich dann die automatisierten Tests, Deployments und die DevOps-Pipelines sehr positiv auf die Bereitstellungsgeschwindigkeit und die Qualität der Software auszahlen.

Die mip GmbH hat in ihren Projekten viel Erfahrung bei der Erstellung aber auch der Umstellung auf containerisierte Anwendungen gesammelt und berät ihre Kunden gezielt, wie ein größtmöglicher Mehrwert bei der Umsetzung der Anforderungen an individuelle Lösungen erzielt werden kann.

Jörg Kremer ist Head of Consulting bei der mip GmbH.

mip GmbH