Referenzarchitekturen für serverlose Functions

Eine Referenzarchitektur ist eine Vorlage mit erforderlichen Komponenten und den technischen Anforderungen an deren Implementierung. Eine Referenzarchitektur ist keine auf einen bestimmten Kunden zugeschnittene Lösung, sondern ein abstraktes Szenario auf Grundlage umfassender Erfahrung. Verwenden Sie eine Referenzarchitektur, bevor Sie selbst eine serverlose Lösung entwerfen, um eine ideale technische Architektur zu veranschaulichen und dann an Ihre Umgebung anzupassen und in diese zu integrieren.

Allgemeine serverlose Architekturmuster

Zu den gängigen serverlosen Architekturmustern gehören:

  • Serverlose APIs, mobile und Web-Back-Ends.
  • Ereignis- und Streamverarbeitung, Datenverarbeitung für Internet der Dinge (Internet of Things, IOT), Big Data- und Machine Learning-Pipelines.
  • Integration und Enterprise Service Bus zum Verbinden von Branchensystemen, Veröffentlichen und Abonnieren (Pub/Sub) von Geschäftsereignissen.
  • Automatisierung und digitale Transformation sowie Prozessautomatisierung.
  • Middleware, Software-as-a-Service (SaaS) wie Dynamics und Big Data-Projekte.

Webanwendungs-Back-Ends

Einzelhandelsszenario: Abrufen von Onlinebestellungen aus einer Warteschlange, Verarbeiten und Speichern der resultierenden Daten in einer Datenbank

Diagram shows a request made in a web app queued in Service Bus, then processed by a function and sent to Cosmos DB.

Back-Ends für mobile Anwendungen

Finanzdienstleistungsszenario: Kollegen verwenden Mobile Banking, um untereinander die Kosten für das Mittagessen zu erstatten. Derjenige, der das Mittagessen bezahlt hat, fordert über eine mobile App eine Zahlung an, indem er eine Benachrichtigung auf den Smartphones seiner Kollegen auslöst.

Diagram shows an H T T P A P I call, processed by a function and sent to Cosmos DB which triggers another function to send notifications.

Back-Ends mit IoT-Verbindung

Produktionsszenario: Ein Produktionsunternehmen überwacht seine Maschinen mit IoT. Functions erkennt ungewöhnliche Daten und löst eine Meldung an die Störungsstelle aus, wenn eine Reparatur erforderlich ist.

Diagram shows I o T devices that produce requests for repair, which are sent to the I o T Hub, then routed for processing by using Zendesk.

Verarbeitung für einen interaktiven Bot

Tourismusszenario: Kunden fordern verfügbare Unterkünfte auf ihren Smartphones an. Ein serverloser Bot analysiert die Anforderungen und gibt mögliche Unterkünfte zurück.

Diagram shows a user request through a conversational interface that a bot deciphers for another function to process the request.

Echtzeit-Dateiverarbeitung

Medizinisches Szenario: Die Lösung lädt Patientendatensätze sicher als PDF-Dateien hoch. Die Lösung liest dann die Daten aus, verarbeitet sie mit optischer Zeichenerkennung und fügt sie einer Datenbank hinzu, um einfache Abfragen zu ermöglichen.

Diagram shows patient records uploaded, then decomposed and sent to Cognitive Services to be structured into a database.

Streamverarbeitung in Echtzeit-

ISV-Szenario (Independent Software Vendor): Eine umfangreiche Cloud-App sammelt große Mengen an Telemetriedaten. Diese Daten werden von der App nahezu in Echtzeit verarbeitet und für die Verwendung in einem Analytics-Dashboard in einer Datenbank gespeichert.

Diagram shows an app that collects data, which is ingested by Event Hubs, processed by a function, and sent to Cosmos DB.

Automatisierung geplanter Aufgaben

Finanzdienstleistungsszenario: Die App analysiert eine Kundendatenbank alle 15 Minuten auf doppelte Einträge, um zu vermeiden, dass mehrere Mitteilungen an dieselben Kunden gesendet werden.

Diagram shows a database which is cleaned by a function every 15 minutes, which removes duplicate entries.

Erweitern von SaaS-Anwendungen

Dienstleistungsszenario: Eine SaaS-Lösung bietet Erweiterbarkeit durch Webhooks, die Functions implementieren kann, um bestimmte Workflows zu automatisieren.

Diagram shows an issue created in GitHub, which triggers a webhook call, which is processed by a function by posting the issue details to Slack.

In den folgenden ausgewählten serverlosen Referenzarchitekturen werden bestimmte Szenarien im Einzelnen beschrieben. In den verknüpften Artikeln finden Sie Diagramme und Details zur Architektur.

Serverlose Microservices

In der Referenzarchitektur für serverlose Microservices werden Sie durch das Entwerfen, Entwickeln und Bereitstellen der Rideshare-Anwendung des fiktiven Unternehmens Relecloud geführt. Hier finden Sie praktische Anleitungen zum Konfigurieren und Bereitstellen aller Architekturkomponenten mit hilfreichen Informationen zu den einzelnen Komponenten.

Serverlose Webanwendung und Ereignisverarbeitung mit Azure Functions

Diese zweiteilige Lösung beschreibt ein hypothetisches Auslieferungssystem mit Drohnen. Drohnen senden den Flugstatus an die Cloud, wo diese Nachrichten zur späteren Verwendung gespeichert werden. Mithilfe einer Webanwendung können Benutzer die Nachrichten abrufen, um den aktuellen Gerätestatus zu ermitteln.

Ereignisbasierte Cloudautomatisierung

Die Automatisierung von Workflows und Routineaufgaben in der Cloud kann die Produktivität eines DevOps-Teams erheblich erhöhen. Ein serverloses Modell eignet sich am besten für ereignisgesteuerte Automatisierungsszenarien. In dieser ereignisbasierten Automatisierungsreferenzarchitektur werden zwei Cloudautomatisierungsszenarien veranschaulicht: Tagging von Kostenstellen und Drosselungsreaktion.

Multicloudlösungen mit Serverless Framework

In der Serverless Framework-Architektur wird beschrieben, wie das Microsoft CSE-Team (Commercial Software Engineering) gemeinsam mit einem globalen Vertriebspartner eine serverlose Hochverfügbarkeitslösung für die Azure- und AWS-Cloudplattform (Amazon Web Services) bereitgestellt hat.

Weitere Referenzarchitekturen für serverlose Functions

In den folgenden Abschnitten werden weitere serverlose und Azure Functions-Referenzarchitekturen und -szenarien aufgelistet.

Allgemein

Web- und mobile Back-Ends

KI und Machine Learning

Daten und Analysen

IoT

Spiele

Automation