Serverless is een verdere voortzetting van innovatie in de cloud om ervoor te zorgen dat je zo efficiënt mogelijk gebruik kunt maken van de beschikbare resources en niet meer hoeft na te denken over welke servers en services je hiervoor moet reserveren en onderhouden om je systeem te laten voldoen aan de behoefte van je klant.
Dit betekent: maximaal rendement uit de gebruikte hoeveelheid compute resources en bijvoorbeeld ook het gebruik van automatische opschaling van de systemen bij een verhoogde vraag. Vervolgens rekenen we alleen nog maar af op basis van de werkelijk gebruikte hoeveelheid computer-rekenkracht. Een serverless architectuur maakt eigenlijk alleen nog gebruik van ‘platform as a service'(PaaS)-, ‘backend as a service'(BaaS) en ‘functions as a service'(FaaS)-diensten. Dat klinkt abstract, dus laten we dit aan de hand van figuur 1 verder verduidelijken. Deze afbeelding is een sterk vereenvoudigde weergave van de werkelijkheid.
Traditioneel bouw je systemen op basis van software die gebruik gaat maken van hardware of tegenwoordig voornamelijk virtuele hardware of IaaS(infrastructure as a service)-diensten bij een cloudprovider. Bij de uitlevering van de software wordt een infrastructuur opgezet op basis van servers, netwer ken en vaak ook databases. Als je een traditioneel systeem laat landen op een cloudinfrastuctuur dan praten we over het gebruik van IaaS-diensten en kun je de configuratie van een dergelijke infrastructuur volledig vastleggen in software. We spreken over software-defined compute, networking en infrastructure & configuration as code.

Op- en afschalen
De volgende stap in het beter gebruiken van de cloud is dat we de architectuur niet meer in termen van netwerk, servers en database, maar meer in termen van services definiëren. Services voor het leveren van databasediensten en services voor het leveren van webdiensten. Daar onder ligt nog steeds de infrastructuur die we in het verleden moesten managen, maar met platform as a service hoeft dat niet meer.
Bij platform as a service wordt nog wel veelal gedacht in termen van schaalgrootte op basis van compute resources. Dus als je een webserverdienst afneemt, dan kies je voor een hoeveelheid RAM-geheugen en een aantal CPU-cores die de verzoeken kunnen afhandelen. Dat betekent ook dat je in het geval van een verhoogde vraag regels moet instellen om de dienst op te schalen en af te schalen als het weer rustiger is. Deze schalingsregels leg je vaak in een dergelijke dienst vast op basis van gebruikte hoeveelheid CPU of gebruikte hoeveelheid RAM. Je betaalt ook in dit geval voor de compute resources die voor je beschikbaar worden gehouden, of je die nu gebruikt of niet.
Minimale verspilling
Bij serverless computing willen we in het geheel niet meer nadenken over de hoeveelheid RAM, CPU, disks et cetera. Wat we willen is een dienst afnemen die, naar gelang er meer verzoeken bij komen, automatisch deze verzoeken gaat afhandelen en dat je daarbij alleen betaalt voor de geconsumeerde hoeveelheid compute. Het grote voordeel hiervan is dat je alleen nog betaalt voor wat je gebruikt. Bijkomend voordeel voor de cloudleveranciers is dat zij hun serverpark kunnen optimaliseren voor maximaal gebruik. Dit noemen we ook wel een zo hoog mogelijke server density.
Hoe meer functionaliteit zij kunnen laten draaien op hun hardware, des te beter het is voor iedereen. Dus feitelijk zou het serverless model een win-winsituatie moeten opleveren voor klant, leverancier en zelfs onze leefomgeving, aangezien we minder verspilling hebben van stroom en servers die veelal niets staan te doen en staan te wachten op werk.
Bij serverless maken we ook meer gebruik van losse diensten die we aan elkaar rijgen tot een geheel. Dit zorgt ervoor dat je vaak sneller een werkend systeem kunt ontwikkelen, dan dat we gewend zijn als we veel meer code zelf moeten schrijven.
Nieuwe uitdagingen
Serverless biedt naast voordelen uiteraard ook nadelen en uitdagingen. Een van de meest in het oog springende zaken is dat je te maken krijgt met systemen die bestaan uit steeds meer bouwblokken die bij een of meerdere cloudleveranciers worden afgenomen. Als het systeem uitvalt, heb je een uitdaging: het achterhalen waar het probleem in het systeem zich voordoet. Welke dienst is uit de lucht of heeft een verminderde performance, welke alternatieven heb je op het moment dat een dergelijke service jouw systeem onbruikbaar maakt en hoe kun je deze problemen verhelpen?
Bij het gebruik van PaaS- en FaaS-diensten is vaak het enige wat je kunt doen een support call inschieten en wachten tot het probleem is opgelost. Tenzij je een slimme architectuur hebt, dan kun je wellicht switchen naar een andere leverancier. Dit zijn wel zaken die je van tevoren moet bedenken bij het samenstellen van de totale oplossing.
Cloudleveranciers optimaliseren serverpark voor maximaal gebruik
Pay-per-use
Een andere uitdaging is het voorspellen van je kosten. Omdat je nu gaat betalen voor de werkelijke gebruikte compute, zal je ervoor moeten zorgen dat deze kosten evenredig terug te verdienen zijn via het gebruik van je eigen klanten. Met andere woorden, was het in het verleden nog zo dat je kon uitrekenen datje voor een x-aantal servers bedrag y nodig hebt om zaken te kunnen doen, nu word je geconfronteerd met een pay-per-use model. Vaak heb je ook een navenant bedrijfsmodel nodig om deze kosten door te belasten in de prijs van de dienst die je aanbiedt. Helaas wordt een dergelijk aspect nog weleens over het hoofd gezien, omdat software-architecten en -developers zich lang niet altijd bezighouden met de kosten die bepaalde services met zich meebrengen en de vraag of deze wel passen in je huidige bedrijfsmodel.
Last but not least levert het gebruik van PaaS- en FaaS-diensten vaker een vendor lock-in op, omdat deze diensten niet uitwisselbaar zijn met andere dienstverleners. Als je bijvoorbeeld gebruikmaakt van Amazon Lambda als FaaS-oplossing, dan kun je niet zomaar een-op-een verhuizen naar Azure of Google Cloud Functions als alternatief, zonder dat je hiervoor code moet gaan aanpassen.
Conclusie
Serverless is een term die de komende tijd steeds meer bekendheid zal genereren. Als je de term weer hoort, onthoud dan dat het een aantal interessante voordelen heeft waaronder het automatisch opschalen bij verhoogde vraag, het beter benutten van beschikbare resources en het sneller kunnen ontwikkelen van functionaliteit.
Echter zit er ook een keerzijde aan dit verhaal, waaronder een grotere cloud vendor lock-in, het moeilijker oplossen van fouten door eigen personeel en in veel gevallen een veel minder voorspelbaar kostenmodel omdat je gaat betalen per gebruikte compute, hetgeen lang niet altijd even inzichtelijk en voorspelbaar is, afhankelijk van de gekozen architectuur.