Serverless: de volgende stap in cloud computing

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 onderhou­den om je systeem te laten voldoen aan de behoefte van je klant.

Dit betekent: maximaal rendement uit de gebruikte hoeveelheid compute resources en bij­voorbeeld ook het gebruik van automati­sche opschaling van de systemen bij een verhoogde vraag. Vervolgens rekenen we alleen nog maar af op basis van de wer­kelijk 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 in­frastructuur volledig vastleggen in soft­ware. 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 afhan­delen 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 cloudleve­ranciers 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 uiter­aard ook nadelen en uitda­gingen. 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 perfor­mance, welke alternatieven heb je op het moment dat een dergelijke service jouw systeem onbruikbaar maakt en hoe kun je deze problemen verhelpen?

Bij het ge­bruik 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 ven­dor lock-in op, omdat deze diensten niet uitwisselbaar zijn met andere dienstver­leners. 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 genere­ren. Als je de term weer hoort, onthoud dan dat het een aantal interessante voor­delen 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 moei­lijker 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.