Serverless Computing

Amazon Web Services (AWS) är en ledande aktör inom området. Deras definition av serverless lyder: "Serverless Computing syftar oftast på serverlösa applikationer. Serverlösa applikationer är sådana som inte kräver att du tillhandahåller eller hanterar några servrar. Du kan fokusera på din kärntjänst och affär i stället för operativsystem, OS-uppdateringar, provisionering, rätt dimensionering, skalning och tillgänglighet.”

Serverless computing är därmed en modell för att köra tjänster eller kod i molnet där leverantören dynamiskt allokerar resurser. Trots namnet används fortfarande servrar i bakgrunden, men all hantering och resursplanering av dessa sköts av molnleverantören. Utvecklaren behöver inte oroa sig för att hålla reda på servrarna som kör koden, vare sig under utveckling eller när den tas i drift. Som företag får man helt enkelt mer tid för sin produkt och kan fokusera på det som skapar värde för kunden och användaren.

Utöver att slippa tilldela och administrera enskilda servrar, fysiska eller virtuella, ligger serverless computing väl i linje med moderna tankesätt kring systemutveckling, där funktioner och tjänster bryts ned till fristående och skalbara komponenter. Den term som oftast används för att beskriva detta synsätt är mikrotjänster (microservices).

FÖRDELAR MED SERVERLESS COMPUTING:

Det låter dig fokusera på det viktigaste – din produkt eller tjänst.
Du kan dra nytta av en plattform utan att behöva tänka på infrastruktur och samtidigt öka utvecklarnas produktivitet. Du får mer tid att fokusera på affärsmål och skapa produkter som når marknaden snabbare.Det är enkelt. Som utvecklare behöver du inte hantera servrar och inte heller installera mjukvara som sedan måste underhållas och administreras. Ingen infrastruktur eller inställningar krävs – arbetsmoment som i många fall är mycket tidskrävande.

• Det är kostnadseffektivt och ger bättre kostnadskontroll.
  Som företag betalar du endast för de resurser du använder. Serverlös databehandling är händelsestyrd och resurser allokeras så snart de triggas av en händelse. Du debiteras endast för den tid och de resurser som krävs för att köra koden – ofta ner på mycket detaljerad nivå.

  Det sparar tid.
  Att arbeta serverless är betydligt mer tidseffektivt, både för företaget och för kunden. Som nämnt tidigare bidrar detta även till snabbare utveckling och lansering av nya produkter på marknaden.

  Det är flexibelt och skalbart.
  Din applikation skalas automatiskt. Om en viss funktion kräver mer kapacitet tilldelar plattformen dynamiskt mer resurser. I en mer traditionell arkitektur måste hela webbtjänsten skalas. Det ger även mer sömlösa kopplingar mellan olika funktioner.

  Det är tillförlitligt och säkert.
  Du får tillgång till en robust, tillgänglig och säker IT-miljö när den behövs.

  Det är enkelt att bygga intelligenta lösningar.
  I serverless-miljöer finns artificiell intelligens nära till hands för utvecklare, vilket gör det enklare att bygga smarta och avancerade applikationer.

PLATTFORMAR OCH TJÄNSTER INOM SERVERLESS COMPUTING

Det finns flera olika implementationer av serverless computing. Det främsta exemplet idag är AWS Lambda med cirka 70 % marknadsandel, men Microsoft erbjuder Azure Functions, Google har Cloud Functions och Apache/IBM har OpenWhisk. AWS Lambda stöder många applikations- och backend-varianter och gör det möjligt att köra kod utan att konfigurera eller hantera servrar. Språk som stöds i Lambda inkluderar Node.js, Java, C#, Go och Python. Som företag betalar du endast för de resurser du använder, och AWS mäter beräkningskapaciteten i intervaller om 100 millisekunder.

Genom att kombinera AWS Lambda med andra serverlösa tjänster från AWS, såsom S3, DynamoDB, API Gateway, Kinesis, SNS och SQS, kan du skapa kraftfulla lösningar som har alla de fördelar vi tidigare beskrivit. I AWS Lambda finns även möjligheter att integrera intelligens i form av tjänster som Amazon Rekognition, Polly, Translate, Lex och Transcribe i dina applikationer.

AWS Lambda och serverless computing används idag inom alla typer av branscher och i alla typer av lösningar. AWS lyfter till exempel fram iRobot, med över 20 miljoner sålda robotar, där den underliggande plattformen bygger på en serverless-arkitektur baserad på AWS Lambda och AWS IoT. Ett annat exempel är Thomson Reuters, som hanterar och analyserar över 4 000 händelser per sekund med hjälp av Amazon Kinesis och AWS Lambda. Fler fallstudier finns hos AWS.

En självklar fördel är att du kan börja med serverless och växa in i det. Du kan flytta enskilda funktioner från en traditionell plattform till AWS Lambda eller använda serverlösa tjänster när nya funktioner ska utvecklas. Viktigast av allt är att serverless idag ses som ett självklart plattformsval, på samma sätt som virtuella maskiner och containers tidigare har varit.

Felfall och felfrekvens

Även om detta från början handlade om latensinjektion, som i Yan Cuis artiklar, är latens långt ifrån den enda typen av fel som kan uppstå i serverlösa applikationer. I failure-lambda, failure-azurefunctions och failure-cloudfunctions finns det idag fem olika felfall att välja mellan:

Identifiera svagheter (latens)

Injicerar fördröjning i den körda funktionen, styrd av ett minimi- och maximivärde i millisekunder. Detta kan till exempel användas för att simulera tjänstefördröjning eller för att testa och justera timeout-värden.

Undantag (Exception)

Kastar ett undantag i funktionen. Hjälper dig att testa hur applikationen och koden hanterar fel.

Statuskod

Funktionen returnerar en vald statuskod, till exempel 502 eller 404 istället för normala 200. Detta ger möjlighet att testa vad som händer när fel uppstår.

Diskutrymme

Fyller den temporära disken med filer för att skapa ett fel. Om du använder disk för att lagra temporära filer kan du testa hur applikationen beter sig när disken blir full eller när det inte går att skriva till den.

Svartlista (med tillstånd av Jason Barto)

Blockerar anslutningar till angivna värdar. Används för att simulera att tjänster eller tredjepartsleverantörer är otillgängliga.

Alla dessa felfall kan användas tillsammans med en inställbar felfrekvens. Standardinställningen är att injicera fel vid varje anrop, men i verkligheten är det mer sannolikt att exempelvis en tredjepartstjänst är otillgänglig i 50 % av anropen eller att ett undantag uppstår i var fjärde körning. Genom att justera felfrekvensen kan du simulera detta.