Techblog

Serverless Computing - wie reif ist das Konzept?

Von Alfred Feldmeyer

4. April 2018

Serverless Computing? Das geht doch nur für kleine Projekte!

Oder?

Im Februar diesen Jahres war in Hamburg die JeffConf, eine Konferenz rund ums Serverless Computing. In Gesprächen mit Kollegen über das Thema, kommt früher oder später folgender Einwand:

Ja, aber das kannst du doch eigentlich nur in kleinen Projekten verwenden, oder? Bei einem echten Projekt macht das doch eigentlich gar keinen Sinn!

Von Vorne: Serverless Computing ist ein Software-Architektur-Muster. Es geht darum, die Abhängigkeit zur Hardware möglichst zu eliminieren. FaaS (Function as a Service) ist eine konkrete Ausprägung davon. Die Grundidee: Der Zustand der Anwendung wird auf den kleinsten möglichen Zeitraum verringert und event-basiert ausgelöst. Dabei spielt es keine Rolle, ob es sich um einen HTTP-Request oder die Änderung eines Datensatzes handelt. Populärster Vorreiter dieser Art ist AWS-Lambda. So weit, so gut.

Und in groß?

Aber funktioniert das auch im größeren Stil über mehr als hundert Funktionen? Yan Cui liefert hier interessante Einblicke. Er berichtet auf der JeffCon vom Aufbau der Yubl-Plattform mit 170 produktiven Lambda-Funktionen und einer Kostenersparnis gegenüber EC2 von 95%. Dabei warb er um die Einhaltung der Prinzipien von CI/CD, Logging, Testing und der Verwendung von sinnvollem Monitoring, um die Time-To-Market zu reduzieren.

Das Rad sollte nicht neu erfunden werden. Derzeit gibt es unterschiedliche Deployment-Frameworks, mit jeweils eigenen Ausrichtungen. Eine kleine Auswahl (ohne Anspruch auf Vollständigkeit):

Umgekehrte Testpyramide

Jedes dieser Tools dient zum Upload eines Projekts in eine FaaS-Umgebung (nicht nur in AWS). Yan Cui zeigte exemplarisch, wie Unit- und Integrationstests umsetzbar sind (anhand von JavaScript) und empfahl der Verwendung der umgekehrten Testpyramide für schnelleres Feedback durch den Kunden. Die Erstellung eines Unit-Test sollte keine Probleme bereiten.

Der Integrationstest ist die Ausführung der Funktion inklusive abhängiger Dienste wie DynamoDB, Kinsis und Co. Die genutzten Dienste beinhalten dabei die Testdaten. Akzeptanztest unterscheiden sich von Integrationstests lediglich in der Art der Aufrufs. Ein Akzeptanztest kann beispielsweise über einen HTTP-Request durch das Amazon Gateway mittels Jenkins oder Gitlab-CI bewerkstelligt werden.

Yan Cui bemängelte, dass Logs in AWS CloudWatch nicht einfach zu durchsuchen sind, da diese separat gesammelt werden. Daher streamte er die Logs aller CloudWatch-Log-Gruppen mittels neuerlicher Lamdba-Funktion in einen ELK-Stack. Es ist also auch im Serverless-Umfeld möglich (und sinnvoll) einen ELK- oder EFK-Stack zu betreiben.

Fehlersuche

Ein Problem stellt die Fehlersuche in der Serverless-Architektur dar: Berichtet ein Kunde von einem Fehler, kann bei einem verteilten Prozess nicht immer auf eine konkrete Lambda-Funktion gezeigt werden, die sich fehlerhaft verhält. Beispielsweise kann es vorkommen, dass eine Lambda-Funktion mehrfach ausgeführt wird (Retry-Behaviour/Wiederholung im vermuteten Fehlerfall). In diesem Fall würde ein einziger fachlicher Durchlauf mehrere verteilte Ausführungen bewirken, was bei der Interpretation der Logs Schwierigkeiten bedeuten kann. Abhilfe schaffte Yan Cui durch Korrelations-IDs: Ein fachlicher Ablauf wird z.B. durch eine Request-ID oder User-ID über alle Funktionen hinweg identifiziert.

Für Monitoring und Analyse technischer Metriken untersuchte Cui ioPipe. Es erlaubt durch die Einbindung eines OpenSource-Moduls innerhalb von Sekunden, die übermittelten Telemetriedaten via Dashboard zu untersuchen. Allerdings verlängert es die Ausführungszeit der Lambda-Funktionen und damit werden natürlich die Kosten ein wenig erhöht. Ebenfalls erhöht sich die Latenz, bis dem Benutzer eine Antwort gesendet werden kann. Akzeptabel?

Amazon found every 100ms of latency cost them 1% in sales.
https://bit.ly/2EXPfbA

Dieser Aussage folgend entschied sich Yan Cui gegen ioPipe. Er sammelte seine Metriken mittels eigenem Log-Formaten in CloudWatch und konfiguriert dort entsprechend Alarme. Möglichst nativ zum AWS-Ökosystem, um die Ausführungszeiten gering zu halten. Gleichzeitig können Logs mit Metriken in Diensten wie Datadog visualisiert werden. Ein solcher Log hat z.B folgende Form:

console.log("MONITORING|1489795335|24.8|latency|user-api-latency")

Eine Entwicklung nach den Prinzipien einer 12-Faktoren-App empfiehlt, die Konfiguration möglichst durch Umgebungsvariablen zu definieren, um keine sensiblen Informationen in Anwendung bzw. Code selbst zu halten. Obgleich sich für Lambda-Funktionen Umgebungvariablen definieren lassen, ist Cui der Meinung, dass der Zugriff zu sensiblen Informationen dieser Art gesondert geregelt werden sollte. Grund dafür ist, dass die Umgebungvariablen in Lambda nur ruhend verschlüsselt sind. Er propagiert, dass diese auch bei der Übergabe verschlüsselt sein sollten z.B. unter Verwendung von Consul, etcd oder dem AWS SSM Parameter Store als zentrale rollenbasierte Konfigurationsverwaltung für alle Lambda-Funktionen.

Vorsichtig zustimmend

Die Frage war: Kann man größere Projekte mit AWS Lambda potenziell umsetzen. Ein eindeutiges Ja will ich dazu (noch) nicht geben, aber wir sind auf dem besten Weg dahin: Wir haben die Möglichkeit, unsere Anwendung ordentlich zu testen, CI/CD lässt sich umsetzen, und auch DevOps-Evangelisten sollten unter Verwendung von EFK/ELK hinsichtlich schnellem Feedback auf ihre Kosten kommen.

Cuis Ausführungen zeigen aber auch, dass man sich mit den AWS-Ökosystem arrangieren sollte, wenn man Kosten sparen will. Jede (fachlich) unnötige Aktion kann zu längeren Ausführungszeiten beitragen und damit zu höheren Kosten führen. Ob sich das lohnt, muss jeder selbst wissen.


Quellen

  1. https://www.crisp-research.com/serverless-infrastructure-der-schmale-grat-zwischen-einfachheit-und-kontrollverlust/
  2. https://www.slideshare.net/theburningmonk/serverless-in-production-an-experience-report-jeffconf-88207165

Neuen Kommentar schreiben

Public Comment form

  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3>

Plain text

  • Keine HTML-Tags erlaubt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

ME Landing Page Question

Erhalten Sie regelmäßig Praxis-Tipps per E-Mail

Praxis-Tipps per E-Mail erhalten