Der zwanzigste Tag
des Februar liegt hinter uns
sense.ai.tion – aktueller Status
Im vergangenen Monat hat sich die Architektur des Systems leicht verändert. Es sind nun mehr Service-Module in der ersten Version des Systems enthalten, als ursprünglich geplant. Während der Arbeit mussten wir leider erkennen, dass eine Microservices Architektur eine fatale Eigenschaft besitzt: Die Service-Module vermehren sich inflationär!
Größe und Ressourcenbedarf der erzeugten Microservices sind mehr als zufriedenstellend. Die Container sind jeweils nur wenig größer als 20Mbyte.
Das Prinzipbild der Architektur visualisiert neben dem Aufbau auch den Grad der Fertigstellung. Wir nähern uns mit großen Schritten der Freigabe des Minimum Viable Product an die ersten Anwender.
Blau im grauen Bereich – “fremde” Software, die in unser System eingebunden ist
So wie jedes Schema vereinfacht, bildet auch die Farbverteilung nur einen Teil der Wahrheit ab. Die Module des Frameworks (wiederverwendbare Software-Bestandteile, auf denen jeder der einzelnen Microservices/Service-Module aufbaut) sind darin nicht zu sehen. Diese entstanden in vielen Experimenten und unter unzähligen Planungsanpassungen von November bis Januar. Auf ihrer Basis lassen sich nun die Service-Module sehr schnell umsetzen – durchdachte Vorarbeiten zahlen sich immer aus.
Neben den ursprünglich geplanten Arbeiten sind bereits weitere begonnen und in Teilen abgeschlossen worden, die nicht direkt zum Cloud System gehören und deshalb ebenfalls nicht auf dem Bild erscheinen. Diese Arbeitszeit müssen wir in den kommenden Monaten nicht mehr aufwenden. Dazu mehr in den nachfolgenden Abschnitten.
“finales” Systemdesign
Das ist ein Nachtrag zum Januar – und ja, “final” ist etwas übertrieben: Was ist schon endgültig auf dieser Welt? Auf jeden Fall ist das Design des sense.ai.tion cloud systems für die Arbeiten diesen Jahres und das Minimum Viable Product fixiert. Da wir versuchen, alles was an unseren eigenen Produktionsprozessen automatisierbar ist, auch von Maschinen ausführen zu lassen, sind weitere Software-Bestandteile und Systeme entstanden und “am Laufen”, die nicht direkt zu dem Cloud System gehören.
Entgegen der ursprünglichen Planung lässt sich das System bereits jetzt bei verschiedenen Cloud-Plattform-Anbietern installieren. Da wir auf “bare metal” Kubernetes setzen, ist das relativ problemlos möglich und die Nutzung des Basis-Standards macht uns unabhängig. Das heißt, wir können unser gesamtes System innerhalb von wenigen Minuten bei jedem Anbieter installieren und starten, der eine managed Kubernetes-Umgebung anbietet oder auch selbst hosten. Damit sichern wir unsere wirtschaftliche Unabhängigkeit und erfüllen eine wesentliche Design-Anforderung an die Architektur des Systems. Dieses besteht – wie das Architekturbild zeigt – aus einer Anzahl kleiner Service-Module (oder Microservices). Das macht das Software-Entwicklerleben nicht leichter, das System jedoch deutlich skalierbarer. Damit erfüllen wir eine zweite Design-Anforderung an die Architektur und wir müssen zukünftig vor einer großen Anzahl an Aufträgen keine Angst haben.
In dem Framework, das in den ersten Monaten entstanden ist, befinden sich Basisfunktionalitäten, die jeder Service-Modul benötigt und “Abstraktoren”, die uns bei der Konsumtion von Infrastrukturleistungen (z.B. Datenbanken, Speicherung von Dateien, Sprache-Text-Wandlung, …) die Unabhängigkeit von einzelnen Anbietern sichern. Neben den grundlegenden Funktionen sichert dieses Framework auch die interne Kommunikation im System ab. Das Thema “in-depth-security” spielt natürlich eine entscheidende Rolle bei der Planung und Umsetzung jeglicher Funktionalität.
Das Basissystem (oder “Minimum Viable Product”) wird die Erzeugung von Gesprächstranskripten als Leistung bieten. Diese wird als reiner WEB-Service und über eine App angeboten, wobei in ersten Anwendungen und Projekte auf jeden Fall die App zur Anwendung kommen wird.
Wie schon geschrieben, haben wir begonnen, unsere Werkbank und Produktionsstrecke zu automatisieren. Die sogenannte Build-Chain arbeitet vollautomatisch nach jeder Änderung an einem Software-Bestandteil. Das heißt, die veränderten Module werden automatisch gebaut, getestet und bei Erfolg produktiv in Betrieb genommen. Durch “rolling updates” gibt es dabei in keiner Funktionalität und für keinen Anwender eine Unterbrechung. Damit erfüllen wir eine weitere, wesentliche Design-Anforderung.
Helm verpackt alles
Der Auf- und Abbau einer Microservices-Anwendung in der Cloud, sowie die Durchführung von Updates sind aufwändig und bindet extrem viel Arbeitszeit. Da sich beinahe täglich ein Service-Modul verändern kann und in einer neuen Version entsteht, stellt dies eine nicht vernachlässigbare wirtschaftliche Belastung für das Unternehmen dar.
Zu unserem Glück gibt es auch andere Leidtragende und inzwischen passende Lösungen: Package-Manager.
Wir haben uns für die Nutzung von “Helm” entschieden. Ja, es gibt in diesem Programm noch Bugs und funktionale Lücken – das Potential ist jedoch gewaltig, die Community groß und die angestrebten Effekte sind sofort positiv spürbar. Dieser Package-Manager gestattet die Konfiguration von kompletten Cloud-Anwendungen zu beschreiben und für unterschiedliche Infrastrukturbedingungen anpassbar zu gestalten…
Um es kurz zu machen: Durch Helm können wir einen Arbeitsablauf, der vorher über eine Stunde konzentrierter Arbeit benötigte, drastisch reduzieren. Wir benötigen praktisch nur noch einen Aufruf eines Kommandos und nach ca. fünf Minuten ist das komplette System installiert und/oder aktualisiert. Natürlich ist Helm nur ein kleiner Teil der aufgeführten Automatisierung unserer Werkbank.
***
Wie immer wünsche ich “sense.ai.tion-al communications”,
Matthias
