CIOs werden zu neuartigen Architekturkonzepten gezwungen

Eine typische Applikationsarchitektur erinnert bildlich an einen "Monolith", einen großen massiven Stein, der aus einem einzelnen Stück besteht. In diesem Zusammenhang kann man daher auch von einem "Applikationsklotz" sprechen, da sich darin die Eigenschaften schwer, unbeweglich und gar nicht bis kaum veränderbar widerspiegeln.

Über die letzten Jahrzehnte hinweg wurden viele, meistens große monolithische Applikationen entwickelt. Das bedeutet, dass eine Applikation sämtliche Module, Bibliotheken, Abhängigkeiten und so weiter beinhaltet, die notwendig sind, um die reibungslose Funktionsfähigkeit sicherzustellen.

Dieses Architekturkonzept bringt einen großen Nachteil mit sich. Ändert sich auch nur ein kleiner Teil an der Applikation, dann muss die gesamte Applikation neu getestet, kompiliert und bereitgestellt werden - ebenfalls die Teile der Applikation an denen keine Änderungen vorgenommen wurden. Ein riesiger Aufwand, der Personal, Zeit und IT-Ressourcen benötigt und in vielen Fällen zu Verzögerungen führt, insbesondere dann, wenn innerhalb eines der Teilabschnitte ein Fehler passiert. Weiterhin erschwert ein Monolith die Sicherstellung und Umsetzung von:

• Skalierbarkeit

• Verfügbarkeit

• Agilität

• Continuous Delivery

Um den oben beschriebenen Herausforderungen zu begegnen muss dafür gesorgt werden, dass die Applikationsarchitektur, anstatt aus einem einzigen großen Objekt, aus vielen einzelnen voneinander unabhängigen Objekten besteht. Alle Teilobjekte miteinander integriert führen dann zur Gesamtfunktionalität der Applikation. Die Änderung eines Teilobjektes beeinflusst dabei nicht die Eigenschaften und Funktionsweisen eines anderen Teilobjektes. Unterm Strich bedeutet dies, dass jedes Teilobjekt als eigener unabhängiger Prozess beziehungsweise Service funktioniert. Dieses Konzept wird auch als "Microservice-Architektur" bezeichnet.

Was ist ein Microservice?

Ein Microservice kapselt eine abgeschlossene Funktionalität und wird unabhängig entwickelt und betrieben. Es handelt sich dabei also um eine kleine eigenständige Softwarekomponente, die eine Teil-Funktion innerhalb einer großen, verteilten Softwareapplikation bereitstellt. Ein Microservice lässt sich somit unabhängig entwickeln und bereitstellen und skaliert autonom und selbständig. Auf Microservices basierende Applikationsarchitekturen sind daher modularisiert und lassen sich einfacher und schneller um neue Funktionen erweitern und im Laufe des Lebenszyklus warten.

Im Gegensatz zu klassischen Applikationsarchitekturen verfolgen moderne Cloud-basierte Architekturen den Microservice-Ansatz. Dies ist den Eigenschaften der Cloud geschuldet, an denen die Cloud-nativen Applikationsarchitekturen entsprechend angepasst werden müssen. Das bedeutet, sie müssen Themen wie die Skalierbarkeit und Hochverfügbarkeit von Beginn an mit berücksichtigen. Die Vorteile einer Microservice-Architektur zeichnen sich insbesondere durch die folgenden Eigenschaften aus:

• Bessere Skalierbarkeit: Wird ein Teil-Service einer Applikation zu einem Zeitpunkt mehr in Anspruch genommen als die anderen, ist er in der Lage eigenständig zu skalieren, ohne die restlichen Teile der Applikation negativ zu beeinflussen.

• Höhere Verfügbarkeit der gesamten Applikation: Fällt ein Teil-Service aus, beeinflusst er damit nicht die gesamte Applikation sondern nur die Funktionalität die er abbildet. Das kann bedeuten, dass ein Teil-Ausfall keine direkte Außenwirkung hat, wenn es sich dabei um einen Backend-Service handelt.

• Bessere Agilität: Änderungen, Verbesserungen und Erweiterungen lassen sich unabhängig von der Funktionalität der gesamten Applikation vornehmen und ohne andere Teil-Services zu beeinträchtigen.

• Continuous Delivery: Die Änderungen, Verbesserungen und Erweiterungen lassen sich regelmäßig vornehmen, ohne dass für die gesamte Applikation ein Update vorgenommen werden muss beziehungsweise ohne die gesamte Applikation in den Wartungsmodus zu schicken.

Ein weiterer Vorteil einer Microservice-Architektur: Ein Microservice lässt sich in mehr als einer Applikation einsetzen. Einmal entwickelt kann er später für eine Funktion in vielen weiteren Applikationsarchitekturen sorgen.