Beiträge

Microservices, Service Registry „Die Zentrale“

Im Rahmen unseres IT Projektes “Microservices” und der damit verbundenen Blog Serie möchte ich in diesem Beitrag über unserer Erfahrungen mit den „Platform Services“, welche ein zentraler Baustein in der Microservices Architektur sind, berichten. Es sind zusätzliche Dienste welche den Betrieb von zahlreichen Anwendungsservices vereinfachen. Dazu gehören unter anderem

Alle diese Dienste ermöglichen es eine große Anzahl an Microservices zu betreiben und nutzbar zu machen. Diese Auflistung sieht auf den ersten Blick nach sehr viel Aufwand und technischer Infrastruktur aus und beinhaltet Begrifflichkeiten, welche tiefgehendes, technisches Wissen erfordern um die Bedeutung und Notwendigkeit verstehen zu können. Aus diesem Grund möchte ich in den kommenden drei Beiträgen etwas Licht ins Dunkle bringen und versuchen den Mehrwert dieser technischen Services zu erläutern. Beginnen möchte ich mit der Service Registry, weil diese aus meiner Sicht die grundlegendste Komponente ist auf welcher viele der anderen Services aufsetzen.

 

Die Services Registry stellt in gewisser Weise eine Art Telefonzentrale dar , die Clientanwendung, wie zum Beispiel ein Content Management System oder aber eine andere beliebige Webanwendung, anrufen können um nach einem Dienst zufragen, welcher gerade benötigt wird. Tatsächlich fragt die aufrufende Anwendung mit einem Namen wie zum Beispiel: “Suche” oder “Dokumentenmanagement” die Service Registry und erhält die Information wie dieser Service zu erreichen ist. Die Information beinhaltet eine vollständige URL und kann als Einstiegspunkt zur Verwendung des Service benutzt werden.

 

Die einfachere und klassische Variante ohne die Verwendung einer Service Registry ist, dass die Client Anwendung die URL auf den Einstiegspunkt selber gespeichert hat. Allerdings gibt es bei dieser klassischen Variante einige Nachteile:

 

  • Die URL ist statisch in der Clientanwendung gepflegt und muss bei Veränderungen der URL mit geändert werden. Zieht der zu nutzende Service auf einen anderen Server um oder ändert sich der TCP/IP Port, muss die Clientanwendung in der Regel mit angepasst werden.
  • Es ist keine Verwendung von clientseitigem Load Balancing möglich. Das bedeutet, selbst wenn der Service auf mehreren Servern eingerichtet ist, kann der Client diese nicht dynamisch nutzen.
  • Es gibt oft keine Echtzeit Übersicht über den aktuellen Stand der zur Verfügung stehenden Services. Es besteht natürlich die Möglichkeit, ein sehr gutes Monitoring einzurichten, was diese Fähigkeit besitzt. Allerdings sind die klassischen Monitoring Lösungen wie zum Beispiel Nagios dafür nicht konzipiert und vorgesehen. In den meisten Fällen sind diese auch so nicht eingerichtet.

 

Diese aufgeführten Nachteile der herkömmlichen Verknüpfung von Clientanwendung und Anwendungsdienst (Service)  zeigen im Umkehrschluss natürlich auch die Vorteile einer Service Registry:

 

  • Zentrale Übersicht aller Service und deren Status
  • Möglichkeit eines Load balancing
  • Keine clientseitige Anpassung bei Service und Infrastruktur Änderungen

 

Aber rechtfertigen diese Vorteile den Aufwand und den Betrieb einer Service Registry? Der Aufwand der Installation einer Service Registry ist sehr gering, da es bereits sehr gute und ausgereifte Produkte gibt:

 

 

Die beiden erst genannten Produkte sind diejenigen mit der höchsten Verbreitung und damit auch die ausgereiftesten. In unserem Projekt haben wir hauptsächlich auf den Netflix OSS gesetzt und daher auf Eureka. Auch wir haben in unserem Pilotprojekt sehr gute Erfahrungen mit Eureka gemacht. Wichtig bei der Verwendung ist, dass die Service Registry nicht wiederum selbst zum Single Point of Failure wird und daher immer mehrfach betrieben werden sollte. Aber auch dieser Aspekt ist mit sehr geringem Aufwand umzusetzen. Ich empfehle für den Einstieg daher ein Spring Boot Projekt mit aktivierter Service Registry, welches im Beispiel Microservices Projekt von Eberhardt Wolff zur Verfügung steht. Sie werden erstaunt sein, mit wie wenig Quellcode die Service Registry umgesetzt ist.

Der Quellcode…

@SpringBootApplication
@EnableEurekaServer
@EnableDiscoveryClient
public class ServiceRegistryApplication {

public static void main(String[] args) {
SpringApplication.run(ServiceRegistryApplication.class, args);
}
}

 

Fazit:

Aus meiner persönlichen Sicht ist der Einsatz einer Service Registry auch ohne die Verwendung der gesamten Microservices Architektur von unschätzbarem Vorteil, sobald mehrere zentrale Services im Hause betrieben werden. Alleine die Tatsache, dass nicht mehr mit jeder Infrastruktur Anpassung die Client Anwendung und die Dokumentation bzw. das Monitoring angepasst werden müssen, sind im Dauerbetrieb mit geringem Personaleinsatz von unschätzbarem Wert. Hinzu kommt, dass wir in unserem Beispiel Projekt sowohl die Anbindung von Java Webanwendungen als auch von reinen HTML / Javascript Anwendungen relativ einfach umsetzen konnten. Wir konnten aus dem weit verbreiteten CMS Typo3 sehr leicht die Service Registry nach einem Service anfragen und diesen anschließend nutzen. Integriert man diese Anfrage Logik zum Beispiel in eine Typo3 Extension und macht diese so nachnutzbar für andere Typo3-Projekte, wird der Aufwand auf alle Projekte betrachtet noch geringer und der Nutzen somit noch größer. Zusätzlich bietet eine Service Registry als Basis der Platform Services weitere Möglichkeiten, welche ebenfalls von unschätzbarem Wert, um stabilen Betrieb von zentralen Services sind.

 

Diese Möglichkeiten werde ich in den kommenden Beiträgen detailliert aufführen und zeigen, wie man zum Beispiel ein bestehendes Fremdsystem, wie zum Beispiel Fedora Content Repository oder Pazpar2-Suche, in eine solche Service-Struktur einfach einbindet, ohne die Produkte selbst anpassen zu müssen.

Ich freue mich daher auf die kommenden Beiträge und hoffe auf zahlreiche Kommentare.

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.