Suche
Interview mit Sascha Möllering

„Das Aufbrechen eines Monolithen in Microservices ist keine triviale Aufgabe“

Dominik Mohilo

Sascha Möllering

In vielen Unternehmen und Projekten setzt man heutzutage nicht mehr auf monoloithische Architekturen, sondern auf Microservices. Im Interview spricht Sascha Möllering, Solutions Architect bei der Amazon Web Services Germany GmbH, über die Wanderung von Microservices-Architekturen in die Cloud, Best Practices beim Erstellen von Microservices und darüber, warum sich Docker und Serverless so gut für eine kleinteiligere Architektur eignen.

Wer Sascha Möllering einmal live erleben möchte, der hat auf dem diesjährigen Microservices Summit und auf der W-JAX 2017 dazu Gelegenheit. In seinem Workshop „Microservices in der AWS-Cloud“ stellt er auf dem Microservices Summit unterschiedliche Ansätze vor, um Microservices in der AWS-Cloud auszurollen. Auf der W-JAX 2017 zeigt er in seiner Session „Reaktive Architekturen mit Microservices“ die grundlegenden Muster von reaktiven Architekturen.

JAXenter: In deinem Workshop stellst du verschiedene Ansätze vor, Microservices-Architekturen in der AWS-Cloud anzusiedeln. Welche Ansätze gibt es da?

Sascha Möllering: Bei vielen AWS-Kunden sehen wir – in Abhängigkeit von den entsprechenden Anforderungen – drei unterschiedliche Implementierungsansätze für Microservices in der AWS-Cloud. Der erste Ansatz basiert auf der Nutzung von AWS Elastic Beanstalk, einem Service zum Bereitstellen und Skalieren von Webanwendungen und -Services, die mit Java, .NET, PHP, Node.js, Python, Ruby, Go und Docker auf Servern wie Apache, Nginx, Passenger und IIS entwickelt werden. Bei AWS Elastic Beanstalk wird Code einfach in den Service geladen und dieser übernimmt automatisch die Bereitstellung – von der Kapazitätsbereitstellung, Lastverteilung und automatischen Skalierung bis zur Statusüberwachung der Anwendung. Service Discovery wird bei diesem Ansatz mit Hilfe von Elastic Load Balancing implementiert.

Ein weiterer Ansatz besteht in der Nutzung der Container-Technologie Docker. Für die Orchestrierung nutzen viele Kunden den Amazon EC2 Container Service (ECS), einen hochgradig skalierbaren, sehr leistungsfähigen Container-Management-Service, der es erlaubt, Anwendungen auf einem automatisch verwalteten Cluster von Amazon-EC2-Instanzen zu betreiben und zu skalieren. Eine Alternative für die Orchestrierung von Docker-Containern ist bspw. die Installation von Kubernetes über kops oder kube-aws.

Ein dritter Ansatz ist die Verwendung von AWS Lambda für die Implementierung der Geschäftslogik. AWS Lambda ist ein serverloser Datenverarbeitungsservice, der Code beim Eintreten bestimmter Ereignisse ausführt und automatisch die zugrundeliegenden Datenverarbeitungsressourcen verwaltet.

Docker und AWS Lambda eignen sich für Microservices besonders, da beide Technologien darauf ausgelegt sind, einen hohen Grad an Isolation zu ermöglichen.

JAXenter: Gerade Serverless und Docker sind seit einiger Zeit in aller Munde. Wieso eignen sich diese Ansätze besonders gut für Microservices?

Sascha Möllering: Microservices sind ein Architekturstil, bei dem komplexe Anwendungen aus simplen und unabhängigen Prozessen zusammengesetzt sind, die untereinander über wohldefinierte APIs miteinander kommunizieren. Diese Services sind klein, entkoppelt und implementieren maximal eine Domäne. Docker und AWS Lambda eignen sich für die Implementierung dieser Eigenschaften besonders, da beide Technologien darauf ausgelegt sind, einen hohen Grad an Isolation zu ermöglichen. Darüber hinaus kapseln sowohl AWS Lambda als auch Docker die eigentlichen Implementierungsdetails, die Services kommunizieren also nur über entsprechende Schnittstellen miteinander.

JAXenter: Was würdest du Unternehmen raten, die ihren Monolithen in Microservices aufbrechen und in die Cloud verlagern wollen?

Sascha Möllering: Das Aufbrechen eines Monolithen in Microservice ist eine Aufgabe, die nicht trivial ist. Es ist sinnvoll, damit zu beginnen, ein Domänenmodell für die Anwendung zu definieren. Auf technischer Ebene sollte damit begonnen werden, Schnittstellen für die einzelnen Services des Monolithen zu definieren (RESTFul API oder Entkopplung der Services über ein Messaging-System) und diese Services herauszubrechen. Die Kommunikation zwischen dem Restmonolithen und dem neuen Service sollte ausschließlich über diese Schnittstelle realisiert sein. Jeder Microservices ist für das jeweilige datenhaltende System zuständig, der Monolith darf also keine direkten Zugriffe auf dieses System durchführen. Oft nutzen klassische monolithische Anwendungen verteilte Transaktionen (bei JavaEE über die JTA-API). In einer Microservice-Architektur muss ein alternatives Pattern wie beispielsweise Event Sourcing genutzt werden.

JAXenter: Gibt es in Sachen Microservices sogenannte Best Practices, die jeder Entwickler, der sich mit den Thema befassen will, immer beachten sollte?

Sascha Möllering: Für Microservices gelten im Allgemeinen folgende Best Practices:

  1. Es muss eine sinnvolle Dokumentation existieren (auch und gerade für die Schnittstellen).
  2. Monitoring und Troubleshooting müssen Teil des Designprozesses sein.
  3. Jeder Microservice sollte einfach auszurollen und leicht skalierbar sein.
  4. APIs von Microservices sollten selbsterklärend sein, was die Nutzung vereinfacht.
  5. Microservices sind per Definition ein verteiltes System und sollten mit den „Fallacies of Distributed Computing“ im Hinterkopf entwickelt werden.
  6. „Failures are a given and everything will eventually fail over time“, deswegen sollte Resiliency bzw. Antifragility Kern des Architekturdesigns sein

JAXenter: Nehmen wir an, die Microservices-Architektur steht, ist in der Cloud live und alles läuft super – wie stellt man nun sicher, dass es so bleibt?

Monitoring ist ein oft viel zu wenig beachteter Aspekt einer Microservices-Architektur.

Sascha Möllering: Monitoring ist ein oft viel zu wenig beachteter Aspekt einer Microservices-Architektur. Gerade in einem verteilten System mit vielen unterschiedlichen Services ist es wichtig zu wissen, wie es um den Gesamtzustand eines Systems bestellt ist. Das gilt natürlich für die darunterliegende Basisinfrastruktur wie auch für die Services selbst, die definierte Schnittstellen für Healthchecks und Metriken bieten sollten.

Für Docker existiert beispielsweise das Projekt cAdvisor, das die Ressourcenallokation und Performance-Charakteristika der einzelnen Container anaysiert. In Kombination mit Prometheus und Grafana können für den Betrieb sehr informative Dashboards erstellt werden.

Für die Basisinfrastruktur wie beispielsweise EC2-Instanzen bietet Amazon CloudWatch als integrierte Monitoring-Lösung viele nützliche Metriken für die Überwachung der Infrastruktur. Amazon CloudWatch bietet zudem die Möglichkeit, eigene Metriken an den Service zu schicken und auf Basis dieser Metriken Skalierungsregeln zu definieren. Im Kontext von AWS Lambda kann CloudWatch auch für eigene Metriken verwendet werden (technische Metriken oder Business-Metriken). Mehr Informationen zum Thema Microservices in der AWS-Cloud können im kürzlich aktualiserten Microservices-Whitepaper gefunden werden.

Die Fehlersuche in verteilten System wie Microservices-Architekturen kann – in Abhängigkeit von der Menge der Services und den Kommunikationsstrukturen – schnell sehr komplex werden. AWS X-Ray hilft Entwicklern dabei, verteilte Anwendungen zu analysieren und zu debuggen. X-Ray bietet eine End-to-End-Ansicht der Requests auf ihrem Weg durch die einzelnen Services und zeigt eine Übersicht der Komponenten, die den Anwendungen zugrundeliegen.

JAXenter: Welche Erkenntnis sollte jeder Teilnehmer deines Workshops am Ende mit nach Hause nehmen?

Sascha Möllering: In dem Workshop werde ich zunächst die theoretischen Grundlagen von Microservices näher erläutern und danach auf die praktische Umsetzung mit Hilfe von AWS Elastic Beanstalk, Amazon ECS und AWS Lambda eingehen. Für den praktischen Teil wird AWS CodeStar eingesetzt: dieser Service erleichtert die Einrichtung der gesamten Entwicklungs- und Continuous-Delivery-Toolkette zum Codieren, Erstellen, Testen und Ausrollen von Anwendungscode. Die Haupterkenntnis für die Teilnehmer des Workshops soll sein, dass Microservices sehr schnell kollaborativ mit Hilfe von AWS auf Basis von serverlosen Services implementiert und ausgerollt werden können.

JAXenter: Vielen Dank für das Gespräch!

Sascha Möllering arbeitet als Solutions Architect bei der Amazon Web Services Germany GmbH. Seine Interessen liegen in den Bereichen Automation, Infrastructure as Code, Distributed Computing, Container, Serverless und der JVM.
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.