Die Serverless-Plattformen von AWS, Microsoft und Google

Sprachunterstützung

Da alle serverlosen Plattformen eine einzige Codefunktion ausführen, müssen die Cloud-Anbieter die spezifische Sprache und Version unterstützen, die Ihre Funktion benötigt. Sie können schließlich keinen Java-Interpreter verwenden, um Go auszuführen. Wenn Ihr Sprache Node 11 braucht, Ihre Umgebung aber Node 6 verwendet, können Sie auf einige Probleme stoßen. Das bedeutet also, dass Entwickler einen Anbieter wählen müssen, der ihre Programmiersprache unterstützt.

Azure Functions unterstützt eine Vielzahl von Sprachen und war der erste Service, der C# nativ verwendete. Es unterstützt auch Node.js, Java und Python. Außerdem ist eine ältere Version von Azure Functions verfügbar, die experimentellen Support für mehrere neue Sprachen bietet. Entwickler sollten diese Version aber nicht in Produktionsumgebungen verwenden.

Google Cloud Functions ist bezüglich der Sprachoptionen am eingeschränktesten. Es unterstützt nur Node.js, Python und Go. Darüber hinaus unterstützt Google Cloud Functions die Standardsprachen nur zögerlich. Es bietet derzeit nicht Node 10 an – im Gegensatz zu Azure Functions und AWS Lambda.

AWS Lambda unterstützt Node.js, Python, Java, Ruby, C#, Go und PowerShell nativ. Darüber hinaus gibt AWS Entwicklern inzwischen mehr Flexibilität, wenn es um benutzerdefinierte Laufzeiten geht. Entwickler können mittlerweile ihre eigenen Laufzeiten in die Plattform einbringen – womit fast jede Sprache unterstützt werden kann. Genau wie Amazon Machine Images (AMI) für EC2 können die benutzerdefinierten Laufzeiten von Lambda über Lambda-Ebenen veröffentlicht werden. Dies erlaubt es Open-Source-Communities, ihre eigenen Sprachen zu unterstützen und anzubieten. Auf diese Weise können Entwickler Node 11, C++ oder sogar Bash auf Lambda verwenden.

Entwickler können auch Lambda-Ebenen einsetzen, um andere häufig verwendete Pakete zu veröffentlichen, die nativ für Lambda-Funktionen erstellt werden müssen. Beispiele für Pakete sind Binärkompilierungen wie FFmpeg, SQLite oder Puppeteer.

Eine der kreativsten Anwendungen der Lambda-Ebenen ist IO Pipe, das serverlose Funktionen debuggt und verfolgt. IO Pipe hat seinen gesamten Monitoring Support über Ebenen freigegeben. Benutzer können damit ihre Funktion durch die Einbindung einer Lambda-Ebenen- oder AWS Serverless Application Model Konfigurationsdatei um Monitoring erweitern.

Integrationsmöglichkeiten

Ohne Integrationen unterscheidet sich eine Serverless-Plattform nicht von einem herkömmlichen Server. Stattdessen müssen serverlose Funktionen in Event-Systeme integriert werden, die Ihre Funktion auslösen, wenn etwas passiert. Die einfachste Art von Ereignis ist beispielsweise ein HTTP-Ereignis, das ausgelöst wird, wenn ein Benutzer eine bestimmte URL besucht.

In Azure Functions werden diese Integrationen als Bindings und Trigger bezeichnet. Alle Bindings und Trigger werden im Funktionscode bereitgestellt - einer function.json-Datei. Weitere Bindings und Trigger können hinzugefügt werden, indem die Datei aktualisiert und die Funktion erneut hochgeladen wird. Azure akzeptiert eine Vielzahl von Ereignissen, einschließlich Änderungen in fast jeder seiner Cloud-Datenbanken, sowie ein Cron-ähnliches System namens Timer-Trigger. Azure unterstützt auch Input und Output Bindings. Diese machen es einfacher, Aufgaben ohne sich wiederholenden Code auszuführen, wie zum Beispiel den Versand von Nachrichten über Twilio oder E-Mails über SendGrid.

In Google Cloud Functions rufen Entwickler Funktionen mit dem Firebase Framework auf. Möglich ist auch ein direkter HTTP-Aufruf. Darüber hinaus können Entwickler Cloud Functions basierend auf ihren Pub/Sub-Themen, Cloud Storage oder Stackdriver Logging aufrufen. Cloud Functions können nur einem bestimmten Anwendungsfall dienen, so dass jede Funktion nur eine Art von Aufruf auf einmal unterstützt. Aus diesem Grund sollten Entwickler, die Google Cloud Functions für mehrere Zwecke nutzen möchten, die Verwendung der Pub/Sub-Themenintegration in Betracht ziehen und dieses Thema immer dann auslösen, wenn die Funktion ausgeführt werden soll.

Im Gegensatz zu seinen Konkurrenten kann AWS Lambda mehrere Ereignisquellen zu einer einzigen Funktion hinzufügen. So können Entwickler den Entwicklungsprozess von den Integrationsquellen abkoppeln. Bei Bedarf können Entwickler neue Ereignisquellen hinzufügen, nachdem sie bereits eine Funktion bereitgestellt haben.

In einer Beispielanwendung verwenden wir etwa eine Funktion mit dem Namen indexRecordToAlgolia, die einen DynamoDB-Eintrag nimmt und ihn in der Algolia-Suchplattform indiziert. Diese Funktion hört DynamoDB-Streams ab, wenn neue Datensätze geschrieben oder aktualisiert werden, und konvertiert sie dann in das richtige Format, bevor sie in die Algolia eingefügt werden.

Man kann seine Funktionen sogar so einrichten, dass beim Aufnehmen neuer Elemente in DynamoDB eine zugehörige Lambda-Funktion benachrichtigt und dynamisch hinzugefügt werden kann. Auf diese Weise lassen sich Aktionen separat ausführen und die Entwickler müssen keinen Code ändern oder die Funktion erneut hochladen. Dies ist eine großartige Möglichkeit, die Implementierung eines Systems, das Datensätze, wie beispielsweise Benutzer, zusammenstellt, von einem anderen System zu entkoppeln, das diese Datensätze in eine Suchumgebung indiziert.

Lambda unterstützt über DynamoDB hinaus eine Vielzahl von Integrationen – darunter Kinesis, API Gateway und Amazon Simple Queue Service (SQS). Diese Integrationen können dazu führen, dass Entwickler weniger Bootstrapping-Code schreiben müssen und sich direkt mit der Geschäftslogik beschäftigen können. So können Entwickler zum Beispiel über das API-Gateway Lambda-Funktionen nicht nur über HTTP-Endpunkte, sondern auch über WebSocket-Endpunkte auslösen. Das API-Gateway übernimmt alle komplexen Übersetzungen und ruft Lambda-Funktionen auf, die keine der Implementierungsdetails kennen müssen.

Kosten vergleichen

Serverlose Plattformen sind dafür bekannt, dass sie preiswert und quasi kostenlos sind. Der Grund dafür ist, dass FaaS-Plattformen nur die tatsächliche Ausführung von Code berechnen und die Speicherung von Code nur wenig kostet. Allerdings gibt es Unterschiede in den Preismodellen der Anbieter.

Azure Functions hat die komplexeste Preisgestaltung. Azure rechnet pro Ausführung ab und berücksichtigt zudem die verbrauchte Speicherkapazität und die Zeit, die die Funktion benötigt. Daher muss man mit seiner Funktion keine Speicher- oder CPU-Anforderungen vorab bereitstellen. Allerdings ist jede Ausführung in Bezug auf die Kosten unvorhersehbar. Ähnlich wie Lambda berechnet Azure Functions einen minimalen Speicher und eine minimale Ausführungszeit von 128 MB und 100 ms. Azure Functions können maximal zehn Minuten pro Aufruf ausgeführt werden.

Google Cloud Functions berechnet auch Gebühren pro Ausführung und für die Ausführungszeit. Im Gegensatz zu Azure Functions erfordert Google Cloud Functions jedoch, dass man seine Funktion und Gebühren auf der Grundlage dieser zugewiesenen Ressourcen bereitstellen und nicht auf der Grundlage des tatsächlich verwendeten Speichers oder der CPU. Entwickler können aus fünf verschiedenen Funktionstypen wählen, wobei die Preise auf den entsprechenden CPU- und Speicherebenen basieren. Google Cloud Functions berechnet auch die Rechenzeit auf die nächsten 100 ms. Es gibt eine maximale Laufzeit für alle Google Cloud Functions von 540 Sekunden pro Aufruf.

AWS Lambda rechnet nicht pro Ausführung ab, sondern strikt pro 100 ms Ausführungszeit. Ähnlich wie bei Google Cloud Functions ermöglicht Lambda Entwicklern die Zuweisung von Speicher in Schritten von 128 MB bis maximal 3008 MB. Wie Google und Azure skaliert Lambda die CPU-Auslastung mit dem Speicher. Allerdings geht AWS Lambda mit diesen Werten nicht so frei um wie Google Cloud Functions oder Azure Functions. AWS weist die Benutzer an, die Menge an Speicher anzugeben, die sie für ihre Lambda-Funktion zuweisen möchten und die dann die CPU für sie zuweist. Lambda-Funktionen können maximal 15 Minuten pro Aufruf ausgeführt werden.