Serverless arkitektur: Fördelar och nackdelar

Serverless innebär inte att det inte finns servrar — det innebär att du inte behöver tänka på dem. Molnleverantören hanterar provisioning, skalning och underhåll. Du betalar bara för den tid din kod faktiskt körs. Det låter perfekt. I verkligheten finns det avvägningar.

Hur serverless fungerar

I en serverless-arkitektur deployer du funktioner — inte servrar. Varje funktion reagerar på en händelse (HTTP-request, filuppladdning, schemalagt jobb) och körs i en kortlivad container som skapas och förstörs automatiskt.

AWS Lambda, Azure Functions och Google Cloud Run är de tre dominerande plattformarna. Lambda och Azure Functions är rena FaaS-lösningar (Function as a Service). Cloud Run kör containers men med serverless-skalning.

// AWS Lambda — en typisk funktion
export const handler = async (event) => {
  const { productId } = JSON.parse(event.body);

  const product = await db.products.findUnique({
    where: { id: productId },
  });

  if (!product) {
    return {
      statusCode: 404,
      body: JSON.stringify({ error: "Inte hittad" }),
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify({ data: product }),
  };
};

// Triggas av API Gateway, SQS, S3, etc.
// Körs i max 15 minuter
// Skalas automatiskt till tusentals instanser

Fördelar i praktiken

Noll infrastrukturhantering: Inga OS-uppdateringar, inga säkerhetspatchar, ingen kapacitetsplanering. Molnleverantören hanterar allt under din kod.

Automatisk skalning: Från noll till tusentals instanser utan konfiguration. Perfekt för varierande arbetsbelastningar — Black Friday-trafik hanteras lika enkelt som en vanlig tisdag.

Pay-per-use: Du betalar per anrop och exekveringstid. En funktion som körs 1000 gånger per dag kostar betydligt mindre än en EC2-instans som snurrar 24/7. Vid låg trafik kan kostnaden vara nästan noll.

Snabbare time-to-market: Utan infrastruktur att konfigurera kan ditt team fokusera på affärslogik. En ny API-endpoint går från idé till produktion på timmar, inte dagar.

Nackdelar du måste hantera

Cold starts: När en funktion inte har anropats på ett tag behöver plattformen starta en ny container. Det tar 100ms–3s beroende på runtime, kodens storlek och VPC-konfiguration. Java och .NET har längst cold starts; Node.js och Python är snabbast.

Vendor lock-in: Din kod blir beroende av leverantörens specifika API:er, triggers och konfiguration. Att migrera en Lambda-baserad arkitektur till Azure Functions kräver ofta betydande omskrivning.

Debugging och monitoring: Distribuerade, kortlivade funktioner är svårare att debugga än en monolitisk applikation. Du behöver structured logging, distributed tracing och centraliserad monitoring från dag ett.

Kostnad vid hög volym: Pay-per-use är billigt vid låg trafik men kan bli dyrare än dedikerade resurser vid konstant hög belastning. Räkna på det innan du bestämmer dig.

När serverless är rätt val

• API:er och webhooks med varierande trafik
• Event-drivna workflows (bildbehandling, filkonvertering)
• Schemalagda jobb (rapportgenerering, datarensning)
• Prototyper och MVP:er som behöver komma ut snabbt
• Backend för mobilappar med oregelbundna trafikmönster

När du bör undvika serverless

• Långkörande processer (över 15 minuter)
• WebSocket-baserade applikationer (kräver persistent connection)
• Konstant hög belastning (containers/VPS är billigare)
• Applikationer med hårda latenskrav (cold starts är oacceptabla)

Serverless är ett kraftfullt verktyg — men det är just det, ett verktyg. Det löser inte alla problem, och det är inte alltid billigare. Utvärdera dina specifika krav, räkna på kostnaderna vid realistiska trafikvolymer, och välj medvetet. Läs mer om containeralternativet i vår Kubernetes-guide.