Serverless computing belooft veel goeds voor bedrijven en ontwikkelaars. Daar waar de opkomst van de cloud het draaien van eigen pc-rekenkracht optioneel maakte, biedt een serverless aanpak de kans om nooit meer servers te hoeven onderhouden. Sommige problemen gooien echter roet in het eten, waardoor serverless in veel gevallen minder geschikt is voor een applicatie dan het lijkt.
De logica achter serverless is relatief eenvoudig. Wie applicaties bouwt, wil zich het liefst niet bezighouden met noodzakelijk onderhoud van servers. In feite borduurt het voort op de voordelen die clouddiensten ten opzichte van on-premises bieden. De migratie naar de cloud heeft veel organisaties de kans gegeven om datacenter-resources buiten hun eigen beheer te plaatsen, zonder alle onderhoudskosten die eraan gepaard gaan. Echter gaat serverless nog een stap verder, want bij clouddiensten dienen klanten nog altijd de infrastructuur en de backend te organiseren. Het gebruik van serverless-diensten gebeurt vervolgens op een pay-per-use basis, dat in theorie een vlekkeloze schaalbaarheid mogelijk maakt. Dit verloopt via zogeheten Function as a Service (FaaS)-platformen, waaronder AWS Lambda, Google Cloud Functions en Microsoft Azure Functions.
Kortom: serverless neemt zoveel mogelijk kopzorgen weg voor IT-beheerders en laat applicatie-ontwikkelaars concentreren op wat men echt goed kan: applicaties ontwikkelen. Serverless wordt daarom al jaren geprezen om de kosten- en tijdbesparing die het mogelijk zou maken. Ontwikkelaars kunnen namelijk bestaande platformen en diensten aan elkaar koppelen zonder zelf allerlei functies en functionaliteiten te hoeven programmeren. Men focust zich op zogeheten ‘glue code’ om zaken vanaf een hoog niveau gezamenlijk te laten werken, waardoor de ontwikkelde oplossing op zo weinig mogelijk programmeercode gebaseerd is. Zoals Stedi-CEO Zack Kanter opmerkt, is dit een groot voordeel omdat extra code het ontwikkelproces op lange termijn vertraagt. Daarom levert de adoptie van serverless volgens hem de hoogste ‘development velocity’ op. Dit houdt in dat software op geen enkele andere manier zo snel ontwikkeld kan worden om waarde voor klanten toe te voegen. Wel moeten ontwikkelaars aanvankelijk goed in kaart brengen hoe hun applicatie eruit gaat zien, waarna een ‘agressieve adoptie van off-the-shelf platforms’ volgens Kanter noodzakelijk is.
Daarnaast zou serverless veel bestaande problemen oplossen. Immers ligt de verantwoordelijkheid voor het onderhoud van de infrastructuur elders. Talloze diensten kunnen daarnaast zonder al te veel moeite geïmplementeerd worden. Microservices maken het mogelijk om bijvoorbeeld een betaalsysteem te implementeren, voorraadgegevens bij te werken en allerlei andere functionaliteiten te integreren. Een bijkomend voordeel is dat het uitvallen van één van deze diensten geen ramp hoeft te zijn. Het ontwerp van serverless-systemen gaat namelijk uit van modulaire, onafhankelijke microservices, in tegenstelling tot monolithische applicaties waarbij een enkele fout de gehele werking ervan kan ondermijnen.
Er is altijd een ‘maar’, en het is een grote
Geen vuiltje aan de lucht dus. Een serverless-aanpak klinkt simpelweg als de overtreffende trap van cloud-adoptie, waarbij ook de servers niet langer beheerd hoeft te worden door de eindgebruiker. Alle voordelen van een volwassen, uitgedachte server-infrastructuur zonder de bijbehorende kosten en zorgen.
In maart van dit jaar bewees Amazon Prime Video echter het tegendeel van deze gedachtegang. Men had een serverless tool ontworpen om de kwaliteit van video en audio te monitoren, met onafhankelijke componenten die elk apart van elkaar in schaal konden vergroten bij zwaardere traffic. Men liep echter tegen het probleem aan dat de tool helemaal niet op grote schaal functioneerde. Sommige componenten bleken bij slechts 5 procent van de verwachte hardwarebelasting voor een bottleneck te zorgen. En dit terwijl het hele idee achter serverless is dat de schaalbaarheid inherent aan het ontwerp ervan zit. Doordat dit een wassen neus bleek te zijn, waren alle benodigde bouwstenen simpelweg te duur om te onderhouden.
Bij Prime Video trok men de conclusie dat de gedistribueerde aard van de tool geen voordelen kende. Immers dienden alle componenten werkzaam te zijn om het te laten functioneren, waardoor een groot voordeel van serverless irrelevant voor deze use-case was. Toen men in plaats daarvan alle componenten samenvoegde in een monolithische tool, was het ontwerp grofweg hetzelfde. Onder de streep was het voordeel opmerkelijk omvangrijk: de aanpassing had voor een kostenbesparing van 90 procent (!) gezorgd.
Alsnog hoge kosten
Een veel gehoorde klacht over serverless is dat het vooral op grote schaal zou werken, en juist relatief duur is op kleine schaal. Het voorbeeld van Prime Video ontkracht die voorstelling van zaken. Andere nadelen zijn een stuk algemener. Zo zorgt het verlies van controle over server-hardware ook voor een gebrek aan keuze en kunnen prestaties instabiel zijn. Wie niet heel spaarzaam is met de eigen code-runtime, loopt daarnaast relatief hoge kosten op in vergelijking met het draaien van deze programmeercode met on-prem hardware of via een clouddienst.
Ook is het pay-per-use model niet enkel positief. Een inefficiënte applicatie kan een onvoorspelbare (en daarmee potentieel reusachtige) hoeveelheid resources vereisen, waardoor de kosten de pan uit kunnen rijzen. Met een andere aanpak moet de benodigde infrastructuur al gepland zijn en biedt deze een harde limiet op het functioneren van een applicatie. Het voordeel om zo min mogelijk te hoeven plannen, komt dus met het nadeel dat er een grote mate van onoverzichtelijkheid bij komt. Dat kan een softwaremaker duur komen te staan.
Wanneer wel?
Dat serverless ergens wel nuttig is, blijkt uit een voorbeeld uit de koker van Red Hat. Principal Product Manager bij dat bedrijf Naina Singh vertelt hoe financiële diensten serverless kunnen benutten. Door de flexibele schaal van serverless kunnen banken garanderen dat hun dienstverlening meebeweegt met de vraag vanuit klanten. Ook kunnen fintech-bedrijven met hun erg variabele workloads terecht bij serverless, aldus Singh. Ze noemt het berekenen van financiële risico’s en van productprijzen als voorbeelden hiervoor. Het laat zien dat de technologie zeker uit kan blinken, zij het in specifieke scenario’s.
Software-architect Ben Morris stipt in algemenere zin aan waar serverless goed uit de voeten komt. Zo werkt het goed voor een compacte applicatie die altijd beschikbaar dient te zijn en niet al te veel traffic zal krijgen. Wanneer er wel een kortdurende traffic spike is, kan de serverless-architectuur dit opvangen. Het grote voordeel van de pay-per-use basis is dat het “schaalt naar nul”, aldus Morris.
Ter conclusie: serverless past goed bij specifieke situaties, maar is verre van een ‘silver bullet’. Hoewel deze aanpak schaalbaarheid zou moeten ondersteunen, bewijst de realiteit dat dit alsnog kan stuiten op onverwachte bottlenecks en onvoorstelbare kosten. Totdat die problemen worden opgelost, zal serverless lang niet voor iedereen een aan te raden keuze zijn.
Lees ook: X bespaart enorm dankzij on-prem: volgt er een bredere ‘cloud-exit’?