iteratec Blog

microzoo - Experimentier-Kasten für Microservice-Architekturen

Geschrieben von Dr. Peter Kullmann | 14.12.2021 23:00:00

Beim Entwurf einer Microservice-Architektur für eine konkrete Anwendung müssen viele Entscheidungen getroffen werden, z.B. bezüglich der Service-Struktur, des eingesetzten Technologie-Stack und der Betriebsumgebung. Mit microzoo können Architekt*innen schnell und einfach verschiedene Microservice-Architekturen und Technologie-Stacks testen, vergleichen und bewerten.

Altbewährtes aus Angst vor Fehlern?

Geht es in einem Softwareprojekt um die Auswahl eines Technologie-Stacks, setzen IT-Architekt*innen oft auf Altbewährtes. Um ein Projekt mit möglichst geringem Risiko zum Erfolg zu führen, zählen nicht nur die reinen technischen Anforderungen – auch die verfügbaren Skills im Entwicklungsteam, sowie die Reife und verfügbare Dokumentation der verwendeten Komponenten sind gewichtige Faktoren. Manchmal fehlt auch schlichtweg die Zeit, um sich mit neuen Entwicklungen auseinanderzusetzen, geschweige denn das Risiko eingehen zu können, einen neuen, bisher unbekannten Technologie-Stack einzusetzen.

Risikoreduzierung durch Baukastensystem

Dabei gibt es in den letzten Jahren zahlreiche, vielversprechende Entwicklungen in den Bereichen der Programmiersprachen, Applikations-Frameworks und Betriebsumgebungen, die verschiedene Vorteile im Vergleich zu älteren Technologien bieten. microzoo tritt an, als eine Art Baukastensystem, das Architekt*innen und Entwickler*innen die Möglichkeit gibt, sich möglichst schnell und einfach mit verschiedenen Technologie-Stacks vertraut zu machen, diese zu vergleichen und zu bewerten. Damit reduziert sich das Risiko und sinkt die Hemmschwelle, auf einen neuen Technologie-Stack umzusteigen. microzoo unterstützt bei folgenden Fragestellungen:

  • Technologieauswahl
    • Welche Eigenschaften hat ein bestimmter Technologie-Stack?
    • Wie verhalten sich verschiedene Technologie-Stacks im direkten Vergleich?
  •  Architekturentwurf
    • Welche Eigenschaften hat eine bestimmte Gesamtarchitektur?
    • Wie wirkt sich das Verhalten einzelner Komponenten auf das Gesamtsystem aus?
  • Konfiguration der Betriebsumgebung
    • Wie muss die Umgebung dimensioniert sein?
    • Wie verhält sich eine Anwendung in einer gegebenen Umgebung?
    • Welche Kosten entstehen für den Betrieb?

microzoo eignet sich nicht nur als Werkzeug beim Systementwurf, sondern ist auch bestens als Lern- und Lehrwerkzeug geeignet.

Aufbau von microzoo

microzoo besteht aus einer Sammlung vorgefertigter, konfigurierbarer Komponenten, die typischerweise in einer Microservice-Architektur verwendet werden. Diese Komponenten sind in Kategorien unterteilt. Derzeit unterstützt microzoo die Kategorien Services und Datenbanken. Service-Komponenten implementieren definierte Schnittstellen und sind mit verschiedenen Technologien realisiert. Diese können individuell zu einer Architektur entsprechend einem Anwendungsszenario zusammengestellt und konfiguriert werden. Komponenten innerhalb einer Kategorie sind untereinander austauschbar, so dass unterschiedliche Kombinationen erprobt und verglichen werden können. Das Komponentensystem vom microzoo ist erweiterbar und es ist geplant, den Katalog kontinuierlich zu erweitern. Die Lösung arbeitet container-basiert, d.h. alle Komponenten liegen als Container vor, die dann in einer Container-Plattform wie Docker oder Kubernetes deployed werden können.

Hohe Zugänglichkeit durch Visualisierung

Für die Modellierung von Architekturen wurde bewusst auf hohe Zugänglichkeit gesetzt und ein grafisch unterstütztes Format als Basis für die Systemspezifikation gewählt. Da Architekturen typischerweise in UML- oder UML-ähnlicher Notation visualisiert werden, hat sich das Modellierungswerkzeug PlantUML angeboten, das zudem durch gängige IDEs gut unterstützt wird. PlantUML-Diagramme werden in Textform angelegt und von der der PlantUML-Software zu Grafiken mit weitgehend automatischem Layout verarbeitet.

Aus der textuellen PlantUML-Beschreibung erzeugt die microzoo-Engine, die über ein Command-Line-Interface gesteuert wird, ein Setup für eine Zielumgebungen wie z.B. Docker oder Kubernetes. Ebenfalls mit dem Command-Line-Interface kann ein solches Setup deployed und wieder abgebaut werden. Ist eine Architektur in einer Zielumgebung deployed, kann das System beispielsweise einem Lasttest unterzogen und mit einer Monitoringlösung beobachtet und analysiert werden.

Der Start einer microzoo-Architektur erfolgt dabei mit einem Befehl:

bin/microzoo deploy my-architecture

Dadurch wird die Spezifikation geparst, geprüft, übersetzt und in das Zielsystem deployed.

Derzeit verfügt microzoo noch über wenige Komponenten – einen Spring-Boot-Service und vier Datenbanksysteme. Durch den modularen Aufbau ist es leicht erweiterbar. Um neue Komponenten einzubinden, muss im Wesentlichen eine Manifest-Datei eingebunden werden. Diese beschreibt die Eigenschaften und unterstütze Schnittstellen einer Komponente. Das Manifest wird von der microzoo-Engine verwendet, um die Konfiguration für die Zielumgebungen zu erzeugen.

Die Spezifikation einer Architektur beschreibt nicht nur den Aufbau und die Kommunikationsstruktur, sie erlaubt auch die Eigenschaften eines Systems zu modellieren, indem die Größe von Datenobjekten und das zeitliche Verhalten einzelner Komponenten konfiguriert wird. Damit können gezielt realitätsnahe Bedingungen untersucht werden.

In Zukunft soll microzoo um weitere Komponenten-Kategorien erweitert werden, die typischerweise in Microservice-Architekturen Verwendung finden. Dies umfasst z.B. Service Meshes und Ingress Controller. Ebenso ist die Erweiterung um weitere Kommunikationsprotokolle wie gRPC und message-basierte Verfahren geplant.

microzoo ist über Github frei verfügbar: https://github.com/iteratec/microzoo 

 

Noch Fragen?

Erfahren Sie mehr darüber, wie Sie mit hochflexiblen und leicht skalierbaren Applikationslandschaften  auf schnell wechselnden Nutzeranforderungen im digitalen Geschäftsumfeld reagieren und kundenzentrierte Services effektiv realisieren können. Unsere Architekturexpert*innen freuen sich auf das Gespräch:

Dr. Peter Kullmann hat an der Universität Karlsruhe Informatik studiert und wurde 2001 promoviert. D ach arbeitete er als selbständiger Software-Entwickler und gründete ein Software-Unternehmen. Seit 2014 war er als Architekt bei der iteratec GmbH tätig und hat zahlreiche Software-Projekte in verschiedenen Branchen durchgeführt und begleitet. Wir schätzen seine Beitrag und informieren, dass er nicht mehr bei iteratec tätig ist.