Tech Talk: "Serverless Applications with AWS Lambda" mit Thomas Jäger von Objectbay

Tech Talk: "Serverless Applications with AWS Lambda" mit Thomas Jäger von Objectbay

Ja, herzlich willkommen zu meinem Talk. Danke, dass ich ihn halten darf, über Serverless Applications mit AWS Lambda – in dem Fall sind wir jetzt in der Amazon Welt unterwegs.

Kurz zu mir: Ich bin der Thomas Jäger, bin Software Ingenieur bei der Objectbay Software GmbH. Kurz ein paar Keyfacts über uns: Mittlerweile schon mehr als 50 Mitarbeiter auf drei Standorte verteilt. Wir haben ein Standort in Wien, in Salzburg und unser Headquarter in Traun – also hier gleich ums Eck. Die Firma ist 2006 gegründet worden – gibt's also schon seit 15 Jahren, heißt, wir stammen eigentlich aus einer Zeit wo Softwareentwicklung, oder gerade Webentwicklung noch sehr Applikationsserver-lastig war. Alles war sehr träge, starr, monolithisch aufgebaut und wie jeder Informatiker eigentlich weiß, solche Frameworks ändern sich relativ schnell. Wir haben sehr viel Hypes mitmacht und natürlich genauso viel Hypes begleitet beim letzten Weg in die Bedeutungslosigkeit. Aber das weiß eh jeder Informatiker, dass man hier etwas flexibel unterwegs sein muss. Wir haben über 160 Projekte schon erfolgreich abgeschlossen. Das ist schon ganz schön große Nummer. Wir sind auch was unsere unsere Technologie Stacks betrifft halbwegs breit aufgestellt – anders würde es gar nicht gehen. Breit aufgestellt heißt aber auch man muss über den Tellerrand hinausschauen und sich mal mit Dinge beschäftigen, die jetzt vielleicht vom ersten Blick jetzt zwar vielversprechend aussehen aber auch teilweise komplex aussehen. Web, Mobile Anwendungen und Rich Client Apps machen wir. Wir decken sehr viel Branchen ab, egal ob das jetzt der Finanzsektor ist, da haben wir schon einige Projekte gemacht, Homeland Security – hört sich ganz toll an – Flug, Flughafen, Sicherungssoftware und solche Dinge, Logistikbranche, Telekommunikationsindustrie – da sind wir überall unterwegs und suchen Leute, Lead Junior Senior Mobile Entwickler also alles suchen wir eigentlich. Wir sind sehr breit aufgestellt, das hab ich schon gesagt. Serverless Thematik ist ja bei uns vor einigen Jahren recht aktuell geworden. Wir haben uns das relativ bald schon angeschaut.

Was heißt jetzt eigentlich Serverless in diesem Kontext: Serverless, das klingt eigentlich immer prinzipiell ganz toll. Ich muss mich um keine Server mehr kümmern. Das ist ja immer so in der Webentwicklung, diese Server im Hintergrund. Zumindest sind das Punkte aus Marketing Slides von diese großen Cloud-Anbietern, egal ob das jetzt Google Cloud ist oder AWS ist oder Azure – überall liest man diese Dinge. Ich brauche mich um keinen Server mehr kümmern. Ich muss nur das zahlen was ich wirklich brauche, ich habe keine Server, die vielleicht irgendwo in der Nacht laufen, die ich ja trotzdem in der Nacht zahlen muss, sondern man braucht nur dann zahlen wenn ich auch wirklich die Funktion nutzen will. Faster-time-to-market ist auch so ein Punkt den liest man oft. Da waren wir auch bisschen skeptisch, ob das wirklich so viel bringt. Auf das kommen wir noch hin und zurück. Und diese Skalierung ist jetzt eigentlich das, was uns Softwareentwickler eigentlich die meisten Sorgen bereitet, nämlich skaliert mir Anwendung auch? Oft bei Kunden Projekte weiß man nie so genau wie viele User es letztendlich nutzen – sind das jetzt 10, sind das 100 oder 1000 und womöglich schlägt das Produkt das man gerade entwickelt so ein, dass es eine Million gleichzeitig sind. Und wenn der Server oder Backend-Teil nicht mitskaliert und bringt einem das alles nichts. Und da versprechen sie, das skaliert bis in die Unendlichkeit. Das hört sich natürlich aus Softwareentwicklungssicht schon mal sehr interessant an. Thema wie Availability – 24 Stunden, das Icon sollte das ein bisschen suggerieren. Hätte ich eigentlich grundsätzlich auch bei Server, die ich betreibe 24/7. In dem Fall muss man ein bisschen anders denken. Availability heißt in dem Fall die Funktionen laufen grundsätzlich überhaupt nicht solange ich es nicht brauche. Und wenn ich es brauche ist es sofort da. Das heißt, es ist ein bisschen andere Art von Availability. Und better focus soll suggerieren ich kann mich mehr auf dem wesentlichen Business Case konzentrieren und habe das Rundherum nicht so wirklich. Muss keine Server programmieren, sondern ich kann wirklich das bauen/entwickeln was der Kunde letztendlich wirklich haben will. In dem Fall jetzt AWS Lambda – gibt's eigentlich schon jetzt lange, man kann jetzt nicht mehr sagen, dass das recht der Hype ist. Ist aber zu Beginn nicht so wirklich genutzt worden, weil das Pricing Modell seitens Amazon noch nicht so gestimmt hat, hat auch zu wenig Power gehabt zu Beginn, man hat auch nicht recht gewusst für was soll man das jetzt überhaupt einsetzen. Wie es halt so ist in der Softwareentwicklung, vieles ergibt sich dann über die Zeit. Kommt eigentlich aus dem Event Driven Computing. In Wahrheit kurz beschrieben: Code wird ausgeführt in response-to-events. Also irgendwas tritt auf und das AWS Lambda lauft dann los und macht mir dann mein Ding – hört sich einmal grundsätzlich interessant an. Basiert auf Amazon Linux AMI.

Amazon Maschine Image wird von Amazon supportet, was schon sehr interessant ist. Muss mich um diese Dinge nicht kümmern, um den Container und unterstützt auch Speicher mittlerweile von 128 MB bis 10 GB Memory, was ganz interessant ist und up to 6 vCPU quasi. Also die Dinge haben jetzt schon richtig Power.

Kurz zurück zu dem, wie nutzt man das eigentlich, der Use Case: irgendein Event tritt auf, das Lambda rennt los und ich kann mit andere Amazon Services Dinge austauschen, kann die anstarten, kann da interagieren mit Drittsystemen, die vielleicht selbst bei mir sogar laufen. Mit generell alles was ich mir irgendwo vorstellen kann. Und die Benefits sind ganz klar: Ich muss mich nicht mehr um viele Dinge kümmern, das ganze Load Balancing dahinter, des Autoscaling, es skaliert einfach mit, egal ob da jetzt 10 Benutzer gleichzeitig mit meiner Software arbeiten oder eine Millon – des skaliert einfach mit. Ich muss mir um das einfach keine Gedanken mehr machen. Error Handling ist dabei, die ganzen Security-Mechanismen. Ich kann genau definieren was darf das Lambda tun, was nicht. Log-Management, das ganze OS-Management ist genauso dabei. Das heißt das Betriebssystem was dahinter steckt, mit dem komme ich eigentlich gar nicht in Berührung. Was ja gut ist, weil ich will mich auf die Softwareentwicklung konzentrieren. Und Metriken gibts auch genug, die was ich automatisch mitkriege zu meinen Lambdas. Klingt einmal ganz gut.

Das sind dann so die Basis Execution-Models wie ich Lambdas verwenden kann. Irgendein Push kommt gegen meine Anwendung, gegen mein Lambda z.B. ein Post Call auf einen REST Endpoint und das Lambda läuft los. Fertig. Das ist so die klassische Art und Weise wie man so Lambda startet. Kann natürlich auch Event-basiert sein. Und zwar ich starte/emmitte irgendein Event, das kann jetzt wieder ein anderer Amazon Dienst wie der Notification Service sein oder Amazon S3 Storage kann das genauso sein, oder Kafka – irgendein Event auf meinem Event Bus tritt auf, mein Lambda reagiert darauf und startet sich. Also auch eigentlich von der Architektur ganz interessant. Oder auch so Poll-based Mechanismen. Auch wieder Amazon, das Wort habe ich jetzt schon sehr oft benutzt: Amazon. Dynamo DB oder Amazon Kinesis – so real time Transformationen kann ich damit machen. Selbst Veränderungen in der Datenbasis, selbst Veränderungen an einer Entität kann ich benutzen um ein Lambda zu starten. Also sehr viele verschiedene Möglichkeiten.

Damit ich dann wirklich darauf eingehen kann, was wir schon benutzt haben und welchen Mehrwert wir in der ganzen Geschichte sehen, nur einen kleinen, kurzen Ausflug in das Amazon API Gateway. Das ist so das Fenster, die Tür in die Welt nach außen. Sehr viele Amazon Funktionen, ob das jetzt Lambda ist oder Kinesis und so weiter – die müssen ja irgendwie nach außen kommunizieren können bzw. die Außenwelt mit unseren Back End Services. Und das ist quasi das jetzt Amazon API Gateway. Das ist dafür zuständig für das Erstellen, Veröffentlichen, Warten, Überwachen und auch Sichern von irgendwelchen APIs. Das können REST APIs sein, WebSockets und das brauche ich mal grundsätzlich damit ich die ganze Lambda-Funktionalität nutzen kann. Und das ist jetzt eigentlich genau das, was wir am meisten nutzen, nämlich Serverless Architektur im Web. Und zwar meine ganze Applikation, das da sollte der User sein ganz links der irgendeine REST-Anwendung oder Angular-Anwendung erwartet. Die Anwendungen selbst, da liegt eigentlich der ganze statische Content, egal ob das jetzt HTML ist, JavaScript ist CSS-Files sind, ob das Bilder sind – das liegt alles um Amazon S3 Storage drinnen, der ist quasi unlimitiert schnell abrufbar. Ich muss mich auch nicht um welche Skalierung kümmern, das liegt da drin, mein statischer Content und da wird dann normalerweise über ein CDN nach außen zur Verfügung gestellt. Das kann jetzt in der Amazon Cloud Front sein und Amazon Cloud Front stellt man einfach den Inhalt schnell zur Verfügung. Das heißt ich komme als User, wenn ich jetzt mein Handy offen habe, also auf meinem Smartphone die Anwendungen abrufe oder irgendwo mit meinem Laptop mit meiner Anwendung interagieren möchte, kriege sofort die Anwendung geserved. Und natürlich muss meine Anwendungen mit Back End Systemen, mit Datenbanken, mit anderen Services kommunizieren und dazu nutzt man das Amazon API Gateway. Und das Amazon API Gateway schieb die ganzen Calls eigentlich nur durch auf Lambda-Funktionen. Und diese Lambda-Funktionen können dann mit einer Datenbank usw. interagieren. Und das Ding skaliert bis theoretisch in die Unendlichkeit. Also egal ob da jetzt – also ich kann mir da fast keinen Traffic vorstellen den man mit dem nicht abdecken kann. Also da muss irgendein Amazon-Datencenter voll werden und das ist eher unrealistisch, damit ich das Ding quasi nicht erfolgreich ausführen kann.

Andere Architektur-Prinzipien wären solche Messaging Systeme – haben wir auch im Einsatz. Irgendwelche Daten werden irgendwohin gepusht. Irgendwer legt z.B. in einem CRM System einen neuen Kunden an, diese Kunden Applikation schiebt ein Event raus „Hey, der Kunde ist jetzt angelegt worden“. Mehrere Services gibt es, die hören auf dieses Event. Unter anderem auch unsere Lambda Funktion, die automatisch startet und dann den Kunden z.B. anlegt, gleich Environments provisioniert, irgendwelche Dinge für den Kunden einrichtet – also auch messagebasiert funktioniert das sehr gut. Und auch so storagebasierte Systeme funktionieren wirklich sehr gut und sind schon erprobt. Ich lade irgendweilche Files hoch – ein Fotograf, hunderte von Bildern, Videos und so weiter, landen in einem Amazon S3 Storage und nur das Uploaden und das erfolgreiche Ablegen dort kann schon als Event genutzt werden, damit Lambda-Funktionen loslaufen, die das Bild nehmen, von A nach B kopieren, Image-Transformationen machen, vergrößern, verkleinern – was auch immer. Also sehr viele Dinge kann man dann machen. Das ist so klassische Ansätze. Oder was man so kennt aus dieser herkömmlichen Server-Welt, irgendwelche Dinge die z.B. jeden Tag um 2 Uhr in der Früh passieren, so timebased-events. Da kann man Amazon Cloudwatch benutzen oder andere Dinge. Z.B. um 2 Uhr in der Früh das die Lambda-Funktion Logfiles zusammenräumt, um 2 Uhr in der Früh will ich dass die Lambda-Funktion irgendwie einen Report, einen Tagesreport erstellt. Also ich hab sehr viele Möglichkeiten und ich kann Cloudwatch nutzen für Anomaly Detection. Ich kann sagen einen Service – weil Cloudwatch ist da zum Überwachen und Beobachten von diversen Services – wenn der z.B. erkennt am Service der gerade läuft, dem geht es gerade schlecht – genau das Event kann ich dann benutzen um mit der Lambda-Funktion irgendwas zu reparieren. Grundsätzlich sehr viel Möglichkeiten.

So, da haben wir jetzt sehr viele Lambdas, Lambdas, Lambdas. Irgendwann wird das sehr chaotisch, ja da gebe ich recht – da sind wir auch draufgekommen. Zu viele von diesen Dingen, das macht es ein bisschen unübersichtlich. Darum gibt's Step Functions. Mit AWS Step Functions kann man z.B. wirklich Struktur reinbringen, das Ganze koordinieren. Man kann, z.B. das ist jetzt der Used Case, irgendjemand ladet ein Bild hoch und das erste was passiert ist, dass Lambda startet. In dem Fall Step Functions und in dem Fall das erste was gemacht wird Image Metadaten werden z.B. extrahiert. Basierend auf diesen Image Metadaten kann ich dann in einem weiteren Schritt festlegen, wenn das jetzt der PNG oder JPG ist dann mach dies: StoreImage oder SendImage – kann ich parallele Lambdas definieren, oder ich kann andere Sachen abrufen. Wenn es zum Beispiel kein PNG oder JPG ist, dann soll irgendein Fehler entstehen, NotSupportingImageType. Selbst auf das kann man reagieren, also auch dieses Error-Handling funktioniert ganz gut. Man kann komplexe States, States Machines abbilden und so schön visualisieren und anschaulich machen.

Jetzt stellt sich natürlich die Frage: Was kostet das jetzt alles? Ja, es kostet was aber es ist jetzt eigentlich gar nicht so viel. Man muss es sich mal anschauen. Und zwar, zwei Faktoren sind sehr wichtig. Einmal mal der Request. Also wieviele Requests brauche ich mal grundsätzlich, wie oft wird Lambda ausgeführt. Das ist einfach nur die Anzahl wie oft das Lambda getriggert wird. Und auch die Dauer. Also wie lang braucht mein Lambda. Das wird gemessen in Millisekunden, braucht es jetzt 30 Millisekunden für die Aufgabe oder 10 Sekunden. Das hat alles Einfluss auf das letztendlich wie teuer es wird.

Ich habe es hier noch kurz auf den Folien, eine Million Requests kosten 20 Cent. Hört sich jetzt einmal sehr günstig an und die Duration ist für jede Gigabytes-Sekunde. Das heißt gemessen wird, ich kann meinem Lambda gewisse Anzahl an Memory zur Verfügung stellen, hier unten habe ich ein Beispiel mit 512MB. Für jede Gigabit die ich brauche in der Sekunde zahle ich eine sehr kleine Zahl an Duration. Und ich hab auch einen Free Tier dabei. Ich kriege einmal grundsätzlich eine Milion Request gratis, was auch nicht schlecht ist. Wird für viele Anwendungen, für viele Use-Cases wahrscheinlich schon reichen. Und ich habe auch 400.000 GB pro Sekunde gratis dabei. Das heißt zum Starten hindert mich eigentlich mal überhaupt nix. Hab da mal grobes Beispiel, das ist 1:1 übernommen von Amazon Slides – wir schauen uns dann auch noch ein eigenes Beispiel an, ein Realworld-Beispiel – 512 MB Memory für mein Lambda. Das wird drei Millionen Mal im Monat aufgerufen. Drei Millionen mal irgendeine Task z.B. drei Millionen Bilder, die hochgeladen werden. Jeder Task dauert eine Sekunde, das heißt er kopiert es vielleicht von A nach B, kostet 19 Dollar. Also mal grundsätzlich günstig. Wenn ich genau das mit irgendeiner herkömmlichen Server Infrastruktur nachbauen will, schaffe ich es sicher nicht um diesen Preis.

Jetzt schauen wir uns noch so eine Real World Example an. Das ist jetzt wirklich aus einem Projekt. Wir haben eine Million Image Video Uploads – sehr viel Content ist das pro Monat in einem S3 Storage. Daraufhin werden 512 MB Lambdas Funktionen gestartet. Das heißt, egal ob jetzt ein Bild hochlade oder 100 gleichzeitig – dann laufen halt 100 Lambdas, theoretisch können auch 100.000 oder Millionen Lambdas gleichzeitig funktionieren. Und jeder hat im Schnitt ungefähr 5 Sekunden gebraucht, also doch relativ lang ist das Lambda gelaufen, weil das ja viele Dinge passieren und ich brauche auch dieses API Gateway dazu. Das ist jetzt auch wieder konfiguriert gewesen mit einer Million Requests ca. Also eine Million möchte ich hochladen, das heißt eine Million Requests brauch ich ca., damit ich diese Lambdas starten kann. Ergibt sich ein Preis von 38 Dollar im Monat. Da kann man ein bisschen was tweaken, da kann man sicher noch bisschen was rausholen. Das andere Beispiel auf der anderen Seite wäre jetzt genau dasselbe mit einer Spring Boot Anwendung, die ich irgendwo laufen hab. Das heißt, damit ich ausfallsicher bin, muss ich das ein paar Mal hinstellen: 2-, 3-, 4-, 5-mal. Um Lambdas muss ich mich nicht kümmern, da kann ich Millionen gleichzeitig starten. Ich brauche halt mehrere Instanzen, was mir schon mal grundsätzlich etwas kostet. Ich zahle es Tag und Nacht – da kann ich natürlich auch bisschen tweaken und sagen in der Nacht drehe ich es ab. Was ist aber wenn genau um 1 in der Nacht ein Fotograf etwas hochladen will – dann funktioniert das nicht. Bei Lambdas überhaupt kein Problem, das wird nur gestartet wenn ich es brauche. Das ist jetzt ein real world Beispiel – wir würden hier bei 117 – 120 Dollar sein. Also man sieht schon mal, wenn wir es noch größer skalieren würden, wenn das eine größere Anwendung ist die nicht nur Bilder hoch lädt – am linken Preis würde sich nicht viel ändern, rechts wird sich massiv etwas ändern weil ich eine andere Server-Infrastruktur brauche, weil ich stärkere Server brauche. Man muss sich auch vorstellen da hat jedes Lambda 512 MB an Memory. Auf der anderen Seite hat der gesamte Server 16 GB am RAM. Jetzt kann man sich ausrechnen, wenn da jemand 200 Bilder oder Videos gleichzeitig hochlädt, wird das nicht mehr so schnell sein wie links wo wirklich jeder seine 512 MB hat. Die kann man auch rauf auf 10 GB schieben, dann wird es halt wieder teurer.

Kurz nochmals zur ersten Folie – Conclusio: Give it a try, absolut ausprobieren! Gibt auch eine super Calculator von AWS wo man das bisschen durchspielen kann die Szenarien, was wird das wirklich kosten.

  • No Servers to manage – stimmt absolut, da können wir den Slides von den Cloud Anbietern glauben, das stimmt wirklich.
  • Pay what you need – haben wir gerade gesehen, also ich zahle wirklich nur das, was ich brauche, sonst gar nichts.
  • Faster time to market – da waren wir uns nicht ganz so sicher, schwer messbar erstens mal. Und ich muss mich ja trotzdem um die Lambda Struktur außen rum kümmern, ich muss mich um die Step Functions kümmern. Das würde ich mal nicht so unterschreiben, vielleicht auf lange Sicht schon.
  • Scales with Useage – absolut. Das skaliert, ich brauche mich um das nicht mehr kümmern, das ist für uns auch immer ein großer Pain Point gewesen.
  • Availability – ist schwer zu messen, Availability. Haben wir mit unserem Spring Boot Anwendungen auch nie großartig ein Problem gehabt, weil die ja immer gelaufen sind.
  • Better focus – ja natürlich kann man sich mehr auf die Business Cases konzentrieren und mehr aufs Entwickeln, aber richtig fokussierter jetzt an die Sache ranzugehen… ja, vielleicht muss man sich noch intensiver mit der Thematik auseinandersetzen und den Beobachtungszeitraum größer setzen, vielleicht fokussiert man sich wirklich besser letztendlich dann auf das Doing. Kann ich aber jetzt so auch nicht unterschreiben.

Ja. Dankeschön!

 

Technologien in diesem Artikel