Suche
Interview mit Niko Köbler

„Serverless lässt mich sehr schnell und ohne Kostenrisiko neue Ideen etablieren und umsetzen.“

Hartmut Schlosser

Niko Köbler

Es gibt Momente, in denen will man einfach nur Code schreiben und in der Cloud ausführen, ohne sich lange mit der Infrastruktur aufhalten zu müssen. Ereignisgesteuerte Funktionen in der Cloud ausführen – darauf ist AWS Lambda spezialisiert. Im Interview sprachen wir mit W-JAX Speaker Niko Köbler über den Serverless-Ansatz, dessen Zukunft und wofür er sich besonders gut bzw. überhaupt nicht eignet.

w-jax 2016 logoTreffen Sie Niko Köbler auf der W-JAX 2016

Die Session Darfs auch etwas kleiner sein? Microservices mit AWS Lambda wird am Mittwoch, 9. November, ab 16.45 Uhr im Saal „München“ stattfinden.
 

 

JAXenter: Was macht für dich persönlich den Reiz des Serverless-Ansatzes aus?

Niko Köbler: Serverless heißt ja nicht, dass man keine Server mehr benötigt. Es geht ja vielmehr darum, dass man sich nicht mehr mit dem Management der Server beschäftigen muss, sondern einfach nur noch Services verwendet. Um alles andere kümmert sich der Cloud-Provider seiner Wahl (in meinem Falle gerne AWS). Ich als Entwickler kann mich also wieder mehr der Implementierung der Lösung widmen und muss mich nicht damit auseinandersetzen, dass das OS und das JDK der Rechner-Instanz aktuell ist, der Application-Server oder die Anwendung auf dem Server gestartet ist und läuft (und auch per Autostart gestartet wird), was zu tun ist, wenn die Anwendung skalieren muss oder damit sie hochverfügbar ist. Zusätzlich bezahle ich auch nur das, was ich wirklich nutze, sei es in Form von der Zeit, die eine Funktion ausgeführt wird oder der Anzahl wie oft eine API aufgerufen oder Nachrichten aus Queues abgerufen werden. Habe ich Leerlaufzeiten, muss ich nicht für sich langweilende Rechner-Instanzen bezahlen und bin trotzdem verfügbar. Das lässt mich sehr schnell und ohne Kostenrisiko neue Ideen etablieren und umsetzen.

Man sollte eine Serverless-Lösung in seine Überlegungen mit einbeziehen, wenn es um zustandslose Anwendungen geht

Ein Beispiel aus meinem letzten Projekt: Wir mussten Partnern eine Schnittstelle zur Verfügung stellen, die Nachrichten bzw. Datensätze entgegennimmt. Die Zahl und die Häufigkeit der Nachrichten war sehr gering und die Partner sollten nicht mit Messaging-APIs belästigt werden sondern einfach nur per HTTP ihre Daten abliefern. Also haben wir einfach ein API-Gateway so konfiguriert, dass die eingehenden HTTP-Requests ihre Nachrichten in ein Publish-Subscribe Messaging-System (SNS) lieferten. Die Messaging-Middleware hatten wir, um keine Nachrichten zu verlieren. Als Subscriber gab es dann dedizierte Queues (SQS), die wiederum von Lambda-Funktionen konsumiert wurden. Die Lambda-Funktionen haben dann die eingehenden Nachrichten verarbeitet und in einer Datenbank abgelegt. Selbstgeschriebener Code war also nur in den Lambda-Funktionen enthalten, alles anere haben wir uns wie in einem Lego-Baukasten zusammengesteckt (bzw. -konfiguriert). Das war nicht nur schnell auf die Beine gestellt, sondern auch noch günstig.

JAXenter: Was sind deiner Erfahrung nach die größten Herausforderungen, um eine Serverless-Anwendung produktiv zum Laufen zu bringen?

Je kleiner eine technische Lösung wird, desto mehr wird es davon in Produktiv- umgebungen geben

Niko Köbler: Eigentlich gibt es in Serverless-Umgebungen keine neuen Herausforderungen als in anderen Verteilten Umgebungen. Nur werden diese Anforderungen für Serverless-Anwendungen noch notwendiger. Neben einem ausführlichen Logging und Monitoring aller möglichen Metriken ist eine von mir immer wieder diskutierte Anforderung die Sache mit der Dokumentation. Je kleiner eine technische Lösung wird, desto mehr wird es davon in Produktivumgebungen geben. Letztendlich muss ich also wissen, welche und wieviele Instanzen von welchen Services laufen in meiner Umgebung und welche Kommunikationswege und -abhängigkeiten haben diese. Nichts Neues also, aber je kleiner die Einheiten werden, desto wichtiger.

Serverless: ja oder nein?

JAXenter: Für welche Art von Anwendungen eignet sich der Serverless-Ansatz gut?

Niko Köbler: Grundsätzlich sollte bzw. kann man eine Serverless-Lösung dann in seine Überlegungen mit einbeziehen, wenn es um zustandslose Anwendungen geht, die zudem eine hohe Anforderung an Skalierbarkeit und Verfügbarkeit stellen. So könnte eine Website ihre statischen Inhalte (z.B. die Angular-2- oder React-SPA) aus S3 über CloudFront ausliefern und alles, was dynamisch geliefert wird, z.B. eine Art Gästebuch oder Forum, kann die Requests über das API-Gateway und Lambda-Funktionen weiterleiten, die die Daten aus einer DynamoDB lesen oder diese dort reinschreiben.

Da die Serverless-Welt (im Speziellen die von AWS) von Events geprägt ist, kommen Serverless-Services vor allem auch bei der Event-Verarbeitung in Betracht. Das „Hello World“ der Serverless-Welt ist das Bild, das im S3 Storage abgelegt wird, damit ein S3-Event erzeugt und eine Lambda-Funktion auslöst wird, die sich dieses Bild holt, ein Thumbnail davon berechnet und dieses in einen anderen Ordner in S3 wieder hochlädt.

Dadurch, dass fast alle AWS-Services Events erzeugen (können), sind serverlose Services, Lambda-Funktionen im speziellen, auch sehr gut für das interne Management der eigenen genutzten Cloud-Services geeignet.

JAXenter: Für welche Anwendungen eignet sich der Serverless-Ansatz eher weniger?

Niko Köbler: Für alle anderen 😉

Nein, Spaß beiseite. Zustand („state“) in der Anwendung und langlaufende, Speicher-intensive Berechnungen sind meiner Erfahrung nach eher wenig für serverlose Anwendungen geeignet. Hier gibt es u.U. spezielle Anforderungen an die Anwendung, die eine „standardisierte“ und nur in gewissen Rahmen anpassbare Umgebung nich abdecken kann. Dann wird eine Lösung mit dedizierten und vom Anwender selbst verwaltete Rechner-Instanzen wieder wichtig.

Extreme Microservices & NoOps

JAXenter: Weshalb ist Serverless im Rahmen der DevOps-Bewegung interessant (es macht derzeit ja auch die Formel „NoOps“ die Runde).

Speicher-intensive Berechnungen sind eher wenig für serverlose Anwendungen geeignet

Niko Köbler: Serverless zwingt den Entwickler von Anfang an noch mehr, sich mit der Infrastruktur und deren Zusammenhängen auseinanderzusetzen. Schließlich muss ich als Entwickler auch irgendwie und irgendwo dokumentieren und konfigurieren, welche Serverless-Services ich in meiner Lösung verwende. Auch muss ich in der Lage sein, das Zusammenspiel (welche Ressource darf mit welchen Rechten auf eine andere Ressource/einen anderen Service zugreifen) der Services jederzeit „auf Knopfdruck“ wieder herstellen zu können. „NoOps“ wird vor allem dadurch geprägt, dass ich mich mit rein administrativen Dingen und dem Betrieb, der Skalierung und Verfügbarkeit der Systeme nicht auseinandersetzen muss, da das ja der Cloud-Anbieter, der die Services anbietet, für mich übernimmt.

JAXenter: Domain-driven Design ist ein Inspirationsgeber für Microservices-Architekturen. Serverless wurde auch schon als „Extreme Microservices“ bezeichnet. Wie siehst du den Zusammenhang zwischen DDD und Serverless – ergänzen sich die Ansätze, stehen sie nebeneinander oder sind sie nicht miteinander vereinbar?

Niko Köbler: Serverlose Funktionen haben für mich viel mehr einen technischen Aspekt, um fachliche Anforderungen zu lösen, als es das Thema „Microservices“ hat. Schließlich könnte ich einen Microservice mit einem fachlichen „Bounded Context“, mit mehreren serverlosen „Funktionen“ weiter runterbrechen, bis hin zur technischen Auführung, was nicht mehr viel mit dem Bounded Context an sich zu tun hat.

Durch dieses Runterbrechen bis auf eine technische Aufgabe, könnte man bei einer Funktion schon fast wieder in Richtung Wiederverwendung (das böse Wort) denken, da bestimmte Aufaben so von der gleichen Funktion übernommen/ausgeführt werden können, obwohl der Ursprung aus zwei fachlich unterschiedlichen Microservices kommt (z.B. Authorisierung, Logging, andere Event-basierte Aufgaben).

JAXenter: Derzeit gibt es ja AWS Lambda als für den Produktiveinsatz empfohlene Serverless-Lösung – viele andere Lösungen sind noch im Alpha- oder Beta-Zustand. Was fehlt dir noch in der Gesamtlandschaft der Serverless-Lösungen, was man in den nächsten Jahren unbedingt nachliefern sollte?

Innovationen werden nicht mit etablierten Standards getrieben

Niko Köbler: Es gibt schon viel mehr „Serverless“-Services und -Lösungen, als nur AWS Lambda. Lambda und das API-Gateway haben der Serverless-Bewegung nur einen Push für dessen Popularität gegeben. Der bekannteste „Serverless“ Service bei AWS ist sicherlich die Storage-Lösung S3, die gibt es schon sehr lange. Um hier Daten im Speicher abzulegen, muss ich selbst auch keine Server betreiben. Verschiedene Datenbank- und Datenverarbeitungs-Lösungen (Kinesis für Streams, SNS und SQS für Messaging-ähnliche Dienste) sind bereits etabliert und auch ansonsten gibt es im AWS-Universum Services, die bereits produktiv eingesetzt werden können. Lambda ist lediglich die Compute-Lösung, für die es bislang noch nichts gab und man dafür jeweils eine eigene EC2-Instanz nutzen musste. Und mit dem API-Gateway muss ich mir in dem Zusammenhang auch keine Gedanken mehr über die HTTP-Kommunikation machen, die mir von diesem Service abgenommen wird.

Die Frage ist doch auch nicht wirklich, ob Alpha-, Beta- oder Release-Version – vielmehr sollte für Unternehmen interessant sein, ob sie mit den Angeboten Lösungen für ihr Businessmodell bauen und betreiben können. Innovationen werden nicht mit etablierten Standards getrieben.
Letztendlich fehlt mir also nichts in der Serverless-Welt, die einzelnen Angebote werden sich noch weiter entwickeln und sich verändern, je nach Nachfrage der Anwender. Vielleicht wird auch die ein oder andere Lösung wieder verschwinden und andere Services angeboten werden. Lassen wir uns hier einfach überraschen.

nikokoeblerNiko Köbler macht irgendwas mit Computern, viel im Web, meistens (funktional) auf der JVM. Er ist Co-Lead der JUG Darmstadt, Autor und Sprecher auf internationalen Konferenzen. Niko tweetet unter @dasniko.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

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