Microservice-Projektblog: Eierlegende Wollmilchsau
In der Abteilung Informations- und Datenmanagement der Staatsbibliothek zu Berlin (IDM) wird derzeit evaluiert, inwieweit das Architekturmuster„Microservices“ als Grundlage zukünftiger Eigenentwicklungen hilfreich sein können. In einer Reihe von Blogbeiträgen geben wir im Sinne eines Werkstattberichtes einen Einblick in das Projekt und unsere Erfahrungen mit der Umsetzung.
Der Auslöser unserer Neugier auf die relativ neue Technologie war die konkrete Aufgabe, dass ein Altsystem im Bereich der Nachweissysteme (Gesamtkatalog der Wiegendrucke) technisch modernisiert werden sollte. Soweit kein ungewöhnlicher Fall: in gewohnter Arbeitsweise wurde ein Team aus Entwicklern und einem fachliche Experten zusammengestellt. Eine Kleinigkeit war allerdings diesmal anders. Es gab neben den fachlichen Anforderungen – die Modernisierung des Nachweissystems zum Gesamtkatalog der Wiegendrucke – auch folgende nicht funktionalen Anforderungen:
- Leichte Erweiterbarkeit des Systems
- Testbarkeit
- Hoher Grad an Wiederverwendungsmöglichkeiten
- Skalierbarkeit
Mein erster Gedanke war: aha wir sollen also die „eierlegende Wollmilchsau“ entwickeln.
Der offensichtliche Grund für diese neuen Anforderungen war, dass in den letzten Jahren an der Staatsbibliothek im Rahmen von Projekten zwar funktional sehr gute Softwaresysteme entstanden sind, diese allerdings nicht in jedem Fall optimal betrieben, gewartet und nachgenutzt werden konnten. Zudem wiederholten sich zunehmend ähnliche fachliche Anforderungen nach Suche in Metadaten, Authentifizierung, Erfassung und Verwaltung der Metadaten sowie Präsentation der Metadaten. Diese nicht funktionalen Anforderungen führten zur Suche nach neuen Architekturansätzen für Enterprise Software. Microservices versprechen auf den ersten Blick viele der Anforderungen zu erfüllen, nun sind aber die bekannten Fragen zu klären:
- Wie definieren sich Microservices?
- Wann sollte die Microservices Architektur verwendet werden?
- Wie entwickle ich konkret Microservices?
- Wie betreibe ich Microservices?
- Erreiche ich mit Microservices die nicht funktionalen Anforderungen besser?
Alle diese Fragen waren auch nach der Lektüre etlicher Fachaufsätze und Publikationen für uns nicht eindeutig genug zu beantworten. Im Großen und Ganzen liegt es an der Komplexität und Umfang der Gesamtarchitektur der IT Systeme der Staatsbibliothek und dem auch aus Informatikersicht anspruchsvollen Thema Microservices. Es gibt bei der Staatsbibliothek nicht den klassischen Fall eines bestehenden, monolithischen Systems welches mit der Microservice Architektur ersetzt oder ergänzt werden soll. Es gibt auch nicht die *eine* Webpräsentation, auf welche alle Usecases und Fachlichkeiten dargestellt und realisiert werden. Anstelle dessen gibt es sehr viele heterogene Anwendungssysteme auf einer gemeinsamen Infrastruktur.
Um nun genau zu evaluieren, ob und in welchem Umfang Microservices einige Dinge innerhalb der IT Landschaft der Staatsbibliothek verbessern können, und diese wirklich als ganzheitliches Integrationskonzept gesehen werden kann, sollen diese Fragestellungen nun in einem eigenständigen Projekt geklärt werden.
Im Rahmen dieses Projektes werden ich und meine Kollegen dieses Blog regelmäßig mit Informationen zum Thema Microservices und unseren Erfahrungen dazu ergänzen. Unsere Ziele sind:
- Einen noch höheren Grad der fachlichen Nachnutzung einzelner Services
- Eine einheitliche Integrationsstrategie
- Eine Infrastrukturplattform die Microservices bzw. die fachlichen Anwendungen ausfallsicherer, höher verfügbar, skalierbarer und flexibler macht
- Schnellere Realisierung von fachlichen Anforderungen
Ein guter Einstieg in das Thema Microservices ist dieser Beitrag von Martin Fowler. Hier werden die grundlegenden Fragestellungen erörtert sowie auf viele weitere Informationsquellen verwiesen.
Ebenfalls empfehle ich das Buch zum Thema Microservices mit dem Titel „Microservices: Grundlagen der flexiblen Softwarearchitektur“ von Eberhard Wolff.
Natürlich freuen wir uns auf Kommentare, sollten Sie in Ihren Einrichtungen bereits Erfahrungen mit Konzeption und dem Einsatz von Microservices gesammelt haben.
bpk /Fritz Eschen
Osteuropa-Abteilung der Staatsbibliothek zu Berlin, Lizenz CC BY-SA-NB
SBB-PK CC BY-NC-SA 3.0
Eine Microservices-Architektur verlangt viel Disziplin und Kenntnis im Bereich Entwicklung, Entwurf und Betrieb, und hat bei den meisten kleineren Projekten erst einmal Nachteile: hoehere Latenz; Aufwand fuer Monitoring, Orchestration, Discovery; jedes Refactoring von Schnittstellen ist teuer, Feedbackschleifen fuer Entwickler werden laenger, teilweise unausgereifte Werkzeuge. Die Vorteile kommen zum tragen, wenn man mit einer grossen Zahl von Teams arbeiten muss oder die Skalierbarkeit und Verfuegbarkeit auf „web-scale“ noetig ist.
Bei den meisten Bibliothekssystemen, so sehr wir uns das auch wuenschen wuerden, sind diese Bedingungen nicht gegeben. Es ist meistens richtig mit sauber strukturierten Monolithen zu beginnen, und Wiederverwendung durch Softwarebibliotheken zu realisieren. Dann kann man sich der Werkzeuge von automatischen Tests, Continous Integration und vielleicht Continous Delivery bedienen, um die Test- und Wartbarkeit zu erhoehen. Ob bare metal, cloud, container, VM: die Platform fuers deployment ergibt sich wahrscheinlich aus den Gegebenheiten der Organistation: Und als es dann wirklich noetig ist, ist eine „echte“ Microservices Architektur eine logische Fortentwicklung auf Basis von einem gut designten Fundament.
Hallo Herr Wiermer,
Vielen Dank für Ihren sehr interessanten und fundierten Kommentar. Gerne würden ich mit Ihnen in einen Erfahrungsaustausch in Sachen Microservices in der Bibliothek treten. Noch bin ich voller Microservices Euphorie und der Überzeugung, dass nach dem Überwinden der Aufwände im Aufbau der Plattform Service (Service Registry, Routing, Deployment,…) die Integration und Weiterentwicklung von fachlichen Anforderungen sich schneller und mit einer höheren Qualität realisieren lassen. Zum Start unseres Projektes werden wir stark auf den Netflix OSS und Spring Boot setzen um auch die Entwicklungsaufwände so gering wie möglich zu halten. Dennoch teile ich Ihre Ansicht, dass die Anwendung von Microservices als Architektur für jedes Projekt einzeln gut abgewägt werden muss.
Danke jedenfalls fuer ihre Bereitschaft, ihre Erfahrungen zu teilen. Wir (Nationalbibliothek der Niederlande) ueberarbeiten auch gerade unsere klassische Servicearchitektur und suchen auch noch nach dem richtigen Weg. Als Community koennen wir alle noch deutlich besser werden im Bereich der modernen Softwaremethoden, und da ist jedweder Tatendrang richtig.