Programmierung von AWS Lambda

Kapitel 1. Einführung in Serverless, Amazon Web Services und AWS Lambda

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Um deine serverlose Reise zu beginnen, nehmen wir dich mit auf eine kurze Tour durch die Cloud und definieren Serverless. Danach tauchen wir in die Amazon Web Services (AWS) ein - das wird für einige von euch neu sein und für andere eine Auffrischung.

Nach diesen Grundlagen stellen wir dir Lambda vor - was es ist, warum du es verwenden solltest, was du mit Lambda bauen kannst und wie Java und Lambda zusammenarbeiten.

Eine kurze Geschichtsstunde

Lass uns auf in das Jahr 2006 zurückreisen. Damals hatte noch niemand ein iPhone, Ruby on Rails war eine heiße neue Programmierumgebung und Twitter wurde gerade eingeführt. Viel wichtiger für uns ist jedoch, dass zu diesem Zeitpunkt viele Leute ihre serverseitigen Anwendungen auf physischen Servern hosten, die sie besitzen und in einem Rechenzentrum untergebracht haben.

Im August 2006 geschah etwas, das dieses Modell grundlegend verändern sollte. Amazons neue IT-Abteilung, AWS, kündigte die Einführung der Elastic Compute Cloud (EC2) an.

EC2 war eines der ersten Infrastructure-as-a-Service (IaaS) Produkte. IaaS ermöglicht es Unternehmen, Rechenkapazitäten zu mieten, d. h. einen Host, auf dem ihre Serveranwendungen für das Internet laufen, anstatt eigene Maschinen zu kaufen. Außerdem können sie Hosts "just in time" bereitstellen, d.h. die Zeitspanne zwischen der Anforderung eines Rechners und seiner Verfügbarkeit liegt in der Größenordnung von Minuten. 2006 war dies alles dank der Fortschritte in der Virtualisierungstechnologie möglich - alle EC2-Hosts waren zu dieser Zeit virtuelle Maschinen.

Die fünf wichtigsten Vorteile von EC2 sind:

Geringere Arbeitskosten

Bevor es IaaS gab, mussten Unternehmen spezielle technische Mitarbeiter einstellen, die in Rechenzentren arbeiteten und ihre physischen Server verwalteten. Das bedeutete alles, von der Stromversorgung und Vernetzung über die Aufstellung und Installation bis hin zur Behebung physischer Probleme mit den Rechnern, wie z. B. defektem Arbeitsspeicher, und der Einrichtung des Betriebssystems (OS). Bei IaaS fällt all das weg und wird stattdessen vom IaaS-Dienstleister (AWS im Fall von EC2) übernommen.

Geringeres Risiko

Wenn Unternehmen ihre eigenen physischen Server verwalten, sind sie Problemen ausgesetzt, die durch ungeplante Vorfälle wie fehlschlagende Hardware verursacht werden. Dies führt zu Ausfallzeiten von sehr unbeständiger Länge, da Hardwareprobleme in der Regel selten auftreten und es lange dauern kann, sie zu beheben. Mit IaaS muss der Kunde im Falle eines Hardwareausfalls zwar immer noch etwas arbeiten, aber er muss nicht mehr wissen, was er tun muss, um die Hardware zu reparieren. Stattdessen kann der Kunde einfach einen neuen Rechner anfordern, der innerhalb weniger Minuten zur Verfügung steht, und die Anwendung neu installieren, was die Anfälligkeit für solche Probleme verringert.

Geringere Infrastrukturkosten

In vielen Szenarien sind die Kosten für eine angeschlossene EC2-Instanz günstiger als der Betrieb eigener Hardware, wenn du Strom, Netzwerk usw. berücksichtigst. Das gilt vor allem dann, wenn du Hosts nur für ein paar Tage oder Wochen betreiben willst, statt für viele Monate oder Jahre am Stück. Wenn du Hosts stundenweise mietest, anstatt sie direkt zu kaufen, kannst du auch anders abrechnen: EC2-Maschinen sind Betriebsausgaben (Opex) und keine Investitionsausgaben (Capex) wie physische Maschinen, was in der Regel eine viel günstigere Buchhaltung ermöglicht.

Skalierung

Die Infrastrukturkosten sinken erheblich, wenn man die Skalierungsvorteile von IaaS bedenkt. Mit IaaS können Unternehmen die Anzahl und die Art der betriebenen Server viel flexibler skalieren. Es ist nicht mehr nötig, 10 High-End-Server im Voraus zu kaufen, weil man glaubt, dass man sie in ein paar Monaten brauchen könnte. Stattdessen kannst du mit ein oder zwei kostengünstigen virtuellen Maschinen (VMs) mit geringer Leistung beginnen und dann die Anzahl und Art der VMs im Laufe der Zeit ohne negative Auswirkungen auf die Kosten erhöhen oder verringern.

Vorlaufzeit

In den schlechten alten Zeiten der selbst gehosteten Server konnte es Monate dauern, einen Server für eine neue Anwendung zu beschaffen und bereitzustellen. Wenn du eine Idee hattest, die du innerhalb von ein paar Wochen ausprobieren wolltest, war das einfach zu schade. Mit IaaS sinkt die Vorlaufzeit von Monaten auf Minuten. Damit ist das Zeitalter der schnellen Produktexperimente eingeläutet, wie es die Ideen von Lean Startup nahelegen.

Die Wolke wächst

IaaS war eines der ersten Schlüsselelemente der Cloud, zusammen mit der Speicherung (z.B. AWS Simple Storage Service (S3)). AWS war einer der ersten Anbieter von Cloud-Diensten und ist auch heute noch führend, aber es gibt auch viele andere Cloud-Anbieter wie Microsoft und Google.

Die nächste Entwicklung der Cloud war Platform as a Service (PaaS). Einer der beliebtesten PaaS-Anbieter ist Heroku. PaaS setzt auf IaaS auf und abstrahiert die Verwaltung des Betriebssystems des Hosts. Bei PaaS stellst du nur Anwendungen bereit, und die Plattform ist für die Installation des Betriebssystems, Patch-Upgrades, die Überwachung des Systems, die Erkennung von Diensten usw. zuständig.

Eine Alternative zur Nutzung eines PaaS ist die Verwendung von Containern.Docker ist in den letzten Jahren unglaublich populär geworden, da es eine Möglichkeit darstellt, die Systemanforderungen einer Anwendung klarer vom Betriebssystem selbst abzugrenzen. Es gibt Cloud-basierte Dienste, die Container für ein Team hosten und verwalten bzw. orchestrieren. Diese werden oft als Container-as-a-Service (CaaS)-Produkte bezeichnet. Amazon, Google und Microsoft bieten allesamt CaaS-Plattformen an. Die Verwaltung von Flotten von Docker-Containern wurde durch den Einsatz von Tools wieKubernetes erleichtert, entweder in selbstverwalteter Form oder als Teil eines CaaS (z. B. GKE von Google, EKS von Amazon oder AKS von Microsoft).

Alle drei dieser Ideen - IaaS, PaaS und CaaS - können unter dem Begriff "Compute as a Service" zusammengefasst werden; mit anderen Worten, es handelt sich um verschiedene Arten von allgemeinen Umgebungen, in denen wir unsere eigene spezialisierte Software ausführen können. PaaS und CasS unterscheiden sich von IaaS dadurch, dass sie die Abstraktionsebene weiter erhöhen und es uns ermöglichen, mehr von unserer "schweren Arbeit" an andere abzugeben.

Serverless eingeben

Serverless ist die nächste Evolution des Cloud Computing und kann in zwei Ideen unterteilt werden: Backend as a Service und Functions as a Service.

Backend as a Service

Backend as a Service (BaaS) ermöglicht es uns, serverseitige Komponenten, die wir selbst programmieren und/oder verwalten, durch Dienste von der Stange zu ersetzen. Vom Konzept her ist es näher an Software as a Service (SaaS) als an Dingen wie virtuellen Instanzen und Containern. Bei SaaS geht es jedoch in der Regel darum, Geschäftsprozesse auszulagern - z. B. Personal- oder Vertriebstools oder technische Produkte wie GitHub -, während wir bei BaaS unsere Anwendungen in kleinere Teile zerlegen und einige dieser Teile vollständig mit extern gehosteten Produkten implementieren.

BaaS-Dienste sind domänenübergreifende Remote-Komponenten (d. h. keine prozessinternen Bibliotheken), die wir in unsere Produkte einbinden können, wobei eine Anwendungsprogrammierschnittstelle (API) ein typisches Integrationsparadigma ist.

BaaS ist vor allem bei Teams beliebt, die mobile Apps oder Single-Page-Web-Apps entwickeln. Viele dieser Teams sind in der Lage, sich in erheblichem Maße auf Dienste von Drittanbietern zu verlassen, um Aufgaben zu erledigen, die sie sonst selbst hätten erledigen müssen. Schauen wir uns ein paar Beispiele an.

Zunächst gibt es Dienste wie Firebase von Google. Firebase ist ein Datenbankprodukt, das vollständig von einem Anbieter (in diesem Fall Google) verwaltet wird und auf das direkt von einer mobilen oder Webanwendung aus zugegriffen werden kann, ohne dass wir einen eigenen Anwendungsserver dazwischenschalten müssen. Dies ist ein Aspekt von BaaS: Dienste, die Datenkomponenten in unserem Namen verwalten.

BaaS-Dienste ermöglichen es uns auch, uns auf Anwendungslogik zu verlassen, die jemand anderes implementiert hat. Ein gutes Beispiel hierfür ist die Authentifizierung - viele Anwendungen implementieren ihren eigenen Code, um die Anmeldung, das Login, die Passwortverwaltung usw. durchzuführen, aber meistens ist dieser Code in vielen Anwendungen ähnlich. Solche Wiederholungen über Teams und Unternehmen hinweg sind reif für die Auslagerung in einen externen Dienst, und genau das ist das Ziel von Produkten wie Auth0 und AmazonsCognito. Beide Produkte ermöglichen es, dass mobile Apps und Webanwendungen über eine umfassende Authentifizierung und Benutzerverwaltung verfügen, ohne dass ein Entwicklungsteam den Code zur Implementierung dieser Funktionen schreiben oder verwalten muss.

Der Begriff BaaS ( ) wurde mit dem Aufschwung der mobilen Anwendungsentwicklung bekannt; manchmal wird er auch als Mobile Backend as a Service (MBaaS) bezeichnet. Der Grundgedanke, vollständig extern verwaltete Produkte als Teil unserer Anwendungsentwicklung zu nutzen, ist jedoch nicht nur auf die mobile Entwicklung oder die Frontend-Entwicklung im Allgemeinen beschränkt.

Funktionen als Dienstleistung

Die andere Hälfte von Serverless ist Functions as a Service (FaaS). FaaS ist wie IaaS, PaaS und CaaS eine weitere Form von Compute as a Service - eine generische Umgebung, in der wir unsere eigene Software ausführen können. Einige Leute auf verwenden gerne den Begriff Serverless Compute anstelle von FaaS.

Bei FaaS stellen wir unseren Code als unabhängige Funktionen oder Operationen bereit und konfigurieren diese Funktionen so, dass sie aufgerufen oder ausgelöst werden, wenn ein bestimmtes Ereignis oder eine Anfrage innerhalb der FaaS-Plattform eintritt. Die Plattform selbst ruft unsere Funktionen auf, indem sie für jedes Ereigniseine eigene Umgebung instanziiert . DieseUmgebung besteht aus einer ephemeren, vollständig verwalteten, leichtgewichtigen virtuellen Maschine oder einem Container, der FaaS-Laufzeitumgebung und unserem Code.

Das Ergebnis dieser Art von Umgebung ist, dass wir uns im Gegensatz zu allen anderen Rechenplattformen keine Gedanken über die Laufzeitverwaltung unseres Codes machen müssen.

Außerdem müssen wir uns bei FaaS aufgrund verschiedener Faktoren, die wir gleich beschreiben werden, nicht um Hosts oder Prozesse kümmern, und die Skalierung und das Ressourcenmanagement werden in unserem Namen durchgeführt.

Serverlos differenzieren

Die Idee von, extern gehostete Anwendungskomponenten zu nutzen, wie wir es bei BaaS tun, ist nicht neu - die Menschen nutzen gehostete SQL-Datenbanken schon seit einem Jahrzehnt oder länger - was also macht einige dieser Dienste zu Backends als Service? Und welche Aspekte haben BaaS und FaaS gemeinsam, die uns dazu veranlassen, sie unter dem Begriff Serverless Computing zusammenzufassen?

Es gibt fünf Schlüsselkriterien, die serverlose Dienste - sowohl BaaS als auch FaaS - voneinander unterscheiden und die es uns ermöglichen, die Architektur von Anwendungen auf eine neue Art und Weise anzugehen. Diese Kriterien lauten wie folgt:

Erfordert keine Verwaltung eines langlebigen Hosts oder einer Anwendungsinstanz

Das ist der Kern von Serverless. Bei den meisten anderen Arten, serverseitige Software zu betreiben, müssen wir eine Instanz einer Anwendung bereitstellen, ausführen und überwachen (unabhängig davon, ob sie von uns oder anderen programmiert wurde), und die Lebensdauer dieser Anwendung erstreckt sich über mehr als eine Anfrage. Serverless bedeutet das Gegenteil: Es gibt keinen langlebigen Serverprozess oder Serverhost, den wir verwalten müssen. Das soll nicht heißen, dass es diese Server nicht gibt - das tun sie auf jeden Fall -, aber sie sind nicht unsere Sorge oder Verantwortung.

Automatische Skalierung und automatische Bereitstellung, abhängig von der Last

Auto-Skalierung ist die Fähigkeit eines Systems, die Kapazitätsanforderungen dynamisch an die Last anzupassen. Die meisten bestehenden Auto-Skalierungslösungen erfordern ein gewisses Maß an Arbeit für das nutzende Team. Serverlose Dienste skalieren sich von der ersten Nutzung an selbst, ohne dass du etwas dafür tun musst.

Serverlose Dienste stellen auch automatisch Ressourcen zur Verfügung, wenn sie eine automatische Skalierung durchführen. Damit entfällt der gesamte Aufwand für die Zuweisung von Kapazitäten, sowohl in Bezug auf die Anzahl als auch die Größe der zugrunde liegenden Ressourcen. Das ist eine große Erleichterung für den Betrieb.

Hat Kosten, die auf der genauen Nutzung basieren, von und bis hin zu Nullnutzung

Dies hängt eng mit dem vorhergehenden Punkt zusammen - die Kosten für serverlose Dienste sind genau mit der Nutzung korreliert. Die Kosten für die Nutzung einer BaaS-Datenbank beispielsweise sollten eng mit der Nutzung verknüpft sein, nicht mit einer vordefinierten Kapazität. Die Kosten sollten sich weitgehend aus der tatsächlich genutzten Speicherung und/oder den Anfragen ergeben.

Wir sagen nicht, dass sich die Kosten ausschließlich nach der Nutzung richten sollten - es können auch einige Gemeinkosten für die Nutzung des Dienstes im Allgemeinen anfallen - aber der Löwenanteil der Kosten sollte proportional zur feinkörnigen Nutzung sein.

Die Leistungsfähigkeit wird nicht nur durch die Größe/Anzahl der Hosts bestimmt.

Es ist sinnvoll und nützlich, dass eine serverlose Plattform eine Leistungskonfiguration offenlegt. Diese Konfiguration sollte jedoch vollständig von den zugrunde liegenden Instanz- oder Hosttypen abstrahiert werden.

Hat implizite Hochverfügbarkeit

Auf verwenden wir den Begriff Hochverfügbarkeit (HA) in der Regel so, dass ein Dienst auch dann noch Anfragen bearbeitet, wenn eine zugrunde liegende Komponente fehlschlägt. Bei einem serverlosen Dienst erwarten wir vom Anbieter, dass er HA transparent für uns bereitstellt.

Wenn wir zum Beispiel eine BaaS-Datenbank nutzen, gehen wir davon aus, dass der Anbieter alles Notwendige tut, um den Ausfall einzelner Hosts oder interner Komponenten zu bewältigen.

Was ist AWS?

Wir haben in diesem Kapitel schon ein paar Mal über AWS gesprochen, und jetzt ist es an der Zeit, diesen Giganten unter den Cloud-Providern etwas genauer zu betrachten.

Seit dem Start im Jahr 2006 ist AWS rasant gewachsen, was die Anzahl und Art der angebotenen Dienste, die Kapazität der AWS-Cloud und die Anzahl der Unternehmen, die sie nutzen, angeht. Sehen wir uns all diese Aspekte an.

Arten von Dienstleistungen

AWS bietet mehr als hundert verschiedene Dienste an. Einige davon sind relativ einfach - Netzwerke, virtuelle Maschinen, einfache Blockspeicherung. Über diesen Diensten stehen abstrakt die Komponentendienste - Datenbanken, Platforms as a Service, Message Busses. Darüber kommen dann die echten Anwendungskomponenten - Benutzerverwaltung, maschinelles Lernen, Datenanalyse.

An der Seite dieses Stacks befinden sich die Verwaltungsdienste, die für die Arbeit mit AWS im großen Maßstab erforderlich sind - Sicherheit, Kostenberichte, Bereitstellung, Überwachung usw.

Diese Kombination von Diensten ist in Abbildung 1-1 dargestellt.

Abbildung 1-1. AWS-Service-Ebenen

AWS wird gerne als ultimativer IT-"Legostein"-Anbieter angepriesen - es bietet eine riesige Anzahl von steckbaren Ressourcentypen, die zusammengefügt werden können, um riesige, massiv skalierbare Unternehmensanwendungen zu erstellen.

Kapazität

AWS beherbergt seine Computer in mehr als 60 Rechenzentren auf der ganzen Welt, wie inAbbildung 1-2 dargestellt. In der AWS-Terminologie entspricht jedes Rechenzentrum einer Availability Zone (AZ), und nahe beieinander liegende Cluster von Rechenzentren werden zu Regionen zusammengefasst. AWS hat mehr als 20 verschiedene Regionen, die sich über 5 Kontinente verteilen.

Das sind eine Menge Computer.

Während die Gesamtzahl der Regionen weiter wächst, steigt auch die Kapazität innerhalb jeder Region. Eine große Anzahl US-amerikanischer Internetunternehmen betreibt ihre Systeme in der Region us-east-1 in Nord-Virginia (vor den Toren von Washington DC) - und je mehr Unternehmen ihre Systeme dort betreiben, desto zuversichtlicher kann AWS die Anzahl der verfügbaren Server erhöhen. Dies ist ein positiver Kreislauf zwischen Amazon und seinen Kunden.

Abbildung 1-2. AWS-Regionen (Quelle: AWS)

Wenn du einige von Amazons niedrigeren Services wie EC2 nutzt, gibst du normalerweise eine Availability Zone an, die verwendet werden soll. Bei den höherwertigen Diensten gibst du in der Regel nur eine Region an, und Amazon kümmert sich um alle Probleme auf Ebene der einzelnen Rechenzentren.

Ein überzeugender Aspekt von Amazons Regionsmodell ist, dass jede Region logistisch und in Bezug auf die Softwareverwaltung weitgehend unabhängig ist. Das heißt, wenn in einer Region ein physisches Problem wie ein Stromausfall oder ein Softwareproblem wie ein Fehler bei der Bereitstellung auftritt, sind die anderen Regionen fast sicher nicht betroffen. Das Regionsmodell bedeutet für uns als Nutzer/innen zwar einen gewissen Mehraufwand, aber insgesamt funktioniert es gut.

Wer nutzt AWS?

AWS hat eine große Anzahl von Kunden, die über den ganzen Planeten verteilt sind. Große Unternehmen, Regierungen, Start-ups, Einzelpersonen und alle dazwischen nutzen AWS. Viele der Internetdienste, die du nutzt, werden wahrscheinlich bei AWS gehostet.

AWS ist nicht nur für Websites geeignet. Viele Unternehmen haben einen großen Teil ihrer "Backend"-IT-Infrastruktur zu AWS verlagert, weil sie es für attraktiver halten als ihre eigene physische Infrastruktur zu betreiben.

AWS hat natürlich keine Monopolstellung. Google und Microsoft sind ihre größten Konkurrenten, zumindest in der englischsprachigen Welt, während Alibaba Cloud mit ihnen auf dem wachsenden chinesischen Markt konkurriert. Und es gibt viele andere Cloud-Provider, die für bestimmte Kundengruppen geeignete Dienste anbieten.

Wie nutzt du AWS?

Deine erste Interaktion mit AWS wird wahrscheinlich über die AWS Web Console erfolgen. Dafür brauchst du eine Art Zugangsberechtigung, die dir Rechte innerhalb eines Kontos gibt. Ein Konto ist ein Konstrukt, das mit der Rechnungsstellung zusammenhängt (d.h. du bezahlst AWS für die von dir genutzten Services), aber es ist auch eine Gruppierung von definierten Servicekonfigurationen innerhalb von AWS. In der Regel betreiben Unternehmen eine Reihe von Produktionsanwendungen in einem Account. (Konten können auch Unterkonten haben, aber darauf gehen wir in diesem Buch nicht näher ein - du solltest nur wissen, dass die Zugangsdaten, die du von einem Unternehmen erhältst, für ein bestimmtes Unterkonto gelten).

Wenn du keine Zugangsdaten von deinem Unternehmen erhalten hast, musst du ein Konto erstellen. Dazu musst du AWS deine Kreditkartendaten mitteilen. AWS bietet jedoch ein großzügiges kostenloses Angebot an, und wenn du dich an die grundlegenden Übungen in diesem Buch hältst, solltest du am Ende nichts an AWS zahlen müssen.

Deine Anmeldedaten können in Form eines normalen Benutzernamens und eines Passworts vorliegen oder über einen SSO-Workflow (z. B. über Google Apps oder Microsoft Active Directory). In jedem Fall wirst du dich am Ende erfolgreich bei der Webkonsole anmelden. Wenn du die Webkonsole zum ersten Mal verwendest, kann das eine beängstigende Erfahrung sein, denn alle 100+ AWS-Dienste wollen deine Aufmerksamkeit - Amazon Polly schreit "PICK ME!!!" genauso wie ein seltsames Ding namens Macie. Und was ist mit all den Diensten, die nur unter einem Akronym bekannt sind - was sind sie?

Die Startseite der AWS-Konsole ist unter anderem deshalb so überwältigend, weil sie nicht als ein Produkt entwickelt wurde, sondern als hundert verschiedene Produkte, die alle einen Link auf der Startseite haben. Außerdem kann ein Produkt ganz anders aussehen als ein anderes, weil jedes Produkt innerhalb des AWS-Universums ein hohes Maß an Autonomie genießt. Manchmal fühlt sich die Nutzung von AWS wie eine Höhlenwanderung durch die AWS-Unternehmensorganisation an - keine Sorge, das geht uns allen so.

Neben der Webkonsole ist die andere Möglichkeit, mit AWS zu interagieren, die umfangreiche API. Ein großartiger Aspekt, den Amazon schon sehr früh in seiner Geschichte hatte, sogar noch vor den Zeiten von AWS, ist, dass jeder Service über eine öffentliche API vollständig nutzbar sein muss. Das bedeutet, dass im Grunde alles, was in AWS konfiguriert werden kann, über die API möglich ist.

Über der API liegt die CLI, die Befehlszeilenschnittstelle, die wir in diesem Buch verwenden. Die CLI lässt sich am einfachsten als eine Thin-Client-Anwendung beschreiben, die mit der AWS-API kommuniziert. Über die Konfiguration der CLI sprechen wir im nächsten Kapitel ("AWS Command Line Interface").

Was ist AWS Lambda?

Lambda ist die FaaS-Plattform von Amazon. Wir haben FaaS bereits kurz erwähnt, aber jetzt ist es an der Zeit, sie etwas genauer zu betrachten.

Funktionen als Dienstleistung

Wie wir bereits auf vorgestellt haben, ist FaaS eine neue Art, serverseitige Software zu entwickeln und bereitzustellen, die auf die Bereitstellung einzelner Funktionen oder Operationen ausgerichtet ist. Viele Leute denken, dass Serverless FaaS ist, aber sie verpassen dabei das komplette Bild. Dieses Buch konzentriert sich zwar auf FaaS, aber wir ermutigen dich, auch BaaS in Betracht zu ziehen, wenn du größere Anwendungen entwickelst.

Wenn wir herkömmliche serverseitige Software einsetzen, beginnen wir mit einer Host-Instanz, in der Regel eine VM-Instanz oder ein Container (siehe Abbildung 1-3). Dann stellen wir unsere Anwendung, die normalerweise als Betriebssystemprozess läuft, auf dem Host bereit. Normalerweise enthält unsere Anwendung Code für mehrere verschiedene, aber miteinander verbundene Vorgänge; ein Webservice kann zum Beispiel sowohl das Abrufen als auch das Aktualisieren von Ressourcen ermöglichen.

Abbildung 1-3. Traditionelle serverseitige Softwareverteilung

Aus der Sicht des Eigentümers sind wir als Nutzer für alle drei Aspekte dieser Konfiguration verantwortlich - die Host-Instanz, den Anwendungsprozess und natürlich die Programmabläufe.

FaaS ändert dieses Modell der Bereitstellung und des Eigentums (siehe Abbildung 1-4). Wir streichen sowohl die Host-Instanz als auch den Anwendungsprozess aus unserem Modell. Stattdessen konzentrieren wir uns nur auf die einzelnen Operationen oder Funktionen, die die Logik unserer Anwendung ausdrücken. Wir laden diese Funktionen einzeln auf eine FaaS-Plattform hoch, für die wiederum der Cloud-Anbieter und nicht wir verantwortlich sind.

Abbildung 1-4. FaaS-Software-Bereitstellung

Die Funktionen sind jedoch nicht ständig in einem Anwendungsprozess aktiv und warten, bis sie ausgeführt werden müssen, wie es bei einem herkömmlichen System der Fall wäre. Stattdessen ist die FaaS-Plattform so konfiguriert, dass sie bei jedem Vorgang auf ein bestimmtes Ereignis wartet. Wenn dieses Ereignis eintritt, instanziiert die Plattform die FaaS-Funktion und ruft sie dann auf, wobei sie das auslösende Ereignis übergibt.

Sobald die Funktion ausgeführt wurde, kann die FaaS-Plattform sie wieder abbauen. Zur Optimierung kann sie die Funktion auch noch eine Weile behalten, bis ein anderes Ereignis verarbeitet werden muss.

FaaS wie von Lambda implementiert

AWS Lambda wurde 2014 eingeführt und wächst seitdem in Umfang, Reife und Nutzung. Einige Lambda-Funktionen haben einen sehr geringen Durchsatz - sie werden vielleicht nur einmal am Tag oder noch seltener ausgeführt. Andere hingegen werden vielleicht Milliarden Mal pro Tag ausgeführt.

Lambda setzt das FaaS-Muster um, indem es ephemere, verwaltete Linux-Umgebungen instanziiert, in denen jede unserer Funktionsinstanzen läuft. Lambda garantiert, dass immer nur ein Ereignis pro Umgebung verarbeitet wird. Zum Zeitpunkt der Erstellung dieses Artikels verlangt Lambda außerdem, dass die Funktion die Verarbeitung des Ereignisses innerhalb von 15 Minuten abschließt; andernfalls wird die Ausführung abgebrochen.

Lambda bietet ein außergewöhnlich leichtgewichtiges Programmier- und Bereitstellungsmodell - wir stellen einfach eine Funktion und die zugehörigen Abhängigkeiten in einer ZIP- oder JAR-Datei bereit, und Lambda verwaltet die Laufzeitumgebung vollständig.

Lambda ist eng mit vielen anderen AWS-Diensten integriert. Dadurch gibt es viele verschiedene Arten von Ereignisquellen, die Lambda-Funktionen auslösen können, und das führt dazu, dass man mit Lambda viele verschiedene Arten von Anwendungen erstellen kann.

Lambda ist ein vollständig serverloser Dienst, wie er in unseren Unterscheidungskriterien definiert ist:

Erfordert keine Verwaltung eines langlebigen Hosts oder einer Anwendungsinstanz

Mit Lambda sind wir vollständig von dem zugrunde liegenden Host abstrahiert, auf dem unser Code läuft. Außerdem verwalten wir keine langlebige Anwendung - sobald unser Code ein bestimmtes Ereignis verarbeitet hat, steht es AWS frei, die Laufzeitumgebung zu beenden.

Automatische Skalierung und automatische Bereitstellung, abhängig von der Last

Diese ist einer der Hauptvorteile von Lambda - Ressourcenmanagement und Skalierung sind völlig transparent. Sobald wir unseren Funktionscode hochgeladen haben, erstellt die Lambda-Plattform gerade genug Umgebungen, um die Last zu einem bestimmten Zeitpunkt zu bewältigen. Wenn eine Umgebung ausreicht, erstellt Lambda die Umgebung, wenn sie benötigt wird. Wenn hingegen Hunderte von separaten Instanzen benötigt werden, skaliert Lambda schnell und ohne jeglichen Aufwand für uns.

Hat Kosten, die auf der genauen Nutzung basieren, von und bis hin zu Nullnutzung

AWS berechnet für Lambda nur die Zeit, in der unser Code pro Umgebung ausgeführt wird, und zwar auf 100 ms genau. Wenn unsere Funktion alle 5 Minuten für 200 ms aktiv ist, werden uns nur 2,4 Sekunden Nutzung pro Stunde in Rechnung gestellt. Diese präzise Nutzungskostenstruktur ist gleich, egal ob eine oder tausend Instanzen unserer Funktion benötigt werden.

Die Leistungsfähigkeit wird nicht nur durch die Größe/Anzahl der Hosts bestimmt.

Da wir mit Lambda vollständig vom zugrunde liegenden Host abstrahiert sind, können wir keine Anzahl oder Art der zugrundeliegenden EC2-Instanzen angeben, die verwendet werden sollen. Stattdessen legen wir fest, wie viel Arbeitsspeicher unsere Funktion benötigt (bis zu maximal 3 GB), und auch andere Leistungsaspekte sind davon abhängig. Darauf gehen wir später im Buch näher ein - siehe "Speicher und CPU".

Hat implizite Hochverfügbarkeit

Wenn ein bestimmter zugrunde liegender Host fehlschlägt, startet Lambda automatisch Umgebungen auf einem anderen Host. Wenn ein bestimmtes Rechenzentrum/eineVerfügbarkeitszone fehlschlägt, startet Lambda automatisch Umgebungen in einem anderen AZ in derselben Region. Beachte, dass es an uns als AWS-Kunden liegt, mit einem regionsweiten Ausfall umzugehen, und wir sprechen darüber am Ende des Buches - siehe "Global verteilte Anwendungen".

Warum Lambda?

Die grundlegenden Vorteile der Cloud, die wir bereits beschrieben haben ( ), gelten auch für Lambda: Der Betrieb ist im Vergleich zu anderen Host-Plattformen oft günstiger, der Aufwand für den Betrieb einer Lambda-Anwendung ist geringer und die Skalierungsflexibilität von Lambda übertrifft jede andere Rechenoption in AWS.

Der wichtigste Vorteil aus unserer Sicht ist jedoch, wie schnell du mit Lambda in Kombination mit anderen AWS-Diensten Anwendungen erstellen kannst. Wir hören oft von Unternehmen, die in nur ein oder zwei Tagen brandneue Anwendungen für die Produktion erstellen. Die Tatsache, dass wir uns von einem Großteil des infrastrukturbezogenen Codes, den wir oft für normale Anwendungen schreiben, befreien können, ist eine enorme Zeitersparnis.

Lambda hat auch mehr Kapazität, mehr Reife und mehr Integrationspunkte als jede andere FaaS-Plattform. Es ist nicht perfekt, und einige andere Produkte bieten unserer Meinung nach eine bessere "Entwickler-UX" als Lambda. Aber ohne eine starke Bindung an einen bestehenden Cloud-Anbieter würden wir AWS Lambda aus all den oben genannten Gründen empfehlen.

Wie sieht eine Lambda-Anwendung aus?

Herkömmliche langlaufende Serveranwendungen haben oft mindestens eine von zwei Möglichkeiten, die Arbeit für einen bestimmten Stimulus zu beginnen - sie öffnen entweder einen TCP/IP-Socket und warten auf eingehende Verbindungen oder haben einen internen Zeitplanungsmechanismus, der sie dazu veranlasst, sich an eine entfernte Ressource zu wenden, um nach neuer Arbeit zu suchen. Da Lambda grundsätzlich eine ereignisorientierte Plattform ist und Lambda eine Zeitüberschreitung erzwingt, ist keines dieser Muster auf eine Lambda-Anwendung anwendbar. Wie bauen wir also eine Lambda-Anwendung?

Der erste Punkt, den du beachten solltest, ist, dass Lambda-Funktionen auf der untersten Ebene auf eine von zwei Arten aufgerufen werden können:

• Lambda Funktionen können von AWS synchronaufgerufen werden RequestResponse. In diesem Szenario ruft eine vorgeschaltete Komponente die Lambda-Funktion auf und wartet auf die Antwort, die die Lambda-Funktion erzeugt.

• Alternativ kann eine Lambda-Funktion von AWS asynchronaufgerufen werden - Event. In diesem Fall wird die Anfrage des Upstream-Aufrufers sofort von der Lambda-Plattform beantwortet, während die Lambda-Funktion mit der Bearbeitung der Anfrage fortfährt. In diesem Szenario wird keine weitere Antwort an den Aufrufer zurückgegeben.

Diese beiden Aufrufmodelle haben verschiedene andere Verhaltensweisen, auf die wir später eingehen, beginnend mit"Aufruftypen". Jetzt wollen wir sehen, wie sie in einigen Beispielanwendungen eingesetzt werden.

Web API

Eine naheliegende Frage ist, ob Lambda für die Implementierung einer HTTP-API verwendet werden kann, und glücklicherweise lautet die Antwort ja! Lambda-Funktionen sind zwar selbst keine HTTP-Server, aber wir können eine andere AWS-Komponente, das API Gateway, verwenden, um das HTTP-Protokoll und die Routing-Logik bereitzustellen, die wir normalerweise in einem Webservice haben (siehe Abbildung 1-5).

Abbildung 1-5. Web API mit AWS Lambda

Das obige Diagramm zeigt eine typische API, wie sie von einer einseitigen Webanwendung oder einer mobilen Anwendung verwendet wird. Der Client des Nutzers tätigt über HTTP verschiedene Aufrufe an das Backend, um Daten abzurufen und/oder Anfragen zu starten. In unserem Fall ist die Komponente, die die HTTP-Aspekte der Anfrage bearbeitet, Amazon API Gateway - ein HTTP-Server.

Wir konfigurieren API Gateway mit einer Zuordnung von Anfrage zu Handler (z. B. wenn ein Kunde eine Anfrage anGET /restaurants/123 stellt, können wir API Gateway so einrichten, dass es eine Lambda-Funktion namensRestaurantsFunction aufruft und die Details der Anfrage übergibt). API Gateway ruft die Lambda-Funktion synchron auf und wartet darauf, dass die Funktion die Anfrage auswertet und eine Antwort zurückgibt.

Da die Lambda-Funktionsinstanz selbst keine fernaufrufbare API ist, ruft das API-Gateway die Lambda-Plattform an und gibt dabei die aufzurufende Lambda-Funktion, die Art des Aufrufs (RequestResponse) und die Anfrageparameter an. Die Lambda-Plattform instanziiert dann eine Instanz von RestaurantsFunction und ruft diese mit den Anfrageparametern auf.

Die Lambda-Plattform hat einige Einschränkungen, wie die bereits erwähnte maximale Zeitüberschreitung, aber abgesehen davon ist sie eine ziemlich normale Linux-Umgebung. Unter RestaurantsFunction können wir zum Beispiel eine Datenbank aufrufen - Amazons DynamoDB ist eine beliebte Datenbank für Lambda, unter anderem wegen der ähnlichen Skalierungsmöglichkeiten der beiden Dienste.

Sobald die Funktion ihre Arbeit beendet hat, gibt sie eine Antwort zurück, da sie synchron aufgerufen wurde. Diese Antwort wird von der Lambda-Plattform an das API Gateway zurückgegeben, das die Antwort in eine HTTP-Antwortnachricht umwandelt, die wiederum an den Kunden zurückgegeben wird.

Normalerweise erfüllt eine Web-API mehrere Arten von Anfragen, die verschiedenen HTTP-Pfaden undVerben (wie GET, PUT, POST usw.) zugeordnet sind. Bei der Entwicklung einer Lambda-gestützten Web-API werden die verschiedenen Arten von Anfragen in der Regel als unterschiedliche Lambda-Funktionen implementiert, obwohl du nicht gezwungen bist, ein solches Design zu verwenden - du kannst alle Anfragen als eine Funktion behandeln, wenn du möchtest, und die Logik innerhalb der Funktion auf der Grundlage des ursprünglichen HTTP-Anfragepfads und Verbs umschalten.

Dateiverarbeitung

A gängiger Anwendungsfall für Lambda ist die Dateiverarbeitung. Stellen wir uns eine mobile Anwendung vor, die Fotos auf einen entfernten Server hochladen kann, die wir dann anderen Teilen unserer Produktsuite zur Verfügung stellen wollen, allerdings in unterschiedlichen Bildgrößen, wie in Abbildung 1-6 dargestellt.

Abbildung 1-6. Dateiverarbeitung mit AWS Lambda

S3 ist Amazons Simple Storage Service - derselbe, der 2006 eingeführt wurde. Mobile Anwendungen können über die AWS-API auf sichere Weise Dateien auf S3 hochladen.

S3 kann so konfiguriert werden, dass es die Lambda-Plattform aufruft, wenn die Datei hochgeladen wird, indem es die aufzurufende Funktion angibt und einen Pfad zur Datei übergibt. Wie im vorherigen Beispiel instanziiert die Lambda-Plattform dann die Lambda-Funktion und ruft sie mit den von S3 übergebenen Anfragedaten auf. Der Unterschied besteht jedoch darin, dass es sich um einen asynchronen Aufruf handelt (S3 hat den AufruftypEvent angegeben) - es wird weder ein Wert an S3 zurückgegeben noch wartet S3 auf einen Rückgabewert.

Dieses Mal existiert unsere Lambda-Funktion nur für den Zweck eines Seiteneffekts - sielädt die durch den Anfrageparameter angegebene Datei und erstellt dann neue, größenveränderte Versionen der Datei in einem anderen S3-Bucket. Mit den Seiteneffekten ist die Arbeit der Lambda-Funktion erledigt. Da sie Dateien in einem S3-Bucket erstellt hat, können wir diesem Bucket auch einen Lambda-Trigger hinzufügen, der weitere Lambda-Funktionen aufruft, die diese erzeugten Dateien verarbeiten und so eine Verarbeitungspipeline erstellen.

Andere Beispiele für Lambda-Anwendungen

Die beiden vorherigen Beispiele auf zeigen zwei Szenarien mit zwei verschiedenen Lambda-Ereignisquellen. Es gibt noch viele andere Ereignisquellen, mit denen wir viele andere Arten von Anwendungen erstellen können. Im Folgenden sind nur einige davon genannt:

• Wir können nachrichtenverarbeitende Anwendungen erstellen, die Nachrichtenbusse wie Simple Notification Service (SNS), Simple Queue Service (SQS), EventBridge oder Kinesis als Ereignisquelle nutzen.

• Wir können E-Mail-verarbeitende Anwendungen erstellen, die den Simple Email Service (SES) als Ereignisquelle nutzen.

• Wir können Anwendungen mit Zeitplannungsprogrammen erstellen, ähnlich wie Cron-Programme, die CloudWatch Scheduled Events als Auslöser verwenden.

Beachte, dass viele dieser Dienste außer Lambda BaaS-Dienste sind und damit auch serverlos. Die Kombination von FaaS und BaaS zu serverlosen Architekturen ist aufgrund ihrer ähnlichen Skalierungs-, Sicherheits- und Kosteneigenschaften eine außerordentlich leistungsfähige Technik. Tatsächlich sind es solche Kombinationen von Diensten, die die Popularität des serverlosen Computings vorantreiben.

Wir sprechen in Kapitel 5 ausführlich über die Erstellung von Anwendungen auf diese Weise.

AWS Lambda in der Java-Welt

AWS Lambda unterstützt von Haus aus eine große Anzahl von Sprachen. JavaScript und Python sind sehr beliebte Einstiegssprachen für Lambda (und auch für wichtige Produktionsanwendungen), unter anderem weil sie dynamisch typisiert und nicht kompiliert sind, was sehr schnelle Entwicklungszyklen ermöglicht.

Wir haben jedoch beide mit Lambda in Java angefangen. Java hat in der Lambda-Welt gelegentlich einen schlechten Ruf - teilweise zu Recht, teilweise zu Unrecht. Wenn sich das, was du in einer Lambda-Funktion brauchst, in etwa 10 Zeilen ausdrücken lässt, ist es in der Regel schneller, etwas in JavaScript oder Python zu erstellen. Für größere Anwendungen gibt es jedoch viele gute Gründe, Lambda-Funktionen in Java zu implementieren, von denen wir hier einige nennen:

• Wenn du oder dein Team mit Java besser vertraut sind als mit den anderen von Lambda unterstützten Sprachen, kannst du diese Kenntnisse und Bibliotheken in einer neuen Laufzeitplattform wiederverwenden. Java ist im Lambda-Ökosystem genauso eine "erstklassige Sprache" wie JavaScript, Python, Go usw. - Lambda schränkt dich nicht ein, wenn du Java verwendest. Wenn du bereits viel Code in Java implementiert hast, kann die Portierung eines Teils davon auf Lambda einen erheblichen Zeitvorteil gegenüber der Neuimplementierung in einer anderen Sprache bedeuten.

• In Messaging-Systemen mit hohem Durchsatz kann der typische Laufzeit-Leistungsvorteil von Java gegenüber JavaScript oder Python erheblich sein. Nicht nur, dass "schneller" in der Regel in jedem System "besser" ist, mit Lambda kann "schneller" aufgrund des Preismodells von Lambda auch zu spürbaren Kostenvorteilen führen.

Für JVM-Workloads unterstützt Lambda zum Zeitpunkt der Erstellung dieses Artikels die Java 8- und Java 11-Laufzeitumgebung. Die Lambda-Plattform instanziiert eine Version der Java-Laufzeitumgebung in ihrer Linux-Umgebung und führt unseren Code dann innerhalb dieser Java-VM aus. Unser Code muss also mit dieser Laufzeitumgebung kompatibel sein, aber wir sind nicht darauf beschränkt, nur die Sprache Java zu verwenden. Scala, Clojure, Kotlin und andere können alle auf Lambda ausgeführt werden (mehr dazu unter "Andere JVM-Sprachen und Lambda").

Es gibt auch eine erweiterte Option mit Lambda, um deine eigene Laufzeit zu definieren, wenn keine dieser Java-Versionen ausreicht - wir besprechen das weiter unter "Benutzerdefinierte Laufzeiten".

Die Lambda-Plattform liefert ein paar grundlegende Bibliotheken mit der Laufzeit (z. B. eine kleine Teilmenge der AWS Java-Bibliothek), aber alle anderen Bibliotheken, die dein Code benötigt, musst du selbst mit deinem Code bereitstellen. Wie du das machst, erfährst du in "Build and Package".

Schließlich gibt es in Java zwar das Programmierkonstrukt derLambda-Ausdrücke, diese haben aber nichts mit den AWS Lambda-Funktionen zu tun. Es steht dir frei, Java Lambda-Ausdrücke in deiner AWS Lambda-Funktion zu verwenden, wenn du das möchtest (da AWS Lambda Java 8 und höher unterstützt) oder nicht.

Zusammenfassung

In diesem Kapitel hast du erfahren, wie Serverless Computing die nächste Evolution der Cloud ist - eine Art, Anwendungen zu erstellen, indem man sich auf Dienste verlässt, die Ressourcenmanagement, Skalierung und vieles mehr transparent und ohne Konfiguration erledigen.

Außerdem weißt du jetzt, dass Functions as a Service (FaaS) und Backend as a Service (BaaS) die beiden Hälften von Serverless sind, wobei FaaS das Allzweck-Computing-Paradigma innerhalb von Serverless ist. Für weitere Informationen über Serverless im Allgemeinen verweisen wir dich auf unser kostenloses O'Reilly-Ebook What Is Serverless?

Außerdem hast du zumindest ein Grundwissen über Amazon Web Services - eine der beliebtesten Cloud-Plattformen der Welt. Du hast gelernt, welche enormen Kapazitäten AWS für das Hosting unserer Anwendungen hat und wie du sowohl über die Webkonsole als auch über die API/CLI auf AWS zugreifst.

Du hast AWS Lambda kennengelernt - Amazons FaaS-Produkt. Wir haben das "Denken in Lambda" mit einer traditionell erstellten Anwendung verglichen, darüber gesprochen, warum du Lambda im Vergleich zu anderen FaaS-Implementierungen nutzen solltest, und dann einige Beispiele für Anwendungen genannt, die mit Lambda erstellt wurden.

Zum Schluss hast du einen kurzen Überblick über Java als Lambda-Sprachoption gesehen.

In Kapitel 2 implementieren wir unsere erste Lambda-Funktion - mach dich bereit für eine mutige neue Welt!

Übungen

1. Besorge dir die Zugangsdaten für ein AWS-Konto. Am einfachsten geht das, indem du ein neues Konto erstellst. Wie bereits erwähnt, musst du in diesem Fall eine Kreditkartennummer angeben, aber alles, was wir in diesem Buch tun, sollte durch die kostenlose Stufe abgedeckt sein, es sei denn, du bist sehr enthusiastisch bei Tests!

   Alternativ kannst du auch ein bestehendes AWS-Konto verwenden. In diesem Fall empfehlen wir jedoch, ein "Entwicklungskonto" zu verwenden, um die " Produktionssysteme" nicht zu beeinträchtigen.

   Wir empfehlen außerdem, dass der von dir gewählte Zugang dir alle administrativen Rechte innerhalb des Kontos einräumt; andernfalls wirst du durch lästige Sicherheitsfragen behindert.

2. Melde dich in der AWS-Konsole an. Suche den Abschnitt Lambda - gibt es dort schon Funktionen?

3. Erweiterte Aufgabe: Sieh dir Amazons Serverless-Marketing-Seite an, insbesondere die Seite, auf der die verschiedenen Dienste der "Serverless-Plattform" beschrieben werden. Welche dieser Dienste erfüllen die oben beschriebenen Unterscheidungskriterien für einen serverlosen Dienst vollständig? Welche nicht, und inwiefern sind sie "größtenteils" serverlos?