Serverless og lambda'er - systemer, som bygger på enkelte funktioner - er ikke bare det rene hype, men også en håndfast måde at skære udgifter til driften ned. I hvert fald hvis ens system passer til arkitekturen.
Det er holdningen hos Gojko Adzic, som er konsulent og udvikler. På den nyligt afholdte Goto-konference i København fortalte han om sine erfaringer ved at flytte app'en Mindmup.com, en såkaldt 'mindmap', over på serverless-arkitektur, tidens modeord.
Serverless er en dårlig betegnelse, for naturligvis er der servere involveret. Det burde snarere hedde 'betal for, hvad du bruger,' siger Gojko Adzic.
For Gojko Adzic og Mindmup har det betydet, at omkostninger i forhold til virtualiserede servere er reduceret til en tyvendedel.
Lambda'er, hvis navn er lånt fra funktionsprogrammering, refererer til Amazons tjeneste AWS Lambda, hvor kunderne kun betaler, når en kodestump afvikles.
Leverandør-håndjern er et forretningsmæssigt valg
Udover lambda'er benytter han Cognito, som er Amazons brugerstyringssystem, og det kan skære to måneder af udviklingstiden, lyder det glade budskab
Men bliver man ikke låst fast til en bestemt leverandør?
»Jo jo, men det er et forretningsmæssigt valg. Vi besluttede, at det var bedre med fastlåst leverandør, fordi vi kunne gøre det hurtigere, end hvis vi skrev vores eget system. En anderledes brugeradministration vil ikke give mig en konkurrencemæssig fordel i min app. Det gør forretningslogikken til gengæld. Vi er kun to på projektet, så at blive fastlåst til en leverandør, vi stoler på, er en fornuftig forretningsmæssig beslutning,« forklarer Gojko Adzic i et rivende tempo.
Der er dog også ulemper ved lambda'er. I sit foredrag på konferencen fortæller han, at han »kan snakke en halv time om ulemperne ved serverless og lambda«.
Version2 beder Gojko Adzic om at uddybe de vigtigste ulemper:
»I dag er der ingen tjenesteaftaler (SLA’er), så der er ingen garanti for noget som helst, når man bruger AWS Lambda. Efter vores erfaring fungerer det rimeligt godt, men der er altså ingen garantier. Jeg gætter på, at Amazon vil tilbyde det på et tidspunkt. Det er stadig en forholdsvis ny tjeneste, den har været her i omkring to et halvt år.«
Han peger også på, at der begynder at komme 'compliance', opfyldelse af regulativer, på lambda-fronten, ligesom med andre Amazon-tjenester.
Lad browseren snakke med backend
Men hvad kan serverless og lambda'er egentlig bruges til?
»Lambda er bygget med henblik på throughput og ikke på latency,« mener Gojko Adzic. Throughput er mængden af data, der kan processeres, og latency er i denne forbindelse hastigheden, som den udføres med.
»Amazon offentliggør ikke tal på ydelsen, men vores erfaring er, at når man går fra en webklient i USA til Amazons gateway og tilbage igen, tager det 50 millisekunder og 100 fra Europa. Hvis man arbejder med opgaver, som kan løses indenfor denne tid, er lambda’er perfekte. Hvis man har behov for garanterede maksimumstal for latency, så er lambda’er ikke helt der endnu, selvom udviklingen går hurtigt.«
Nogle mennesker, såsom Version2's udsendte medarbejder, synes, at det er svært at dreje hovedet omkring den tanke, at mange applikationer håndterer komplekse tilstande, og hvordan det klares med lambdaer og serverless. Men det synes Gojko Adzic ikke.
»Der er forskellig slags tilstande - brugertilstande, sessionstilstande og datatilstande. Hvis du for eksempel anvender et CMS-system, så afhænger en given artikel ikke af en given bruger. Du har en artikel med billeder og en titel, og det skal alligevel ned i en database eller et filsystem, ligesom det gjorde tidligere. Den slags blev ikke håndteret på applikationsserveren, for servere kan dø.«
»Brugertilstand blev før håndteret i hukommelsen, men ved at bruge autorisation på det lave niveau og ved at bruge Cognito kan det tillades slutbrugeren at kommunikere direkte fra browseren til backend-resurserne. Det er interessant.«
Og lidt uhyggeligt?
»Det er lidt uhyggeligt, men folk tænker, at det er deres egen database, og det er det ikke - det er Amazons. Det er dine data - men de er beskyttet af Amazons sikkerhedsmekanismer, uanset om en klient snakker med dem, om din app snakker med dem, eller en anden app, eller en angriber snakker med dem - det er de samme autoriseringsmekanismer. Hvis du ikke stoler på at lade Amazon opbevare dine data, så skal du ikke placere dem der.«
Det giver god mening at tænke på lambda ikke som en serverproces, men som lim mellem forskellige tjenester, synes Gojko Adzic, som spår, at vi kommer til se mere af den slags i de kommende år:
»Jeg tror, at de forretningsmæssige fordele ved lambda er så vanvittige (det handler om penge), så når compliance, latency og SLA’er er på plads - som allerede eksisterer for andre af Amazons tjenester - vil det nedsætte barrieren for mange. Besparelsen ved at køre lambda i modsætning til almindelig virtualisering vil gøre, at indenfor fem til ti år vil alt, hvad der kan køre som lambda, køre lambda.«
