Achtergrond: IT zonder servers bestaat niet

On premise of serverless

Hostingproviders en de grote public-cloudaanbieders dragen stevig bij aan het uitsterven van on-premise ICT. De zaal met kilometers bekabeling en geloei van ventilatoren die wanhopig proberen om de boel een beetje koel te houden, is bijna een nostalgische herinnering. Maar IT zonder servers bestaat niet. In 2019 tenminste…

 

Een leeg datacenter betekent niet dat er geen servers meer zijn. Die servers staan alleen op een andere locatie. Buiten het zicht en met de komst van serverless computing ook buiten het zicht van de boekhouding. Je betaalt op de factuur niet langer voor een server of VM, maar alleen voor de hoeveelheid berekeningen die je uit laat voeren door de leverancier.

Ongelukkige naam

De naam serverless computing dekt enerzijds de lading, maar is ook wat ongelukkig. Hoewel je als klant geen server meer afneemt, wordt voor het uitvoeren van alle code nog steeds gebruikgemaakt van servers. Het is daarom handiger om te spreken over functieverwerking. Amazon biedt functieverwerking aan als Lambda, Google als Cloud Functions en Microsoft middels Azure Functions. Ook Oracle (Fn), Apache (OpenWhisk) en IBM (Cloud Functions) hebben zich inmiddels voor een rol in het serverless toneelstuk gemeld.

Op de weegschaal

Functieverwerking neemt een aantal problemen weg. Zo heb je geen omkijken meer naar het dagelijks beheer van het besturingssysteem of capaciteitsmanagement. De leverancier van de functieverwerking handelt dit allemaal af. Mocht de webapplicatie er dus ineens een groot aantal gebruikers bij krijgen in het midden van de nacht, dan kun je rustig blijven slapen. De benodigde hoeveelheid processorkracht, geheugen en bandbreedte wordt automatisch verhoogd. Je betaalt alleen voor wat je gebruikt.

De kracht van serverless computing zit in flexibiliteit. Het is uitstekend te combineren met containers voor het creëren van een op microservices gebaseerd applicatielandschap. Je kunt bijvoorbeeld op basis van binnenkomende data via de API een functieverwerkingsopdracht sturen en de uitkomst benutten binnen de rest van je applicatie of opslaan in een database. Het grote voordeel is dat je hiervoor geen losse VM hoeft te gebruiken en er dus vrijwel geen kosten worden gemaakt als er geen opdrachten worden verstuurd. Je betaalt in dat geval alleen nog voor de opslagruimte die je applicatie- of functiecode in gebruik neemt.

Geschikte applicaties

Met deze potentie komen we ook direct aan bij een belangrijk nadeel van serverless computing. Om er rendement uit te halen, zul je werkpakketten of applicaties moeten hebben die geschikt zijn voor het concept. Een grote, monolithische applicatie is niet wat je wilt draaien op een serverless oplossing. In dat geval zullen de kosten voor alle berekening zeer waarschijnlijk hoger uitvallen dan bij gebruik van VM’s. Bij een VM betaal je voor de CPU ongeacht of je die wel of niet gebruikt. Bij serverless betaal je alleen voor het gebruik, maar is de prijs per berekening in verhouding duurder dan die van een VM. Je zult dus niets besparen door een permanent draaiende, CPU-hongerige applicatie op een serverless-omgeving te draaien. De kosten van serverless computing worden opgebouwd uit (in ieder geval) de volgende factoren:

€ = uitvoeringstijd per functie * aantal uitvoeringen + hoeveelheid netwerkverkeer + opslagruimte voor code of benodigde data

Je kunt op basis van deze formule berekenen of serverless duurder of goedkoper is dan een VM voor je workload. Vergeet niet om de TCO van de VM’s en serverless te hanteren, dus inclusief dagelijkse beheerinspanningen. Je moet immers wel appels met appels vergelijken.

Voor wie een test wil doen met serverless computing is er goed nieuws: bij alle grote aanbieders is een beperkte hoeveelheid berekeningen en CPU-tijd gratis. Je kunt dus een experimentje wagen.

Standaardisatie en vendor-lockin

Serverless computing bevindt zich in de opstartfase en wordt nog niet massaal in productieomgevingen gebruikt. Ook behoort het serverless-kunstje nog niet tot de standaard-act van iedere IT-artiest. Daar komt bij dat iedere aanbieder tot op zekere hoogte een eigen wiel heeft uitgevonden. Ze beloven dat er eenvoudig met third parties kan worden gekoppeld, maar het impliciete uitgangspunt is dat het hart van de applicatie toch echt in hun eigen cloud draait. Daarmee hopen ze zelf het gros van de omzet binnen te halen.

De aanbieders hebben met serverless een nieuwe vorm van vendor lock-in gecreëerd. De virtuele ketting wordt gesmeed door de code die je ontwikkelt om zo goed mogelijk te laten werken op het door jou gekozen serverless platform. In het ontwikkelen van die code zit tijd en daarmee geld. Als de code vervolgens niet kan worden hergebruikt op het serverless platform van een andere aanbieder, dan zul je opnieuw ontwikkelkosten moeten maken om de code te migreren.

Dit is niet onopgemerkt gebleven. Er is dan ook een interessant opensourceproject dat van het uitwisselen van serverless workloads een peulenschil moet maken: Knative, een initiatief van Google waar onder andere ook Pivotal, Red Hat, IBM en SAP bij betrokken zijn. De basis van Knative wordt gevormd door Kubernetes, aangevuld met andere opensourceproducten en technologieën zoals Istio. Het idee is dat, net zoals met Kubernetes, verschillende leveranciers Knative als dienst aanbieden. Zo ontstaat één serverless oplossing, ongeacht de cloud die je kiest.

Potentie

De potentie van serverless computing is enorm. Net als container biedt het een volgende stap in fl exibiliteit en schaalbaarheid. Ben je bezig met plannen voor een nieuwe applicatie of heb je workloads die geschikt zijn om als functie(s) uit te voeren, overweeg dan de inzet van een serverless oplossing. Zeker als je goed zit in je huidige cloud, dan is er weinig op tegen om ermee te gaan experimenteren.

Zie voor meer informatie
• aws.amazon.com/lambda
• azure.microsoft.com/nl-nl/ services/functions/
• cloud.google.com/functions
• knative.org
• istio.io
• kubernetes.io
• openwhisk.apache.org

Marcel Kornegoor is CTO bij AT Computing BV

[Dit artikel is eerder gepubliceerd in het Datacenter & Cloud Dossier 2019]

Lees het artikel hier in PDF