In einer Microservices-Architektur arbeiten viele einzelne Prozesse mit begrenzten Aufgabengebiet zusammen, um komplexe Anforderungen zu bedienen.
Die folgenden Videos handeln von Chancen und Fallstricken des praktischen Einsatzes von Microservices.
The Evolution of Microservices
Adrian Cockroft gibt einen Überblick zu den Beweggründen des Einsatzes von Microservices, geht dann auf die Interaktionen in einem komplexen System ein:
What can go wrong?
Er zeigt dort wie auch in einem wunderschön redundant aufgebauten System durch einen einzelnen Service andere Services mit in den Abgrund gerissen werden. (Etwa bei Minute 34)
[button link=“https://youtu.be/Mg4Cs2K7f98″ color=“purple“ target=“blank“ size=“small“]Zum Video: Evolution of Microservices[/button]
[button target=“blank“ color=“purple“ size=“small“ link=“https://learning.acm.org/webinar_pdfs/EvolutionOfMicroservices_WebinarSlides.pdf“]Folien „Evolution of Microservices“[/button]
Six principles for building fault tolerant microservices on the JVM
Christopher Batey geht auf die Details ein. Er zeigt welche verschiedenen Arten von Timeouts wir beachten müssen, und welche anderen Mechanismen den Schaden von einzelnen Serviceausfällen begrenzen können. Er zeigt auch wie man das Verhalten bei solchen Ausfällen testen kann.
Die meisten anderen Prinzipien drehen sich darum, dass ein Microservice auch richtig „Nein“ sagen können muss. Wenn sich die Warteschlange eines Prozesses sich füllt, sollte er aufhören neue Aufträge anzunehmen. Wenn ein Prozess nicht mehr antwortet, sollte man es nicht sofort wieder beim gleichen Prozess probieren. Und man sollte auch die Möglichkeit haben, Teile der Anwendung abschalten zu können um die Gesamtanwendung auch in Stresssituationen am Leben zu halten.
[button link=“https://youtu.be/dKWNZnuZhd0″ color=“purple“ target=“blank“ size=“small“]Zum Video: fault tolerant microservices[/button]
Kill „Microservices“ before it is too late
Ein provokanter Vortragstitel von Chad Fowler. Der Vortrag enthält noch mehr Provaktionen, die man nicht unbedingt teilen muss, die aber zum nachdenken anregen.
Zu seinen Thesen gehört: Die Aufteilung der Anwendung in Microservices und ihre Kommunikation untereinander sollte weitgehend stabil sein (Immutable Infrastructue), die einzelnen Microservices können auch mal komplett ausgetauscht werden, beispielsweise um sie in einer anderen Programmiersprache zu implementieren. Eine überraschende Folgerung:
Unit-Tests sind wenig hilfreich, er spricht sogar von einem „Design Smell“, Integratonstests dafür um so wichtiger.
[button link=“https://youtu.be/-UKEPd2ipEk“ color=“purple“ target=“blank“ size=“small“]Zum Video: Kill Microservices[/button]
Life beyond Distributed Transactions
Wenn zwei Microservices an einer Transaktion teilnehmen, jedoch jeweils Ihre eigene Datenbank haben, wie stellen wir Konsistenz her? Meine letzte Empfehlung ist kein Video, dafür ein sehr lesenswerter Artikel von Pat Helland. Er strukturiert zunächst das Problem, das spätestens dann entsteht wenn die nötigen Daten nicht mehr auf einen Rechnersystem untergebracht werden können. In Folge untersucht er Methoden, um zu konsistenten Ergebnissen zu kommen.
[button link=“https://queue.acm.org/detail.cfm?id=3025012″ color=“purple“ target=“blank“ size=“small“]Zum Artikel bei ACM-Queue[/button]