Kapitel 1. Einführung in Serverless auf AWS

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Das Geheimnis des Weiterkommens liegt darin, anzufangen.

Mark Twain

Willkommen bei serverless! Du betrittst das pulsierende Ökosystem einer modernen, aufregenden Computing-Technologie, die unsere Vorstellung von Software radikal verändert, unsere Vorurteile über die Entwicklung von Anwendungen in Frage stellt und die Cloud-Entwicklung für alle zugänglicher macht. Es ist eine unglaubliche Technologie, die viele Menschen lieben, und wir freuen uns darauf, dir alles darüber beizubringen.

Die Softwarebranche entwickelt sich ständig weiter, und das Tempo der Entwicklung in der Softwareentwicklung ist so hoch wie in kaum einer anderen Disziplin. Die Geschwindigkeit des Wandels bringt viele Unternehmen und ihre IT-Abteilungen aus dem Gleichgewicht. Für diejenigen, die optimistisch sind, bietet der Wandel jedoch auch Chancen. Wenn Unternehmen den Wandel akzeptieren und ihre Prozesse anpassen, gehen sie voran. Diejenigen, die sich dem Wandel widersetzen, werden dagegen von der Konkurrenz und den Verbraucherwünschen überrollt.

Wir sind immer auf der Suche nach Möglichkeiten, unser Leben zu verbessern. Menschliche Bedürfnisse und Technologie gehen Hand in Hand. Unsere sich entwickelnden täglichen Anforderungen verlangen nach immer besseren Technologien, die wiederum Innovationen hervorbringen. Wenn wir die Leistungsfähigkeit dieser Innovationen erkennen, verbessern wir unsere Bedürfnisse, und der Kreislauf geht weiter. Die Industrie entwickelt sich seit Jahrzehnten auf diese Weise weiter, aber nicht in großen Sprüngen, sondern in kleinen Schritten, da eine Verbesserung die nächste auslöst.

Um Serverless und die damit verbundenen Möglichkeiten richtig einschätzen zu können, ist es von Vorteil, seine Geschichte zu verstehen. Damit wir uns auf unser Thema konzentrieren können, ohne zu den Ursprüngen von Bits und Bytes zurückzureisen, beginnen wir mit der Cloud und wie sie zu einer ernstzunehmenden Größe wurde.

Lehn dich zurück, entspann dich und mach dich bereit für eine Reise durch die aufregende Welt der Serverless-Technologie!

Der Weg zu Serverless

In den frühen 2000er Jahren war ich (Sheen) an der Entwicklung verteilter Anwendungen beteiligt, die hauptsächlich über Service-Busse und Webservices kommunizierten - eine typische serviceorientierte Architektur (SOA). In dieser Zeit stieß ich zum ersten Mal auf den Begriff "Cloud", der in der Tech-Branche gerade für Schlagzeilen sorgte. Ein paar Jahre später erhielt ich von der Unternehmensleitung den Auftrag, diese neue Technologie zu untersuchen und über bestimmte Schlüsselmerkmale zu berichten. Das erste Cloud-Angebot, das ich untersuchen sollte, war niemand anderes als Amazon Web Services.

Mein Bestreben, der Wolke näher zu kommen, begann dort, aber es dauerte noch ein paar Jahre, bis ich die bahnbrechenden Auswirkungen auf die Branche richtig einschätzen und verstehen konnte. Wie beim Schmetterlingseffekt war es faszinierend zu sehen, wie die Ereignisse der Vergangenheit uns in die Gegenwart geführt haben.

Hinweis

Der Schmetterlingseffekt ist ein Begriff, der sich auf das Konzept bezieht, dass eine kleine Veränderung im Zustand eines komplexen Systems nichtlineare Auswirkungen auf den Zustand dieses Systems zu einem späteren Zeitpunkt haben kann. Das am häufigsten genannte Beispiel ist der Flügelschlag eines Schmetterlings irgendwo auf der Welt, der als Auslöser für einen Taifun an einem anderen Ort dient.

Vom Mainframe-Computing zur modernen Cloud

Während Mitte des 19. Jahrhunderts wurden Großrechner aufgrund ihrer enormen Rechenleistung populär. Obwohl sie riesig, klobig, sehr teuer und mühsam zu warten waren, waren sie die einzigen verfügbaren Ressourcen, um komplexe geschäftliche und wissenschaftliche Aufgaben zu erledigen. Nur wenige Unternehmen und Bildungseinrichtungen konnten sie sich leisten und führten Aufträge im Batch-Modus aus, um die teuren Systeme optimal zu nutzen. Das Konzept des Time-Sharing wurde eingeführt, um die Rechenressourcen für die Ausführung von Programmen für mehrere Teams zu planen und zu teilen (siehe Abbildung 1-1). Diese Aufteilung der Kosten und Ressourcen machte das Computing für verschiedene Gruppen erschwinglicher, ähnlich wie die On-Demand-Ressourcennutzung und Pay-per-Use-Computing-Modelle der modernen Cloud.

Mainframe computer time-sharing (source: adapted from an image in Guide to Operating Systems by Greg Tomsho [Cengage])
Abbildung 1-1. Großrechner-Time-Sharing (Quelle: angepasst an eine Abbildung in Guide to Operating Systems von Greg Tomsho [Cengage])

Das Aufkommen der Vernetzung

Frühe Mainframes waren unabhängig und konnten nicht miteinander kommunizieren. Die Idee eines intergalaktischen Computernetzwerks oder galaktischen Netzwerks, um entfernte Computer miteinander zu verbinden und Daten auszutauschen, wurde in den frühen 1960er Jahren von dem Computerwissenschaftler J.C.R. Licklider, liebevoll Lick genannt, vorgestellt. Die Advanced Research Projects Agency (ARPA) des Verteidigungsministeriums der Vereinigten Staaten leistete Pionierarbeit, die im Advanced Research Projects Agency Network (ARPANET) umgesetzt wurde. Dies war eine der ersten Netzwerkentwicklungen, die das TCP/IP-Protokoll, einen der Hauptbausteine des Internets, verwendeten. Dieser Fortschritt bei der Vernetzung war ein großer Schritt nach vorn.

Der Beginn der Virtualisierung

In den 1970er Jahren nahm eine weitere Kerntechnologie der modernen Cloud Gestalt an. 1972 brachte IBM das Virtual Machine Operating System heraus, das es ermöglichte, mehrere Betriebsumgebungen auf einem einzigen Großrechner zu betreiben. Aufbauend auf den frühen Time-Sharing- und Netzwerkkonzepten fügte die Virtualisierung ein weiteres wichtiges Teil des Cloud-Puzzles hinzu. Die rasanten technologischen Entwicklungen der 1990er Jahre brachten diese Ideen zur Umsetzung und brachten uns der modernen Cloud näher. Virtuelle private Netzwerke (VPNs) und virtuelle Maschinen (VMs) wurden schon bald zum Allgemeingut.

Der Begriff Cloud Computing entstand Mitte bis Ende der 1990er Jahre. Manche schreiben ihn dem Computerriesen Compaq Corporation zu, der ihn 1996 in einem internen Bericht erwähnte. Andere schreiben ihn Professor Ramnath Chellappa und seinem Vortrag auf der INFORMS 1997 über ein "neues Paradigma für das Computing" zu. Unabhängig davon war die Computerbranche angesichts der Geschwindigkeit, mit der sich die Technologie entwickelte, bereits auf dem Weg zu massiven Innovationen und Wachstum.

Der erste Blick auf Amazon Web Services

Als die Virtualisierungstechnologie ausgereift war, bauten viele Unternehmen Funktionen zur automatischen oder programmgesteuerten Bereitstellung von VMs für ihre Mitarbeiter und zur Ausführung von Geschäftsanwendungen für ihre Kunden auf. Ein E-Commerce-Unternehmen, das diese Möglichkeiten zur Unterstützung seines Geschäftsbetriebs gut genutzt hat, war Amazon.com.

Anfang 2000 untersuchten die Ingenieure von Amazon, wie ihre Infrastruktur effizient skaliert werden konnte, um die steigende Kundennachfrage zu befriedigen. Im Rahmen dieses Prozesses entkoppelten sie die gemeinsame Infrastruktur von den Anwendungen und abstrahierten sie als Service, so dass mehrere Teams sie nutzen konnten. Dies war der Beginn des Konzepts, das heute unter als Infrastructure as a Service (IaaS) bekannt ist. Im Sommer 2006 startete das Unternehmen Amazon Elastic Compute Cloud (EC2), um virtuelle Maschinen als Service in der Cloud für jedermann anzubieten. Das war der bescheidene Anfang des heutigen Mammuts Amazon Web Services, im Volksmund AWS genannt!

Cloud-Bereitstellungsmodelle

Als Cloud-Dienste dank der Bemühungen von Unternehmen wie Amazon, Microsoft, Google, Alibaba, IBM und anderen an Dynamik gewannen, begannen sie, die Bedürfnisse verschiedener Geschäftssegmente zu erfüllen. Es bildeten sich unterschiedliche Zugangsmodelle und Nutzungsmuster heraus (siehe Abbildung 1-2).

Figurative comparison of different cloud environments
Abbildung 1-2. Figürlicher Vergleich verschiedener Cloud-Umgebungen

Das sind heute die wichtigsten Varianten:

Öffentliche Wolke

Der Cloud-Dienst , auf den die meisten von uns für die Arbeit und den privaten Gebrauch zugreifen, ist die öffentliche Cloud, bei der der Zugriff auf die Dienste über das öffentliche Internet erfolgt. Obwohl die Cloud-Provider in ihren Rechenzentren gemeinsame Ressourcen nutzen, sind die Aktivitäten der einzelnen Nutzer durch strenge Sicherheitsgrenzen voneinander getrennt. Dies wird gemeinhin als Multitenant-Umgebung bezeichnet.

Private Cloud

Im Allgemeinen ist eine Private Cloud eine Unternehmens-Cloud, bei der eine einzelne Organisation Zugang zu der Infrastruktur und den dort gehosteten Diensten hat. Sie ist eine mandantenfähige Umgebung. Eine Variante der Private Cloud ist die Government Cloud (z. B. AWS GovCloud), bei der die Infrastruktur und die Dienste speziell für eine bestimmte Regierung und ihre Organisationen bereitgestellt werden. Dies ist eine hochsichere und kontrollierte Umgebung, die von den Bürgern des jeweiligen Landes betrieben wird.

Hybride Wolke

Eine hybride Cloud nutzt sowohl öffentliche als auch private Cloud- oder On-Premises-Infrastruktur und -Dienste. Die Aufrechterhaltung dieser Umgebungen erfordert klare Grenzen für die Sicherheit und die gemeinsame Nutzung von Daten .

Hinweis

Unternehmen, die es vorziehen, ihre Workloads und Dienste von mehreren Public Cloud-Providern zu nutzen, arbeiten in einer sogenannten Multi-Cloud-Umgebung. Wir werden dies im nächsten Kapitel näher erläutern.

Der Einfluss von "Alles als Service

Die Idee von , etwas "als Dienstleistung" anzubieten, ist nicht neu oder spezifisch für Software. Öffentliche Bibliotheken sind ein gutes Beispiel für die Bereitstellung von Informationen und Wissen als Dienstleistung: Wir leihen Bücher aus, lesen sie und geben sie zurück. Das Leasing von Computern für Unternehmen ist ein weiteres Beispiel, bei dem kein Kapital für den Kauf und die Wartung von Ressourcen aufgewendet werden muss. Stattdessen verbrauchen wir sie als Dienstleistung zu einem erschwinglichen Preis. Das gibt uns auch die Flexibilität, den Dienst nur bei Bedarf zu nutzen - durch die Virtualisierung wird er von einer physischen zu einer virtuellen Ware.

In der Technologie führt eine Möglichkeit zu mehreren Möglichkeiten, und eine Idee zu vielen. Von reinen VMs haben sich die Möglichkeiten auf Netzwerkinfrastruktur, Datenbanken, Anwendungen, künstliche Intelligenz (KI) und sogar einfache Einzweckfunktionen ausgeweitet. Innerhalb einer kurzen Zeitspanne hat sich die Idee, etwas als Dienstleistung anzubieten, so weit entwickelt, dass wir heute fast alles als Dienstleistung anbieten können!

Infrastructure as a Service (IaaS)

IaaS ist eine der grundlegenden Cloud-Dienste, zusammen mit Platform as a Service (PaaS), Software as a Service (SaaS) und Function as a Service (FaaS). Es handelt sich dabei um das Grundgerüst einer Cloud-Plattform - Netzwerk-, Rechen- und Speicherressourcen, die in der Regel in einem Rechenzentrum untergebracht sind. Ein grundlegendes Verständnis von IaaS ist von Vorteil, da es die Basis für Serverless bildet.

Abbildung 1-3 zeigt den Aufbau der AWS-Rechenzentren in einem bestimmten geografischen Gebiet, das als Region bezeichnet wird, aus der Vogelperspektive. Um einen ausfallsicheren und hochverfügbaren Service anbieten zu können, hat AWS in jeder Region über Gruppen von Rechenzentren , die Availability Zones (AZs) genannt werden, Redundanz eingebaut. Zu den wichtigsten IaaS-Angeboten von AWS gehören Amazon EC2 und Amazon Virtual Private Cloud (VPC).

An AWS Region with its Availability Zones
Abbildung 1-3. Eine AWS-Region mit ihren Availability Zones

Plattform als Service (PaaS)

PaaS ist eine Service-Abstraktionsschicht über IaaS, um eine Anwendungsentwicklungsumgebung in der Cloud anzubieten. Sie stellt die Plattform und die Tools bereit, die für die Entwicklung, den Betrieb und die Verwaltung von Anwendungen benötigt werden, ohne dass die Infrastruktur, die Hardware und die notwendige Software bereitgestellt werden müssen, wodurch die Komplexität reduziert und die Entwicklungsgeschwindigkeit erhöht wird. AWS Elastic Beanstalk ist eine beliebte PaaS, die heute verfügbar ist.

Software as a Service (SaaS)

SaaS ist wahrscheinlich die am meisten genutzte Anwendung und deckt viele der Anwendungen ab, die wir täglich nutzen, wie z. B. das Abrufen von E-Mails, das Teilen und Speichern von Fotos, das Streamen von Filmen und die Verbindung mit Freunden und Familie über Konferenzdienste.

Neben den Cloud-Providern nutzen auch zahlreiche unabhängige Softwareanbieter (ISVs) die Cloud (IaaS- und PaaS-Angebote), um ihre SaaS-Lösungen Millionen von Nutzern zugänglich zu machen. Dank der niedrigen Kosten und der einfachen Einführung von Cloud und Serverless Computing ist dies ein schnell wachsender Markt. Abbildung 1-4 zeigt, wie diese drei Schichten der Cloud-Infrastruktur zusammenpassen.

The different layers of cloud infrastructure
Abbildung 1-4. Die verschiedenen Schichten der Cloud-Infrastruktur

Datenbank-as-a-Service (DBaaS)

DBaaS ist eine Art von SaaS, die verschiedene Möglichkeiten der Datenspeicherung und -verarbeitung abdeckt. Neben den traditionellen relationalen SQL-Datenbankmanagementsystemen (RDBMS) gibt es jetzt auch verschiedene andere Arten von Datenspeichern als verwaltete Dienste, darunter NoSQL-, Objekt-, Zeitreihen-, Graph- und Suchdatenbanken.

Amazon DynamoDB ist eine der beliebtesten NoSQL-Datenbanken, die als Service verfügbar sind (siehe Abbildung 1-5). Eine DynamoDB-Tabelle kann Milliarden von Datensätzen speichern und trotzdem CRUD-Operationen (Erstellen, Lesen, Aktualisieren und Löschen) mit einer Latenzzeit im einstelligen oder niedrigen zweistelligen Millisekundenbereich anbieten. Du wirst die Verwendung von DynamoDB in vielen serverlosen Beispielen in diesem Buch sehen.

Pictorial representation of Amazon DynamoDB and its data tables
Abbildung 1-5. Bildliche Darstellung von Amazon DynamoDB und seinen Datentabellen

Amazon Simple Storage Service (S3) ist ein Dienst zur Speicherung von Objekten, der Milliarden von Objekten und Petabytes an Daten verarbeiten kann (siehe Abbildung 1-6). Ähnlich wie das Konzept der Tabellen in RDBMS und DynamoDB speichert S3 die Daten in Buckets, wobei jeder Bucket seine eigenen spezifischen Eigenschaften hat.

Das Aufkommen von Diensten wie DynamoDB und S3 sind nur einige Beispiele dafür, wie sich die Anforderungen an die Speicherung unstrukturierter Daten im Laufe der Zeit verändert haben und wie die Cloud es Unternehmen ermöglicht, sich von der begrenzten vertikalen Skalierung und dem banalen Betrieb herkömmlicher RDBMS zu lösen und sich auf den Aufbau von Cloud-Lösungen zu konzentrieren, die einen Mehrwert für das Unternehmen bringen.

Pictorial representation of Amazon S3 and its data buckets
Abbildung 1-6. Bildliche Darstellung von Amazon S3 und seinen Daten-Buckets

Funktion als Service (FaaS)

Einfach ausgedrückt ist FaaS eine Art von Cloud-Computing-Dienst, mit dem du deinen Funktionscode ausführen kannst, ohne selbst Hardware bereitstellen zu müssen. FaaS ist ein Kernstück des Cloud-Computing-Puzzles, indem es die dringend benötigte Rechenleistung als Service zur Verfügung stellt, und wurde bald zum Katalysator für die weit verbreitete Einführung von Serverless. AWS Lambda ist die meistgenutzte FaaS-Implementierung, die heute unter verfügbar ist (siehe Abbildung 1-7).

Pictorial representation of AWS Lambda service and functions
Abbildung 1-7. Bildliche Darstellung von AWS Lambda Service und Funktionen

Managed versus Fully Managed Services

Bevor die Merkmale von Serverless im Detail erkundet, ist es wichtig zu verstehen, was mit den Begriffen Managed Services und Fully Managed Services gemeint ist. Als Entwickler nimmst du oft APIs von verschiedenen Anbietern in Anspruch, um Geschäftsaufgaben zu erfüllen und die API-Verträge einzuhalten. Du hast keinen Zugriff auf die Implementierung oder den Betrieb des Dienstes, da der Dienstanbieter sie verwaltet. In diesem Fall konsumierst du einen verwalteten Dienst.

Die Unterscheidung zwischen verwalteten und vollständig verwalteten Diensten ist oft unscharf. Bei bestimmten Managed Services musst du die notwendige Infrastruktur aufbauen und warten, bevor du sie nutzen kannst. Amazon Relational Database Service (RDS) ist zum Beispiel ein verwalteter Service für RDBMS wie MySQL, SQL Server, Oracle usw. Bei der Standardkonfiguration musst du jedoch eine virtuelle Netzwerkgrenze, eine sogenannte virtuelle private Cloud (VPC), mit Sicherheitsgruppen, Instanztypen, Clustern usw. erstellen, bevor du den Dienst nutzen kannst. Im Gegensatz dazu ist DynamoDB ein NoSQL-Datenbankdienst, den du fast sofort einrichten und nutzen kannst. Dies ist eine Möglichkeit, einen verwalteten Dienst von einem vollständig verwalteten Dienst zu unterscheiden. Vollständig verwaltete Dienste werden manchmal auch als serverlose Dienste bezeichnet.

Jetzt, da du etwas Hintergrundwissen über die Ursprünge und die Entwicklung der Cloud hast und die Einfachheit von vollständig verwalteten Diensten verstehst, ist es an der Zeit, einen genaueren Blick auf Serverless zu werfen und das erstaunliche Potenzial zu erkennen, das es für dich hat .

Die Merkmale der serverlosen Technologie

Serverless ist ein technologisches Konzept, das vollständig verwaltete Cloud-Dienste nutzt, um undifferenzierte Aufgaben zu übernehmen, indem es die komplizierten Infrastrukturen und Serverwartungsaufgaben abstrahiert.

John Chapin und Mike Roberts, die Autoren von Programming AWS Lambda (O'Reilly), bringen dies in einfachen Worten auf den Punkt:

Unternehmen, die serverlose Anwendungen entwickeln und unterstützen, kümmern sich nicht um die Hardware oder die mit den Anwendungen verbundenen Prozesse. Sie lagern diese Verantwortung an jemand anderen aus, z. B. an Cloud-Provider wie AWS.

Wie Roberts in seinem Artikel "Serverless Architectures" feststellt , wurde der Begriff "serverless" erstmals um 2012 verwendet, manchmal im Zusammenhang mit Dienstanbietern, die die Verantwortung für die Verwaltung von Servern, Datenspeichern und anderen Infrastrukturressourcen übernahmen (was es den Entwicklern wiederum ermöglichte, sich auf Aufgaben und Prozessabläufe zu konzentrieren), und manchmal im Zusammenhang mit Continuous-Integration- und Source-Control-Systemen, die als Dienst gehostet wurden, anstatt auf den Servern eines Unternehmens vor Ort. Der Begriff gewann nach der Einführung von AWS Lambda im Jahr 2014 und Amazon API Gateway in 2015 an Popularität, wobei der Schwerpunkt auf der Einbindung externer Dienste in die von den Entwicklungsteams erstellten Produkte lag. Der Begriff gewann an Bedeutung, als Unternehmen begannen, serverlose Dienste zu nutzen, um neue Geschäftsmöglichkeiten zu schaffen, und seitdem ist er im Trend.

Hinweis

In den ersten Tagen, vor allem nach der Veröffentlichung von AWS Lambda (dem FaaS-Angebot von AWS), haben viele Leute die Begriffe Serverless und FaaS synonym verwendet, als ob beide dasselbe Konzept darstellen würden. Heute wird FaaS als einer der vielen Servicetypen betrachtet, die Teil des serverlosen Ökosystems sind.

Die Definitionen von Serverless spiegeln oft die wichtigsten Merkmale einer serverlosen Anwendung wider. Zusammen mit den Definitionen wurden diese Merkmale verfeinert und neu definiert, als sich Serverless weiterentwickelte und eine breitere Akzeptanz in der Branche fand. Werfen wir einen Blick auf einige der wichtigsten Definitionen.

Pay-per-Use

Pay-per-use ist das Hauptmerkmal, das jeder mit Serverless in Verbindung bringt. Es stammt hauptsächlich aus den Anfängen von Serverless, als es mit FaaS gleichgesetzt wurde: Du zahlst für jeden Funktionsaufruf. Diese Interpretation gilt für ephemere Dienste wie AWS Lambda; wenn deine Anwendung jedoch Daten verarbeitet, kann es sein, dass du die Daten für einen längeren Zeitraum speichern und in dieser Zeit auf sie zugreifen musst. Vollständig verwaltete Dienste wie Amazon DynamoDB und Amazon S3 sind Beispiele für Dienste, die zur langfristigen Speicherung von Daten genutzt werden. In diesen Fällen fallen Kosten für das Datenvolumen an, das deine Anwendungen jeden Monat speichern, die oft in Gibibytes (GiB) gemessen werden. Erinnere dich daran, dass es sich dabei immer noch um eine nutzungsabhängige Gebühr handelt, die sich nach deinem Datenvolumen richtet, und dass du nicht für ein ganzes Laufwerk oder eine ganze Speicherung bezahlt wirst.

Abbildung 1-8 zeigt eine einfache serverlose Anwendung, bei der eine Lambda-Funktion auf die in einer DynamoDB-Tabelle gespeicherten Daten zugreift. Während du für die Lambda-Funktion auf der Grundlage der Anzahl der Aufrufe und des Speicherverbrauchs zahlst, zahlst du bei DynamoDB zusätzlich zu den nutzungsabhängigen Kosten für die API-Aufrufe zum Lesen und Schreiben von Daten auch für den Speicherplatz, der für die Speicherung der Daten verbraucht wird. In Kapitel 9 wirst du alle Kostenelemente von AWS Lambda und DynamoDB im Detail kennenlernen.

A simple serverless application, illustrating pay-per-use and data storage cost elements
Abbildung 1-8. Eine einfache serverlose Anwendung, die die Kostenelemente Pay-per-Use und Datenspeicherung veranschaulicht

Autoskalierung und Skalierung auf Null

Eine von der wichtigsten Eigenschaften eines vollständig verwalteten Dienstes ist die Fähigkeit, ohne manuelle Eingriffe je nach Bedarf hoch- und runterzuskalieren. Der Begriff " Skalierung auf Null" ist einzigartig für Serverless. Nehmen wir zum Beispiel eine Lambda-Funktion. AWS Lambda verwaltet die Bereitstellung der Infrastruktur, um die Funktion auszuführen. Wenn die Funktion endet und nicht mehr genutzt wird, fordert der Dienst nach einer bestimmten Zeit der Inaktivität die für ihre Ausführung verwendeten Ressourcen zurück und skaliert die Anzahl der Ausführungsumgebungen wieder auf Null.

Umgekehrt skaliert AWS bei einem hohen Anfragevolumen für eine Lambda-Funktion automatisch, indem es die Infrastruktur so bereitstellt, dass so viele gleichzeitige Instanzen der Ausführungsumgebung ausgeführt werden können, wie zur Deckung der Nachfrage erforderlich sind. Dies wird oft als unendliche Skalierung bezeichnet, obwohl die Gesamtkapazität tatsächlich von der Gleichzeitigkeitsgrenze deines Kontos abhängt.

Tipp

Mit AWS Lambda kannst du eine bestimmte Anzahl von Funktionscontainern "warm" halten, indem du den Wert für die bereitgestellte Gleichzeitigkeit einer Funktion festlegst.

Beide Skalierungsverfahren machen Serverless ideal für viele Arten von Anwendungen.

Hohe Verfügbarkeit

Eine hochverfügbare (HA) Anwendung vermeidet einen Single Point of Failure, indem sie Redundanz hinzufügt. Bei einer kommerziellen Anwendung wird im Service Level Agreement (SLA) die Verfügbarkeit in einem bestimmten Prozentsatz angegeben. Da wir bei Serverless vollständig verwaltete Services einsetzen, kümmert sich AWS um die Redundanz und Datenreplikation, indem es die Rechen- und Speicherressourcen auf mehrere AZs verteilt und so einen Single Point of Failure vermeidet. Die Einführung von Serverless bietet daher standardmäßig eine hohe Verfügbarkeit.

Kaltstart

Der Kaltstart wird häufig mit FaaS in Verbindung gebracht. Wie du bereits gesehen hast, wird zum Beispiel die Ausführungsumgebung einer AWS Lambda-Funktion heruntergefahren, wenn sie eine Zeit lang nicht genutzt wird. Wenn die Funktion nach einer gewissen Zeit der Inaktivität erneut aufgerufen wird, stellt AWS eine neue Ausführungsumgebung bereit, um sie auszuführen. Die Latenzzeit bei dieser ersten Einrichtung wird in der Regel als Kaltstartzeit bezeichnet. Sobald die Ausführung der Funktion abgeschlossen ist, behält der Lambda-Service die Ausführungsumgebung für einen unbestimmten Zeitraum bei. Wird die Funktion in diesem Zeitraum erneut aufgerufen, fällt die Kaltstart-Latenzzeit nicht an. Wenn es jedoch weitere gleichzeitige Aufrufe gibt, stellt der Lambda-Dienst für jeden gleichzeitigen Aufruf eine neue Ausführungsumgebung bereit, was zu einem Kaltstart führt.

Viele Faktoren tragen zu dieser anfänglichen Latenzzeit bei: die Größe des Deployment-Pakets der Funktion, die Laufzeitumgebung der Programmiersprache, der der Funktion zugewiesene Speicher (RAM), die Anzahl der Vorkonfigurationen (wie statische Dateninitialisierungen) usw. Als Ingenieur, der im Bereich Serverless arbeitet, ist es wichtig, den Kaltstart zu verstehen, da er deine Entscheidungen in Bezug auf Architektur, Entwicklung und Betrieb beeinflusst (siehe Abbildung 1-9).

Function invocation latency for cold starts and warm executions—requests 1 and 2 incur a cold start, whereas a warm container handles request 3
Abbildung 1-9. Latenzzeit für Funktionsaufrufe bei Kaltstarts und warmen Ausführungen - bei den Anfragen 1 und 2 erfolgt ein Kaltstart, während ein warmer Container die Anfrage 3 bearbeitet

Die einzigartigen Vorteile von Serverless

Neben und den Kernmerkmalen von Serverless, die du im vorigen Abschnitt kennengelernt hast, ist es wichtig, einige der einzigartigen Vorteile von Serverless zu verstehen, um den Entwicklungsprozess zu optimieren und es den Teams zu ermöglichen, ihre Geschwindigkeit bei der Bereitstellung von Geschäftsergebnissen zu erhöhen. In diesem Abschnitt werfen wir einen Blick auf einige der wichtigsten Funktionen, die Serverless unterstützt.

Individualität und Granularität der Ressourcen

"One size fits all" gilt nicht für Serverless. Die Möglichkeit, serverlose Dienste auf individueller Ebene zu konfigurieren und zu betreiben, ermöglicht es dir, deine serverlose Anwendung nicht nur als Ganzes zu betrachten, sondern auf der Ebene jeder einzelnen Ressource und mit ihren spezifischen Eigenschaften zu arbeiten. Anders als bei herkömmlichen Container-Anwendungen musst du auf Containerebene keine gemeinsamen Betriebsmerkmale mehr festlegen.

Angenommen, deine Anwendung hat mehrere Lambda-Funktionen. Einige Funktionen bearbeiten Nutzeranfragen von deiner Website, während andere Batch-Aufträge im Backend ausführen. Du könntest den benutzerseitigen Funktionen mehr Speicher zur Verfügung stellen, damit sie schnell reagieren können, und dich für ein längeres Timeout für die Backend-Batch-Job-Funktionen entscheiden, bei denen die Leistung nicht entscheidend ist. Mit Amazon Simple Queue Service (SQS)-Warteschlangen kannst du zum Beispiel konfigurieren, wie schnell du die Nachrichten verarbeiten willst, wenn sie in der Warteschlange ankommen, oder du kannst entscheiden, ob du den Zeitpunkt verzögern willst, zu dem eine Nachricht für die Verarbeitung verfügbar wird.

Hinweis

Amazon SQS ist ein vollständig verwalteter und hoch skalierbarer Message Queuing Service, der zum Senden, Empfangen und Speichern von Nachrichten verwendet wird. Er ist einer der Kernservices von AWS und hilft beim Aufbau lose gekoppelter Microservices. Jede SQS-Warteschlange hat mehrere Attribute; du kannst diese Werte anpassen, um die Warteschlange nach Bedarf zu konfigurieren.

Wenn du eine Anwendung erstellst, die mehrere Ressourcen nutzt - Lambda-Funktionen, SQS-Warteschlangen, DynamoDB-Tabellen, S3-Buckets usw. -, hast du die Flexibilität, das Verhalten jeder Ressource an die geschäftlichen und betrieblichen Anforderungen anzupassen. Abbildung 1-10 zeigt einen Teil eines Microservice für die Auftragsabwicklung.

Die Fähigkeit, auf einer granularen Ebene zu arbeiten, bringt viele Vorteile mit sich, wie du in diesem Buch sehen wirst. Wenn du die Individualität von Ressourcen verstehst und eine granulare Denkweise bei der Entwicklung von serverlosen Anwendungen entwickelst, kannst du sichere, kosteneffiziente und nachhaltige Lösungen entwickeln, die einfach zu bedienen sind.

A section of an order processing microservice, illustrating how each serverless resource has different configurations
Abbildung 1-10. Ein Ausschnitt aus einem Microservice zur Auftragsabwicklung, der verdeutlicht, dass jede serverlose Ressource unterschiedliche Konfigurationen hat

Fähigkeit zur Optimierung von Dienstleistungen hinsichtlich Kosten, Leistung und Nachhaltigkeit

Kosten und Leistung Optimierungsverfahren sind in der Softwareentwicklung weit verbreitet. Wenn du optimierst, um die Kosten zu senken, zielst du darauf ab, die Verarbeitungsleistung, den Speicherverbrauch und die Speicherung zu reduzieren. Bei einer herkömmlichen Anwendung nimmst du diese Änderungen auf einer hohen Ebene vor, die sich auf alle Teile der Anwendung auswirkt. Du kannst nicht eine bestimmte Funktion oder Datenbanktabelle auswählen, auf die du die Änderungen anwenden willst. In solchen Situationen können die Änderungen, die du vornimmst, zu Leistungseinbußen oder höheren Kosten an anderer Stelle führen, wenn sie nicht angemessen ausgeglichen werden. Serverless bietet ein besseres Optimierungsmodell.

Serverless ermöglicht tiefere Optimierung

Eine serverlose Anwendung setzt sich aus mehreren verwalteten Services zusammen und kann mehrere Ressourcen desselben verwalteten Services enthalten. In Abbildung 1-10 hast du zum Beispiel drei Lambda-Funktionen aus dem AWS Lambda-Service gesehen. Du bist nicht gezwungen, alle Funktionen auf dieselbe Weise zu optimieren. Stattdessen kannst du je nach deinen Anforderungen eine Funktion auf Leistung und eine andere auf Kosten optimieren oder einer Funktion ein längeres Timeout geben als den anderen. Du kannst auch unterschiedliche Anforderungen an die gleichzeitige Ausführung berücksichtigen.

Basierend auf ihren Eigenschaften kannst du das gleiche Prinzip mit anderen Ressourcen wie Warteschlangen, Tabellen, APIs usw. anwenden. Stell dir vor, du hast mehrere Microservices, die jeweils mehrere serverlose Ressourcen enthalten. Für jeden Microservice kannst du jede einzelne Ressource auf einer granularen Ebene optimieren. Das ist Optimierung auf ihrer tiefsten und feinsten Ebene in Aktion!

Optimierung der Speicherung

Moderne Cloud-Anwendungen nehmen riesige Datenmengen auf - Betriebsdaten, Metriken, Protokolle usw. Die Teams, denen die Daten gehören, möchten vielleicht ihre Speicherung optimieren (um die Kosten zu minimieren und in manchen Fällen die Leistung zu verbessern), indem sie nur geschäftskritische Daten isolieren und aufbewahren.

Verwaltete Datenservices bieten integrierte Funktionen, um nicht benötigte Daten zu entfernen oder zu übertragen. Amazon S3 unterstützt zum Beispiel pro Eimer Daten Aufbewahrungsrichtlinien, um Daten entweder zu löschen oder in eine andere Speicherklasse zu überführen, und DynamoDB ermöglicht es dir, den Time to Live (TTL)-Wert für jedes Element in einer Tabelle zu konfigurieren. Die Optionen zur Optimierung der Speicherung beschränken sich nicht auf die gängigen Datenspeicher. Du kannst die Aufbewahrungszeit für jede SQS-Warteschlange, jeden Kinesis-Stream, jeden API-Cache usw. festlegen.

Warnung

DynamoDB verwaltet die TTL-Konfiguration der Tabellenelemente effizient, unabhängig davon, wie viele Elemente sich in einer Tabelle befinden und wie viele dieser Elemente einen TTL-Zeitstempel gesetzt haben. In manchen Fällen kann es jedoch bis zu 48 Stunden dauern, bis ein Element aus der Tabelle gelöscht wird. Daher ist dies möglicherweise nicht die ideale Lösung, wenn du eine garantierte Löschung zum exakten TTL-Zeitpunkt benötigst.

Unterstützung für tiefere Sicherheits- und Datenschutzmaßnahmen

Du jetzt verstehst, wie die Individualität und Granularität von Diensten in Serverless es dir ermöglicht, jeden Teil einer Anwendung auf unterschiedliche Anforderungen abzustimmen. Dieselben Eigenschaften ermöglichen es dir, bei Bedarf Schutzmaßnahmen auf einer tieferen Ebene im gesamten Ökosystem anzuwenden.

Berechtigungen auf Funktionsebene

Abbildung 1-11 zeigt eine einfache serverlose Anwendung, mit der du Bestellungen speichern und den Status einer bestimmten Bestellung über die Endpunkte POST /orders bzw. GET /orders/{id}/status abfragen kannst, die von den entsprechenden Lambda-Funktionen verarbeitet werden. Die Funktion, die die Tabelle Orders abfragt, um den Status zu ermitteln, führt eine Leseoperation durch. Da diese Funktion die Daten in der Tabelle nicht verändert, benötigt sie nur die Berechtigung dynamodb:Query. Die Idee, nur die für die Ausführung einer Aufgabe erforderlichen Rechte zu vergeben, wird als das Prinzip der geringsten Rechte bezeichnet.

Hinweis

Das Prinzip der geringsten Privilegien ist eine bewährte Methode, die nur die für die Durchführung einer Aufgabe erforderlichen Berechtigungen gewährt. Wie in Beispiel 1-1 gezeigt, definierst du dies als IAM-Richtlinie, indem du die erlaubten Aktionen für bestimmte Ressourcen einschränkst. Es ist eines der grundlegendsten Sicherheitsprinzipien in AWS und sollte Teil des Sicherheitsdenkens eines jeden Engineers sein. Mehr über dieses Thema erfährst du in Kapitel 4.

Serverless application showing two functions with different access privileges to the same data table
Abbildung 1-11. Serverlose Anwendung mit zwei Funktionen mit unterschiedlichen Zugriffsrechten auf dieselbe Datentabelle

Granulare Berechtigungen auf Datensatzebene

Die IAM-Richtlinie in Beispiel 1-1 hat gezeigt, wie du den Zugriff zum Lesen (Abfragen) von Daten aus der Tabelle Bestellungen konfigurierst. Tabelle 1-1 enthält Beispieldaten einiger Bestellungen, bei denen eine Bestellung zum besseren Zugriff und zum Schutz der Privatsphäre in drei Teile aufgeteilt ist: SOURCE, STATUS, und ADJUSTED.

Tabelle 1-1. Beispiel einer Auftragstabelle mit mehreren Artikelarten
PK SK Status Nachverfolgung Gesamt Artikel
SOURCE 100-255-8730 Verarbeitung 44tesYuwLo 299.99 { ... }
STATUS 100-255-8730 Verarbeitung 44tesYuwLo
SOURCE 100-735-6729 Geliefert G6txNMo26d 185.79 { ... }
ANGEPASST 100-735-6729 Geliefert G6txNMo26d 175.98 { ... }
STATUS 100-735-6729 Geliefert G6txNMo26d

Nach dem Prinzip der geringsten Berechtigung sollte die Lambda-Funktion, die den Status einer Bestellung abfragt, nur auf den STATUS Datensatz dieser Bestellung zugreifen dürfen. Tabelle 1-2 zeigt die Datensätze, auf die die Funktion zugreifen darf.

Tabelle 1-2. STATUS Datensätze, auf die die Statusabfragefunktion zugreifen kann
PK SK Status Nachverfolgung Gesamt Artikel
SOURCE 100-255-8730 Verarbeitung 44tesYuwLo 299.99 { ... }
STATUS 100-255-8730 Verarbeitung 44tesYuwLo
SOURCE 100-735-6729 Geliefert G6txNMo26d 185.79 { ... }
ANGEPASST 100-735-6729 Geliefert G6txNMo26d 175.98 { ... }
STATUS 100-735-6729 Geliefert G6txNMo26d

Um dies zu erreichen, kannst du eine IAM-Richtlinie mit einer dynamodb:LeadingKeys Bedingung und den in Beispiel 1-2 aufgelisteten Richtliniendetails verwenden.

Beispiel 1-2. Richtlinie zur Beschränkung des Lesezugriffs auf eine bestimmte Art von Elementen
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOrderStatus",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": [
        "arn:aws:dynamodb:…:table/Orders"
      ],
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": [
            "STATUS"
          ]
        }
      }
    }
  ]
}

Die hier gezeigte bedingte Richtlinie funktioniert auf Datensatzebene. DynamoDB unterstützt auch Bedingungen auf Attributsebene, um die Werte nur von den zulässigen Attributen eines Datensatzes abzurufen, für Anwendungen, die eine noch feinere Zugriffskontrolle benötigen.

Richtlinien wie diese sind in AWS weit verbreitet und gelten für mehrere gängige Services, die du für die Entwicklung deiner Anwendungen nutzen wirst. Wenn du weißt und verstehst, wo und wann du sie anwenden musst, wirst du als serverless Ingenieur von großem Nutzen sein.

Inkrementelle und iterative Entwicklung

Iterative Entwicklung ermöglicht es Teams, Produkte in kleinen Schritten, aber in schneller Folge zu entwickeln und zu liefern. Wie Eric Ries in seinem Buch The Startup Way (Penguin) sagt, fängst du einfach an und skalierst schnell. Dein Produkt entwickelt sich ständig mit neuen Funktionen weiter, die deinen Kunden zugute kommen und den Geschäftswert erhöhen.

Die ereignisgesteuerte Architektur (EDA), auf die wir in Kapitel 3 näher eingehen werden, ist das Herzstück der serverlosen Entwicklung. Bei der serverlosen Entwicklung setzt du deine Anwendungen aus lose gekoppelten Diensten zusammen, die über Ereignisse, Nachrichten und APIs interagieren. Die EDA-Prinzipien ermöglichen es dir, modulare und erweiterbare serverlose Anwendungen zu entwickeln.1 Wenn du harte Abhängigkeiten zwischen deinen Diensten vermeidest, wird es einfacher, deine Anwendungen zu erweitern, indem du neue Dienste hinzufügst, ohne die Funktion der bestehenden zu beeinträchtigen.

Vielfältig qualifizierte Ingenieurteams

Die Einführung von neuen Technologien bringt sowohl Veränderungen als auch Herausforderungen in einer Organisation mit sich. Wenn Teams auf eine neue Sprache, Datenbank, SaaS-Plattform, Browsertechnologie oder einen Cloud-Provider umsteigen, erfordern Änderungen in diesem Bereich oft auch Änderungen in anderen Bereichen. Die Einführung einer neuen Programmiersprache kann zum Beispiel Änderungen bei den Entwicklungs-, Build- und Deployment-Prozessen erforderlich machen. Ebenso kann die Verlagerung deiner Anwendungen in die Cloud viele neue Prozesse und Fähigkeiten erfordern.

Einfluss der DevOps-Kultur

Der Ansatz DevOps beseitigt die Barrieren zwischen Entwicklung und Betrieb, wodurch neue Produkte schneller entwickelt und einfacher gewartet werden können. Durch die Einführung eines DevOps-Modells wird ein Softwareentwickler, der sich sonst auf die Entwicklung von Anwendungen konzentriert, zu einem Mitarbeiter, der operative Aufgaben übernimmt. Du arbeitest nicht mehr in einem isolierten Softwareentwicklungszyklus, sondern bist in seine vielen Phasen eingebunden, wie z. B. kontinuierliche Integration und Bereitstellung (CI/CD), Überwachung und Beobachtbarkeit, Inbetriebnahme der Cloud-Infrastruktur und Sicherung der Anwendungen.

Die Einführung eines serverlosen Modells bringt dich viele Schritte weiter. Du musst zwar keine Server mehr verwalten, aber du programmierst jetzt die Geschäftslogik, stellst deine Anwendung mit verwalteten Diensten zusammen, verknüpfst sie mit Infrastructure as Code (IaC) und betreibst sie in der Cloud. Nur zu wissen, wie man Software schreibt, ist nicht genug. Du musst deine Anwendung vor böswilligen Benutzern schützen, sie rund um die Uhr für Kunden auf der ganzen Welt verfügbar machen und ihre Betriebseigenschaften beobachten, um sie kontinuierlich zu verbessern. Um ein erfolgreicher Serverless Engineer zu werden, musst du also eine ganze Reihe neuer Fähigkeiten entwickeln und eine DevOps-Mentalität kultivieren (siehe Abbildung 1-12).

Traditional siloed specialist engineers versus multiskilled serverless engineers
Abbildung 1-12. Traditionelle Silo-Spezialistinnen und -Spezialisten im Vergleich zu multidisziplinären serverlosen Ingenieurinnen und Ingenieuren

Deine Entwicklung als serverloser Ingenieur

Betrachte die in Abbildung 1-8 gezeigte einfache serverlose Anwendung, bei der eine Lambda-Funktion eine DynamoDB-Tabelle liest und in sie schreibt. Stell dir vor, du beherrschst TypeScript und hast Node.js als deine Lambda-Laufzeitumgebung gewählt. Während du die Funktion implementierst, ist es deine Aufgabe, die Interaktionen mit DynamoDB zu programmieren. Um effizient zu sein, lernst du NoSQL-Konzepte, identifizierst die Attribute Partitionsschlüssel (PK) und Sortierschlüssel (SK) sowie geeignete Datenzugriffsmuster, um deine Abfragen zu schreiben, usw. Darüber hinaus gibt es möglicherweise Datenreplikation, TTL, Caching und andere Anforderungen. Da auch die Sicherheit ein Thema ist, lernst du etwas über AWS IAM, die Erstellung von Rollen und Richtlinien und vor allem über das Prinzip der geringsten Berechtigung. Von einem Programmierer, der eine bestimmte Sprache beherrscht, vollzieht deine Rolle als Ingenieur eine 360-Grad-Wendung. Während du dich zu einem serverlosen Ingenieur entwickelst, lernst du viele neue Fähigkeiten und Verantwortlichkeiten kennen.

Wie du im vorherigen Abschnitt gesehen hast, erfordert dein Job die Fähigkeit, die Deployment-Pipeline für deine Anwendung zu erstellen, Servicemetriken zu verstehen und proaktiv auf Produktionsvorfälle zu reagieren. Du bist jetzt ein vielseitig ausgebildeter Ingenieur - und wenn die meisten Ingenieure in einem Team vielseitig ausgebildet sind, wird es zu einem vielseitigen Ingenieurteam, das in der Lage ist, eine effiziente serverlose End-to-End-Bereitstellung durchzuführen. Für Unternehmen, die ihre Ingenieure weiterbilden müssen, werden in Kapitel 2 die Möglichkeiten zur Förderung von serverless Talenten im Detail erläutert.

Die Teile einer serverlosen Anwendung und ihr Ökosystem

Ein Ökosystem ist ein geografisches Gebiet, in dem Pflanzen, Tiere und andere Organismen sowie das Wetter und die Landschaft zusammenwirken, um eine Blase des Lebens zu bilden.

NationalGeographic.org

In der Natur enthält ein Ökosystem sowohl lebende als auch nicht lebende Teile, die auch Faktoren genannt werden. Jeder Faktor in einem Ökosystem hängt von jedem anderen Faktor ab, entweder direkt oder indirekt. Die Erdoberfläche ist eine Reihe von miteinander verbundenen Ökosystemen.

Die Analogie zum Ökosystem ist hier beabsichtigt. Serverless wird zu oft als ein Architekturdiagramm oder eine Blaupause vorgestellt, aber es ist viel mehr als FaaS und ein einfaches Framework. Es hat sowohl technische als auch nicht-technische Elemente, die mit ihm verbunden sind. Serverless ist ein technologisches Ökosystem!

Wie du bereits in diesem Kapitel gelernt hast, bilden Managed Services den Hauptbestandteil einer serverlosen Anwendung. Sie allein können eine Anwendung jedoch nicht zum Leben erwecken - viele andere Faktoren sind daran beteiligt. Abbildung 1-13 zeigt einige der Kernelemente, die das serverlose Ökosystem ausmachen.

Parts of the serverless technology ecosystem
Abbildung 1-13. Teile des Ökosystems der serverlosen Technologie

Dazu gehören:

Die Cloud-Plattform

Diese ist der Enabler des serverlosen Ökosystems - in unserem Fall AWS. Die Cloud-Hosting-Umgebung stellt die erforderlichen Rechen-, Speicher- und Netzwerkressourcen bereit.

Verwaltete Cloud-Dienste

Verwaltete Dienste sind die Grundbausteine von Serverless. Du stellst deine Anwendungen zusammen, indem du Dienste für Berechnungen, Ereignistransport, Nachrichtenaustausch, Datenspeicherung und verschiedene andere Aktivitäten nutzt.

Architektur

Dies ist die Blaupause, die den Zweck und das Verhalten deiner serverlosen Anwendung beschreibt. Die Festlegung und Einigung auf eine Architektur ist eine der wichtigsten Aktivitäten bei der serverlosen Entwicklung.

Definition der Infrastruktur

Die Definition der Infrastruktur - auch bekannt als Infrastructure as Code (IaC) und ausgedrückt als beschreibendes Skript - ist wie der Schaltplan deiner Anwendung. Sie verknüpft alles mit den entsprechenden Eigenschaften, Abhängigkeiten, Berechtigungen und Zugriffskontrollen. Wenn IaC in der Cloud eingesetzt wird, hat es die Macht, deine serverlose Anwendung zum Leben zu erwecken oder sie zu zerstören.

Entwicklungs- und Testwerkzeuge

Die Laufzeitumgebung deines FaaS bestimmt die Programmiersprache, die Bibliotheken, die Plug-ins, die Test-Frameworks und verschiedene andere Entwicklungshilfen. Diese Hilfsmittel können je nach Produktbereich und den Vorlieben der Entwicklungsteams von einem Ökosystem zum anderen variieren.

Repository und Pipelines

Das Repository ist ein versionierter Speicher für alle deine Artefakte, und die Pipelines führen die Aktionen aus, die deine serverlose Anwendung von der Entwicklerumgebung bis zu ihren Zielkunden bringen, wobei sie auf dem Weg verschiedene Kontrollpunkte durchlaufen. Die Definition der Infrastruktur spielt in diesem Prozess eine entscheidende Rolle.

Tools zur Beobachtbarkeit

Beobachtbarkeit Tools und Techniken fungieren als Spiegel, der den Betriebszustand deiner Anwendung widerspiegelt und tiefere Einblicke in die Leistung der Anwendung im Hinblick auf ihren Zweck bietet. Ein nicht-beobachtbares System kann nicht aufrechterhalten werden.

Bewährte Methoden

Um deine serverlose Anwendung vor Sicherheitsbedrohungen und Skalierungsanforderungen zu schützen und sicherzustellen, dass sie bei unerwarteten Störungen sowohl beobachtbar als auch widerstandsfähig ist, brauchst du gut architektierte Prinzipien und bewährte Methoden, die als Leitplanken dienen. Das AWS Well-Architected Framework ist ein wichtiger Leitfaden für bewährte Methoden, auf den wir später in diesem Kapitel eingehen werden.

Bauherren und Interessenvertreter

Die Menschen, die die Anforderungen für eine Anwendung entwickeln und diejenigen, die sie in der Cloud entwerfen, bauen und betreiben, sind ebenfalls Teil des Ökosystems. Neben all den Tools und Techniken ist die Rolle der Menschen in einem serverlosen Ökosystem von entscheidender Bedeutung - sie sind dafür verantwortlich, die richtigen Entscheidungen zu treffen und die notwendigen Aktionen durchzuführen, ähnlich wie wir alle in unserem Ökosystem Ökosystem!

Warum ist AWS eine großartige Plattform für Serverless?

Wie bereits erwähnt hat, tauchte der Begriff "serverless" in der Branche erstmals um 2012 auf, gewann aber erst nach der Veröffentlichung von AWS Lambda im Jahr 2014 an Bedeutung. Während die große Zahl derer, die auf den Lambda-Zug aufsprangen, Serverless zu neuen Höhen verhalf, hatte AWS zu diesem Zeitpunkt bereits einige vollständig verwaltete Serverless-Services für Kunden im Angebot. Amazon SQS wurde fast 10 Jahre vor AWS Lambda veröffentlicht. Amazon S3, der beliebte und weit verbreitete Objektspeicher in der Cloud, wurde 2006 auf den Markt gebracht, lange bevor die Cloud in der IT-Branche Einzug hielt.

Dieser frühe Sprung in die Cloud mit einer futuristischen Vision, die Container-Dienste und vollständig verwaltete serverlose Dienste anbietet, ermöglichte es Amazon, neue Produkte schneller als jeder andere Anbieter auf den Markt zu bringen. Viele Early Adopters erkannten das Potenzial und setzten ihre Geschäftsideen schnell um und starteten ihre Anwendungen auf AWS. Auch wenn der Cloud-Markt rasant wächst, bleibt AWS der weltweit führende Cloud-Provider.

Die Popularität der serverlosen Dienste von AWS

Die enge Zusammenarbeit mit Kunden und die Beobachtung von Branchentrends haben es AWS ermöglicht, Ideen schnell zu iterieren und mehrere wichtige serverlose Dienste in Bereichen wie APIs, Funktionen, Datenspeicher, Datenstreaming, KI, maschinelles Lernen, Ereignistransport, Workflow und Orchestrierung und mehr einzuführen.

AWS ist eine umfassende Cloud-Plattform, die über 200 Services für den Aufbau und Betrieb von serverlosen und nicht-serverlosen Arbeitslasten bietet. In Tabelle 1-3 sind einige der am häufigsten genutzten verwalteten serverlosen Dienste aufgeführt. Du wirst viele dieser Dienste in den Diskussionen in diesem Buch wiederfinden.

Das AWS Well-Architected Framework

Das AWS Well-Architected Framework ist eine Sammlung bewährter Methoden für die Entwicklung, den Aufbau und den Betrieb sicherer, skalierbarer, hochverfügbarer, belastbarer und kosteneffizienter Anwendungen in der Cloud. Es besteht aus sechs Säulen, die grundlegende Bereiche eines modernen Cloud-Systems abdecken:

Operative Exzellenz

Die Säule Operational Excellence bietet Gestaltungsprinzipien und bewährte Methoden, um organisatorische Ziele für die Identifizierung, die Vorbereitung, den Betrieb, die Beobachtung und die Verbesserung des Betriebs von Workloads in der Cloud zu formulieren. Zu den Kernprinzipien dieser Säule gehören die Vorhersage von Fehlern und Pläne zur Schadensbegrenzung, die Weiterentwicklung von Anwendungen in kleinen, aber häufigen Schritten sowie die kontinuierliche Bewertung und Verbesserung der Betriebsverfahren.

Sicherheit

Die Säule Sicherheit konzentriert sich auf das Identitäts- und Zugriffsmanagement, den Schutz von Anwendungen auf allen Ebenen, die Gewährleistung des Datenschutzes und der Datenkontrolle sowie die Rückverfolgbarkeit und Prüfung aller Aktionen und die Vorbereitung auf und Reaktion auf Sicherheitsereignisse. Sie sorgt dafür, dass das Sicherheitsdenken in allen Phasen der Entwicklung zum Tragen kommt, und liegt in der Verantwortung aller Beteiligten.

Verlässlichkeit

Eine Anwendung, die in der Cloud bereitgestellt und betrieben wird, sollte skalierbar sein und bei veränderter Nachfrage konsistent funktionieren. Zu den Grundsätzen und Praktiken der Säule Zuverlässigkeit gehören u. a. die Entwicklung von Anwendungen, die mit Servicekontingenten und -grenzen arbeiten, die Verhinderung und Begrenzung von Ausfällen sowie die Erkennung und Wiederherstellung nach Ausfällen.

Leistung Effizienz

Bei der Säule Leistungseffizienz geht es um die Auswahl und den Einsatz der richtigen Technologie und Ressourcen, um ein effizientes System aufzubauen und zu betreiben. Überwachung und Datenmetriken spielen hier eine wichtige Rolle bei der ständigen Überprüfung und dem Treffen von Kompromissen, um die Effizienz jederzeit aufrechtzuerhalten.

Kostenoptimierung

Die Säule Kostenoptimierung leitet Unternehmen an, Geschäftsanwendungen in der Cloud so zu betreiben, dass sie einen Mehrwert liefern und die Kosten niedrig halten. Die bewährten Methoden konzentrieren sich auf das Finanzmanagement, die Schaffung eines Cloud-Kostenbewusstseins, die Nutzung kosteneffizienter Ressourcen und Technologien wie Serverless und die kontinuierliche Analyse und Optimierung auf der Grundlage des Geschäftsbedarfs.

Nachhaltigkeit

Die Säule Nachhaltigkeit ist die neueste Ergänzung zum AWS Well-Architected Framework. Sie konzentriert sich darauf, zu einer nachhaltigen Umwelt beizutragen, indem sie den Energieverbrauch senkt, Anwendungen so gestaltet und betreibt, dass sie weniger Rechenleistung, Speicherplatz und Netzwerk-Roundtrips benötigen, On-Demand-Ressourcen wie serverlose Services nutzt und die Optimierung auf das erforderliche Maß beschränkt und nicht über.

AWS Pläne für technischen Support

Abhängig von dem Umfang deines Cloud-Betriebs und der Unternehmensgröße bietet Amazon vier technische Support-Pläne an, die deinen Bedürfnissen entsprechen:

Entwickler

Dies ist das Einstiegsmodell, das sich für Experimente, den Bau von Prototypen oder das Testen einfacher Anwendungen zu Beginn deiner serverlosen Reise eignet.

Business

Wenn du von der Experimentierphase zum Produktionseinsatz übergehst und Geschäftsanwendungen für Kunden betreibst, ist dies die empfohlene Supportstufe. Neben anderen Support-Funktionen bietet er auch garantierte Reaktionszeiten für Produktionssysteme, die beeinträchtigt werden oder ausfallen (<4 Stunden bzw. <1 Stunde).

Enterprise Auffahrt

Der Hauptunterschied zwischen diesem und dem Enterprise-Tarif ist die garantierte Reaktionszeit, wenn geschäftskritische Anwendungen ausfallen (<30 Minuten, im Gegensatz zu <15 Minuten beim übergeordneten Tarif). Bei den niedrigeren Tarifen gibt es diese Garantie nicht.

Unternehmen

Wenn du zu einem großen Unternehmen mit mehreren Teams gehörst, die anspruchsvolle, geschäftskritische Workloads entwickeln und betreiben, bietet dir der Enterprise-Supportplan die beste Soforthilfe. Im Falle eines Problems mit deinen geschäftskritischen Anwendungen erhältst du innerhalb von 15 Minuten Unterstützung. Dieser Plan bietet außerdem einige zusätzliche Vorteile, darunter:

  • Ein dedizierter Technical Account Manager (TAM), der als erste Anlaufstelle zwischen deinem Unternehmen und AWS fungiert

  • Regelmäßige (in der Regel monatliche) Treffen mit deinem TAM

  • Beratung durch AWS-Experten, wie z. B. Lösungsarchitekten, die auf dein Geschäftsfeld spezialisiert sind, bei der Erstellung einer Anwendung

  • Bewertung deiner bestehenden Systeme und Empfehlungen auf Basis der bewährten Methoden des AWS Well-Architected Framework

  • Schulungen und Workshops zur Verbesserung deiner internen AWS-Fähigkeiten und bewährten Methoden in der Entwicklung

  • Nachrichten über neue Produkteinführungen und neue Funktionen

  • Möglichkeiten, neue Produkte zu testen, bevor sie allgemein verfügbar sind

  • Einladungen zu Vertiefungstagen und persönlichen Treffen mit AWS-Produktteams für die Technologien, mit denen du arbeitest

Hinweis

Das oberste Leitprinzip bei Amazon ist die Kundenbesessenheit: "Führungskräfte beginnen mit dem Kunden und arbeiten rückwärts. Sie arbeiten energisch daran, das Vertrauen der Kunden zu gewinnen und zu erhalten. Obwohl die Führungskräfte auf die Konkurrenz achten, sind sie von den Kunden besessen."

Unterstützung der AWS-Entwicklergemeinschaft

Die AWS-Entwicklergemeinschaft ist ein unglaublich aktives und unterstützendes technisches Forum. Es gibt mehrere Möglichkeiten, Teil dieser Community zu werden, und das ist sehr empfehlenswert, sowohl für dein Wachstum als Serverless-Ingenieur als auch um die erfolgreiche Einführung von Serverless in deinem Unternehmen sicherzustellen. Dazu gehören:

Verbinde dich mit AWS Developer Advocates (DAs).

Die DAs von AWS verbinden die Entwicklergemeinschaft mit den verschiedenen Produktteams bei AWS. Du kannst die Serverless-Entwicklungen in den sozialen Medien verfolgen. Die auf Serverless spezialisierten DAs helfen der Community, indem sie Fragen beantworten und technische Inhalte über Blogs, Live-Streams und Videos, GitHub-Code-Shares, Konferenzen, Meetups usw. beisteuern.

Wende dich an AWS Heroes und Community Builders.

Das AWS Heroes-Programm zeichnet AWS-Experten aus, deren Beiträge einen echten Einfluss auf die Tech-Community haben. Außerhalb von AWS teilen diese Experten ihr Wissen und ihre Erfahrungen bei der Einführung von Serverless.

Zum Zeitpunkt der Erstellung dieses Buches wurde Sheen Brisals als AWS Serverless Hero ausgezeichnet.

Das AWS Community Builders-Programm ist eine weltweite Initiative, die AWS-Enthusiasten und aufstrebende Experten zusammenbringt, die leidenschaftlich gerne Wissen teilen und sich mit AWS-Produktteams und DAs, Heroes und Branchenexperten austauschen. Wenn du die Builders kennenlernst, die zum Serverless-Bereich beitragen, und von ihren Erfahrungen lernst, kannst du dein Wissen vertiefen.

Zum Zeitpunkt des Verfassens dieses Buches ist Luke Hedger als AWS Community Builder anerkannt worden.

Tritt einem AWS Cloud Club bei.

Es gibt eine florierende, von Studierenden geführte Community mit AWS Cloud Clubs in mehreren Regionen weltweit. Studierende können ihrem lokalen Club beitreten, um sich zu vernetzen, mehr über AWS zu erfahren und ihre Karriere voranzutreiben. Cloud Club Captains organisieren Veranstaltungen, um gemeinsam zu lernen, sich mit anderen Clubs zu vernetzen und unter anderem AWS Credits und Zertifizierungsgutscheine zu verdienen.

Melde dich bei AWS Startup oder AWS Educate an.

AWS hat beliebte Programme, die dir helfen, deine Ideen zu verwirklichen. AWS Activate ist für alle, die große Ideen und Ambitionen haben oder Start-ups, die weniger als 10 Jahre alt sind. AWS bietet die notwendigen Werkzeuge, Ressourcen, Kredite und Ratschläge, um den Erfolg in jeder Phase der Reise zu fördern.

AWS Educate ist eine Lernressource für Studierende und Fachkräfte. Es bietet AWS-Credits, die für Kurse und Projekte verwendet werden können, Zugang zu kostenlosen Schulungen und Networking-Möglichkeiten.

Nimm an AWS-Konferenzen teil.

Ein wesentlicher Teil der Reise eines Unternehmens zur Einführung von Serverless ist die kontinuierliche Evaluierung seiner Entwicklungsprozesse, Domänen, Teamorganisation, Entwicklungskultur, bewährten Methoden usw. Konferenzen und Veranstaltungen zur Zusammenarbeit sind die perfekten Plattformen, um Lösungen für deine Probleme zu finden, deine Ideen zu überprüfen und Korrekturmaßnahmen zu ermitteln, bevor es zu spät ist.

Art und Umfang der Konferenzen variieren. Die AWS re:Invent zum Beispiel ist eine jährliche einwöchige Konferenz, die Zehntausende von Tech- und Business-Enthusiasten mit Hunderten von Sitzungen über fünf Tage verteilt zusammenbringt, während AWS Summits und AWS Community Summits lokale, meist eintägigeVeranstaltungen sind , dieauf der ganzen Welt stattfinden, um die Community und Technologieexperten näher zusammenzubringen. Die meisten Inhalte werden auch online geteilt. AWS Events und Webinare ist ein guter Ort, um Veranstaltungen zu finden, die für deine Zwecke geeignet sein könnten .

Zusammenfassung

Wenn du deine serverlose Reise beginnst, entweder als unabhängiger Lernender oder als Teil eines Unternehmensteams, ist es wichtig zu verstehen, wie die Cloud entstanden ist und wie sie die Entwicklung der serverlosen Technologie ermöglicht hat. Dieses Kapitel hat diese Grundlage geschaffen und das erhebliche Potenzial von Serverless und die Vorteile, die es einem Unternehmen bieten kann, aufgezeigt.

Jede Technologie braucht eine solide Plattform, um zu gedeihen, und eine leidenschaftliche Community, die sie unterstützt. Amazon Web Services (AWS) ist zwar nicht die einzige Option, aber eine fantastische Plattform mit zahlreichen Serviceangeboten und speziellen Supportprogrammen für Entwickler. Wie in diesem Kapitel hervorgehoben wird, ist es für eine erfolgreiche Einführung von Serverless von entscheidender Bedeutung, dass du deine Erfahrungen mit anderen teilst und von ausgewiesenen Branchenexperten lernst.

Im nächsten Kapitel befassen wir uns mit der Einführung von Serverless in einem Unternehmen. Wir werden einige der grundlegenden Dinge untersuchen, die ein Unternehmen bewerten und tun muss, um Serverless einzuführen und es zu einem erfolgreichen Projekt für seine Ingenieure, Nutzer und sein Geschäft zu machen.

Interview mit einem Branchenexperten

Danilo Poccia, Chef-Evangelist (EMEA), Amazon Web Services

Danilo arbeitet mit Start-ups und Unternehmen jeder Größe zusammen, um sie bei ihren Innovationen zu unterstützen. In seiner Funktion als Chief Evangelist (EMEA) bei Amazon Web Services setzt er seine Erfahrung ein, um Menschen dabei zu helfen, ihre Ideen zum Leben zu erwecken. Dabei konzentriert er sich auf serverlose Architekturen und ereignisgesteuerte Programmierung sowie auf die technischen und geschäftlichen Auswirkungen von maschinellem Lernen und Edge Computing. Er ist der Autor von AWS Lambda in Action: Event-Driven Serverless Applications (Manning) und spricht auf Konferenzen weltweit.

F: Warum braucht die Softwarebranche die serverlose Technologie?

Wenn du eine Anwendung entwickelst, kann es kompliziert werden, sie einzusetzen, zu testen oder früher oder später eine neue Funktion hinzuzufügen, ohne die bestehenden Funktionen zu zerstören. In den letzten 20 Jahren hat sich die Komplexität zu einer Wissenschaft entwickelt, die in vielen verschiedenen Bereichen wie der Mathematik, der Physik und den Sozialwissenschaften Ähnlichkeiten aufweist. Die Komplexitätstheorie besagt, dass bei starken Abhängigkeiten zwischen Komponenten, selbst einfachen Komponenten, "komplexe" und schwer vorhersehbare Verhaltensweisen entstehen können. Das Verhalten einer Ameise ist zum Beispiel sehr einfach, aber gemeinsam können Ameisen an abgelegenen Orten verstecktes Futter entdecken und es zu ihrem Nest zurückbringen. Das Auftreten unerwarteter Verhaltensweisen lässt sich sehr gut auf die Softwareentwicklung übertragen.

Wenn du eine große Codebasis hast, ist es sehr aufwändig, Seiteneffekte zu reduzieren, damit du nicht etwas anderes kaputt machst, wenn du eine neue Funktion hinzufügst. Meiner Erfahrung nach funktionieren monolithische Anwendungen mit einer großen Codebasis nur, wenn es ein kleines Kernteam von Entwicklern gibt, das seit Jahren an derselben Anwendung arbeitet und viel Erfahrung in der Geschäftsdomäne gesammelt hat. Microservices sind zwar hilfreich, aber du brauchst immer noch Kenntnisse der Geschäftsdomäne, um herauszufinden, wo du die Anwendung aufteilen musst. Das ist es, was das domänenorientierte Design (DDD) den "begrenzten Kontext" nennt. Aus diesem Grund sind Microservices erfolgreicher, wenn sie als Migration einer bestehenden Anwendung implementiert werden, als wenn du bei Null anfängst. Wenn die Grenzen gut gewählt und definiert sind, begrenzst du die internen Abhängigkeiten, um die Gesamtkomplexität des Codes und das Auftreten unerwarteter Probleme zu verringern.

Dennoch bringt jeder Microservice seine nichtfunktionalen Anforderungen in Bezug auf Sicherheit, Zuverlässigkeit, Skalierbarkeit, Beobachtbarkeit, Leistung und so weiter mit. Die serverlose Architektur hilft dabei, diese nicht-funktionalen Anforderungen viel einfacher umzusetzen. Sie kann die Gesamtgröße des Codes reduzieren, indem sie Dienste zur Implementierung von Funktionen nutzt, die nicht nur für deine Implementierung gelten. So kannst du dich auf die Funktionen konzentrieren, die du entwickeln willst, und musst dich nicht um die Infrastruktur kümmern, die für den Betrieb der Anwendung erforderlich ist. Der Vorteil der serverlosen Technologien liegt nicht nur für die technischen Teams, sondern auch für die Unternehmensteams darin, dass sie ihren Kunden mehr und schneller liefern können.

F: Als Autor des ersten Buches über AWS Lambda, was hat sich seit deinen ersten Erfahrungen mit Serverless geändert?

Als ich das Buch 2016 schrieb, gab es nur sehr wenige Werkzeuge für AWS Lambda. In einigen Beispielen in meinem Buch rufe ich Lambda-Funktionen direkt aus dem Browser mit dem AWS SDK für JavaScript auf. In gewisser Weise finde ich das gar nicht schlecht. So kannst du dich mehr auf die Geschäftsfunktionen konzentrieren, die du implementieren musst. Auch wenn viele Kunden damals an AWS Lambda interessiert waren, gab es nur sehr wenige Beispiele für serverlose Arbeitslasten in der Produktion.

Die Idee für das Buch entstand aus einem Workshop, in dem ich zeigen wollte, wie man die Erstellung einer Anwendung vereinfachen kann. Ich beginne zum Beispiel mit Daten. Sind die Daten strukturiert? Lege sie in einer vollständig verwalteten Datenbank wie Amazon DynamoDB ab. Handelt es sich um unstrukturierte Daten? Lege sie in einem Amazon S3-Bucket ab. Wo befindet sich deine Geschäftslogik? Teile sie in kleine Funktionen auf und führe sie auf AWS Lambda aus. Können diese Funktionen auf einem Client oder in einem Webbrowser ausgeführt werden? Lege sie dort ab und führe den Code nicht im Backend aus. Das Ergebnis ist vielleicht das, was wir heute "servicevolle" Architektur nennen.

Heute gibt es viele Tools, die den Aufbau von serverlosen ereignisgesteuerten Anwendungen unterstützen, um Ereignisse zu verwalten (wie Amazon EventBridge) oder die Ausführung deiner Geschäftslogik zu koordinieren (wie AWS Step Functions). Dank besserer Tools können Kunden jetzt fortschrittlichere Anwendungen erstellen. Es geht nicht nur um serverlose Funktionen wie im Jahr 2016. Heute musst du überlegen, wie du die Tools zusammen nutzen kannst, um Anwendungen schneller zu erstellen und weniger Code zu pflegen.

F: In deiner Rolle als Technologie-Evangelist arbeitest du mit verschiedenen Teams zusammen. Wie ermöglicht die serverlose Technologie Teams unterschiedlicher Größe, innovativ zu sein und Lösungen schneller zu entwickeln?

Kleine Teams arbeiten besser. Serverless gibt kleinen Teams die Möglichkeit, mehr zu tun, weil sie die Teile entfernen können, die von einem bestehenden Dienst von der Stange implementiert werden können. Das bringt sie natürlich dazu, eine Microservice-Architektur zu übernehmen und verteilte Systeme zu nutzen. Das kann anfangs schwierig sein, wenn sie noch keine Erfahrung in diesen Bereichen haben, aber es lohnt sich, wenn sie es lernen und die Ergebnisse sehen.

Wenn du die Art und Weise, wie du Anwendungen entwickelst, grundlegend ändern musst, z. B. durch die Einführung von serverlosen oder Microservices, solltest du dich in eine Lage versetzen, in der du Fehler machen kannst. Aus Fehlern lernt man. Wenn du zur Produktion übergehst, hilft dir das Sammeln von Metriken zur Codekomplexität in deiner Deployment-Pipeline, die Codebasis unter Kontrolle zu halten. Um noch einen Schritt weiter zu gehen, finde ich die Idee einer "Fitnessfunktion" (wie sie in dem Buch Building Evolutionary Architectures von Rebecca Parsons, Neal Ford und Patrick Kua [O'Reilly] beschrieben wird) äußerst interessant, vor allem, wenn du "Leitplanken" dafür definierst, wie fit deine Anwendung sein sollte.

Automatisierung hilft in jeder Größenordnung, ist aber für kleine Teams unglaublich effektiv. Das AWS Well-Architected Framework bietet außerdem eine Möglichkeit, die Qualität deiner Implementierung zu messen, und stellt eine Serverless Lens mit spezifischen Anleitungen bereit.

F: Welche Maßnahmen ergreift AWS als führende Cloud-Plattform für die Entwicklung serverloser Anwendungen, um vorauszudenken und seinen Kunden neue Dienste anzubieten?

Ich habe vor mehr als 10 Jahren bei AWS angefangen. Damals waren die Dinge noch anders. Es galt als beeindruckend, eine EC2-Instanz in ein paar Minuten zu starten. Aber auch wenn einige Zeit vergangen ist, verwenden wir bei AWS immer denselben Ansatz, um neue Dienste und Funktionen zu entwickeln: Wir hören auf unsere Kunden. Unsere Roadmap basiert zu 90 bis 95 % auf dem, was unsere Kunden uns sagen. Für den Rest versuchen wir, neue Ideen aus den Erfahrungen einzubringen, die wir im Laufe der Jahre bei Amazon und AWS gesammelt haben.

Wir wollen Werkzeuge bauen, die helfen, die Probleme der Kunden zu lösen, nicht theoretische Fragen. Wir bauen sie so, dass die Kunden selbst entscheiden können, welche Tools sie nutzen wollen. Wir wollen neue Ideen schnell weiterentwickeln und dabei so viel Feedback wie möglich einholen.

F: Welchen Rat würdest du den Lesern geben, die ihre persönliche oder organisatorische Reise zur Einführung von Serverless beginnen?

Lerne das mentale Modell. Konzentriere dich nicht auf die Details der Umsetzung. Verstehe die Vor- und Nachteile der Verwendung von Microservices und verteilten Architekturen. Die Zeit wird wichtig, denn es gibt Latenzzeiten und Gleichzeitigkeit zu berücksichtigen. Entwirf deine Systeme für asynchrone Kommunikation und eventuelle Konsistenz.

Fehler sind ein natürlicher Teil einer jeden Architektur. Überlege dir eine Strategie zur Wiederherstellung und zum Umgang mit Fehlern. Kannst du aufzeichnen und wiederholen, was deine Anwendung gerade tut? Können Ereignisse dir dabei helfen? Zwei Kernanforderungen, die heute noch wichtiger sind als früher, sind Beobachtbarkeit und Nachhaltigkeit. Sie sind enger miteinander verbunden, als man auf den ersten Blick denken könnte.

Übertrage die Teile, die nicht einzigartig für deine Anwendung sind, auf Dienstleistungen und SaaS-Angebote, die diese Funktionen für dich implementieren können. Konzentriere dich auf das, was du bauen willst. Dort kannst du einen Unterschied machen.

1 Ein Modul ist eine unabhängige und in sich geschlossene Einheit der Software.

Get Serverlose Entwicklung auf AWS now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial