Serverless, Development & Deployment – Serverless Framework?

08.11.2023•Tom Trapp
Tech Serverless Amazon Web Services Function as a Service Pay As You Go

banner.png

Serverless ist dir noch kein Begriff? Dann findest du hier alles Wissenswerte zum Thema Serverless.

Im dritten Teil der Serverless Development & Deployment Serie wagen wir den Sprung in die Open-Source Welt und schauen uns das Serverless Framework genauer an.

Nachdem wir nun zwei AWS-only Frameworks, namentlich das AWS Cloud Development Kit (CDK) und das AWS Serverless Application Model (SAM), kennengelernt haben, verlassen wir nun die heile AWS Welt! Das schöne, wir können nun endlich auch Serverless-Ressourcen bei anderen Cloud-Providern anlegen, da das Serverless Framework mehrere Cloud-Provider unterstützt, unter anderem die folgenden:

  • AWS
  • Azure
  • GCP
  • Knative
  • CloudFlare
  • Kubeless

Hinter dem Serverless Framework steckt eine sehr aktive Community, welche das Framework stetig weiterentwickelt und verbessert. Rechtlich gesehen steckt die Firma “Serverless” dahinter, welche ihren Sitz in San Francisco hat. Grundlegend besteht deren Offering aus zwei Produkten, welche wir hier genauer anschauen wollen.

Serverless Framework

Das Serverless Framework ist ein erstmals im Jahr 2015 veröffentlichtes Open-Source Framework, welches uns ermöglicht, Serverless Architekturen zu definieren und zu deployen.

Wie in den letzten TechUps schauen wir uns wieder ein Serverless Land Pattern genauer an, welches wir mit dem Serverless Framework deployen wollen.

Ziel: API Gateway REST API to Lambda Serverless Land Pattern: API Gateway REST API to Lambda IaC Tool: Serverless Framework Sprache: TypeScript Aws Services: API Gateway, Lambda

apigw-lambda-sls.png

Das Pattern deployed eine Lambda-Funktion, welche auf einen beliebigen Pfad gebunden ist und diesen in der Response zurückgibt. Das Pattern ist sehr einfach gehalten, aber es zeigt uns, wie wir mit dem Serverless Framework eine API Gateway REST API zu einer Lambda-Funktion aufbauen können.

Setup

Zuerst müssen wir via npm unsere serverless CLI installieren:

1

npm install -g serverless

Glücklicherweise ist auch hier kein Bootstrapping des Accounts des Cloud-Providers nötig, daher ist das Setup hiermit abgeschlossen!

Development

Wie im vorherigen Beispiel clonen wir das Repository (es kann auch das vorhandene genutzt werden) und wechseln in den korrekten Ordner:

1
2
3

git clone https://github.com/aws-samples/serverless-patterns/ 
cd serverless-patterns/apigw-lambda-sls
code .

Schauen wir uns nun das Projekt genauer an:

  • example-pattern.json: Dies ist eine Konfigurationsdatei für das Pattern im Serverless Land, sie hat nichts mit dem Serverless Framework zu tun.
  • package.json: Die klassische package.json, welche in jedem Node.js Projekt vorhanden sein sollte.
  • README.md: Die klassische Readme, welche in jedem Projekt vorhanden sein sollte, kann aber auch weggelassen werden.
  • serverless.yml: Der eigentliche Inhalt des Projekts, hier ist unsere Serverless Architektur definiert.
  • src: Der Source Code des Projekts, hier handelt es sich um ein TypeScript Projekt.
  • tsconfig.json: Die Konfigurationsdatei für TypeScript.

Das Herzstück des Projekts ist die serverless.yml Datei, welche wir uns nun genauer anschauen werden:

  • Zu Beginn definieren wir, wie unser Service heisst und welche Framework-Version wir nutzen wollen.
  • Anschliessend aktivieren wir ein Plugin, um TypeScript in einer Lambda-Funktion nutzen zu können.
  • Dann definieren wir, welche Provider wir nutzen wollen. In unserem Fall AWS.
  • Wir definieren die Runtime, die Architektur, Stage und Memory unserer Lambda-Funktion.
  • Zu guter Letzt legen wir uns eine Function namens logEvent an, welche wir über unterschiedliche Pfade über unseren API-Gateway aufrufen können.

Moment! Plugins?

Das Serverless Framework bietet eine Vielzahl an Plugins, welche wir in unserem Projekt nutzen können. Aktuell sind es über 350 Plugins, Funktionalität wie z.B. Offline-Testing, Webpack Integration, API Gateway Caching, REST Support etc. wird so einfach in unser Projekt integriert. Sehr cool! 🚀

Local Development

Zuerst einmal müssen wir mit npm unsere Dependencies installieren:

1

npm install

Anschliessend ist unser Projekt bereit fürs lokale Development. Mit folgendem Befehl können wir unsere Lambda-Funktion lokal aufrufen und ihr eine JSON-Payload übergeben:

1

serverless invoke local --function logEvent --data '{"a":"bar","path":"hello"}'

Und wir bekommen ein Ergebnis zurück! 🎉

Selbstverständlich muss hier angemerkt werden, dass es sich um eine sehr einfache Lambda-Funktion handelt, welche keinerlei Dependencies hat. Das Plugin serverless-dynamodb-local ermöglicht uns, eine lokale DynamoDB-Instanz zu starten, welche wir dann auch lokal nutzen können.

Neben dem serverless-dynamodb-local-Plugin gibt es auch andere, sehr wertvolle Plugins wie serverless-offline, welches uns ermöglicht, eine lokale API Gateway Instanz zu starten, welche wir dann auch lokal nutzen können.

Das Serverless Framework geht hier den gleichen Weg wie die anderen Frameworks und setzt ganz auf eine isolierte, lokale Entwicklungsumgebung, in der alles mocked bzw. lokal gestartet werden kann.

Deployment

Nachdem wir mittels npm install unsere Dependencies installiert haben, können wir unser Projekt deployen:

1

serverless deploy --region eu-central-1

Mit der Option region können wir die AWS Region angeben, in welcher wir unsere Serverless Architektur deployen wollen. Selbstverständlich hätten wir dies auch direkt in der serverless.yml Datei definieren können.

Im Output sehen wir, dass unser TypeScript-Projekt kompiliert wurde und die Serverless Ressourcen mittels CloudFormation als Stack angelegt wurden. Glücklicherweise bekommen wir auch hier unsere API Gateway URL zurück, welche wir uns als Environment-Variable abspeichern:

1
2
3

export APIGW_REST_ENDPOINT=https://<api-id>.execute-api.eu-central-1.amazonaws.com/prod

# z.B. export APIGW_REST_ENDPOINT=https://ossjouvvx9.execute-api.eu-central-1.amazonaws.com/prod

Und nun haben wir unsere Funktion erfolgreich deployed. Auffällig ist, dass kein Prompt kommt, um das Anlegen der Ressourcen zu akzeptieren (wie es bei SAM, CDK, Terraform der Fall ist).

Testing

Nun können wir unsere API Gateway URL nutzen, um unsere Lambda-Funktion aufzurufen:

1
2
3
4
5
6
7
8

curl $APIGW_REST_ENDPOINT
# Hello Serverless Citizen, your happy path is: "/"

curl $APIGW_REST_ENDPOINT/a/b
# Hello Serverless Citizen, your happy path is: "/a/b"

curl $APIGW_REST_ENDPOINT/hello-from-tom/1
# Hello Serverless Citizen, your happy path is: "/hello-from-tom/1"

Wir sehen, unsere Lambda-Funktion funktioniert wie erwartet. Nice! Sie ist auf einen beliebigen Pfad gebunden und gibt diesen in der Antwort zurück. Nun haben wir einen kompletten Development Workflow inkl. lokalem Testing, Deployment und Integrationstests durchgeführt. 🔥

Serverless Console

Ein weiteres nützliches Feature aus dem Hause Serverless neben ihrem Framework ist die Console. Diese bietet Live Tracing, Monitoring und Error Tracking für unsere Serverless Architektur.

Die Serverless Console selbst fungiert als SaaS und ist nicht Open-Source. Aktuell befindet sich die Console in einer Beta-Version und unterstützt nur AWS als Integration.

Ziel dieser (und generell jeder) Serverless Console ist es, dass Entwickler alle relevanten Informationen zu ihrer Serverless Architektur an einem Ort haben. Kein lästiges Zusammensuchen mehr von CloudWatch Events o.ä., die Console deployed einen CloudFormation Stack in den jeweiligen AWS Account und holt sich von da alle relevanten Daten, Logs und Informationen ab. Simpel!

sls_console_overview.png Quelle: https://www.serverless.com/blog/introducing-serverless-console

Leider gab es beim Deployment direkt Probleme, wir konnten den Stack nicht erfolgreich in unsere eu-central-1 Region deployen. Daher mussten wir unsere Anwendung kurzerhand nach North Virginia deployen, wo das Deployment der Serverless Console dann problemlos funktionierte. Dies haben wir mit folgenden Command gemacht:

1

serverless deploy --region us-east-1

sls_error_console.png

Ein sehr nützliches Feature der Serverless Console ist das Live-Streaming unserer Events, Logs usw. welches im Dev Mode genutzt werden kann. Dies ist speziell für Testing und Debugging sehr nützlich, da wir direkt in der Console sehen, was gerade passiert, schief läuft oder geloggt wird.

sls_console_live-streaming.png

Cleanup

Zum Schluss müssen wir unsere Serverless Architektur wieder löschen:

1
2

serverless remove --region eu-central-1
serverless remove --region us-east-1

TLDR

Das Open Source Serverless Framework ist ein Tool, mit dem wir Serverless-Architekturen in der Cloud deklarativ erstellen, verwalten und bereitstellen können. Hervorzuheben ist, dass das Serverless Framework nicht nur AWS unterstützt, sondern auch andere Cloud Provider wie Azure, Google Cloud, IBM Cloud, Cloudflare, Oracle Cloud etc. Aktuell gibt es auf dem Serverless Land genau 14 Patterns, welche vom Serverless Framework unterstützt werden. Die hohe Anzahl an Plugins, Lösungen, Blogs und generell Ressourcen zeugt von einer sehr aktiven Community, welche das Serverless Framework aktiv unterstützt.

Vorteile

  • Einfachheit: Das Serverless Framework bietet eine einfache und intuitive Syntax, um Cloud-Ressourcen zu definieren und zu konfigurieren.
  • Cloud-agnostisch: Es unterstützt mehrere Cloud-Anbieter, nicht nur AWS.
  • Vorlagen & Plugins: Es gibt eine große Gemeinschaft, die Plugins und Vorlagen bereitstellt, um die Funktionalität zu erweitern.
  • Automatisierung: Deployment-Prozesse können einfach automatisiert werden.
  • Entwicklungsumgebung: Bietet eine lokale Entwicklungsumgebung für das Testen von Funktionen.

Nachteile

  • Komplexität bei großem Umfang: Bei umfangreichen Anwendungen kann die Konfigurationsdatei komplex und schwer zu verwalten werden.
  • Abhängigkeit: Man bindet sich an ein weiteres Tool, was potenzielle zukünftige Änderungen oder Migrationsaufgaben erschweren kann.
  • Potenzielle Verzögerung: Es kann eine Lücke zwischen dem Erscheinungsdatum neuer Cloud-Funktionen und deren Unterstützung durch das Serverless Framework geben.
  • ServerlessLand: Leider gibt es auf dem ServerlessLand sehr wenig vordefinierte Patterns.
  • AWS-zentrisch: Das Serverless Framework ist sehr AWS-zentrisch, was sich auch in der Anzahl der Patterns, Plugins, Examples widerspiegelt.

CDK, SAM oder Serverless Framework?

Nachfolgend wollen wir eine kurze Gegenüberstellung der bisher bekannten IaC Tools für den Serverless Use Case machen.

  • AWS CDK: Imperativ, spricht Entwickler an, die eine leistungsstarke, programmierbare und AWS-spezifische Lösung bevorzugen.
  • AWS SAM: Deklarativ, ist ideal für jene, die eine spezialisierte und vereinfachte Lösung für Serverless AWS-Anwendungen wünschen.
  • Serverless Framework: Deklarativ, ist für Entwickler, die eine Cloud-unabhängige Lösung mit vielen Plugins und einer aktiven Gemeinschaft suchen.

Im nächsten TechUp lernen wir noch ein weiteres, sehr vielversprechendes imperatives IaC Tool für den Serverless Einsatz kennen, stay tuned! 😉

Tom Trapp

Tom Trapp – Problemlöser, Innovator, Sportler. Am liebsten feilt Tom den ganzen Tag an der moderner Software und legt viel Wert auf objektiv sauberen, leanen Code.