Cloudautomatisering op basis van gebeurtenissen

Het automatiseren van werkstromen en terugkerende taken in de cloud, met behulp van serverloze technologieën, kan de productiviteit van het DevOps-team van een organisatie aanzienlijk verbeteren. Een serverloos model is het meest geschikt voor automatiseringsscenario's die passen bij een gebeurtenisgestuurde benadering.

Architectuur

Scenario's

In dit artikel worden twee belangrijke scenario's voor cloudautomatisering beschreven:

1. Taggen van kostenplaats: met deze implementatie worden de kostenplaatsen van elke Azure-resource bijgehouden. De Azure Policy-servicetagt alle nieuwe resources in een groep met een standaardkostenplaats-id. Azure Event Grid bewaakt gebeurtenissen voor het maken van resources en roept vervolgens een Azure-functie aan. De functie communiceert met Microsoft Entra-id en valideert de kostenplaats-id voor de nieuwe resource. Als dit anders is, wordt de tag bijgewerkt en wordt er een e-mailbericht naar de resource-eigenaar verzonden. De REST-query's voor Microsoft Entra-id worden ter vereenvoudiging gesimuleerd. Microsoft Entra ID kan ook worden geïntegreerd met behulp van de Microsoft Graph PowerShell-module of de Microsoft Authentication Library (MSAL) voor Python.

2. Beperkingsreactie: in dit voorbeeld wordt een Azure Cosmos DB-database bewaakt voor beperking. Azure Monitor-waarschuwingen worden geactiveerd wanneer aanvragen voor gegevenstoegang tot Azure Cosmos DB de capaciteit in aanvraageenheden (of RU's) overschrijden. Een Azure Monitor-actiegroep is geconfigureerd om de automatiseringsfunctie aan te roepen als reactie op deze waarschuwingen. De functie schaalt de RU's naar een hogere waarde, verhoogt de capaciteit en stopt vervolgens de waarschuwingen.

De referentie-implementatie voor scenario één is beschikbaar op GitHub.

De functies in deze serverloze cloudautomatiseringsscenario's worden vaak geschreven in PowerShell en Python, twee van de meest voorkomende scripttalen die worden gebruikt in systeemautomatisering. Ze worden geïmplementeerd met behulp van Azure Functions Core Tools in Azure CLI. U kunt ook de PowerShell-cmdlet Az.Functions gebruiken om Azure Functions te implementeren en te beheren.

Werkstroom

Automatiseringsscenario's op basis van gebeurtenissen kunnen het beste worden geïmplementeerd met behulp van Azure Functions. Ze volgen deze veelvoorkomende patronen:

• Reageren op gebeurtenissen op resources. Dit zijn reacties op gebeurtenissen zoals een Azure-resource of resourcegroep die wordt gemaakt, verwijderd, gewijzigd, enzovoort. Dit patroon maakt gebruik van Event Grid om de functie voor dergelijke gebeurtenissen te activeren. Het tagscenario voor kostenplaats is een voorbeeld van dit patroon. Andere veelvoorkomende scenario's zijn:

  • het verlenen van de DevOps-teams toegang tot nieuw gemaakte resourcegroepen,
  • melding verzenden naar DevOps wanneer een resource wordt verwijderd en
  • Reageren op onderhoudsevenementen voor resources zoals virtuele Azure-machines (VM's).

• Geplande taken. Dit zijn doorgaans onderhoudstaken die worden uitgevoerd met behulp van door timer geactiveerde functies. Voorbeelden van dit patroon zijn:

  • stoppen van een resource 's nachts en beginnend in de ochtend,
  • Blob Storage-inhoud met regelmatige tussenpozen lezen en converteren naar een Azure Cosmos DB-document,
  • periodiek scannen op resources die niet meer in gebruik zijn en verwijderen, en
  • geautomatiseerde back-ups.

• Azure-waarschuwingen verwerken. Dit patroon maakt gebruik van het gemak van het integreren van Azure Monitor-waarschuwingen en actiegroepen met Azure Functions. De functie voert doorgaans herstelacties uit als reactie op metrische gegevens, logboekanalyse en waarschuwingen die afkomstig zijn uit de toepassingen en de infrastructuur. Het scenario met beperkingsreacties is een voorbeeld van dit patroon. Andere veelvoorkomende scenario's zijn:

  • De tabel afkappen wanneer SQL Database de maximale grootte bereikt,
  • een service opnieuw opstarten in een VIRTUELE machine wanneer deze ten onrechte wordt gestopt en
  • meldingen verzenden als een functie mislukt.

• Organiseren met externe systemen. Dit patroon maakt integratie met externe systemen mogelijk met behulp van Logic Apps om de werkstroom te organiseren. Logic Apps-connectors kunnen eenvoudig worden geïntegreerd met verschillende services van derden en Microsoft-services zoals Microsoft 365. Azure Functions kan worden gebruikt voor de daadwerkelijke automatisering. In het tagscenario voor kostenplaats wordt dit patroon gedemonstreerde. Andere veelvoorkomende scenario's zijn:

  • IT-processen bewaken, zoals wijzigingsaanvragen of goedkeuringen, en
  • e-mailmelding verzenden wanneer de automatiseringstaak is voltooid.

• Beschikbaar maken als webhook of API. Automatiseringstaken met behulp van Azure Functions kunnen worden geïntegreerd in toepassingen van derden of zelfs opdrachtregelprogramma's door de functie beschikbaar te maken als webhook/API met behulp van een HTTP-trigger. Er zijn meerdere verificatiemethoden beschikbaar in PowerShell en Python om externe toegang tot de functie te beveiligen. De automatisering vindt plaats als reactie op de app-specifieke externe gebeurtenissen, bijvoorbeeld integratie met Power Apps of GitHub. Veelvoorkomende scenario's:

  • automatisering activeren voor een mislukte service en
  • onboarding van gebruikers naar de resources van de organisatie.

• ChatOps-interface maken. Met dit patroon kunnen klanten een operationele interface op basis van chats maken en ontwikkelings- en bewerkingsfuncties en -opdrachten uitvoeren in overeenstemming met menselijke samenwerking. Dit kan worden geïntegreerd met Azure Bot Framework en microsoft Teams- of Slack-opdrachten gebruiken voor implementatie, bewaking, veelgestelde vragen, enzovoort. Een ChatOps-interface maakt een realtime systeem voor het beheren van productie-incidenten, waarbij elke stap automatisch wordt gedocumenteerd in de chat. Lees hoe ChatOps u kan helpen DevOps beter te gebruiken voor meer informatie.

• Hybride automatisering. Dit patroon maakt gebruik van de Azure-app Service Hybrid Verbinding maken ions voor het installeren van een softwareonderdeel op uw lokale computer. Met dit onderdeel kunt u beveiligde toegang krijgen tot resources op die computer. De mogelijkheid om hybride omgevingen te beheren, is momenteel beschikbaar op Windows-systemen met behulp van PowerShell-functies. Veelvoorkomende scenario's:

  • uw on-premises machines beheren en
  • andere systemen achter de firewall beheren (bijvoorbeeld een on-premises SQL Server) via een jumpserver.

Onderdelen

De architectuur bestaat uit de volgende onderdelen:

• Azure Functions. Azure Functions biedt de gebeurtenisgestuurde, serverloze rekenmogelijkheden in deze architectuur. Een functie voert automatiseringstaken uit wanneer deze worden geactiveerd door gebeurtenissen of waarschuwingen. In twee scenario's wordt een functie aangeroepen met een HTTP-aanvraag. Codecomplexiteit moet worden geminimaliseerd door de functie te ontwikkelen die staatloos en idempotent is.

  Meerdere uitvoeringen van een idempotente functie maken dezelfde resultaten. Om idempotentie te behouden, wordt het schalen van de functie in het beperkingsscenario simplistisch gehouden. In de praktijk moet u ervoor zorgen dat u omhoog of omlaag schaalt. Lees de prestaties en betrouwbaarheid van Azure Functions optimaliseren voor aanbevolen procedures bij het schrijven van uw functies.

• Azure Logic Apps. Logic Apps kan worden gebruikt om eenvoudigere taken uit te voeren, eenvoudig te implementeren met behulp van de ingebouwde connectors. Deze taken kunnen variëren van e-mailmeldingen tot integratie met externe beheertoepassingen. Lees de basisintegratie van ondernemingen in Azure voor meer informatie over het gebruik van Logic Apps met toepassingen van derden.

  Logic Apps biedt geen ontwerpfunctie voor code of visuals met weinig code en kan alleen worden gebruikt in sommige automatiseringsscenario's. Lees deze vergelijking tussen Azure Functions en Logic Apps om te zien welke service geschikt is voor uw scenario.

• Event Grid. Event Grid biedt ingebouwde ondersteuning voor gebeurtenissen van andere Azure-services, evenals aangepaste gebeurtenissen (ook wel aangepaste onderwerpen genoemd). Operationele gebeurtenissen, zoals het maken van resources, kunnen eenvoudig worden doorgegeven aan de automatiseringsfunctie met behulp van het ingebouwde mechanisme van Event Grid.

  Event Grid vereenvoudigt de automatisering op basis van gebeurtenissen met een model voor publiceren/abonneren, waardoor betrouwbare automatisering mogelijk is voor gebeurtenissen die via HTTPS worden geleverd.

• Azure Monitor. Azure Monitor-waarschuwingen kunnen controleren op kritieke omstandigheden en corrigerende maatregelen nemen met behulp van Azure Monitor-actiegroepen. Deze actiegroepen zijn eenvoudig geïntegreerd met Azure Functions. Dit is handig om eventuele foutvoorwaarden in uw infrastructuur te bekijken en op te lossen, zoals databasebeperking.

• Automatiseringsactie. Dit brede blok vertegenwoordigt andere services waarmee uw functie kan communiceren, om de automatiseringsfunctionaliteit te bieden. Bijvoorbeeld Microsoft Entra-id voor tagvalidatie, zoals in het eerste scenario, of een database die moet worden ingericht als in het tweede scenario.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Tolerantie

Azure Functions

HTTP-time-outs verwerken

Als u HTTP-time-outs voor een langere automatiseringstaak wilt voorkomen, moet u deze gebeurtenis in een Service Bus in de wachtrij plaatsen en de werkelijke automatisering in een andere functie afhandelen. In het automatiseringsscenario voor beperkingsreacties ziet u dit patroon, ook al is het inrichten van azure Cosmos DB RU's snel.

Durable Functions, die de status tussen aanroepen behouden, bieden een alternatief voor de bovenstaande benadering. Durable Functions biedt alleen ondersteuning voor specifieke talen.

Logboekfouten

Als best practice moet de functie eventuele fouten vastleggen bij het uitvoeren van automatiseringstaken. Hierdoor kunnen de foutvoorwaarden correct worden opgelost. Azure Functions biedt systeemeigen ondersteuning voor integratie met Application Insights als telemetriesysteem.

Gelijktijdigheid

Controleer de gelijktijdigheidsvereiste voor uw automatiseringsfunctie. Gelijktijdigheid wordt beperkt door de variabele maxConcurrentRequests in te stellen in het bestand host.json. Deze instelling beperkt het aantal gelijktijdige functie-exemplaren dat wordt uitgevoerd in uw functie-app. Aangezien elke instantie CPU en geheugen verbruikt, moet deze waarde worden aangepast voor CPU-intensieve bewerkingen. Verlaag de maxConcurrentRequests functieaanroepen als deze te traag lijken of niet kunnen worden voltooid. Zie de sectie Hostgedrag configureren om de gelijktijdigheid beter af te handelen voor meer informatie.

Idempotentie

Zorg ervoor dat uw automatiseringsfunctie idempotent is. Zowel Azure Monitor als Event Grid kunnen waarschuwingen of gebeurtenissen verzenden die aangeven dat de voortgang, zoals uw geabonneerde gebeurtenis, is opgelost, geactiveerd, wordt uitgevoerd, enzovoort, uw resource wordt ingericht, gemaakt, enzovoort, of zelfs valse waarschuwingen verzendt vanwege een onjuiste configuratie. Zorg ervoor dat uw functie alleen op de relevante waarschuwingen en gebeurtenissen reageert en negeert alle andere, zodat onwaar- of onjuist geconfigureerde gebeurtenissen geen ongewenste resultaten veroorzaken. Zie Azure Functions ontwerpen voor identieke invoer voor meer informatie.

Event Grid

Als uw werkstroom Gebruikmaakt van Event Grid, controleert u of uw scenario een groot aantal gebeurtenissen kan genereren, voldoende om het raster te verstoppen. Zie de bezorging van Event Grid-berichten en probeer opnieuw te begrijpen hoe gebeurtenissen worden verwerkt wanneer de bezorging niet wordt bevestigd en pas uw logica dienovereenkomstig aan. De kostenplaatswerkstroom implementeert hiervoor geen extra controles, omdat er alleen wordt gecontroleerd op gebeurtenissen voor het maken van resources in een resourcegroep. Het bewaken van resources die zijn gemaakt in een volledig abonnement, kan een groter aantal gebeurtenissen genereren, waarvoor een tolerantere verwerking is vereist.

Azure Monitor

Als er een voldoende groot aantal waarschuwingen wordt gegenereerd en Azure-resources worden bijgewerkt, kunnen de beperkingslimieten van Azure Resource Manager worden bereikt. Dit kan een negatieve invloed hebben op de rest van de infrastructuur in dat abonnement. Vermijd deze situatie door de frequentie te beperken van waarschuwingen die worden gegenereerd door Azure Monitor. U kunt ook de waarschuwingen beperken die worden gegenereerd voor een bepaalde fout. Raadpleeg de documentatie over Azure Monitor-waarschuwingen voor meer informatie.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Toegang tot de functie beheren

Beperk de toegang tot een door HTTP geactiveerde functie door het autorisatieniveau in te stellen. Met anonieme verificatie is de functie eenvoudig toegankelijk met een URL zoals http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. Verificatie op functieniveau kan het HTTP-eindpunt verdoezelen door functiesleutels in de URL te vereisen. Dit niveau is ingesteld in de file function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

Voor een productieomgeving zijn mogelijk extra strategieën vereist om de functie te beveiligen. In deze scenario's worden de functies uitgevoerd binnen het Azure-platform door andere Azure-services en worden ze niet blootgesteld aan internet. Functieautorisatie is soms voldoende voor functies die worden geopend als webhook.

Overweeg beveiligingslagen toe te voegen boven op functieverificatie, zoals:

• verifiëren met clientcertificaten of
• zorg ervoor dat de aanroeper deel uitmaakt van of toegang heeft tot de map die als host fungeert voor de functie door App Service-verificatie in te schakelen.

Verificatie op functieniveau is de enige optie die beschikbaar is voor Azure Monitor-actiegroepen met behulp van Azure Functions.

Als de functie moet worden aangeroepen vanuit een toepassing of service van derden, is het raadzaam om er toegang toe te bieden met een API Management-laag . Deze laag moet verificatie afdwingen. API Management heeft een verbruikslaag geïntegreerd met Azure Functions, waarmee u alleen kunt betalen als de API wordt uitgevoerd. Lees Uw functies maken en beschikbaar maken met OpenAPI voor meer informatie.

Als de aanroepende service service-eindpunten of private link ondersteunt, kunnen de volgende opties voor kostenbijters worden overwogen:

• Gebruik een toegewezen App Service-plan, waar u de functies in een virtueel netwerk kunt vergrendelen om de toegang tot het netwerk te beperken. Dit is niet mogelijk in een serverloos model op basis van verbruik.
• Gebruik het Azure Functions Premium-abonnement, dat een toegewezen virtueel netwerk bevat dat door uw functie-apps moet worden gebruikt.

Als u prijzen en functies tussen deze opties wilt vergelijken, leest u de schaal en hosting van Azure Functions.

Bepalen waartoe de functie toegang heeft

Beheerde identiteiten voor Azure-resources, een Microsoft Entra-functie, vereenvoudigt de verificatie en toegang tot andere Azure-resources en -services. De code hoeft de verificatiereferenties niet te beheren, omdat deze wordt beheerd door Microsoft Entra-id.

Er zijn twee typen beheerde identiteit:

• Door het systeem toegewezen beheerde identiteiten: deze worden gemaakt als onderdeel van de Azure-resource en kunnen niet worden gedeeld tussen meerdere resources. Deze worden verwijderd wanneer de resource wordt verwijderd. Gebruik deze voor scenario's waarbij één Azure-resource nodig is of waarvoor onafhankelijke identiteiten nodig zijn. In beide scenario's worden door het systeem toegewezen identiteiten gebruikt, omdat ze slechts één resource bijwerken. Beheerde identiteiten zijn alleen vereist om een andere resource bij te werken. Een functie kan bijvoorbeeld de resourcetags lezen zonder een beheerde identiteit. Zie deze instructies voor het toevoegen van een door het systeem toegewezen identiteit aan uw functie.

• Door de gebruiker toegewezen beheerde identiteiten: deze worden gemaakt als zelfstandige Azure-resources. Deze kunnen worden gedeeld over meerdere resources en moeten expliciet worden verwijderd wanneer ze niet meer nodig zijn. Lees deze instructies voor het toevoegen van door de gebruiker toegewezen identiteit aan uw functie. Gebruik deze voor scenario's die:

  • Toegang tot meerdere resources vereisen die één identiteit kunnen delen, of
  • Vooraf autorisatie nodig om resources te beveiligen tijdens het inrichten, of
  • Resources hebben die regelmatig worden gerecycled, terwijl machtigingen consistent moeten zijn.

Zodra de identiteit is toegewezen aan de Azure-functie, wijst u deze een rol toe met behulp van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor toegang tot de resources. Als u bijvoorbeeld een resource wilt bijwerken, moet de rol Inzender worden toegewezen aan de identiteit van de functie.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken. Hier volgen enkele overwegingen voor het verlagen van de kosten.

Azure Logic-apps

Logische apps hebben een prijsmodel voor betalen per gebruik. Triggers, acties en connectoruitvoeringen worden gemeten wanneer er een logische app wordt uitgevoerd. Alle geslaagde en mislukte acties, inclusief triggers, worden beschouwd als uitvoeringen.

Logische apps hebben ook een vast prijsmodel. Als u logische apps wilt uitvoeren die communiceren met beveiligde resources in een virtueel Azure-netwerk, kunt u deze maken in een ISE (Integration Service Environment).

Zie het prijsmodel voor Azure Logic Apps voor meer informatie.

In deze architectuur worden logische apps gebruikt in het kostenplaatslabelscenario om de werkstroom te organiseren.

Ingebouwde connectors worden gebruikt om verbinding te maken met Azure Functions en e-mailmeldingen te verzenden wanneer een automatiseringstaak is voltooid. De functies worden weergegeven als webhook/API met behulp van een HTTP-trigger. Logische apps worden alleen geactiveerd wanneer een HTTPS-aanvraag plaatsvindt. Dit is een rendabele manier in vergelijking met een ontwerp waarbij functies continu polling uitvoeren en controleren op bepaalde criteria. Elke polling-aanvraag wordt gemeten als een actie.

Zie Prijzen voor Logic Apps voor meer informatie.

Azure Functions

Azure Functions is beschikbaar met de volgende drie prijsplannen.

• Verbruiksabonnement. Dit is het meest rendabele, serverloze abonnement dat beschikbaar is, waarbij u alleen betaalt voor de tijd dat uw functie wordt uitgevoerd. Onder dit plan kunnen functies maximaal 10 minuten tegelijk worden uitgevoerd.

• Premium-abonnement. Overweeg om een Azure Functions Premium-abonnement te gebruiken voor automatiseringsscenario's met aanvullende vereisten, zoals een toegewezen virtueel netwerk, een langere uitvoeringsduur, enzovoort. Deze functies kunnen maximaal een uur worden uitgevoerd en moeten worden gekozen voor langere automatiseringstaken, zoals het uitvoeren van back-ups, het indexeren van databases of het genereren van rapporten.

• App Service-plan. Hybride automatiseringsscenario's die gebruikmaken van de Azure-app Service Hybrid Verbinding maken ions, moeten het App Service-plan gebruiken. De functies die onder dit plan zijn gemaakt, kunnen onbeperkt worden uitgevoerd, vergelijkbaar met een web-app.

In deze automatiseringsscenario's worden Azure Functions gebruikt voor taken zoals het bijwerken van tags in Microsoft Entra ID of het wijzigen van de Azure Cosmos DB-configuratie door de RU's op te schalen naar een hogere waarde. Het verbruiksabonnement is geschikt voor deze use-case, omdat deze taken interactief zijn en niet langlopend zijn.

Azure Cosmos DB

Azure Cosmos DB factureert voor ingerichte doorvoer en verbruikte opslag per uur. Ingerichte doorvoer wordt uitgedrukt in aanvraageenheden per seconde (RU/s), die kunnen worden gebruikt voor typische databasebewerkingen, zoals invoegingen, leesbewerkingen. Opslag wordt gefactureerd voor elke GB die wordt gebruikt voor uw opgeslagen gegevens en index. Zie het prijsmodel van Azure Cosmos DB voor meer informatie.

In deze architectuur worden waarschuwingen geactiveerd wanneer aanvragen voor gegevenstoegang tot Azure Cosmos DB de capaciteit in aanvraageenheden (of RU's) overschrijden. Als reactie op deze waarschuwingen is een Azure Monitor-actiegroep geconfigureerd om de automatiseringsfunctie aan te roepen. De functie schaalt de RU's naar een hogere waarde. Dit helpt de kosten laag te houden, omdat u alleen betaalt voor de resources die uw workloads per uur nodig hebben.

Gebruik de Azure Cosmos DB-capaciteitscalculator om een snelle kostenraming van uw workload te krijgen.

Zie de sectie Kosten in Microsoft Azure Well-Architected Framework voor meer informatie.

Implementatieoverwegingen

Voor kritieke automatiseringswerkstromen die het gedrag van uw toepassing beheren, moet er geen downtime-implementatie worden bereikt met behulp van een efficiënte DevOps-pijplijn. Lees de serverloze back-endimplementatie voor meer informatie.

Als de automatisering betrekking heeft op meerdere toepassingen, houdt u de resources die nodig zijn voor de automatisering in een afzonderlijke resourcegroep. Eén resourcegroep kan worden gedeeld tussen automatiserings- en toepassingsresources, als de automatisering betrekking heeft op één toepassing.

Als de werkstroom betrekking heeft op een aantal automatiseringsfuncties, groepeer dan de functies die geschikt zijn voor één scenario in één functie-app. Lees de functie-app Beheren voor meer informatie.

Wanneer u uw toepassing implementeert, moet u deze bewaken. Overweeg om Application Insights te gebruiken om de ontwikkelaars in staat te stellen de prestaties te bewaken en problemen te detecteren.

Zie de sectie DevOps in Microsoft Azure Well-Architected Framework voor meer informatie.

Imperatieve acties in Azure-resources

In beide bovenstaande scenario's was het eindresultaat een wijziging in de Azure-resourcestatus via directe interactie met Azure Resource Manager. Hoewel dit het beoogde resultaat was, moet u rekening houden met de impact die dit kan hebben op uw omgeving als de gewijzigde resources oorspronkelijk declaratief zijn geïmplementeerd, zoals door Bicep- of Terraform-sjablonen. Tenzij deze wijzigingen weer worden gerepliceerd in uw bronsjablonen, kan het volgende gebruik van deze sjablonen de wijzigingen die door deze automatisering zijn aangebracht ongedaan maken. Houd rekening met de impact van het combineren van imperatieve wijzigingen in Azure-resources die regelmatig worden geïmplementeerd via sjablonen.

Dit scenario implementeren

Zie de implementatiestappen op GitHub om het kostenplaatsscenario te implementeren.

Volgende stappen

• Training: Inleiding tot Azure Functions
• Documentatie: Inleiding tot Azure Functions
• Wat is Azure Event Grid?

Verwante resources

• Overzicht van code: Serverloze toepassing met Functions
• Architectuurontwerp voor serverloze functies
• Serverloze functies verwijzen naar architecturen