Beiträge

Microservices, Integration

Die Microservices Architektur bietet den Vorteil der freien Technologieauswahl bei jedem Microservice. Ein wichtiger Punkt unseres Evaluierungsprojektes war die Prüfung der Integrationsfähigkeit von Softwarekomponenten, welche nicht Java, bzw. Spring Cloud im Technologiestack enthalten. Dazu möchte ich in diesem Beitrag unserer Blogserie zeigen auf welche Art und Weise wir legacy Software, wie zum Beispiel Fedora4 Content Repository in die „Platform Service“ der Microservices Welt integriert haben.

 

Integration

Für die Integration solcher “nicht Java basierten Softwarekomponenten” stellt Netflix Open Source Stack (Netflix OSS) das Projekt Prana bereit. Prana ist eine sogenannte Sidecar Anwendung. Durch die Nutzung von Prana ist es möglich die “Platform Service“, wie zum Beispiel Eureka, Circuit Breaker und Ribbon in solchen Projekten zu verwenden. Wie der Name “Beistellwagen” schon verrät wird das Prana Projekt lediglich neben den nicht Netflix fähigen Microservice gestellt und konfiguriert. Wie genau das funktioniert, möchte ich gerne an folgendem konkreten Beispiel demonstrieren.

 

Dazu haben wir im ersten Schritt ein Spring Boot Projekt aufgesetzt und Spring Cloud Sidecar durch folgende Annotation an der “main” Klasse aktiviert.

 

@EnableSidecar

@SpringBootApplication

public class SideCarApplication {

 

public static void main(String[] args) {

SpringApplication.run(SideCarApplication.class, args);

}

}

 

Anschließend müssen im Sidecar Projekt noch folgende Properties gesetzt werden:

 

spring.application.name=Fedora4-Sidecar

server.display-name=Staatsbibliothek Fedora Sidecar

server.port=9080

sidecar.health-uri=http://localhost:8080/rest/health.json

sidecar.port=8080

sidecar.home-page-uri=http://localhost:8080/

 

Mit der Angabe der health-uri wird auf einen REST Endpunkt der Fedora4 Anwendung verwiesen, aus welchem Sidecar die Statusinformation zur Übermittlung an Eureka erhält. Dazu haben wir im Fedora4 folgendes triviales JSON Dokument hinterlegt:

health.json

{“status”:”UP”}

Bei erreichbarem Fedora4 kann Sidecar nun diese Statusinformation an Eureka übermitteln. Sidecar muss auf demselben Server laufen wie Fedora4. Zusätzlich zur Sidecar Konfiguration müssen natürlich noch die Konfigurationswerte für Eureka, Hystrix und Ribbon gesetzt werden. Um Fedora4 in Eureka sichtbar zu machen haben wir daher für die Service Registry folgende Werte gesetzt:

 

eureka.instance.leaseRenewalIntervalInSeconds=10

eureka.client.healthcheck.enabled=true

eureka.client.serviceUrl.defaultZone=http://localhost:8761/serviceregistry/eureka/

eureka.client.registryFetchIntervalSeconds=5

 

Ist Fedora4 gestartet zeigt Eureka die Integration wie folgt an:

fedora-sidecar

Ist das Sidecar Projekt gestartet und verfügbar, kann anschließend Fedora4 über folgende URL angesteuert werden:

 http://<hostname>:9080/fedora4-sidecar/

 

Welche Vorteile bringt uns diese Integration nun aber ganz konkret.

 

  • ohne Fedora4 anpassen zu müssen, lässt es sich in die “Platform Services” von Netflix integrieren,
  • Fedora4 ist damit in der Service Registry sichtbar und abrufbar,
  • ein Aufruf von Fedora4 über die Sidecar URL wird als Circuit Breaker Command ausgeführt,
  • es werden Hystrix Metriken generiert welche im Hystrix Dashboard sichtbar sind,
  • es kann Load Balancing verwendet werden, sobald Fedora4 mehrfach installiert ist,
  • es kann die zentrale Configuration Management Instanz verwendet werden.

 

Obwohl Fedora4 kein Microservice ist können Client Anwendungen die Service Registry nach der Einstiegs URL von Fedora4 fragen. Anschließend wird jede Anfrage der Clients via Hystrix abgesichert und aufgezeichnet. So konnten wir zum Beispiel die Antwortzeiten der Fedora4 REST API im Hystrix Dashboard aufzeichnen und auswerten.

hystrix-fedora

All diese Vorteile sind ohne eine einzige Anpassung des Fedora4 Systems möglich. Auf dieselbe Art  und Weise haben wir einen reinen Javascript Microservice eingebunden.

 

Fazit

Wie dieser Beitrag zeigt, ist die Integration einer Softwarekomponente, welche nicht den Netflix Stack via Bibliotheken Integration nutzen kann, sehr einfach. Die aufgezeigten Möglichkeiten, welche sich dadurch bieten finde ich beeindruckend. Hinzufügen muss ich allerdings, dass sich auf diese Art und Weise nur Softwarekomponenten integrieren lassen, welche über eine REST API angesprochen werden können. Da alle Aufrufe dieser REST API über Sidecar geroutet werden. Für Softwarekomponenten ohne REST API ist die Integration ebenfalls möglich aber etwas aufwendiger.

Microservices, Widerstandsfähigkeit

Widerstandfähigkeit eines Microservices Systems in Bezug auf Serviceausfälle oder Netzwerklatenz war ein wichtiger Aspekt, welchen wir in unserem Microservices Projekt eingehend untersuchen wollten. Daher freue ich mich dieses Thema und unsere Erfahrungen in unserer Blogserie etwas eingehender beleuchten zu können.

Widerstandsfähig bezieht sich hierbei auf die Client Anwendung, welche die einzelnen nachgelagerten Microservices verwendet. Dieser Begriff meint dabei, dass die Client Anwendung auch im Fall von Netzwerk- bzw. Serviceausfällen nicht blockiert und immer noch durch den Anwender verwendet werden kann. Blockieren kann die Anwendung zum Beispiel, wenn diese einen Microservice verwendet, welcher sehr viel Zeit benötigt, um eine Antwort im Netzwerk bereit zu stellen. Warum dieser Microservice nicht schnell genug antwortet, spielt bei dieser Betrachtung keine Rolle. Die Client Anwendung wartet solange bis entweder die Antwort eintrifft oder aber ein zuvor definierter Timeout einen Fehler erzeugt. Eine hohe Wartezeit einer Anfrage kann bei starker Verwendung der Client Anwendung dazu führen, dass immer mehr Anfragen der Nutzer das System immer stärker blockieren. Ein Blockieren der Client Anwendung kann aber auch durch eine Überlastung des Netzwerks ausgelöst werden. Die Client Anwendung fühlt sich in solchen Fällen für den Nutzer träge und langsam an. Im Falle von Webanwendungen verlässt der Nutzer in der Regel dann sehr schnell die Seite.

 

Als Lösung für solche Situationen bietet der Netflix OSS das Projekt Hystrix, als sogenannte „Circuit Breaker“ Bibliothek, an. Ein „Circuit Breaker“ ist eine Sicherung, welche ausgelöst wird, sobald gewisse Umstände eintreten. Hystrix bietet darüber hinaus viele zusätzliche Funktionalitäten:

 

  • kapselt ein Kommando und bietet synchrone und asynchrone Ausführung,
  • löst nach definiertem Timeout die Sicherung aus,
  • führt jedes Kommando in einem definierten Thread Pool aus,
  • auslösen der Sicherung bei zu hoher Fehlerrate eines Kommandos,
  • ermöglicht die Ausführung eines Fallbacks im Fehlerfall,
  • erzeugt Performance Metriken,
  • ermöglicht die Nutzung eines Caches.

 

Alle diese Funktionalitäten stehen zur Verfügung, sobald ein in der Client Anwendung ausgeführtes Kommando in ein “HystrixCommand” überführt wird. Meiner Meinung nach ist es wichtig, den nachfolgend abgebildeten Ablauf der Ausführung eines Hystrix Kommandos zu verstehen.

Abbildung .1: Netflix, Hystrix Command Fflow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Abbildung .1: Netflix, Hystrix Command Flow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Die detaillierte Beschreibung des Ablaufs finden Sie hier. Der Grund, warum ich diese Abbildung hier aufgeführt habe ist, dass diese sehr schön zeigt, dass Hystrix nicht nur ein reiner Ciruit Breaker ist. Wie zu erkennen ist, bietet Hystrix ein definiertes Verfahren zur Absicherung eines Netzwerkkommandos. Es besteht mit Hilfe der Hystrix Metriken die Möglichkeit sehr einfach und bequem Antwortzeiten auszuwerten. Durch die Integration konnten wir in unserem Projekt die Antwortzeiten eines Fedora4 Content Repository Servers, eines EMC S3 Object Storage Servers und des lokalen Dateisystems vergleichen. Die Hystrix Metriken konnten wir sehr einfach mittels des Hystrix Dashboards visualisieren und in Echtzeit auswerten. So kann auch in produktiven Umgebungen die Reaktions- bzw. Widerstandsfähigkeit einzelner Systeme optimal bewertet werden. Dies ersetzt natürlich keine umfassende Monitoringlösung, bietet aber die Möglichkeit, die Auslastung einzelner Systeme schnell zu erkennen und richtig zu behandeln.

 

Die Integration

Die Integration von Hystrix ist, wie auch bei den anderen “Platform Services” Komponenten, einmal mittels der nativen Netflix Bibliothek oder aber auch über das Spring Cloud Projekt möglich. In unserem Projekt haben wir beide Möglichkeiten erfolgreich durchgeführt.Spring Cloud bietet eine sehr einfache und leichte Integration via Annotation:

 

Beispiel:

@HystrixCommand(commandKey = “DMS->EMCS3:findObjectContent”, groupKey = “DMS->EMCS3”)

 

Hierbei wird lediglich der Name des Kommandos und des Threadpools definiert. Es ist über die Zusatzbibliothek hystrix-javanica zusätzlich möglich, alle Konfigurationswerte direkt in der Annotation aufzuführen. Wir haben uns allerdings dazu entschieden, die Konfiguration in der zentralen „application.properties“ Datei durchzuführen.

 

Im Bereich der nativen Netflix Bibliothek ist die Integration ebenfalls sehr leicht. Nach dem Einbinden der Abhängigkeiten hystrix-core und hystrix-metrics-event-stream kann die Integration durchgeführt werden. Die Klasse, mit welcher ein Kommando im Netzwerk ausgeführt wird, muss lediglich die Klasse HystrixCommand erweitern und die Methode run() implementieren. Die Konfiguration erfolgt über die Datei “eureka-client.properties”.

Bei einigen Standardwerten der Konfiguration mussten wir Anpassungen vornehmen, da Hystrix die Sicherung für unseren Anwendungsfall zu schnell ausgelöst hat. Dies ist uns bei Belastungstests mit dem Werkzeug JMeter aufgefallen. Letztendlich konnten wir mit folgenden Einstellungen ein sehr gutes Antwortverhalten bei einer stark belasteten Komponente erzeugen:

 

hystrix.command.default.execution.isolation.strategy=THREAD

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=120000

hystrix.command.default.execution.isolation.thread.maxConcurrentRequests=1024

hystrix.command.default.fallback.isolation.thread.maxConcurrentRequests=1024

hystrix.threadpool.default.coreSize=1024

hystrix.threadpool.default.maxQueueSize=1024

hystrix.threadpool.default.keepAliveTimeMinutes=2

hystrix.threadpool.default.queueSizeRejectionThreshold=15

hystrix.threadpool.default.metrics.rollingStats.numBuckets=12

hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds=1440  

 

Sich diese Konfigurationswerte genau zu betrachten und diese festzulegen, ist ein wichtiger Schritt bei der Integration von Hystrix. Allerdings muss natürlich jeder selbst entscheiden, welche Werte für welches Kommando sinnvoll sind.

 

Fazit

Die Integration ist, wie bereits bei den anderen “Platform Services” des Netflix OSS, nicht sehr aufwendig. Dieses Werkzeug, finde ich persönlich, wegen der vielen zusätzlichen Funktionalitäten sehr interessant und nützlich. Es bietet eine standardisierte Lösung, um ein Netzwerkkommando gesichert auszuführen, ein Fallback zur Verfügung zu stellen, einen Cache zu nutzen und Performancemesswerte zu erzeugen. In Zukunft werde ich für mich persönlich daher immer bewerten, ob nicht die Verwendung dieser Bibliothek bei jeglichen Netzwerkzugriffen eines Projektes sinnvoll ist.

Microservices, Load Balancing

Die Prüfung der Skalierbarkeit von Microservices war ein weiteres sehr wichtiges Thema in unserem Microservices Projekt. Im Rahmen unser dazugehörigen Blog Serie möchte ich hier das Thema Load Balancing im Kontext der Microservice Architektur näher beleuchten. Häufig werden im Bereich der Bibliothekssysteme zentrale Dienste, wie zum Beispiel ein zentrales Dokumentenmanagement wie Fedora oder eine zentrale Suche mit Solr oder Elasticsearch benötigt. In unserem Projekt wollten wir herausfinden, wie und mit welchem Aufwand Services dynamisch skaliert werden können. Dies bedeutet, dass in Situationen in welchen die Client Anwendungen durch die Nutzer der Bibliothek stark verwendet werden, die Services dynamisch auf zusätzliche Server installiert und anschließend verwendet werden. Dynamisch bedeutet an dieser Stelle automatisiert und damit ohne Administrations-, Konfigurations- bzw. Entwicklungsaufwand.

Wie in unserem ersten Beitrag beschrieben, bietet die Microservices Architektur unter anderem den Vorteil der einfacheren und genaueren Skalierung einzelner Microservices. Wird nun eine Softwarekomponente bzw. ein Service auf mehrere Server automatisiert installiert, müssen diese auch durch die Anwendungen genutzt werden können. Als Teil der „Platform Services“ bietet der Netflix Open Source Stack (Netflix OSS) auch hier eine sehr gute Lösung. Bevor ich die konkrete Lösung vorstelle, möchte ich noch etwas zur Theorie des Load Balancing sagen. Grundsätzlich gibt es zwei wesentliche Varianten um dieses aufzubauen.

 

Zentrales Load Balancing.

Dabei wird ein zentraler Load Balancer zwischen den Client Anwendungen und den Services aufgebaut. Alle Anfragen der Clients werden über den Load Balancer geroutet und dieser verteilt die Anfragen nach einem bestimmten Verfahren auf die einzelnen Service Instanzen. Ein Nachteil dieser Lösung ist, dass der Load Balancer ein Single Point of Failure ist. Dies bedeutet, dass wenn diese Komponente ausfällt bzw. stark überlastet ist, sie keine Anfragen mehr von den Anwendungen zu den Services weiterleitet.

Zentrales Load Balancing

Zentrales Load Balancing

Dezentrales Load Balancing

Hierbei hält die Client Anwendung alle Informationen, welche Service Instanzen verfügbar sind, bei sich lokal vor. Diese Informationen werden regelmäßig aktualisiert, sodass die aktuelle Situation der verfügbaren Services dem Client jederzeit bekannt ist. Die Client Anwendung entscheidet mit Hilfe eines eingebauten Load Balancing Mechanismus selbst, welche Service Instanz für eine Anfrage verwendet wird. Damit ist keine zentrale Load Balancer Instanz mehr notwendig und es gibt keinen Single Point of Failure. Auch bei dieser Lösung gibt es wiederum Nachteile, dass zum Beispiel die lokale Information, welche Instanzen der Services verfügbar sind, veraltet sein kann.

Dezentrales Load Balancing

Dezentrales Load Balancing

Die einzelnen Load Balancing Verfahren, nach welchem Algorithmus eine von mehreren verfügbaren Service Instanzen ausgewählt wird, möchte ich hier nicht aufführen, da es in diesem Beitrag um die Integration im Bereich der Microservices Architektur geht und nicht um das Load Balancing als solches. Der Netflix OSS bietet mit der Bibliothek Ribbon eine Möglichkeit des dezentralen, client-seitigem Load Balancing. Die Information, welche Service Instanzen auf welchem Server verfügbar sind, basieren auf den Informationen aus der Service Registry Eureka. Durch die Integration von Eureka ist das Load Balancing dynamisch und wird jederzeit an die verfügbaren Instanzen angepasst. Es ist auch möglich, Ribbon ohne Eureka einzusetzen, was hier aber nicht näher erläutert werden soll, da es für den produktiven Einsatz nicht empfohlen werden kann.

 

Unsere Erfahrungen

Die Integration von Ribbon in eine Client Anwendung ist einmal mit der Spring Cloud oder aber durch die Einbindung der nativen Netflix Bibliothek möglich. Bei beiden Varianten gibt es jeweils die Möglichkeit mittels direkter Verwendung eines Ribbon Clients das Load Balancing zu integrieren oder die Methode REST Templates zu definieren und zu verwenden. Beide Varianten unterscheiden sich vom Aufwand nicht. Elegant bei der Template Variante ist aus meiner Sicht die Trennung der Definition der zur Verfügung stehenden Funktionalität und deren Verwendung. So können zentral alle zur Verfügung stehenden Templates definiert und diese anschließend an den unterschiedlichsten Stellen eingesetzt werden. Dies vereinfacht die Wartung der bestehenden Möglichkeiten sehr stark. Allerdings konnten wir beim Einsatz des REST Templates für einen HTTP POST Request mit Multipart Upload nicht erfolgreich umsetzen. Beim Absetzen des HTTP POST Request wurde jeweils folgender Fehler gemeldet:

the request was rejected because no multipart boundary was found

Bisher haben wir noch keine Antwort zu unsere Anfrage nach einer Lösung aus der ribbon usergroup erhalten. Zusätzlich zur Integration im Quellcode muss das Load Balancing noch konfiguriert werden. Hier kann zum Beispiel auch zwischen den möglichen Verteilungsverfahren gewählt werden. Ribbon unterstützt zum Beispiel folgende:

  • RoundRobinRule
  • AvailabilityFilteringRule
  • WeightedResponseTimeRule

Alle Details zur Konfiguration von Ribbon können im Wiki des Projektes nachgelesen werden. Zusammenfassend können wir sagen, dass die Integration von Ribbon in eine Anwendung ohne großen Aufwand umzusetzen ist und sehr zuverlässig funktioniert. Bis auf die Ausnahme des HTTP POST Multipart Request sind wir auf keine weiteren Schwierigkeiten gestoßen.

 

Einsatz des Load Balancing

Unsere Client Anwendungen im Pilotprojekt bietet die Funktion eines Upload von XML Dateien. Diese lädt die Dateien nach der Auswahl im Browser via einer REST Schnittstelle in ein Dokumentenmanagementsystem (Microservice). In die Client Anwendungen haben wir das Load Balancing mit Hilfe der nativen Netflix Bibliothek integriert. In einem Test eines Ausfalls von einem der Dokumentenmanagement Services während des Uploads von 1000 XML Dateien konnten wir zeigen, dass der Upload nicht beeinträchtigt wird. Der Anwender bemerkt nicht, dass zu Beginn des Uploads noch zwei und während des Uploads nur noch eine Service Instanz des Dokumentenmanagement Services die Daten speichert. Ohne den Einsatz von Eureka und Ribbon wäre der Upload bei Ausfall des Dokumentenmanagement Services abgebrochen.

 

Fazit:

Auch für das Thema Load Balancing kann ich den Einsatz für zentrale Services in Kombination mit einer Service Registry nur stark empfehlen. Der Aufwand der Integration in eine Java Anwendung ist meines Erachtens eher gering und lohnt sich. Nach Abschluss der Integration können die Microservices einfach skaliert und die Client Anwendung kann so jederzeit stärker verwendet werden und reagiert robuster auf Ausfälle.

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.

New Urbanism: bei uns, nebenan und vor der Haustür

Am heutigen Samstag, 19. März, verleiht die Notre Dame School of Architecture (Indiana, USA) in einer ganztägigen Zeremonie zum 14. Mal den renommierten Richard H. Driehaus-Preis, den international wichtigsten Preis für Traditionelle Architektur und Neuen Urbanismus. Preisträger der mit 200.000 US-Dollar dotierten Auszeichnung ist in diesem Jahr Scott Merrill, Gründer und Chefdesigner des US-amerikanischen Architekturbüros Merrill, Pastor & Colgan. Er wird gewürdigt für seine originellen Entwürfe, die regionale Besonderheiten der Landschaft ebenso aufnehmen wie klassische Formentraditionen aus allen Epochen und Regionen. Merrills Projekte reichen von Ferienanlagen, Wohnblocks und Büroquartieren über Kirchenbauten, Rathäuser und Stadtparks bis hin zu Tanzclubs oder auch einem Bahnhof für Hochgeschwindigkeitszüge in den Vereinigten Arabischen Emiraten.

Zu wegweisenden Vertretern und Bauten der Traditionallen Architektur und des Neuen Urbanismus, der in den späten 1980er Jahren in den USA entstand, können Sie sich auch über unsere Bestände informieren. Darunter finden sich auch einige Berliner Bauten, wie der im amerikanischen Backsteinstil von Hans Kollhoff errichtete Kollhoff-Tower am Potsdamer Platz oder die 2015 eröffnete Mall of Berlin am Leipziger Platz von Sergei Tchoban, um nur zwei Beispiele zu nennen. Wichtigstes Prinzip des New Urbanism ist die Rückbesinnung auf die Vorteile kleiner, überschaubarer Städte und Gemeinden, die sich an historischen Altstädten orientieren und durch Nachhaltigkeit und hohe Lebensqualität auszeichnen. Wohn- und Geschäftsviertel sollen nicht mehr streng getrennt sein, sondern eine gemeinsame Einheit mit fußgängerfreundlichen Plätzen und Grünflächen bilden, so dass lebenswerte Nachbarschaften entstehen.

Sie möchten mehr über die Umsetzung dieser Ideen und andere städtebauliche und architektonische Highlights in Berlin erfahren? Am 27. April um 16.30 Uhr zeigen wir Ihnen in unserem Workshop „Bauten, Parks und Plätze – Literaturrecherche zur Architektur am Beispiel Berlins“ wie Sie die richtige Lektüre finden. Melden Sie sich gleich hier an!

Ach übrigens: Der große Bruder des Driehaus-Preises – wenn auch nur halb so hoch dotiert – ist der international noch mehr beachtete Pritzker-Architektur-Preis, mit dem zunächst Jay A. Pritzker und nach dessen Tod die Hyatt-Stiftung bereits seit 1979 jährlich Spitzenleistungen der modernen Architektur würdigt. Auch zu diesen Geehrten haben unsere Kataloge einiges zu bieten. Als deutsche Preisträger wurden bisher Gottfried Böhm (1986) und Frei Otto (2005) ausgezeichnet.

Für Informationen über den diesjährigen Preisträger Alejandro Aravena aus Chile, der am 4. April im UNO-Hauptquartier in New York ausgezeichnet wird, dürfen wir Sie an unseren guten Nachbarn, das Iberoamerikanische Institut verweisen.

Wieder Kuben in Guben

Die „Urvilla der Moderne“ des großen Architekten Mies van der Rohe in Guben/Gubin soll wiederauferstehen. Eine Tagung und eine Ausstellung in der Staatsbibliothek geben am 11. März 2016 den Startschuss für das Rekonstruktionsvorhaben.

Mies, Mies, immer nur Mies. Direkt neben der Neuen Nationalgalerie am Kulturforum wird bei einer Tagung am 11. März 2016 eine weitere Ikone des Baukünstlers verhandelt. Im Otto-Braun-Saal der Staatsbibliothek geht es um ein Haus aus Backstein, das der große Architekt der Moderne rund vierzig Jahre zuvor in einen Hang in Guben staffelte. Die Villa Wolf von 1926 gilt mit ihrem offenen Grundriss als die Mies’sche „Urvilla der Moderne“. Gelegen im heute polnischen Teil der Stadt, wurde sie im Zweiten Weltkrieg zerstört, ist darum weitestgehend unbekannt und soll nun als weltweit erstes Mies-Museum wiederaufgebaut werden. Mit der Auftaktveranstaltung, die von einer Ausstellung begleitet wird, stellt Florian Mausbach, Initiator des Projekts und ehemaliger Präsident des Bundesamtes für Bauwesen und Raumordnung, sein Rekonstruktionsvorhaben der Öffentlichkeit vor. Dazu hat er ein Programm zusammengestellt, das mit einer Reihe interessanter Namen aufwartet: Neben den internationalen Mitstreitern kommen renommierte Mies-Experten wie Wita Noack (Haus Lemke) oder Wolf Tegethoff und der ehemalige Finanzminister und „verhinderte Architekt“ Hans Eichel zu Wort. Außerdem spricht Fernando Ramos Galino. Der spanische Architekt hatte in den Achtzigerjahren Mies‘ berühmten Pavillon des Deutschen Reichs für die Weltausstellung von 1929 in Barcelona wiederaufbauen lassen und berichtet nun von dieser Erfahrung.

Aber was war eigentlich das Besondere am Haus Wolf? Die Villa war so etwas wie der erste revolutionäre Schritt Mies van der Rohes hin zum freien Raum. Aus den kleinen „Urkuben“, den Backsteinen, entwickelt er einen großen Kubus. Das Flachdach ermöglichte es dem dritten und letzten Bauhausdirektor, den Grundriss frei zu gestalten. So entstand seine erste radikal modern gestaltete Villa. Die nun der Vergessenheit entzogen werden soll, sagt Florian Mausbach, der das Vorhaben mit dem Satz „Wir wollen einen Schatz ausgraben und wieder bekannt machen“ begründet. Haus Wolf soll das erste und wichtigste Ausstellungsstück des neuen Mies-van-der-Rohe-Museums werden. Damit erledigen sich für den Projektinitiator auch alle Fragen der Rekonstruktionsdebatte.

Studierende der Fachhochschule Potsdam haben auf Basis von Scans der Originalentwürfe aus dem Mies-Archiv des New Yorker MoMA Pläne für den möglichst originalen Wiederaufbau der „Urvilla der Moderne“ angefertigt. Diese sind nun in einer Ausstellung zu sehen, die vom 11. März bis 9. April 2016 im Foyer der Staatsbibliothek gezeigt wird. Bis das fertige 1:1 Modell der Villa Wolf dann steht, sind aber noch einige Schritte nötig. Es gilt, den noch komplett vorhandenen Keller – in dem übrigens ein Großteil der Porzellansammlung des damaligen Bauherren, des Textilfabrikanten Erich Wolfs, in Scherben liegt – archäologisch zu sondieren. Gemeinsam mit polnischen Studierenden der TU Posen werden Studenten der HTW Berlin Ausgrabungen vornehmen. Diese Arbeit ist auch notwendig, um die Daten der Originalpläne zu verifizieren. Vor allem aber gilt es, die Finanzierung zu sichern und die Baukosten von grob geschätzt 2 Millionen Euro zusammenzubringen. Wenn alles gut läuft, könnte 2019 – dem Jahr des 100. Bauhausjubiläums und des 50. Todestags Mies van der Rohes – Baustart sein.

Dieser Text wurde auf der Grundlage eines Interviews mit Florian Mausbach erstellt von unserer Gastautorin Gesine Bahr-Reisinger, Wissenschaftliche Redakteurin der Abteilung Medien und Kommunikation der Stiftung Preußischer Kulturbesitz.

Ausstellung: Mies van der Rohes Villa Wolf in Gubin

Die „Urvilla der Moderne“ – Mies van der Rohes Villa Wolf in Gubin

Wiederaufbau als Modell 1:1

11. März – 9. April 2016

Mo – Fr 9 – 21 Uhr, Sa 10 – 19 Uhr
sonn- und feiertags geschlossen

Eintritt frei

Staatsbibliothek zu Berlin
Foyer
Haus Potsdamer Straße 33
10785 Berlin

Weitere Informationen: www.villawolfgubin.eu

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.