Serverlösa applikationer är den, något missvisande, benämningen på att köra enskilda funktioner med programkod på en molntjänst. Det som är serverlöst är att man som utvecklare eller driftsansvarig inte behöver bry sig om servrarna som används för att köra funktionerna. Serverlösa funktioner är nog en bättre benämning.

Det här är en relativt ny företeelse. Amazons marknadsledande molntjänst Lambda lanserades i slutet av 2014. Sedan har konkurrenter som Microsoft, med Azure Functions, samt Google, IBM och Oracle hängt på med egna erbjudanden.

I dag finns det lösningar för att köra serverlösa funktioner med de flesta populära programmeringsspråk. Och rent tekniskt behöver det inte spela någon större roll vilket språk som används för en funktion, eftersom den är autonom och kommunicerar med omvärlden med någon typ av anrop.

Läs också: Är det här början till slutet för relationsdatabasen?

Intresset för serverlösa funktioner, eller ”functions” som är begreppet som ofta används i vardagstal, ökar kontinuerligt. Det är lätt att inse fördelarna. Man behöver inte bry sig om att köpa in, konfigurera eller administrera servrar, det kostar inget när funktioner inte körs och sättet att organisera programkod ligger i linje med den starka trenden för mikrotjänster.

Det går att se serverlösa funktioner som en fortsättning på mikrotjänster, i en strävan att organisera programkod i allt mindre block som är autonoma, med allt mer avgränsad funktionalitet.

Funktionerna kan också lösa skalbarhetsproblem för mindre delar av applikationer. I det senare fallet lyfter man helt enkelt ut koden med prestandaproblem till serverlösa funktioner och kör resten av applikationen som tidigare.

I princip kan man tänka sig tre sätt att använda serverlösa funktioner:

  • För enstaka händelser. Ett exempel är att göra mindre modifieringar eller kontroller av bildfiler som laddas upp till en molntjänst.
  • Som lösning för att köra vissa delar av en applikation. Merparten kan till exempel köras som mikrotjänster i containrar, eller som en monolit på en fysisk server eller i en virtuell maskin. De delar som körs som serverlösa funktioner anropas vid behov.
  • Som arkitektonisk bottenplatta för en hel applikation eller webbtjänst. I det här fallet finns all kod för applikationen i form av serverlösa funktioner. Utvecklarna får lov att hålla reda på strukturen i stort på något sätt.

De två första typerna kan tyckas snarlika. Skillnaden är främst hur man tänker i designarbetet. I det första fallet ser man inte serverlösa funktioner som en del av en helhet. I det andra fallet tänker man på serverlösa funktioner som en av flera olika delar av en applikation.

Daniel Marell är utvecklare och arkitekt på konsultföretaget CAG. Hans erfarenhet är att de flesta exempel på serverlösa funktioner som visas och diskuteras är av den första typen, alltså enstaka händelser, eller ”events” som det heter på fackspråk.

– Man ser mest diskussioner om uppenbara användningsfall, inte om arkitekturer i vilka funktioner är en del, säger Daniels Marell.

Han tror inte på idén om att basera hela applikationer på serverlösa funktioner:

Daniels Marell
Daniels Marell.

– Det blir till exempel problem med kod som är gemensam för flera delar av en applikation. Jag tycker att man ska börja med att skapa en arkitektur baserad på mikrotjänster och sedan köra vissa delar som funktioner.

Den andra strategin, med andra ord: lyft ut vissa delar av en applikation till serverlösa funktioner.

Han jämför också med vissa andra populära plattformar:

– Serverlösa funktioner som de ser ut idag är inte en rak tronföljare till Kubernetes eller Google App Engine. Användningsområdet för serverlösa funktioner är smalare.

Patrik Corneliusson är teknikchef på Raceone, en tjänst för att rapportera live för deltagare i tävlingslopp. Han har mycket erfarenhet av serverlösa funktioner.

– Vi använder funktioner för att hantera åtgärder som utförs mer sällan, framför allt om det blir en stor volym när de ska utföras. Det blir en lösning på skalbarhet, för att hantera belastningstoppar. Den riktigt stora fördelen är kostnaden. Det kostar inget när funktionerna inte körs, säger Patrik Corneliusson.

I Raceones fall är det enkelt att se fördelarna. Det är lätt att föreställa sig stora belastningstoppar vid arrangemang som till exempel Stockholm Marathon. Raceone använder Microsofts molntjänst Azure Functions.

Läs också: Utveckling utan programmering? Nu verkar den drömmen besannas

Raceone baserar sin arkitektur på mikrotjänster och lyfter sedan alltså ut viss funktionalitet i serverlösa funktioner. Hittills har man inte nått alla sina mål med lösningen:

Patrik Corneliusson
Patrik Corneliusson.

– Vi har gjort belastningstester och når inte riktigt ända fram med funktioner i alla scenarier, förklarar Patrik Corneliusson.

Han berättar vidare att den största begränsningen gäller hur snabbt körningen av funktioner kan dras i gång. Däremot har han inte märkt så stora problem med att hantera stora volymer.

Både Daniel Marell och Patrik Corneliusson tror på blandade lösningar där delar av applikationer eller webbtjänster bryts ut och körs som serverlösa funktioner. Om man ska lyckas fullt ut med en sådan strategi så är det nog bäst att ha serverlösa funktioner i tankarna redan från början när det skissas på en arkitektur. Annars kan det bli besvärligare att ”koppla loss” de delar som ska köras som serverlösa funktioner.