Serverless Architecture: Is Software nu Lego?

Serverless: de ideale link tussen APIs, Events, en je eigen code.

Serverless Computing is een Cloud Computing model waarbij de gebruikers enkel code en een stuk configuratie aanleveren voor een beoogde software, en de cloud provider de volledige verantwoordelijkheid in handen neemt voor het beheer van de onderliggende resources (rekenkracht, geheugen, netwerk, etc.). De gebruikers zijn normaal gezien software ontwikkelaars, en het concept valt dan ook onder de noemer "Platform as a Service" (PaaS). Bij Gartner wordt deze technologie ook Functional Platform as a Service (FPaaS) genoemd. Elders gebruikt men kortweg de term "Function as a Service” (FaaS).

Serverless gaat dus nog een stuk verder dan wat momenteel als "mainstream" PaaS-gebruik kan worden beschouwd: Container platformen en Kubernetes. Bij deze laatste is de developer zelf nog verantwoordelijk voor een deel van de "stack" en bepaalt daarmee zelf voor een groot deel op welke manier de software binnen de container zal werken, en daarmee dus ook over de manier waarop de gecompileerde programmacode wordt geïnstalleerd en uitgerold. Bij Serverless zal men enkel broncode (en een stuk tekstuele configuratie) uploaden naar het platform. De configuratie bepaalt daarbij op welke manier het stuk code kan worden opgeroepen (daarover dadelijk meer). Ook de granulariteit van Serverless is typisch kleiner dan die van Containers: meestal wordt er slechts één specifieke functie per Serverless eenheid geïmplementeerd, tegenover typisch een volledige microservice (of groter...) bij Containers.

AWS Lambda

Serverless Architecture verwierf bekendheid dankzij het product "AWS Lambda" van Amazon. Dit is momenteel nog steeds het platform waarrond het meest furore wordt gemaakt, mede dankzij een verregaande integratie met de rest van de AWS platformen. Je kan b.v. erg interessante zaken doen rond event-based monitoring. Naast Amazon hebben alle grotere Cloud providers nu wel een Serverless oplossing, en er zijn ook reeds enkele open source initiatieven ontstaan (b.v. Kubeless, een platform dat bovenop een Kubernetes cluster werkt), waarmee je op je eigen infrastructuur een FPaaS kan gaan opzetten.

Serverless = Event Driven

Men kan dus als het ware functies in een Cloud uitrollen, maar hoe worden deze dan uiteindelijk opgeroepen? Daar komt de configuratie bij te pas. Zo'n functie zal men namelijk typisch oproepen als gevolg van één of andere gebeurtenis, en dit zal men dan definiëren in de bijhorende configuratie. Indien het een functie is die een website ondersteunt kan dit b.v. een oproep naar een bepaalde API zijn, waar de functie dan een stukje van implementeert. Maar in principe kan men de functie laten reageren op alle mogelijke soorten gebeurtenissen, zolang men deze gebeurtenissen kan capteren via het gebruikte Cloud platform. Voorbeelden zijn legio:

• Business Events (b.v. een bestelling wordt geplaatst)
• Events gepubliceerd door andere software (mogelijks andere Serverless functies)
• Het binnenkomen van nieuwe data (b.v. door het monitoren van een database of door het volgen van een zogenaamde "stream", dus eigenlijk een vorm van "Reactive Programming").
• Het verstrijken van een bepaalde hoeveelheid tijd (dit komt neer op scheduling)
• Het binnenkomen van sensor data (denk aan Internet of Things)

De mogelijkheden zijn in principe eindeloos. Men kan dus eigenlijk stellen dat Serverless Architecture een vorm is van Event Driven Architecture, waarbij van het infrastructuur aspect abstractie wordt gemaakt. Over Event Driven Engineering hebben we reeds uitvoerig geblogd.

Voor- en Nadelen

Serverless is een nuttige technologie aan het worden, met duidelijke voordelen. Er moet echter nog een beetje gezocht worden naar oplossingen voor enkele problemen...

Pay Per Use

In de meeste platformen zal men een Serverless functie enkel uitvoeren en dit aanrekenen, wanneer ze daadwerkelijk wordt opgeroepen. Je betaalt dus enkel voor het daadwerkelijke verbruik ervan, en wanneer ze niet wordt gebruikt, betaal je niets. Dit principe noemt men "Scale to Zero". Dit kan echter ook een nadeel zijn: als de functie echt enorm veel gebruikt wordt, zal de prijs typisch nogal oplopen en kan het interessanter worden deze op een andere manier aan te bieden (b.v. door een aantal containers die men permanent actief maakt, aan een lagere maandelijkse kost).

Schaalbaarheid en Elasticiteit

Deze aspecten zijn nu heel gemakkelijk. Een functie heeft typisch geen toestand, en vermits de developer enkel rekening moet houden met de code voor één uitvoering, is het de Cloud provider die instaat voor het verzorgen van parallellisatie en alle andere aspecten die bij een verhoogde schaal komen kijken. Men krijgt dus als het ware een zeer flexibele schaalbaarheid cadeau (en in het geval van een publieke Cloud Provider ook een quasi oneindige). Daartegenover staat weliswaar dat de performantie bij een laag gebruik iets slechter kan zijn, vermits een serverless functie normaal gezien pas wordt geïnitialiseerd (en resources krijgt) op het moment dat ze wordt opgeroepen.

Veiligheid

Ook het veiligheidsaspect is een tweesnijdend zwaard: alhoewel men zich minder zorgen moet maken over de veiligheid van onderliggende infrastructuur (de Cloud Provider doet dit normaal gezien volgens de state of the art), vergroot men op een andere manier de zogenaamde "attack surface". Typisch zal men voor een volledige oplossing heel veel kleine functies nodig hebben, en het aantal toegangswegen tot de applicatiecode is op die manier groter.

Eenvoudige Ontwikkeling, Complex Beheer

De productiviteit van de ontwikkelaars zal waarschijnlijk een stuk hoger zijn, gezien ze enkel rekening moeten houden met functionaliteit en code, en veel minder belang moeten hechten aan onderliggende infrastructuur. Daartegenover staat een verhoogde vendor lock-in: een stuk van de code en de configuratie zal typisch gebruik maken van vendor-specifieke functies, die men bij een andere provider niet zal terugvinden.

Daarnaast is er een groot nadeel verbonden aan het bouwen van een groot web van interopererende functies: de complexiteit van dit gedistribueerde geheel. Er ontstaat als het ware een doos vol kleine "legoblokjes" van allerlei functies, die men dan wel nog met een goed plan tot een mooi geheel in elkaar zal moeten puzzelen. In principe is dit niet nieuw: zelfs binnen monolithische applicaties moet men aandacht besteden aan allerlei componenten en stukken code die onderling afhankelijk zijn, omdat ze elkaar oproepen of dezelfde resources gebruiken. Maar doordat deze complexiteit nu verschuift naar de configuratie en het platform, en ze typisch overheen een netwerk zal reiken, wordt het een probleem van beheersbaarheid en routering, eerder dan van code kwaliteit. Men zal nog goede manieren moeten vinden om dit soort zaken beter te gaan ondersteunen, misschien zelfs door encapsulatie, zoals dit reeds vrij goed op punt staat voor het eigenlijke programmeerwerk.

Conclusie

Serverless Architecture is een snel maturerende technologie met duidelijke voordelen. De FaaS platformen maken zeker deel uit van wat de aantrekkingskracht van de Cloud groter maakt. Ze moeten zich echter nog iets grondiger gaan bewijzen: nu komt het er op aan om de laatste nadelen, zoals de beheersbaarheid, nog op punt te stellen en om de meest nuttige toepassingen voor deze architectuur te vinden en te bouwen.