Funktionalität vs. Skalierung
Funktionalität & Skalierung - Zwei Seiten einer Anwendung, die bereits in der Software-Architektur Beachtung finden sollten.
Dr. Matthias Boldt - Am Anfang geht alles sehr schnell und die Ereignisse überschlagen sich beinahe. Die Idee ist großartig und das Commitment des Gründungs-Teams ist überwältigend. Zügig ist das IT-Startup gegründet und bereits nach kurzer Zeit läuft ein experimenteller Prototyp des Produktes. Einige Debugging-Sessions und Optimierungen später zeigt die Software erste der erwünschten Ergebnisse. Ein Grund zum Feiern.
Und dann geschieht es: Das Team der Software-Entwicklung lehnt sich entspannt zurück. Auftrag erfüllt, die Funktionsfähigkeit ist prinzipiell nachgewiesen. Nun soll der Vertrieb zeigen, was er kann …
Aber ist damit die Arbeit zum Aufbau der ersten Version eines vermarktbaren Produktes wirklich bereits beendet? Kann der Vertrieb in dieser Phase potenziellen Kunden ein substanzielles Angebot unterbreiten und/oder sind Endkunden bereit Geld für das Produkt auszugeben und ihre Zeit in die Nutzung zu investieren?
Hat man einmal erlebt, was es heißt, ein Produkt von Null an bis zur Marktreife zu entwickeln, dann weiß man sofort: Das “dicke Ende” kommt erst noch.
Und nun, wie weiter?
Klar, ein funktionierender Software-Workflow ist noch lange kein verkaufbares Produkt. Und so liefert bereits ein erstes und ernsthaftes Nachdenken über die Lage eine große Anzahl offener Arbeitspakete:
- Ein Schema für Zugangsberechtigungen muss entworfen werden, das die Geschäftsabläufe und Strukturen der künftigen Kunden widerspiegelt. Daraus ist eine Rechteverwaltung zu entwickeln und natürlich in die Anwendung zu integrieren.
- Die Themenkomplexe Datenschutz und Datensicherheit müssen unbedingt bearbeitet werden. Die Anwendung und auch deren praktischer Betrieb benötigen eine Sicherheitsarchitektur. Daraus entstehen natürlich viele weitere Arbeitsaufgaben.
- Für die Pflege des Produktes muss eine funktionsfähige CI/CD-Pipeline erstellt werden. Insbesondere die Continuous-Integration ist schließlich als gute Werkbank die Grundlage der Evolvierbarkeit der Software.
- Mit Hilfe von Kooperationspartnern aus der Praxis sollen Betatests ausgeführt werden. Dafür müssen diese Partner zuerst einmal gefunden werden. Am Ende führen die Tests natürlich zu immer neuen, notwendigen Anforderungen … und wieder entstehen neue Arbeitsaufgaben.
- Das User-Interface - die Nutzeroberfläche - des Produktes muss ein ansprechendes und gleichzeitig erwartungskonformes Design erhalten. Damit sind die meisten Software-Entwickler auf Grundlage ihrer Persönlichkeitsstruktur ‘überfordert’ … handelt es sich doch nicht um Funktionalität, sondern teilweise um eine künstlerische Tätigkeit.
- Das allseits ungeliebte Thema ‘Dokumentation’ muss irgendwann vor der Markteinführung dann auch noch bearbeitet werden. Auch im Zeitalter intuitiver Apps gilt nach wie vor: Eine nicht dokumentierte Funktionalität ist eine nicht vorhandene Funktionalität. Anwender nutzen nur etwas, von dem sie auch Kenntnis besitzen.
- Da es noch nicht auswändig genug war: Für die zukünftige Pflege der Software wird zusätzlich noch eine spezielle ‘Software-Dokumentation’ benötigt, schließlich müssen auch Entwickler Algorithmen verstehen, die sie nicht selbst verfasst haben.
- … und es gibt noch viele weitere Themen aus unterschiedlichen Bereichen (Software-Entwicklung, Vertrieb, Service, Buchhaltung, …)
Diese Liste der Arbeiten für eine Produktisierung lässt sich noch fortgeführen. Eines dieser ‘sonstigen Themen’, das hier noch nicht genannt wurde, ist die Skalierung der Anwendung. Es lohnt sich dies etwas genauer zu betrachten. Die Fähigkeit zur Skalierung kann starke positive und auch sehr negative betriebswirtschaftliche Auswirkungen haben - nicht ganz unwichtig für den Erfolg eines Unternehmens.
Belastung von Software-Systemen
Im praktischen Einsatz ist eine Software ganz unterschiedlichen Belastungen ausgesetzt. Natürlich ist das von extrem vielen Parametern und Rahmenbedingungen abhängig. Moderne Software ist heute zum überwiegenden Teil als ein Cloud-System realisert. Wird dieses im B2B-Geschäft eingesetzt, lässt sich in vielen Fällen die Anzahl der Anwender und auch deren Nutzungszeit einschätzen. Daraus ergibt sich ein großer Vorteil für die Planung der Infrastruktur und auch der Einsatzzeiten des Support-Teams.
Für ein Software-System, das im B2C-Umfeld eingesetzt wird, ist dies nahezu unmöglich. Mit Simulationen und Modellierungen kann man versuchen, den realen Bedarf an Ressourcen zu ermitteln. Was solche Verfahren leisten (oder dass sie in den meisten Fällen grandios scheitern) können, zeigen die jüngsten Erfahrungen mit Modellierungen zum Wetter, zu Naturkatastrophen und zur Entwicklung von Pandemien … in keinem Falle wurden die berechneten Verläufe später durch die Realität bestätigt. Es gilt also auch weiterhin: Erstens kommt es anders und zweitens als man modelliert. (… ein Witz aus meiner Studienzeit und nicht ganz ernst gemeint.) Klar wird jedoch, dass man sein Software-System auf alle denkbaren Eventualitäten der Praxis vorbereiten muss.
Wenn die Vermarktung des Produktes gut läuft, was sich verständlicher Weise alle der Beteiligten wünschen, wird es unvorhersehbare Peaks in der Nutzung geben. Da kann jeder Verkaufsstart, jede Social-Media-Aktion die (un)gewollt ‘viral geht’, jede Werbung in den Broadcasting-Medien zu Zugriffs- und Nutzungszahlen führen, die für eine unterdimensionierte Infrastruktur zum Desaster wird. Eine zeitliche Vorausschau dieser Ergebnisse ist so und so unmöglich. Zu viele Parameter bestimmen den zukünftigen Lauf der Ereignisse, der sich damit unserer Erkenntnis entzieht.
Es ergibt sich DIE wesentliche Frage:
Hält die Anwendung einem (un)erwartet großen Kundenansturm stand?
Da es unmöglich ist, die Nutzungsraten zu kalkulieren, gibt es nur die Chance, in der Architektur der Anwendung Möglichkeiten einer Skalierung vorzusehen. Mit deren Hilfe kann dann hoffentlich (relativ) schnell auf Veränderungen in den Nutzungszahlen reagiert werden.
Skalierung ist nicht gleich Skalierung
Die Möglichkeiten zum Skalieren einer Anwendung sind eng mit ihrer Architektur verbunden. Abhängig von ihrer Konstruktion kann prinzipiell auf zwei Arten skaliert werden. Entweder wird die komplette Anwendung dupliziert und es laufen mehrere ihrer Instanzen parallel oder es werden Kopien einzelner Teile/Module des Systems nebeneinander gestartet.
Skalierung vollständiger Anwendungen
Bei einem monolithischen Aufbau der Anwendung muss diese in den meisten Fällen vollständig repliziert werden. Dies erfordert natürlich spezielle Vorsehungen in der Anwendung selbst, da zum Beispiel beim Zugriff auf zentrale Datenbestände kein versehentliches Überschreiben stattfinden darf. Zusätzlich ist eine infrastrukturelle Vorrichtung notwendig, welche die Verteilung von Anfragen auf die unterschiedlichen Instanzen vornimmt. Das kann z.B. in Form eines Load-Balancers geschehen.
Um eine gesamte Anwendung zu replizieren und zu starten, sind einige Vorbereitungen zu treffen. Zuerst einmal müssen die entsprechenden Ressourcen (Compute- und Storage-Ressourcen) bereitgestellt werden. In dem beschriebenen Fall handelt es sich meist um größere Einheiten. Damit sind oft rampup-Zeiten von mehreren Stunden bis zu Tagen verbunden. Das kann durch das Vorhalten von startbereiten Instanzen vermieden werden … z.B. in einem ‘cold standby’ Modus.
Die dauerhafte Bereitstellung größerer, ungenutzter Ressourcen ist natürlich kein betriebswirtschaftliches Optimum. Es entstehen unnötige Kosten und ‘green-IT’ funktioniert ebenfalls anders. Dazu kommt die Problematik, dass nie die gesamte Anwendung stark belastet ist, sondern nur einige ihrer Teile/Module. In einem monolithischen System können diese leider nicht getrennt vom Rest der Software skaliert werden. Wegen Überlastungen, die nur kleine Teile betreffen, wird also das gesamte System dupliziert.
Zusätzlich ist wegen der aufgeführten Rahmenbedingungen ein automatisches Skalieren schwerer umsetzbar. Es mmuss zum Beispiel die passende Konfiguration der gesamten Anwendung immer in der aktuellen Form für die zusätzlichen Instanzen vorgehalten werden. Dabei handelt es sich meist um eine große Anzahl an Parametern, die eine starke Fehleranfälligkeit generiert.
Das Zuschalten von neuen Instanzen der Anwendung in den produktiven Verbund ist immer ein ’langsamer’ Vorgang. Im besten Falle ist mit einer ‘Wartezeit’ von mehreren Minuten zu rechenen, es kann sich aber auch um viele Stunden handeln … wenn z.B. große Datenbanken repliziert werden müssen.
Die Skalierung mittels vollständiger Instanzen einer Anwendung ist also nur bedingt geeignet, um spontane Peaks in der Nutzung aufzufangen.
Skalierung einzelner Funktionen
Mittels einer nach dem Microservices-Architekturmuster gestalteten Anwendung lassen sich die zuvor aufgeführten Probleme umgehen. Natürlich ergeben sich dabei andere, neue Nachteile - keine Lösung ist perfekt. Hier soll jedoch nur auf die Vorteile und neuen Möglichkeiten bezüglich der Skalierung mit Microservices eingegangen werden.
Da in einem Software-System mit einer “sauberen” Microservice-Architektur die einzelnen Verarbeitungsmodule/-services stateless sind und keine enge Kopplung besitzen, können einzelne Teile der Anwendung je nach Bedarf skaliert werden.
Natürlich bedarf das einer exakten Erfassung der Belastung einzelner Services, also der funktionalen Teile der Anwendung. Dies sollte “zeitnah” erfolgen, das heißt in einem Intervall von wenigen Sekunden ständig aktualisiert werden. Mit den Messwerten lässt sich dann die Notwendigkeit einer Skalierung visualisieren/signalisieren und eine Steuerung implementieren.
Da auf diese Weise nur einzelne Services skaliert werden, sind die rampup-Zeiten der Module sehr viel geringer als für eine komplette, monolithische Anwendung. Dies diese Services stateless sind, gibt es für sie im Normalfall auch keine komplizierte Konfiguration, was die rampup-Zeiten zusätzlich positiv beeinflusst.
Natürlich ist im Ergebnis einer ausschließlichen Skalierung einzelner Teile der gesamte Ressourcen-Bedarf der Anwendung viel geringer als im Falle einer monolithischen Lösung. Schließlich kann er sehr spezifisch an die realen Anforderungen angepasst werden.
Zusätzlich ist eine schnelle Reaktion auf Veränderungen in der Nutzung möglich. Prinzipiell kann auf jeden Peak, der gemessen wird, im Bereich von Millisekunden reagiert werden. In der Praxis vollzieht sich das natülich meist im Bereich von Sekunden bis Minuten. Schließlich soll ein “Überschwingen” verhindert werden … denn auch das up- und down-scaling benötigt Ressourcen und erzeugt zusätzlichen Stress in der Anwendung.
Innerhalb des gesamten Clusters einer Cloud-Anwendung ist auf diese Art und Weise eine gleichmäßige Verteilung der Last über vorhandenen Ressourcen möglich, die natürlich viel besser ausgenutzt werden können. Ein richtiger Schritt auf dem praktischen Weg zur green IT.
Nicht zuletzt ist so eine weitgehende Automatisierung der Skalierung und ein umfassendes Monitoring dieser einfacher realisierbar.
Automatisierte Anpassung der Ressourcen an den Bedarf
Das Skalieren einer Anwendung kann mit einem erheblichen personellen Aufwand verbunden zu sein. Diesen gilt es natürlich aus betriebswirtschaftlichen Gründen zu vermeiden, da die personellen Ressourcen Budgets binden, die für andere Aufgaben sinnvoller eingesetzt werden können. Außerdem werden auf diese Weise vielfältige, zusätzliche Abhängigkeiten geschaffen und der organisatorische Aufwand steigt.
Ein automatisches Skalieren ist eine gute Möglichkeit, um nicht nur den Ressourcen- und Energiebedarf einer Anwendung immer den praktischen Anforderungen anzupassen, sondern auch den Personaleinsatz zu optimieren … ganz zu schweigen von der verbesserten User-Experience einer in jeder Situation reibungslos laufenden Anwendung. Es lohnt sich also, das Thema autoscaling und entsprechende Möglichkeiten in einem eigenen Artikel zu betrachten.
sense.AI.tion hat die Erfahrungen
sense.AI.tion hat vielfältige, praktische Erfahrungen mit dem Entwurf und Aufbau von skalierbaren Microservice Systemen in der Cloud gesammelt. Wir können bei Entwurf, Aufbau und Betrieb einer solchen Anwendung helfen … und das onshore … vom Rande Berlins … nah und kompetent. Wir geben unsere Erfahrungen gern weiter.