Het onderwerp van vandaag is iets waar bijna iedereen van gehoord heeft, maar bijna niemand kan uitleggen. Serverless. Wat is het precies? Is het echt alleen code die nergens op draait of is het iets veel groters? Laten we één ding duidelijk stellen. Serverless betekent niet geen servers. Het betekent dat je er niet aan hoeft te denken en dat verschil verandert alles in hoe je software bouwt. Aan het einde van deze aflevering begrijp je wat Azure Functions werkelijk zijn, hoe de prijsstelling echt werkt en wanneer je ze moet gebruiken. We breken dit op in de bouwstenen, te beginnen met de grootste mythe. Wat serverless eigenlijk betekent? Laten we direct een paar mythes uit de weg ruimen. De naam serverless is de slechtste marketingterm die Microsoft ooit heeft bedacht. Het laat mensen denken dat er letterlijk geen server bij betrokken is. Dat is niet waar. Er zijn servers, heel veel zelfs.

Je hoeft ze alleen nooit aan te raken. Twintig jaar geleden, als je een stuk code op internet wilde draaien, moest je veel werk verzetten. Je huurde een virtuele machine, installeerde een besturingssysteem, configureerde een webserver en zette je applicatie klaar. Vervolgens bracht je elk weekend door met het installeren van beveiligingsupdates en ervoor zorgen dat de boel niet om drie uur s'nachts crashte. En dit is het punt. Je betaalde voor die server of je code nu draaide of niet. Hij stond daar maar te zoomen en geld te kosten terwijl jij sliep. Serverless zet dit hele model volledig op zijn kop. Je schrijft je code, upload deze en het platform regelt de rest. Het besturingssysteem, beveiligingspatches, schalen en beschikbaarheid. Jouw taak is alleen het schrijven van de logica die ertoe doet. Zie het als het verschil tussen een restaurant, keuken runnen en een automaat gebruiken. Een restaurant, keuken heeft personeel, constante voorraad en onderhoud nodig.

Het kost elke dag geld, zelfs als er niemand naar binnen loopt. Een automaat staat in een hoekje niets te doen totdat iemand op een knop drukt. Dan komt hij tot leven, doet zijn werk en gaat weer in de slaapstand. Je betaalt alleen voor de elektriciteit wanneer hij daadwerkelijk werkt. Dat is serverless in een notendop. Azure Functions is de versie van Microsoft hiervan. Het draait kleine stukjes code als reactie op gebeurtenissen. Je code is inactief totdat iets hem wakker maakt. Dan draait hij, voltooit zijn taak en gaat weer slapen. Dus hoe ziet die code er eigenlijk uit? Wat Azure Functions zijn. Een functie is een enkel stukje code dat één specifieke taak uitvoert. Dat is alles. Het is geen complete applicatie met een inlogpagina, een database en twintig schermen. Het is één gerichte taak. Denk erover als een lichtschakelaar in huis ofwel uit ofwel aan om werk te verrichten en dan weer uit.

Een traditionele webserver is het tegenovergestelde, alsof je elk licht in huis 24 uur per dag, zeven dagen per week laat branden, zelfs als er niemand thuis is. Azure Functions ondersteunen een heleboel verschillende programmeertalen. Je kunt gebruiken waar je je prettig bij voelt, Javascript, Python, C Sharp, Java, PowerShell. Er is hier geen enkel goed antwoord. Kies de taal die je al kent. Laten we nu een veel voorkomend misverstand ophelderen. Een Function App is niet hetzelfde als een Function. De Function App is de container. Zie het als een gereedschapskist. Je maakt één Function App aan en in die gereedschapskist voeg je meerdere Functions toe. Elke Function is een apart stuk gereedschap dat zijn eigen taak uitvoert. Je hebt misschien één Function die gebruikersregistraties afhandelt, een andere die geüploaden afbeeldingen verwerkt en een derde die nachtelijke rapporten verstuurt.

Ze zitten allemaal in dezelfde gereedschapskist, maar werken onafhankelijk van elkaar. Nog één ding over Functions, ze zijn van nature stateles. Dat betekent dat ze niets onthouden tussen verschillende runs door. Als je Function een bestand verwerkt en klaar is, dan is dat het. De volgende keer dat hij draait, begint hij opnieuw zonder enige herinnering aan de vorige keer. Dat klinkt als een beperking, maar het is juist de eigenschap die ze zo krachtig maakt. Omdat Functions geen geheugen of status vasthouden, kan Azure direct 100 kopieën van je Function opstarten bij pieken in het verkeer, en ze net zo snel weer afsluiten als het verkeer afneemt. Zo krijg je schaalbaarheid zonder te betalen voor inactieve servers. Hier is de vraag, als een Function daar maar wat zit te wachten tot iets hem wakker maakt, wat maakt hem dan eigenlijk wakker? Dat is waar triggers om de hoek komen kijken. Triggers, het wanneer.

Elke Function moet precies één trigger hebben, en dat is niet optioneel. De trigger is de gebeurtenis die je Function wakker maakt. Zonder die trigger zit je code daar maar te wachten en doet helemaal niets. Zie triggers als een deurbel. Je Function is binnen in het huis aan het wachten. Hij zou eeuwig kunnen wachten. Er gebeurt niets totdat iemand aanbelt. Dan komt de Function in actie, doet open, voert zijn taak uit en gaat weer terug naar het wachten. Er zijn vier triggers die beginners het vaakst tegenkomen. De HTTP trigger is het meest gebruikelijke startpunt. Iemand bezoekt een URL of doet een API aanroep, en je Function wordt geactiveerd. Zo bouw je lichtgewicht API zonder dat je een volledige webserver hoeft op te zetten. Dan is er nog de timer trigger, die volgens een planning draait. Je stelt een Cron Expressie in, zoals elk uur uitvoeren of elke nacht om middernacht, en je functie wordt op die exacte tijden geactiveerd.

Perfect voor onderhoudstaken, opschoonklussen of het genereren van nachtelijke rapporten. De blob trigger wordt geactiveerd wanneer een bestand wordt geüpload naar Azure Opslag. Stel dat iemand een PDF uploadt naar een specifieke map. De blob trigger detecteert die upload en voert je functie automatisch uit. Dit is geweldig voor beeldverwerking, documentconversie en bestandsvalidatie. En de Q-trigger wordt geactiveerd wanneer er een bericht in een wachtrij verschijnt. Wachtrijen zijn een manier om verschillende onderdelen van je systeem te ontkoppelen. De ene service plaatst een bericht in een wachtrij, en je functie pakt het op en verwerkt het zodra deze klaar is. Dat voorkomt dat een trage service alles blokkeert. Dit is het belangrijkste punt. Wanneer een trigger wordt geactiveerd, worden de gegevens automatisch doorgegeven aan je functie. Je hoeft niet te pollen of te controleren of er iets is gebeurd.

De trigger geeft je alles wat je nodig hebt, en je functie verwerkt het vervolgens. Een functie zonder trigger is slechts code die niet staat te doen. De trigger is wat het een doel geeft. Dus, de trigger vertelt je functie wanneer deze moet draaien. Maar waar komen de gegevens vandaan en waar gaan ze heen? Dat is waar bindings om de hoek komen kijken. Bindings, data erin, data eruit. Bindings zijn een manier om je functie te vertellen welke data gelezen moet worden en waar resultaten heen moeten zonder extra code te schrijven. Dat is een mondvol, dus laat ik het vereenvoudigen. Er bestaan twee typen. Input bindings halen gegevens naar je functie toe. Output bindings sturen gegevens naar buiten. Zonder bindings zou je telkens SDK code moeten schrijven als je met een opslagaccount, database of wachtrij wilt communiceren. Je zou verbindingsreeksen beheren, pogingen opnieuw uitvoeren, gegevens serialiseren en antwoorden deserialiseren.

Dat is een hoop boilerplate code alleen om een bestand te lezen. Met bindings declareer je gewoon wat je nodig hebt. Je zegt, ik wil lezen uit deze blobcontainer. Of, ik wil schrijven naar deze wachtrij. De runtime zorgt voor de rest. Hij opent de verbinding, leest de gegevens en geeft deze als parameter door aan je functie. Wanneer je functie klaar is, neemt hij de retourwaarde en schrijft deze naar de door jou opgegeven locatie. Zie bindings als leidingen. Je verbindt je functie met een opslagaccount, een database of een wachtrij. De gegevens stromen automatisch door die leidingen. Je functie hoeft niet te weten hoe de leidingen werken. Hij ontvangt alleen wat er doorheen komt en verstuurt wat eruit moet. Hier is een concreet voorbeeld. Stel dat je een blobinputbinding hebt. Wanneer je functie start, leest deze automatisch een bestand uit de blobopslag en geeft dit aan je door als parameter.

Je hoeft geen storage SDK code te schrijven. Je ontvangt simpelweg de data en verwerkt deze. Een ander voorbeeld is een queue outputbinding. Je functie verwerkt iets en aan het einde retourneer je een waarde. De runtime neemt die waarde, serialiseert deze en plaatst hem in de wachtrij. Je hoeft geen wachtrijcode te schrijven. Je hoeft alleen een waarde te retourneren. Bindings zijn optioneel. Je kunt er 0, 1 of vele hebben. Sommige functies hebben alleen een trigger nodig zonder enige binding. Anderen hebben misschien 3 of 4 verbindingen met verschillende services. De combinatie van triggers en bindings maakt Azure Functions zo krachtig. Jij schrijft de bedrijfslogica, de daadwerkelijke besluitvormingscode. Het platform regelt de volledige integratie. Je functie blijft klein, gefocust en makkelijk te begrijpen. Het verhaal over de prijzen. De prijsstelling is wat de meeste beginners verrast.

Voor de meeste mensen is het consumptieplan de standaard keuze en je zou er 90% van de tijd mee moeten beginnen. Zo werkt het. Je betaalt alleen wanneer je functie daadwerkelijk draait. Wanneer deze inactief is, betaal je niets. 0, geen cent. Twee componenten bepalen de rekening. Ten eerste het aantal executies, hoe vaak je functie wordt geactiveerd. Ten tweede de uitvoeringstijd, gemeten in iets dat gb seconde wordt genoemd. Dat is in feite hoe lang je functie draaide vermenigvuldigd met hoeveel geheugen deze gebruikte. De gratis toelage is genereus. Je krijgt 1 miljoen executies per maand en 400.000 gigabyte seconde volledig gratis. Voor de meeste kleine projecten, hobbyapps en prototypes betaal je nooit een cent. Nooit. Als je boven de gratis toelage uitkomt, zijn de tarieven nog steeds ongelooflijk goedkoop. 20 cent per miljoen executies. Dat is geen typfout. 20 cent voor een miljoen runs.

Zie het als betalen voor elektriciteit, alleen als je de schakelaar omzet. Er is geen maandelijkse basistarief voor de bedrading in je muren. Je betaalt alleen voor de stroom die je daadwerkelijk verbruikt. Nu zijn er ook andere plannen. Flex Consumption is nieuwer en biedt ondersteuning voor virtuele netwerken. Premium houdt je functies altijd warm, dus er is geen vertraging door een koude start. Dedicated geeft je vaste capaciteit op een traditioneel app-serviceplan. Maar om te beginnen is Consumption bijna altijd de juiste keuze. Toch één waarschuwing. De gratis toelage wordt gedeeld over al je functie-apps binnen hetzelfde abonnement. Als je 10 functie-apps hebt, putten ze allemaal uit dezelfde 1 miljoen gratis executies. Houd dat dus in de gaten als je er meer dan een paar gaat bouwen. De prijsstelling is geweldig. Maar laten we dit concreet maken met een voorbeeld. Een scenario uit de praktijk.

Stel je voor dat je een website beheert waar gebruikers profielfoto's uploaden. Die afbeeldingen zijn enorm, wel 10 megabyte per stuk. En dat zorgt voor een paar echte problemen. Grote bestanden kosten meer opslagruimte. Ze vertragen je website telkens wanneer iemand een pagina laat en ze frustreren je gebruikers die op foto's moeten wachten. Dus heb je een manier nodig om die afbeeldingen automatisch te verkleinen. Zonder Azure Functions zou je vanaf nul een achtergrondproces moeten bouwen. Dat betekent een aparte server regelen, een wachtrij opzetten om de werklast te beheren en code schrijven om alle onderdelen aan te sturen. Dat is een hoop onnodige complexiteit voor zoiets eenvoudigs als het verkleinen van een afbeelding. Met Azure Functions heb je alleen één blob trigger en één functie nodig. Geen zorgen over servers. Laat me uitleggen hoe het werkt. Een gebruiker uploadt een foto via je website en dat bestand belandt in Azure Blob Storage.

Zodra het aankomt, wordt er automatisch een blob trigger geactiveerd. Je functie wordt geactiveerd, voert de compressiecode uit en slaat de kleinere versie weer op in de opslag. Dit alles gebeurt binnen enkele seconden. De gebruiker hoeft nooit te wachten omdat het hele proces achter de schermen draait, volledig onzichtbaar. Hier is nog een alledaags voorbeeld, het sturen van een welkomstmail wanneer iemand zich aanmeldt voor je dienst. Een HTTP trigger vangt het aanmeldingsverzoek van je website op. Je functie start, haalt het e-mailadres van de gebruiker op, verstuurt een welkomstbericht via SendGit en is dan klaar. De gebruiker ontvangt de e-mail vrijwel direct. Geen e-mail server om in te stellen, geen wachtrij om te beheren, gewoon één functie, één taak, klaar. Dit zijn precies de taken waarvoor Azure Functions is ontworpen. Kleine, gerichte, event-driven taken. Geen enorme applicaties, geen complexe workflows, maar gewoon één ding goed gedaan, geactiveerd door iets wat ergens anders gebeurt.

Wanneer gebruik je Azure Functions? Dus, wanneer kies je voor een functie en wanneer gebruik je iets anders? Hier is een snelle manier om te beslissen. Vraag jezelf af of de taak kort is, event-driven is en of deze stateles is. Als je alle drie met ja hebt beantwoord, is Azure Functions waarschijnlijk de juiste tool. Laten we beginnen met de goede use cases. API's en webhooks zijn een perfecte match. Je hebt een lichtgewicht eindpunt nodig dat reageert op een HTTP-verzoek, één ding doet en een resultaat teruggeeft, en dat is precies waar HTTP-triggers voor zijn gemaakt. Bestands- en beeldverwerking is een ander groot voorbeeld. Een bestand belandt in de opslag, je functie start, transformeert het en slaat het resultaat op, allemaal zonder server. Geplande taken zoals nachtelijke opschoonacties of het genereren van rapporten werken uitstekend met timer-triggers. Datatransformatie voor ETL-pipelines komt ook veel voor, en functies vormen de perfecte integratielijn om twee services te verbinden die normaal gesproken niet met elkaar communiceren.

Laten we nu bespreken wanneer functies minder geschikt zijn. Langlopende processen vormen een probleem omdat functies op het verbruiksabonnement standaard een time-out-limit van 5 minuten hebben, tot maximaal 10 minuten indien geconfigureerd. Als je taak langer duurt dan dat, heb je iets anders nodig. Stateful applicaties zijn ook niet geschikt. Functies onthouden niets tussen uitvoeringen door. Als je sessiestatus moet behouden of de voortgang over stappen heen wilt bijhouden, werk je het ontwerp tegen. Zware rekenwerklasten zijn ook niet de juiste keuze. Als je langdurig CPU-kracht nodig hebt gedurende minuten of uren, is een virtuele machine of container een betere optie. En complexe workflows, waarbij de ene taak afhankelijk is van de andere, kunnen beter worden afgehandeld door Durable Functions of Logic Apps. Hier is een kort overzicht van de alternatieven. Azure Logic Apps is de no-code optie voor het verbinden van services.

Als je geen aangepaste code hoeft te schrijven, kunnen Logic Apps de klus klaren met een visuele ontwerper. Azure App Service is bedoeld voor volledige webapplicaties die 24 zevende draaien. Als je een complete website of API nodig hebt die altijd aanstaat, is dat jouw tool. Azure Container Apps biedt je gecontaineriseerde microservices met meer controle over de runtime. En Azure Virtual Machines geeft je volledige controle over het besturingssysteem als je dat nodig hebt. Hier is een eenvoudige vuistregel. Als je de taak in één zin kunt omschrijven, is het waarschijnlijk een goede kandidaat voor een functie. Comprimeer afbeeldingen wanneer ze worden geüpload. Verstuur een welkomstmail wanneer iemand zich aanmeldt. Voer elke nacht om middernacht een opschoon taak uit. Eén zin, één taak, één functie. Veelgemaakte beginnersfouten om te vermijden. Laten we nu een paar dingen bespreken waar je op moet letten.

Dit zijn de fouten waar bijna iedereen in trapt als ze beginnen. Een veelgemaakte beginnersfout is denken dat functies altijd gratis zijn. De gratis toekenning is ruimhartig. Ik weet dat een miljoen uitvoeringen veel klinkt, maar als je functie viraal gaat of wordt bestookt door een bot, lopen die uitvoeringen snel op. Hou dus je verbruik in de gaten, stel een budgetwaarschuwing in Azure in en voorkom een verassingsrekening aan het eind van de maand. Een andere fout is het negeren van cold starts. De eerste keer dat je functie draait nadat deze inactief is geweest, duurt het langer. Op het verbruiksabonnement kan dat enkele seconden duren. Voor de meeste use cases is dat prima. Maar als je een latencygevoelige API bouwt waarbij elke milliseconde telt, overweeg dan het premium abonnement of schakel Always Ready instances in. En dan is er nog het schrijven van functies die te lang draaien.

Het verbruiksabonnement heeft een timeout 5 minuten standaard, 10 minuten maximaal. Als je functie 15 minuten nodig heeft om een bestand te verwerken, wordt deze halverwege beëindigd. Deel die taak op in kleinere stukken of gebruik een ander hostingabonnement. Nog iets dat je makkelijk vergeet is het niet gebruiken van run from package deployment. Het is een simpele configuratiewijziging die cold starts verbetert en deployments betrouwbaarder maakt. In plaats van losse bestanden te kopiëren, implementeer je een zip-pakket. Het is één vinkje in de portal, doe het gewoon. HTTP-eindpunten blootstellen zonder authenticatie is een andere valkuil. Het is makkelijk om een functie op anoniem te laten staan tijdens het testen en hem daarna niet te beveiligen. Stel het autorisatieniveau vanaf het begin correct in. Gebruik functie- of beheerdersleutels. Laat de deur niet openstaan. Storage-accounts hergebruiken voor meerdere functie-apps is ook een probleem.

Tijdens de ontwikkeling is delen prima. In productie moet elke functie-app een eigen storage-account hebben. Anders krijg je problemen met lawaaierige buren waarbij het verkeer van de ene functie de andere vertraagt. En tot slot application insights niet inschakelen. Zonder dat vlieg je blind. Je ziet geen fouten, storingen of prestatieproblemen. Je weet niet of je functie te lang draait of stilletjes faalt. Schakel het vanaf dag 1 in. Het kost 30 seconden en bespaart uren aan debuggen. De gouden regel voor dit alles is hou je functies klein, gericht en stateles. Eén taak per functie, niets meer. Dat is dus het systeem. Azure Functions is serverless compute die kleine stukjes code uitvoert als reactie op gebeurtenissen. Je betaalt alleen wanneer je code draait. Triggers vertellen je functie wanneer hij moet ontwaken. Bindings verbinden hem met de benodigde data en het verbruiksabonnement houdt het bijna gratis voor kleine projecten.

Je beste set op dit moment is het maken van een simpele HTTP-getriggerde functie in de Azure Portal. Het kost 5 minuten en is gratis. Abonneer je op Microsoft Knowledge Nuggets voor meer uitleg in begrijpelijke taal... ...en deel dit met iemand die steeds vraagt wat serverless betekent. Vrouw.