#aws #cloud #developer
13. Jul 2016 |
- min Lesezeit
Der Einstieg am ersten Tag gestaltete sich eher unspannend. Bei nicht wirklich neuen oder tiefschürfenden Informationen über die Datenpersistenz-Dienste S3, DynamoDB und Konsorten und darüber für welche Anwendungsfälle man was verwenden kann/soll etc., hatte man zunächst das Gefühl, auf einer reinen Sales-Veranstaltung zu sein. Aber es wurde wohl nicht ganz zu unrecht davon ausgegangen, dass ein Großteil des Publikums bisher keinen Kontakt mit den AWS-Produkten hatte.
Erfreulicherweise steigerte sich der Informationsgehalt bzw. die Anzahl an Aha-Momenten, je länger der Tag dauerte. Für richtige AWS-Cracks mit Sicherheit auch nichts komplett neues, bekam man ausreichend Einblicke in die mittlerweile doch gewaltige AWS-Produktpalette. Für jemanden wie mich durchaus spannend zu sehen, für wie viele verschiedene immer wiederkehrende Anwendungsfälle Amazon bereits fertige Dienste zur Verfügung stellt. Vorbei die Zeiten, als man sich EC2-Instanzen selbst provisionieren musste, um beispielsweise ElasticSearch an den Start zu bekommen. Natürlich konnten, ob der Kürze der Zeit, bei weitem nicht alle Produkte vorgestellt werden, aber zumindest habe ich aussreichend Inspiration mitbekommen, um mich wiedermal etwas gründlicher mit dem AWS-Portfolio auseinanderzusetzten.
Besonders interessant ist das Thema Serverless Architecture. In der Amazon Cloud lässt sich dieses Konzept beispielsweise über AWS Elastic Beanstalk oder AWS Lambda realisieren. Entscheidend hierbei ist, dass man sich dabei das gesamte Setup und Provisionieren von Compute-Instanzen sparen kann.
Im Falle von AWS Elastik Beanstalk lädt man vereinfacht ausgedrückt nur ein ZIP-Paket mit dem Application Code hoch und das Ding läuft prinzipiell. Im Normalfall wird wohl auch automatisch erkannt, um welche Sprache (oder sogar Framework) es sich handelt. Wenn nötig oder sinnvoll, wird man beispielsweise noch gefragt, welches Application Server-Paket (z.B. puma für eine Sinatra-App) man gerne nutzen möchte. AutoScaling lässt sich einfach hinzufügen und zu den Ansprüchen passend konfigurieren.
Deutlich weiter geht AWS Lambda.
Wo es bei Amazon Beanstalk noch Application-Container gibt, die hoch und runter gefahren und skaliert werden können, gibt es bei AWS Lambda nichts der gleichen. Es gibt nur noch einzelne Funktionen. Diese Funktionen werden Event gesteuert ausgeführt. Das ganze läuft dann auf irgendeiner verfügbaren Instanz in der für Lambda dediziert laufenden AWS-Linux Flotte.
Unterstützt werden aktuell die Programmierumgebungen Python, Java und Node.js. Ganz egal welche Umgebung einem besser liegt, man programmiert und deployt nur noch einzelne Funktionen. Man könnte auch Micro- oder je nach Umfang Nano-Services dazusagen. Der Applikationscharakter ergibt sich erst daraus, wie diese Funktionen zusammenarbeiten. Innerhalb der Lambda-Funktionen ist man prinzipiell vollkommen frei, welche anderen AWS- oder 3rd-Party-Dienste man integrieren möchte.
Als Events können Nachrichten auf Message-Queues (SQS), Ereignisse auf Daten-Pipelines (Kinesis) oder zum Beispiel einfache Schreibzugriffe auf ein S3-Buckets oder einer DynamoDB sein. Eine Lambda-Funktion kann auch direkt andere Lambda-Funktionen triggern. Aber auch klassische HTTP-Requests können als Event-Auslöser dienen. Dazu muss man lediglich das Amazon API Gateway entsprechend konfigurieren. Und so lassen sich RESTful-API-Services bauen - komplett ohne Server/Infrastruktur-Setup!
Besonders spannend ist auch das Preismodell. Man zahlt lediglich für die Laufzeit multipliziert mit der zur jeweiligen Lambda-Funktion konfigurierten Speicherallokation. Dabei ist das kostenlose Kontingent durchaus großzügig bemessen. Und auch wenn man in den kostenpflichtigen Bereich kommt, ist AWS Lambda eine kosteneffiziente Lösung. Man darf aber natürlich nicht die etwaige Kosten für weitere (AWS-)Dienste vergessen.
Um die Kosteneffizienz zu verdeutlichen wurde das Projekt zur Hymne UEFA-Euro 2016 vorgestellt. Der Künstler wollte (und hat schlussendlich) die Gesänge von 1 Million Fans in den Song integrieren. Dafür wurde eine kleine Webapplikation entwickelt. Abgesehen von so Standardthemen wie Login, Facebook-Integration etc. bestand die Hauptanwendung daraus, dass Nutzer sich den aktuellen Stand des Songs anhören, ihren eigenen Audiotrack aufnehmen und hochladen konnten. Nach dem Hochladen wurde ihr Gesang direkt zum Song hinzugemischt und war in der neuen Version wieder direkt anhörbar. Nach Traffic-Abschätzung durch UEFA etc. wurde geschätzt, dass die Kosten für die Infrastruktur mit klassischen AWS-Mitteln (EC2 etc.) für 3 Monate Laufzeit ungefähr $12.000 kosten würde. In der Tat wurde die gesamte Applikation mit AWS-Lambda-Funktionen umgesetzt. Insbesondere also auch die rechenintensiven (Audiocompositing…) Bereiche. Tatsächlicher Kostenpunkt für Amazon-Infrastruktur mit AWS Lambda nach den 3 Monaten: $9! Und nein…ich habe keine Zehnerpotenzen vergessen. Also ziemlich beeindruckend.
Nach etwas müdem Start hat sich die Veranstaltung auf jeden Fall gelohnt. Ich habe sehr viel Inspiration und Motivation aufgetankt, mich mit den AWS-Produkten intensiv auseinanderzusetzen. Ich bin mir sicher, wir finden viele spannende Anwendungsfälle bei unseren Kundenprojekten und insbesondere auch bei unseren eigenen Produkten, um mit Hilfe von AmazonWebServices noch mehr herausholen zu können.
Weiter zu Teil 2: AWS IoT Hackathon.