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.

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.

_________________________

Dit is een ingezonden bijdrage van Koen Vanderkimpen, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

In een vorige blog bespraken we reeds de basis van Event Driven Engineering: de definitie van wat Events juist zijn, het publish/subscribe mechanisme, en de Event-Driven Architecture, gebaseerd op de Event Bus. Nu zullen we het gaan hebben over Event Sourcing: het bouwen van applicaties, volledig gebaseerd op het concept van Events, en over Complex Event Processing: een techniek waarmee, in real-time, intelligente beslissingen kunnen worden genomen.

Event Sourcing

De meeste webapplicaties die we kennen, hebben één of andere toestand die evolueert doorheen de tijd, en die doorgaans opgeslagen wordt in een achterliggende database. Wanneer we b.v. inloggen op online banking, zien we het huidige saldo van onze rekeningen. Wanneer we morgen geld van onze rekening halen, dan zal deze toestand overmorgen zijn veranderd.

Wanneer we even afstand nemen van deze gang van zaken, dan kunnen we de bedenking maken, dat elke huidige toestand in feite het gevolg is van een hele reeks van historische toestandsveranderingen, startende bij één of andere begintoestand, wanneer de applicatie voor het eerst online ging.

Welnu, elke toestandsverandering binnen een systeem kunnen we perfect modelleren als… een Event! Wanneer we dit daadwerkelijk doen, kunnen we het computersysteem op zo’n manier laten werken, dat de huidige toestand “berekend wordt” op basis van alle in chronologische volgorde gezette toestandsveranderingen, die we als Events in de applicatie laten binnenkomen. Wanneer we daarnaast ook nog deze Events opslaan – i.p.v. de huidige toestand – dan spreken we van “Event Sourcing“. Dit wil dus letterlijk zeggen dat de broncode van de applicatie gebaseerd is op Events.

Een bedenking die iedereen snel zal maken, is natuurlijk dat dit na verloop van tijd zeer onefficiënt zou worden: hoe meer Events er zijn, hoe zwaarder de berekening wordt om de huidige toestand te bekomen! Om die reden zullen er uiteraard steeds bepaalde optimizaties aanwezig zijn in de applicatie, zonder wezenlijk de Event-Sourced eigenschappen ervan te veranderen. Zo is het natuurlijk zaak om de huidige toestand in een cache of buffer te houden, zodat enkel nieuwe Events in rekening gebracht moeten worden om de toestand te laten evolueren. Daarnaast is het ook handig om van deze toestand af en toe een backup weg te schrijven, zodat ook bij het eventuele uitvallen van de toepassing, slechts een deel van de toestand opnieuw berekend dient te worden aan de hand van Events.

Met het bewaren van Events in plaats van enkel de huidige toestand, krijgt men een aantal interessante mogelijkheden. Zoals in de vorige paragraaf gezegd, kunnen we de toestand terug heropbouwen. Sterker nog: we kunnen de toestand van eender welk moment in de geschiedenis van de applicatie terugbrengen (handig om te weten wat er op een bepaald moment aan de hand was). Daarnaast kunnen we nieuwe versies van de applicatie testen door Events opnieuw af te laten spelen voor een testversie: zo krijgt men erg realistische tests. Ten slotte laat de rijkheid aan gegevens binnen de Events ons toe om temporele queries te gaan uitvoeren; dit soort data zouden we bij een standaard aanpak vaak kwijt zijn.

Er zijn een aantal speciale vormen van temporele gegevens die automatisch beschikbaar zijn, indien men Event Sourcing goed aanpakt. Zo kunnen Events erg eenvoudig gelogd worden en op die manier deel gaan uitmaken van een rijkere applicatielogging. Ook audit logs kunnen vaak (deels) uit de Events worden afgeleid. Ten slotte vormen de Events van een Event-Sourced applicatie automatisch ook een goede backup van de gegevens, gezien men de toestand van de applicatie ermee kan heropbouwen.

Complex Event Processing (en Analytics)

Complex Event Processing (CEP) systemen zijn een belangrijke schakel wanneer men applicaties tijdige intelligente beslissingen wil laten nemen, op basis van wat er aan het gebeuren is. Dit soort systemen zal naar binnenkomende Events luisteren (zoals andere applicaties die zich ervoor inschrijven), en zal specifiek letten op het voorkomen van bepaalde patronen in Events die zich afspelen. Wanneer het CEP systeem zo’n opeenvolging van Events heeft opgemerkt, zal het reageren. Dit kan het doen door zelf een nieuw, “complex” Event te publiceren, waar weer andere systemen op zullen kunnen reageren. Op die manier transformeren zulke systemen een bepaalde reeks van elkaar opvolgende Events dus in een nieuw, complex Event; dit alles op basis van een set van complexe regels, die door programmeurs, maar vaak ook door een “(zelf-)lerend” systeem, zijn ingegeven.

Op die manier zijn CEP systemen ook belangrijk in Big Data Analytics, waarbij de Big Data bestaat uit zaken die doorheen de tijd gebeuren (plus uiteraard andere vormen van verwante data). Deze vorm van Big Data is bijvoorbeeld interessant bij het detecteren van fraudepatronen, waarbij fraudeurs gedurende een bepaalde tijd een aantal handelingen uitvoeren die uiteindelijk tot fraude leiden. Het herkennen en vervolgens detecteren van de juiste patronen in een hele reeks van handelingen (waar uiteraard ook niet-verdachte handelingen en zelfs niet-gerelateerde handelingen tussen zitten), is daarbij cruciaal.

CEP laat in deze use case toe de resultaten van analytics – de herkende patronen van zaken die gebeuren doorheen de tijd – rechtstreeks toe te passen op een systeem dat live is, waardoor ze in real-time kunnen worden gedetecteerd en er dus veel sneller op kan worden gereageerd. Daarnaast genereren de CEP systemen nieuwe, complexe Events, die de reeds aanwezige Events in de Big Data kunnen verrijken. Hierdoor vergroot de hoeveelheid data waaruit de analytische applicaties zullen kunnen putten om weer nieuwe Event-patronen aan te leren.

Besluit

Events zijn niet alleen nuttig als loskoppelend communicatiesysteem tussen applicaties, maar zijn op zich ook een erg krachtig paradigma als bouwsteen voor sommige individuele applicaties, of als gegevensbron voor Big Data Analytics en real-time intelligente systemen.

Events

Heel veel zaken binnen een softwaresysteem kunnen worden gemodelleerd als een gebeurtenis, of Event: het aanklikken van een knop, het indrukken van een toets, het verbinden met een server, enz. Een bijzonder interessante vorm van gebeurtenissen zijn daarbij degene die ook op business niveau een betekenis hebben: het inloggen van een gebruiker, het versturen van een aanvraagformulier, het aanmaken van een nieuw record met gegevens, of zelfs het beschikbaar worden van een signaal komende uit een big data analytics platform.

Deze gebeurtenissen zijn er altijd, maar we besteden er niet altijd enorm veel aandacht aan: het verbinden van een server wordt simpelweg het oproepen van een hulpdienst vanuit een ander deel van het programma, de gegevens van een aanvraagformulier worden gewoon gecontroleerd en weggeschreven, het signaal wordt getoond op een dashboard, enz. We doen dus wel iets met de gegevens die samenhangen met het Event, maar we beschouwen het Event zelf niet als volwaardig concept. Eens voorbij, verliezen we dan ook het concept van iets dat zich afspeelt op een bepaald moment in de tijd. De betrokken gegevens worden weggeschreven, vaak als deel van een aggregaat, en de historische context en tijdsgebondenheid gaan verloren.

Wanneer we nu het Event wél gaan beschouwen als een object van eerste klasse (in het Engels ‘first class citizen‘), dan maken we er als het ware een tastbaar, vastgrijpbaar iets van. Het Event wordt als dusdanig “gereïficeerd” (‘écht gemaakt’). Wanneer we dit doen, dan spreken we van Event Driven Engineering. Dit is een brede tak binnen de Software Engineering, die zelf nog uit een aantal verschillende paradigma’s bestaat.

De twee meest eenvoudige van deze paradigma’s, het Publish/Subscribe mechanisme en het bredere concept Event Driven Architecture, zullen we verder uitdiepen in deze blog.

Publish/Subscribe

Het publish/subscribe mechanisme is al erg lang een gekende techniek binnen software-ontwerp, om subsystemen van elkaar los te koppelen.

Het mechanisme speelt zich af tussen drie partijen: de publisher (die een Event kan “publiceren”), de subscriber (die zich voor een event kan “onderschrijven”), en het Event systeem. Deze partijen kunnen verschillende vormen aannemen (van één welbepaald object binnen een applicatie, over subsystemen heen, tot verschillende en volledig op zichzelf staande applicaties of IT-systemen). Van publishers en subscribers kunnen er meerdere zijn. Van het Event systeem is er, althans wat de interacties rond minstens één welbepaalde soort Events betreft, slechts één.

Op een bepaald moment kan een subscriber het Event systeem contacteren om zijn interesse te uiten in een welbepaald Event. Vanaf dan is het zo dat, elke keer dit event voorkomt, de subscriber hiervan op de hoogte zal worden gebracht. Dit laatste gebeurt wanneer een publisher op zijn beurt het Event systeem inlicht over een door hem gegenereerd event. Dit laatste wordt ook wel “to fire an Event” genoemd: een Event wordt als het ware afgevuurd. De subscribers hebben dan de verantwoordelijkheid om het Event af te handelen (to “handle an Event”). Naast inschrijven, is het voor subscribers ook mogelijk zich opnieuw uit te schrijven voor een Event, een beetje zoals met een nieuwsbrief.

Het typische publish/subscribe scenario:

1. Een paar subscribers onderschrijven zich
2. Een publisher publiceert een event
3. Het Event komt terecht in het Event Systeem
4. Het Event wordt verspreid via het Event Systeem
5. Het Event bereikt alle subscribers

Voor het publish/subscribe mechanisme is het echter nog niet expliciet vereist om de events te reïficeren. Men kan ook gebruik maken van het principe van callbacks: de subscriber geeft aan wat hij wil dat er gebeurt, indien een bepaalde gebeurtenis voorkomt. De publisher kan dan via het event systeem aangeven dat iets gebeurd is, zonder verdere details te geven, en de callback wordt uitgevoerd. Daarnaast is het zelfs mogelijk dat er geen event systeem is, maar dat subscribers zich rechtstreeks tot publishers richten.

Indien we de Events echter expliciet modelleren, biedt dit mechanisme veel meer opties: publishers kunnen het Event dan verrijken met details over het gebeurde, en deze gegevens kunnen door de subscribers worden gebruikt om het Event beter af te handelen. Bovendien hebben we de optie om het Event voor later hergebruik op te slaan. Daarnaast krijgen we door het invoeren van een event systeem een vorm van indirectie, die toelaat dat publishers en subscribers elkaar niet meer te hoeven kennen.

Een typisch voorbeeld zien we bij de ondersteuning van Grafische User Interfaces (GUI). Grafische elementen zullen daar Events afvuren die door de eindgebruiker werden veroorzaakt (‘er werd op een knop geklikt’, ‘een veld werd ingevuld’, …). De achterliggende applicatiecode zal zich op deze Events hebben ingeschreven en er aldus op kunnen reageren om de applicatie (en GUI) aan te passen.

Event Driven Architecture

Binnen een Event Driven Architecture (EDA), hebben we ook publish/subscribe, maar dan op een veel grotere schaal. Meestal gaat het nu om communicatie tussen verschillende applicaties en systemen op een zo robuust mogelijke manier. Het Event systeem zal nu worden geïmplementeerd a.d.h.v. een BUS systeem, en we zullen het de Event Bus noemen.

EDA kan nuttig worden aangewend wanneer men een heel aantal applicaties heeft, die dezelfde of gerelateerde Business Events behandelen. Gebeurtenissen binnen één applicatie zullen daarbij vaak relevant zijn voor andere applicaties. De Event Bus zal binnen zo’n geheel de verantwoordelijkheid op zich nemen om een Event, door één applicatie gecreëerd, tot bij alle geïnteresseerde applicaties te krijgen. De applicaties hoeven van elkaars bestaan niet af te weten: het is voldoende dat ze van het bestaan van bepaalde Events afweten, en dat ze kunnen communiceren met de Event Bus.

Deze vorm van architectuur laat een grote loskoppeling toe van de betrokken systemen en applicaties, en zorgt er ook voor dat er snel gereageerd kan worden op voorkomende business events, zelfs op plaatsen waar, en op manieren waarop dit niet initiëel werd voorzien. Men kan zich namelijk inbeelden dat men, eens een bepaald Event bestaat en men weet dat het over de bus passeert, nieuwe ideeën kan krijgen om deze Events aan te wenden en erop te reageren, zowel in bestaande als nieuwe applicaties.

Communicatie via Events zal natuurlijk niet de enige communicatie zijn die er tussen verschillende systemen moet bestaan: soms heeft één systeem ook historische informatie nodig, die reeds lang via een andere applicatie is verwerkt en opgeslagen. Het eventuele event, indien het al zou bestaan, dat tot die informatie heeft geleid, is op dat moment natuurlijk reeds lang gepasseerd. Normaal gezien gaat dit echter altijd om read-only operaties. Hier moeten we dus, binnen het geheel van applicaties, nog iets voor voorzien (b.v. een collectie RESTful APIs). Communicatie die schrijfoperaties veroorzaakt, moet echter in principe altijd via Events kunnen worden gemodelleerd (wanneer er een gegeven moet worden aangepast, kan men desnoods deze wijziging op zich óók modelleren als een gebeurtenis).

Conclusie en Vervolg

De Event Driven Architecture is veelbelovend: het laat een sterk loskoppelen toe van de betrokken applicaties en systemen, wat het onderhoud van het softwarepark een stuk eenvoudiger maakt. Maar indien we de Events die op de bus binnenkomen permanent gaan bewaren en voor nog allerlei andere zaken gaan (her-)gebruiken, ontketenen we pas echt de kracht van Event Driven Engineering. Daarover meer in een volgende blog!