Azure Functions til en AI-bygget app

Hvornår giver Azure Functions mening?

En Function er kode, der starter på en bestemt hændelse. Den kan modtage et HTTP-kald, reagere på en købesked, køre efter en tidsplan eller behandle en fil. Platformen håndterer runtime og skalering inden for den valgte hostingplan.

Hvornår er en Function ikke det bedste valg?

• En statisk hjemmeside: HTML, CSS og JavaScript bør normalt ligge på en hostingtjeneste, ikke i en Function.
• En lang, konstant proces: Arbejde, der skal køre uafbrudt eller i meget lang tid, passer ofte bedre i en container eller anden compute-tjeneste.
• En stor monolitisk API: Mange tæt koblede endpoints med konstant trafik kan være enklere at drifte som én webservice.
• CPU-tung behandling: Video, store ML-jobs eller anden tung beregning kræver ofte mere kontrollerede ressourcer.

Vælg hostingplan før produktion

Hostingplanen påvirker pris, skalering, netværk, cold starts og hvilke funktioner der er tilgængelige. Microsoft anbefaler Flex Consumption til mange nye dynamisk skalerende workloads, men valget skal følge appens krav.

• Flex Consumption: Dynamisk skalering, mulighed for always-ready instances og moderne netværksfunktioner.
• Premium: Relevant ved mere forudsigelig performance, avanceret netværk eller højere vedvarende belastning.
• Dedicated: Kan give mening, hvis virksomheden allerede driver en App Service-plan og ønsker faste ressourcer.

En plan kan ikke altid skiftes frit bagefter. Dokumentér derfor krav til svartid, VNet, regionsvalg, skaleringsloft og forventet trafik før oprettelsen.

Opret et Node.js 22-projekt

Brug Azure Functions runtime 4 og den kodebaserede Node.js programming model v4. Node.js 22 er understøttet og er et stabilt valg til nye projekter. Opret projektet med Azure Functions Core Tools eller udvidelsen til Visual Studio Code.

1. 1. Opret en ny mappe eller backendpakke i appens GitHub-repository.
2. 2. Vælg TypeScript, Node.js programming model v4 og Node 22.
3. 3. Start med én HTTP trigger og et klart funktionsnavn.
4. 4. Kør Functions host lokalt og test både gyldige og ugyldige requests.
5. 5. Commit runtimeversion, lockfil, host.json og kildekode.

Et enkelt HTTP-trigger-eksempel

Eksemplet validerer input og returnerer en bevidst HTTP-status. Den egentlige datalagring eller integration bør ligge i en separat funktion eller service, så handleren er let at teste.

import { app, HttpRequest, HttpResponseInit, InvocationContext }
  from "@azure/functions";

async function createLead(
  request: HttpRequest,
  context: InvocationContext
): Promise<HttpResponseInit> {
  const body = await request.json() as { email?: string };

  if (!body.email || !body.email.includes("@")) {
    return { status: 400, jsonBody: { error: "Invalid email" } };
  }

  context.log("Lead request accepted");
  // Gem eller send arbejdet videre her.

  return { status: 202, jsonBody: { accepted: true } };
}

app.http("createLead", {
  methods: ["POST"],
  authLevel: "function",
  route: "leads",
  handler: createLead,
});

authLevel: "function"kræver en function key, men en function key er ikke brugerlogin eller rollebaseret adgang. Browserkode kan heller ikke holde en nøgle hemmelig. Kunde- og medarbejder-API'er skal bruge en rigtig identitetsløsning og server-side tokenvalidering.

Miljøvariabler og secrets

Lokalt læser Functions indstillinger fralocal.settings.json. Filen må ikke pushes til GitHub. I Azure ligger værdierne som app settings eller hentes fra en secret store.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "DATABASE_URL": "local-development-value"
  }
}

• Commit en ufarlig eksempel- eller dokumentationsfil med variabelnavne, ikke værdier.
• Brug separate værdier og ressourcer til udvikling og produktion.
• Brug managed identity til Azure SQL, Storage, Key Vault og andre Azure-tjenester, når det er muligt.
• Hvis en secret er nødvendig, skal den have ejer, udløbsdato og rotationsplan.
• Udskriv aldrig credentials, komplette headers eller tokens i loggen.

Beskyt HTTP-endpoints

Et endpoint på internettet skal antages at blive fundet og kaldt af andre end appens brugerflade. Beskyt det i flere lag.

• Validér identitet, tokenets issuer og audience samt brugerens eller appens rettighed.
• Validér body, queryparametre, content type og størrelsesgrænser før behandling.
• Konfigurér CORS til de konkrete frontenddomæner; CORS er browserkontrol, ikke adgangskontrol.
• Rate-limit eller beskyt dyre og misbrugsfølsomme operationer.
• Returnér forståelige statuskoder uden stack traces, credentials eller intern databaseinformation.

Design til retries og dubletter

Cloudkald kan time out, og hændelser kan blive leveret igen. En robust Function skal derfor kunne genkøre uden at oprette dobbelt betaling, booking, mail eller databasepost.

• Brug en idempotency key eller leverandørens event-ID til at registrere allerede behandlet arbejde.
• Sæt timeouts på eksterne kald og brug begrænsede retries med backoff.
• Adskil transiente fejl fra permanente valideringsfejl.
• Brug køer til arbejde, som ikke behøver afsluttes i samme HTTP-request.
• Gem nok kontekst til, at en fejl kan undersøges og genbehandles sikkert.

Overvågning med Application Insights

En Function er ikke driftsklar, blot fordi den svarede korrekt under udvikling. Application Insights og Azure Monitor skal kunne vise, om den fejler, bliver langsom eller stopper med at modtage forventede hændelser.

• Log en korrelations- eller event-ID, men ikke persondata og secrets.
• Opret alarmer for fejlrate, gentagne exceptions, timeout og kritiske afhængigheder.
• Overvåg også manglende arbejde, fx hvis en forventet daglig synkronisering ikke kører.
• Gennemgå sampling, så vigtige fejl og requests ikke forsvinder fra produktionstelemetrien.
• Dokumentér hvem der modtager alarmen, og hvad personen konkret skal kontrollere.

Deployment uden portal-kopiering

Kildekode bør ikke kopieres manuelt ind i Azure Portal. Deployment skal kunne spores tilbage til en bestemt commit og gentages fra en ren build.

1. 1. Kør lint, tests og TypeScript-build i GitHub Actions.
2. 2. Byg én deploymentpakke fra den godkendte commit.
3. 3. Brug federated identity/OIDC fra GitHub til Azure frem for et langlivet publish profile-secret.
4. 4. Deploy udvikling og produktion med separate environments og Azure-ressourcer.
5. 5. Kør et health check og mindst ét kritisk smoke test efter deployment.

Typiske fejl i AI-byggede Functions

• Alt ligger i én handler: Validering, database, mails og eksterne API-kald kan ikke testes eller genkøres separat.
• Function key bruges som login: Alle brugere deler én nøgle uden individuelle rettigheder.
• Secrets ligger i repoet: En connection string eller API-nøgle bliver en del af historikken.
• Ingen idempotens: Et webhook-retry opretter den samme handling flere gange.
• Kun console.log: Der findes logs, men ingen alarm eller korrelation mellem frontend og backend.
• Direkte portal-deploy: Ingen kan dokumentere, hvilken commit produktionen kører.
• Planen vælges på pris alene: Netværk, cold start og pålidelighed opdages først efter lancering.

Tjekliste før produktion

• □ Function App, storage og afhængigheder ligger i den aftalte EU-region.
• □ Node.js 22, Functions runtime 4 og programming model v4 er dokumenteret.
• □ Udvikling og produktion bruger separate ressourcer og app settings.
• □ HTTP-endpoints har rigtig identitet, inputvalidering og mindst mulige rettigheder.
• □ Managed identity bruges i stedet for secrets, hvor det er muligt.
• □ Retries, idempotens, timeouts og permanente fejl er testet.
• □ Application Insights, alarmer og ansvarlig modtager er sat op.
• □ Deployment kommer fra en kontrolleret GitHub-commit og efterfølges af smoke tests.
• □ Hostingplan, skaleringsloft og budgetalarmer matcher det forventede forbrug.

Relaterede guides

Azure Functions kan kombineres med Microsoft SSO, Azure SQL eller andre databaser. Vælg de relaterede guides efter appens faktiske arkitektur.