.NET-Workloads in AWS Lambda

Bevor wir über Serverless-Computing sprechen, wollen wir uns kurz mit dem traditionellen Computing befassen.

Viele Unternehmen, sowohl kleine als auch große, verwenden lokale Server oder Server in Rechenzentren, um ihre Anwendungen auszuführen. Wenn diese Unternehmen mehr Server benötigen, müssen sie diese kaufen, physisch installieren, konfigurieren, sichern und warten. (In einigen Fällen kümmert sich ein Rechenzentrum möglicherweise darum, sie in Ihrem Namen physisch zu installieren, aber alles andere fällt in Ihren Aufgabenbereich.)

Anschließend kann das Unternehmen seine Anwendungen auf diesen Servern bereitstellen. Bei vielen Unternehmen kann dies Wochen oder Monate dauern. Diese Verzögerungen haben in der Vergangenheit die Skalierung von Anwendungen erschwert.

Mit Cloud-Computing hat sich vieles verändert. Ein Unternehmen kann innerhalb von Minuten eine Server-Instance (oder auch mehrere Instances) starten. Das Unternehmen kann seine eigenen Machine Images erstellen, wobei die virtuelle Maschine und das Betriebssystem genau so konfiguriert sind, wie das Unternehmen es möchte. Dies reduziert den Konfigurationsaufwand, der nach dem Start des Servers erforderlich ist, der Server muss jedoch weiterhin mit Patches, Sicherheitsupdates, Softwareupdates usw. auf dem neuesten Stand gehalten werden.

In vielen Fällen werden diese Server oft rund um die Uhr in Betrieb gehalten, obwohl sie die ganze Zeit nicht genutzt werden. Die Server sind oft so eingerichtet, dass sie die Spitzenlast bewältigen, die die Anwendung erwartet. Außerhalb dieses Spitzenwerts sind die Server jedoch zumindest teilweise inaktiv. Es können entsprechende Skalierungsrichtlinien verwendet werden, um die dieses Problem zu reduzieren, aber es kann schwierig sein, es vollständig zu korrigieren.

Außerdem führen die Bereitstellung und Wartung der Server sowie die Zeit, die die Server im Leerlauf verbringen, zu Kosten, die für das Unternehmen von Nachteil sind.
Eine Alternative dazu ist Serverless-Computing. Es gibt keine Server, es gibt keine Wartung und die Skalierung wird für Sie erledigt. Sie schreiben Ihren Code, stellen ihn bereit und lassen AWS die Infrastruktur für Sie übernehmen.

AWS bietet zwei Optionen für Serverless-Computing: AWS Fargate für containerbasierte Anwendungen und AWS Lambda für ereignisgesteuerte Anwendungen.

AWS Lambda ist ein Serverless-Compute-Service, der Ihren Code als Reaktion auf vom Service empfangene Ereignisse ausführt. Ereignisse können von anderen AWS-Services wie SNS, SQS, S3, DynamoDB, API Gateway usw. generiert werden.

Mithilfe eines API-Gateways oder von Lambda-Funktions-URLs können Sie als Antwort auf eine HTTP-Anfrage die Ausführung einer Lambda-Funktion auslösen. Lambda-Funktionen können auch direkt aufgerufen werden, obwohl auch dies als Ereignis betrachtet wird.

Sie müssen keine Infrastruktur bereitstellen, um AWS Lambda verwenden zu können. AWS kümmert sich auch um die automatische Skalierung, damit die Anforderungen Ihrer Anwendung erfüllt werden, unabhängig davon, ob es sich um einige Ausführungen pro Tag oder Zehntausende pro Sekunde handelt. Die von AWS verwaltete Lambda-Infrastruktur ist hochverfügbar und fehlertolerant.

Mit Lambda-Funktionen zahlen Sie nur für die Rechenressourcen, die Sie nutzen. Wenn Ihr Code nicht ausgeführt wird, zahlen Sie nicht.

Sie schreiben Ihre .NET-Anwendungen mithilfe der IDEs, mit denen Sie bereits vertraut sind, und stellen Ihre Anwendung dann mithilfe von AWS-Tools (oder einer IaC Ihrer Wahl) in AWS Lambda bereit.

Wenn eine Lambda-Funktion durch ein Ereignis aufgerufen wird, eine Ausführungsumgebung erstellt wird, Ihr Initialisierungscode ausgeführt wird (Konstruktoren usw.), dann wird Ihr Code zur Behandlung des Ereignisses ausgeführt.

Nach Abschluss der Ausführung steht die Ausführungsumgebung für einen nicht festgelegten Zeitraum zur Wiederverwendung zur Verfügung.

Wenn ein anderes Ereignis eintritt, wird dieselbe Ausführungsumgebung verwendet, und der Initialisierungscode wird nicht erneut ausgeführt.

Wenn keine Ausführungsumgebung verfügbar ist, wird eine neue erstellt und der Initialisierungscode wird erneut ausgeführt.

AWS-Lambda-Funktionen bieten derzeit verwaltete Laufzeiten für .NET Core 3.1 und .NET 6. Wenn Sie Anwendungen in anderen .NET-Versionen schreiben möchten, können Sie benutzerdefinierte Lambda-Laufzeiten oder eine containerbasierte Version Ihrer Anwendung verwenden.

AWS stellt C#- und F#-Projektvorlagen für Lambda-Funktionen bereit. Diese können über die Befehlszeile, Visual Studio, Visual Studio Code und Rider verwendet werden.

Sie können Ihre .NET-Lambda-Funktion auf x86_64- und arm64-Prozessoren ausführen. Die Wahl der Prozessorarchitektur hat keinen Einfluss darauf, wie Sie Ihre Anwendungen schreiben. Für die Bereitstellung auf dem Prozessor Ihrer Wahl müssen Sie lediglich einen einzelnen Konfigurationsparameter ändern.

Sie müssen keine neue Sprache lernen. Verwenden Sie Ihre vorhandenen C#- und F#-Kenntnisse, um Ihre Lambda-Funktionen zu schreiben.

Sie können Lambda-Funktionen mit anderen AWS-Services wie SNS, SQS, S3, Step Functions und DynamoDB verwenden, um ereignisgesteuerte Anwendungen zu erstellen. Oder Sie führen benutzerdefinierte Aufgaben als Reaktion auf Ereignisse aus diesen Services aus.

Wenn Sie mehrere laufende Lambda-Funktionen orchestrieren müssen, können Sie AWS Step Functions verwenden. Mit Step Functions erstellen Sie eine Zustandsmaschine, die die Ausführung Ihrer Lambda-Funktionen verwaltet.

Sie brauchen keine Infrastruktur bereitzustellen oder zu verwalten. AWS nimmt Ihnen diese Arbeit ab. Sie müssen lediglich die Prozessorarchitektur und die Größe des Speichers auswählen, die der Funktion zugewiesen werden sollen. Basierend auf Ihrer Speicherauswahl wählt AWS die geeignete CPU-Geschwindigkeit, Netzwerkbandbreite und Festplatten-I/O aus.

Ihre Lambda-Funktionen sind hochverfügbar und fehlertolerant und werden in mehreren Availability Zones in jeder Region ausgeführt.

AWS-Lambda-Funktionen starten innerhalb von Millisekunden nach dem Eintreffen eines Ereignisses und können schnell und automatisch skaliert werden, um dem Umfang der eingehenden Ereignisse zu entsprechen.

Sie zahlen nur für das, was Sie nutzen, und das wird auf die Millisekunde der Nutzung genau abgerechnet.

Lambda hat ein großzügiges, immer kostenloses Kontingent, mit dem Sie eine Million kostenlose Anfragen pro Monat und 400.000 GB-Sekunden Rechenzeit pro Monat ausführen können

Wenn Sie hohe Datenverkehrsmuster haben, skaliert Lambda, um diese Anforderungen zu erfüllen, und wenn der Datenverkehr abnimmt, zahlen Sie nicht für die Ressourcen, die nicht mehr benötigt werden.

Lambda ist Teil von Compute Savings Plans, der niedrigere Preise als Gegenleistung für eine verbindliche Nutzung einer bestimmten Menge an Rechenzeit über einen Zeitraum von ein bis drei Jahren anbietet.

Im nächsten Abschnitt werden Sie sehen, wie einfach es ist, mit AWS Lambda zu beginnen. Mit nur wenigen Minuten Arbeit können Sie zwei AWS-Lambda-Funktionen für .NET in der Cloud ausführen

Geschätzte Zeit: 30 Minuten

Bitte beachten Sie, dass Sie den hier vorgestellten Beispielen folgen können, dies aber nicht müssen.

Wenn Sie noch nie mit Serverless-Technologie gearbeitet haben, mag dies zunächst abschreckend erscheinen. Es kann schon schwierig sein, herauszufinden, wie Sie anfangen müssen.

Am Ende dieses kurzen Moduls werden Sie über zwei .NET-Lambda-Funktionen verfügen, die in AWS ausgeführt werden.

Eine rufen Sie über die Befehlszeile auf, die andere über einen öffentlichen HTTPS-Endpunkt, den Sie fast mühelos einrichten.

Sie verwenden die Befehlszeile, um beide Beispiele zu erstellen, zu bauen und bereitzustellen.

Dies ist die einfachste Lambda-Funktion, die Sie schreiben können. Sie nimmt einige Eingaben entgegen und gibt eine Antwort zurück. In wenigen Minuten ist sie einsatzbereit.

In dieser Demo erstellen Sie eine .NET-API-Anwendung, die HTTPS-Anfragen verarbeitet. Sie können die neuere Minimal-API-Vorlage oder die ältere vollständige API mit Controller-Vorlage verwenden – die Schritte sind dieselben. Wenn Sie mit den Top-Level-Anweisungen und API-Endpunkten von.NET 6 vertraut sind, sollten Sie die Minimalvorlage serverless.AspNetCoreMinimalAPI verwenden. Wenn Sie mit Top-Level-Anweisungen nicht vertraut sind, verwenden Sie die ältere Vorlage serverless.AspNetCoreWebAPI.