Microservice-Architektur
Während in der klassischen objektorientierten Softwaretechnik das Konzept der Wiederverwendbarkeit bereits lange umgesetzt und verfolgt wird, wurde es in der Praxis meist durch Software-Bibliotheken umgesetzt, welche dann in neuen Projekten und Komponenten wieder inkludiert werden. Eine Microservice-Architektur erweitert dieses Konzept dadurch, das jede abgrenzbare Aufgabe, die in einer Software ermittelt wird, als eigener Dienst implementiert und auch betrieben wird. Dieser Dienst kann dann von anderen Teilen der verteilten Software über standardisierte, sprachunabhängige Schnittstellen aufgerufen werden. Ein Beispiel wäre ein e-Mail Dienst, welcher über ein einfaches HTTP Interface aufgerufen werden kann und dann e-Mails in einem bestimmten Format und lokalisiert an die Zieladressen sendet. Alle anderen Dienste und Komponenten einer Software müssten sich mit dem Thema Mailversand auf technischer Ebene nicht mehr befassen.
Die Vorzüge dieser Architektur beginnen bereits bei der Entwicklung. Einzelne Teams können an einzelnen Diensten arbeiten, ohne die gesamte Software im Detail zu kennen. Das Problem wird in einem „Teile und herrsche“-Ansatz gelöst. Die Teams können sich sowohl um Entwicklung als auch um die Installation, Dokumentation und möglicherweise auch um den Betrieb der einzelnen Services kümmern. Die Architektur lässt sich hervorragend mit dem Vorgehen der agilen Entwicklung kombinieren. Weitere wesentliche Vorzüge der Microservice-Architektur sind:
- Durch den geringen Umfang der einzelnen Dienste bleiben Diese übersichtlich und gut verständlich. Sie sind somit gut erweiterbar. Alternativ können einzelne Dienste ersetzt werden, ohne die gesamte verteilte Anwendung zu beeinträchtigen.
- Eine Microservice-Architektur ist gut skalierbar, was eine Voraussetzung für den effizienten Cloud-Betrieb ist. Stark beanspruchte Komponenten können im Gesamtsystem redundant vorgesehen werden und durch Loadbalancer die Last effektiv verteilt werden. Im Gegensatz zum monolithischen Ansatz muss bei hoher Last nicht das gesamte System redundant ausgelegt werden, was Hardware-Ressourcen einspart.
- Die einzelnen Komponenten bleiben unabhängig voneinander und lose gekoppelt, da sie über standardisierte Schnittstellen untereinander kommunizieren.
- Das Gesamtsystem kann leichter gegen den Ausfall einzelner Komponenten abgesichert werden.
Eine Lösung für jedes Problem stellt die Microservice-Architektur allerdings nicht dar. Durch die Verteilung der Dienste entsteht eine deutlich höhere Komplexität des Gesamtsystems. Auch stellen sich bei der Entwicklung einige Aufgaben als anspruchsvoller heraus als bei der Entwicklung eines monolithischen Systems und verursachen Mehraufwände. Die wesentlichen Punkte, die hier beachtet werden sollten, sind:
- Auch wenn das Gesamtsystem gut gegen einen Ausfall abgesichert werden kann, so ist die Wahrscheinlichkeit, dass einzelne Komponenten ausfallen höher als bei einer monolithischen Architektur. Es muss dafür Sorge getragen werden, dass keine einzelne Komponente so systemkritisch wird, dass sie einen „single Point of Failure“ darstellt. Für Ausfälle einzelner Komponenten müssen Konzepte erarbeitet werden, wie das Gesamtsystem darauf zu reagieren hat.
- Das Testen der Komponenten wird schwieriger und aufwändiger. Die Teams können zwar ihre eigene Komponente sehr gut automatisierten Tests unterziehen, das integrative Testen des Zusammenspiels der Komponenten müssen aber Teams untereinander abstimmen und koordinieren.
- Um die Netzwerklast zu reduzieren, kann es sein, dass Redundanzen im Datenmodell nötig werden. Beispielsweise kann es nötig sein, Stammdaten in mehreren Diensten zwischenzuspeichern. Das kann zu Inkonsistenzen führen und Bedarf eines genauen softwaretechnischen Designs.
- Logging und Monitoring wird anspruchsvoller, da die Logs aller Dienste gesammelt und aufbereitet zur Verfügung gestellt werden müssen.
Ab eines gewissen Systemumfangs lohnt sich der Einsatz von Microservices aber definitiv, da die Vorteile die Nachteile mehr als aufwiegen. Gerne erwägen wir mit Ihnen zusammen, ob eine Microservice-Architektur für Ihr Projekt in Frage kommt oder besser ein monolithischer Ansatz gewählt werden sollte.
Zur Umsetzung von Microservices setzen wir die Programmiersprache Java und das Spring Boot Framework in der Version 2 ein. Neben der hervorragenden Eignung für die Programmierung von Microservices unterstützt es nahezu jede Aufgabe mit seinem modularen Aufbau. Weiterhin ist es als Open Source Software kostenfrei.
Monolithische Systeme
Im Gegensatz zur Microservices-Architektur setzt das monolithische System darauf, für eine Softwarelösung nur ein Artefakt zu implementieren und zu installieren. Die gesamte Anwendung wird in einem einzigen Programm geschrieben, was zwar ebenfalls modular aufgebaut sein kann, aber dann vollständig als eine Datei auf einem einzigen Server (pro Instanz des Programms) betrieben wird. Auch wenn das Konzept von Microservices für viele Softwarelösungen das bessere ist, gibt es Fälle in denen die Verwendung eines monolithischen Ansatzes durchaus das bessere Mittel der Wahl ist. Wenn der Zweck und Umfang der Software überschaubar ist und Microservices im Betrieb und bei den Anforderungen an die Infrastruktur des Unternehmens unverhältnismäßig aufwändig sind, sollte ein Monolith zumindest in Betracht gezogen werden. Auch bei dieser Lösung gilt es, sich der Vor- und Nachteile bewusst zu sein. so bietet der Monolith die folgenden Vorteile:
- Es wird nur ein Server für die gesamte Anwendung benötigt. Das erleichtert den Betrieb, das Logging und das Monitoring.
- Es wird weniger Netzlast verursacht. Die meisten Aufrufe innerhalb der Anwendungsmodule sind lokaler Natur.
- Es gibt ein klares, normalisiertes Datenmodell innerhalb der kompletten Anwendung.
- Fehlerbehandlung ist überschaubarer und einfacher zu implementieren.
Die Popularität von Microservices ist natürlich nicht unbegründet. Eine monolithische Architektur hat auch gravierende Nachteile gegenüber der Microservices-Architektur, welche Aufwand und hohe technische Schulden verursachen können. Die wichtigsten Nachteile sind:
- Eine individuelle Skalierung der Anwendung ist schwierig und ineffizient. Es kann nur die gesamte Anwendung mit Load-Balancern oder Clustering hochverfügbar gemacht werden und nicht einzelne Komponenten. Dies kann dann unnötige Hardware-Ressourcen erfordern.
- Es passiert schnell, dass selbst bei einem modularen Aufbau der Software die Komponenten untereinander zu eng gekoppelt werden und eine Entflechtung später aufwändig und nicht mehr ohne Weiteres möglich ist.
- Die Software wird schnell unübersichtlich wenn die immer wieder erweitert wird. Irgendwann ist sie dann vielleicht so umfangreich und unübersichtlich, das selbst die Entwickler sie nicht mehr verstehen.
- Einzelne Komponenten können nicht aktualisiert werden, ohne die gesamte Software zu aktualisieren, inklusive entsprechender Einbußen bei der Verfügbarkeit.
- Keine klar abzugrenzende Zuständigkeit von Entwicklerteams für einzelne Teile der Software, sobald die Koppelung der Komponenten zu eng wird.
- Stärkere Bindung an Technologien, da immer nur die ganze Software im „Bing Bang“ von einer Technologie zu einer anderen migriert werden kann.
Technologisch bevorzugen wir für die Implementierung solcher monolithischen Systeme ebenfalls das Spring Boot Framework in der Version 2, da man mit dieser Technologie auch problemlos einen Monolithen entwickeln kann. Alternativ bieten sich für solche Systeme auch J2EE-Applikationsserver an, wie beispielsweise die Wildfly-Plattform.
Content Management Systeme
Moderne Webpräsenzen haben den Anspruch, dass sie einfach und ohne viele technische Kenntnisse von Betreibern auf dem Laufenden gehalten werden können. Dies ist besonders für Unternehmen und Gewerbetreibende wichtig, welche mit Hilfe ihrer Webseite Kunden akquirieren oder Dienste anbieten. Die Erstellung einer Seite sollte aus technischer Sicht nicht viel Aufwand erzeugen, so dass beispielsweise auch ein Start-Up sich mit wenig finanziellen Aufwand eine informative Webpräsenz zulegen kann. Natürlich ist der Aufwand schlussendlich davon abhängig, was genau Sie für Ihre Seite planen. Eine einfache, statische Seite ist deutlich schneller zu erstellen als eine Seite mit vielen dynamischen Inhalten und Interaktionsmöglichkeiten.
Für die Erstellung von modernen Webseiten verwenden wir wahlweise die Content-Management-Systeme WordPress und Typo3. Mit beiden Systemen konnten wir in den vergangenen Jahren viele positive Erfahrungen sammeln. Die Inhalte werden in einer Weise angezeigt, dass es egal ist auf welchem Gerät die Seite aufgerufen wird. Auch auf einem Mobilgerät oder Tablet wird die Seite so aussehen, wie Sie als Kunde es sich wünschen. Je nach Art der Seite, welche Sie erstellen möchten, geben wir Ihnen gerne eine Beratung, welches System für das was Sie vorhaben besser geeignet ist.
Individuelle Frontends
Eine Unternehmensanwendung benötigt neben den technischen Anforderungen, Systemarchitekturen und Schnittstellen auch ein ansprechendes grafische Oberfläche. Diese Benutzerschnittstelle ist das, was die Anwender, welche mit dem Programm arbeiten, zu sehen bekommen. Die Akzeptanz der neuen Software durch ihre Benutzer hängt zu einem großen Teil von ihrer Benutzerschnittstelle ab. Planung und Entwurf für diese muss mit dem selben Anspruch geschehen, wie die Planung der übrigen Anwendung.
Für die Entwicklung von Benutzeroberflächen im Browser präferieren wir den Einsatz des Angular Frameworks. Als Open-Source Lösung ist auch diese Technologie kostenfrei. Egal ob es sich um Microservices handelt, für welche die GUI entwickelt werden soll, oder um einen Monolithen, das Angular Framework ist hochflexibel und bietet auch bei der Installation absolute Freiheit an. Es kann zum Beispiel mit einem Spring Boot Microservice zusammen auf einem Server betrieben werden, in einem einzigen Artefakt, als auch getrennt in einem Webserver laufen und die Backend-Systeme via RESTful Services aufrufen. Dabei ist es modular aufgebaut und es können über Programm-Bibliotheken viele bereits von der umfangreichen Community entwickelte Features verwendet werden.
Mobile Apps
Anwendungen, welche auf Mobilgeräten oder Tablets installiert und ausgeführt werden, sind einer der wichtigsten Teile der Digitalisierung. Da inzwischen jeder ein Smartphone besitzt, kann jeder mit Hilfe solcher mobilen Anwendungen am digitalen Leben teilnehmen. Welche Hardware von einem Benutzer verwendet wird, sollte mehr und mehr in den Hintergrund treten – gute Apps sollte es sowohl in einer Version für Smartphones von Apple geben, als auch in einer Version für das Android Betriebssystem.
Natürlich bedeutet es unverhältnismäßig viel Aufwand, wenn die gleiche Anwendung mehrmals entwickelt werden muss, damit sie ihren Zweck erfüllt und auf allen Geräten läuft, welche im Umlauf sind. Deswegen setzen wir auf eine Plattform-unabhängige Entwicklung. Die Anwendung wird nur einmal entwickelt und läuft dann auf unabhängig vom verwendeten Mobilgerät.
Um diese Anforderung zu erfüllen, nutzen wir unter anderem das Ionic Framework und das Flutter Framework von Google.
Agile Entwicklung
Für den Erfolg eines Projektes ist ein gutes Vorgehensmodell auch für das Projektmanagement unabdinglich. Eine genaue Planung der Software und des Implementierungsprozesses vor Projektstart ist aber gerade bei größeren Projekten eine echte Herausforderung. Wenn sich in eine komplette Planung eine Fehleinschätzung einreiht, so ist die gesamte Planung schnell überholungsbedürftig. Auch stellt es sich als schwierig dar, Kriterien und Kennzahlen, welche erst im Projektverlauf bekannt werden, für die Zukunft zu nutzen. Ein Beispiel hierfür ist die Arbeitsgeschwindigkeit des Entwicklerteams, welche vor Start der Implementierung in der Regel nicht bekannt ist.
Eine Lösung hierfür bietet das agile Vorgehensmodell. Hierbei wird die Entwurfsphase vor Implementierungsbeginn möglichst kurz gehalten und versucht so früh wie möglich zu ausführbarer Software zu gelangen. Diese wird dann in iterativer Weise immer wieder in enger Abstimmung mit dem Auftraggeber erweitert. Anforderungen können sich während der Entwicklung ändern und es kann schnell darauf reagiert werden. Die Geschwindigkeit der Entwicklerteams wird in jeder Iteration gemessen und bei zukünftiger Planung berücksichtigt. Den Teams wird ein hohes Maß an Selbstorganisation zugestanden und auferlegt. Gerade für die Entwicklung einer Microservices-Architektur ist das agile Modell mit seiner hohen Teamverantwortung sehr gut geeignet.
Wir haben bei der Entwicklung von Software sehr gute Erfahrungen mit der agilen Entwicklung gemacht. Dabei wurde in den agilen Projekten meistens Scrum verwendet, welches den agilen Ansatz konkretisiert. Neben den Projektrollen wird definiert, wie die einzelnen Teammitglieder zusammen ihr weiteres Vorgehen abstimmen und beschließen sollen. Scrum setzt auf gute und häufige Kommunikation zwischen Teams und Auftraggebern, sowie der Kommunikation im Team selbst. So werden Richtlinien vorgegeben, wie oft innerhalb der Teams und teamübergreifend kommuniziert werden sollte. Das konkrete Vorgehen aber beschließen die Teammitglieder und Auftraggeber gemeinsam im Dialog.