Serverless is een cloudontwikkelingsmodel waarmee ontwikkelaars toepassingen kunnen maken en uitvoeren zonder de onderliggende infrastructuur (servers, OS, enz.) te hoeven beheren. De cloudprovider zorgt voor alles, inclusief schalen, serverbeheer en hoge beschikbaarheid. Maar waar moet je beginnen? Welk cloudplatform moet je kiezen? En voor welk gebruik? Lees meer over best practices, de valkuilen die u moet vermijden en volg ons stapsgewijze stappenplan...
Le serverloos is nu een belangrijke trend in cloud computing. Steeds meer organisaties kiezen voor dit model om hun flexibiliteit te vergroten en hun infrastructuurkosten te verlagen.
De serverless markt zal in 2025 ongeveer 25 miljard dollar waard zijn, gedreven door de vraag naar flexibiliteit en kostenreductie. Voor IT-afdelingen betekent dit een strategische hefboom, maar ook een uitdaging om onder de knie te krijgen.
Volgens een Datadog-rapport uit 2023 heeft de meerderheid van de bedrijven die AWS of Google Cloud gebruiken al minstens één serverless implementatie, en doet bijna de helft van de Azure-gebruikers hetzelfde.
Maar wat is serverless precies, waar komt het vandaan en wat verandert het voor IT-professionals?
Wat is serverloos?
Serverless is een cloud-native ontwikkelmodel waarmee applicaties kunnen worden gemaakt en uitgevoerd zonder fysieke of virtuele servers te hoeven beheren.
In tegenstelling tot wat de term suggereert, we hebben het niet over een totale afwezigheid van servers, maar eerder over een volledige abstractie van hun beheer De cloudprovider zorgt voor provisioning (het voorbereiden en configureren van de benodigde hardware- en softwaremiddelen), onderhoud, schaling en beschikbaarheid van de onderliggende infrastructuur.
De ontwikkelaar concentreert zich uitsluitend op de code en de bedrijfslogica, die vaak verpakt is in de vorm van functies of containers. De applicatie draait op aanvraag, in reactie op gebeurtenissen, en de facturering is gebaseerd op het werkelijke gebruik, waardoor de kosten worden geoptimaliseerd, met name voor onregelmatige of onvoorspelbare werklasten.
Verschil met standaard cloud computing
In een standaard cloud computing-model als deIaaS (Infrastructure-as-a-Service) kopen gebruikers vooraf capaciteitseenheden. Ze betalen een publieke cloudprovider voor permanent actieve servercomponenten om hun applicaties op uit te voeren. Het is hun verantwoordelijkheid om servercapaciteit te gebruiken en uit te breiden tijdens perioden van grote vraag en om deze te beperken wanneer deze niet langer nodig is. De cloudinfrastructuur blijft actief, zelfs wanneer de applicatie niet in gebruik is, wat tot kosten kan leiden.
Serverless daarentegen is een gebeurtenisgestuurd uitvoeringsmodel. Applicaties reageren op de vraag en passen zich automatisch aan als dat nodig is. Wanneer een serverloze functie inactief is, kost het niets. De cloudprovider beheert de infrastructuur, inclusief schaling en onderhoud. Het belangrijkste doel is om ontwikkelaars in staat te stellen zich te concentreren op de code van hun applicaties, terwijl de provider de onderliggende infrastructuur beheert.
Serverloze toepassingen worden ingezet in containers die op verzoek automatisch opstarten.
De verschillende soorten serverless computing
Serverless valt voornamelijk uiteen in twee categorieën:
Functie als een service (FaaS) wordt vaak beschouwd als het hart van serverless - het gaat om het inzetten van applicatiefuncties die worden geactiveerd door gebeurtenissen, kortstondig worden uitgevoerd en staatloos (stateless) in tijdelijke containers. De code aan de serverkant blijft de verantwoordelijkheid van de ontwikkelaar, maar de uitvoering ervan wordt beheerd door het cloudplatform in containers die geen gegevens vasthouden tussen twee aanroepen. Dit betekent dat elke keer dat de functie wordt aangeroepen, deze in een nieuwe omgeving start, wat betekent dat er korte taken nodig zijn die niet afhankelijk zijn van gegevens in persistent lokaal geheugen.
Le Backend-as-a-Service (BaaS) verwijst naar kant-en-klare backend diensten geleverd door een derde partij. Bijvoorbeeld beheerde databaseservices, authenticatie, bestandsopslag, realtime messaging, enzovoort, waarbij de ontwikkelaar een API gebruikt zonder deze componenten zelf te hoeven implementeren.
Wat is de oorsprong van serverless?
Het concept van serverless is het resultaat van een geleidelijke evolutie in de wereld van cloud computing. Lang voordat de term populair werd, bestond het idee om ontwikkelaars te ontlasten van serverbeheer al in andere vormen.
Platform als service (PaaS)Eind jaren 2000 bijvoorbeeld boden de Google App Engine en Heroku een voorproefje van serverloosheid, waarbij applicaties konden worden geïmplementeerd zonder de infrastructuur te beheren. De term "serverloos zelf verscheen pas later om een nog granulairdere en event-driven benadering van cloud computing aan te duiden.
Het keerpunt kwam in 2014 wanneer Amazon Web Services lanceert AWS Lambda. Voor velen is dit het concrete startpunt voor serverless zoals we het vandaag begrijpen. AWS Lambda introduceert een model voor het uitvoeren van functies op aanvraag, getriggerd door gebeurtenissen, met facturering per locatie en volledig transparante autoscaling. Je hoeft geen VM's te starten of te stoppen - de code draait in een efemere container die wordt beheerd door AWS en schaalt automatisch.
Sindsdien is het serverloze ecosysteem steeds sterker geworden. Er zijn nieuwe diensten ontstaan om de uitvoering van functies aan te vullen: bijvoorbeeld databases serverloos (AWS DynamoDB in on-demand modus, Azure Cosmos DB serverless), streamverwerking (AWS Kinesis, Google Cloud Pub/Sub + Functions) of serverless orkestrators (AWS Step Functions, Azure Logic Apps).
Er zijn ook open source-oplossingen opgedoken (OpenFaaS, Apache OpenWhisk gebruikt door IBM Cloud) om serverless buiten de grote clouds mogelijk te maken.
Wat zijn de voordelen van serverless?
Serverless is zo succesvol omdat het talloze voordelen biedt aan ontwikkelteams en bedrijven. Hier zijn de belangrijkste voordelen:
- Geen serverbeheer, geen focus op de applicatie. Het eerste, voor de hand liggende voordeel is ontwikkelaars bevrijden van systeembeheertaken. U hoeft geen machines, OS-patches of middleware te configureren of te onderhouden - de cloud zorgt ervoor. Hierdoor kan het team zich concentreren op applicatielogica, functionaliteit en gebruikerservaring, waardoor de ontwikkeling wordt versneld.
- Automatische schaalbaarheid en elasticiteit. Serverloze functies en diensten passen zich automatisch aan de belasting aan. Of er nu 10 aanvragen per dag zijn of 10 miljoen, het platform wijst dynamisch de instances toe die nodig zijn om de aanvragen parallel te verwerken. Deze onmiddellijke elasticiteit is een groot voordeel als het gaat om het opvangen van onverwachte verkeerspieken zonder handmatige tussenkomst. Bijvoorbeeld, een e-commerce website gehost via een Gateway API + Lambda functies zal een piek in het bezoek tijdens Black Friday kunnen opvangen zonder dat de ontwikkelaars overcapaciteit hoeven te plannen - de functies vermenigvuldigen zich op aanvraag. Omgekeerd zullen er in dalperiodes geen resources onnodig draaien. De dimensionering is altijd "precies goed", wat de beschikbaarheid van de service verbetert zonder bijzondere architecturale inspanningen.
- Pay-as-you-go, kostenoptimalisatie. Het bedrijfsmodel voor serverless is over het algemeen betalen-per-gebruikMet andere woorden, het wordt gefactureerd op aanvraag, volgens het werkelijke verbruik. In tegenstelling tot een traditionele server die per uur wordt gefactureerd (zelfs als hij niets doet), kost een serverloze functie alleen iets wanneer hij wordt uitgevoerd. Dit is hoe het werkt, "Bronnen zijn nooit inactief, ze worden alleen geactiveerd op aanvraag".. Klanten betalen alleen voor de daadwerkelijk gebruikte middelen (CPU-tijd, geheugen, aantal oproepen), niet voor inactieve tijd. Dit model kan aanzienlijke besparingen opleveren, vooral voor intermitterende of onvoorspelbare werklasten. Een toepassing waarvan de activiteit in de loop van de tijd sterk varieert, kost bijvoorbeeld veel minder met serverless dan met een permanent toegewezen server.
- Prestaties en snelheid van installatie. Serverloze platforms maken gebruik van de mogelijkheden van clouds om het volgende te bieden zeer korte reactietijden. Het opstarten van een functie gebeurt bijna onmiddellijk (een paar milliseconden voor een 'warme' container), en zelfs als een nieuwe instantie koud wordt opgestart, blijft de vertraging in de meeste omgevingen zeer laag (vooral bij geïnterpreteerde talen). Bovendien worden veel componenten al ondersteund door de leverancier (load balancing, CDN, authenticatie, etc. via managed services), de tijd die nodig is om een nieuwe applicatie te ontwikkelen en te implementeren wordt verkort. Je kunt binnen enkele uren van een idee naar een werkend prototype gaan. Een ontwikkelaar kan bijvoorbeeld een complete REST API in slechts enkele minuten coderen en implementeren met behulp van AWS Lambda en API Gateway, terwijl het configureren van een traditionele serverstack dagen zou hebben geduurd. De snelle provisioning van serverless (geen vertraging bij het bestellen van een server of het opstarten van een VM) betekent dat ontwikkeling zeer snel kan worden uitgevoerd.
Serverless moedigt ook goede DevOps-praktijken aan: Infrastructure as Code (IaaS), frequente implementaties en nauwe samenwerking tussen ontwikkelaars en beheerders. Ontwikkelaars worden aangemoedigd om een "DevOps zonder serverZe integreren de infrastructuur (ook al wordt die beheerd door de cloud) rechtstreeks in hun ontwikkelcyclus via frameworks (Serverless Framework, AWS SAM, Terraform, enz.). Omdat de operationele toetredingsdrempel lager is, is er vaak een een sterkere DevOps-cultuur en een meer democratische benadering van productie. Een ontwikkelaar kan bijvoorbeeld eenvoudig de configuratie van een functie en de bijbehorende triggers opnemen in dezelfde code repository als de applicatie, waardoor autonomie en verantwoordelijkheid voor de gehele levenscyclus worden bevorderd.
- Hoge beschikbaarheid en fouttolerantie. Bij het ontwerp worden serverloze diensten gedistribueerd over de infrastructuur van de cloudprovider, wat redundantie garandeert. Een ingezette functie wordt over het algemeen gerepliceerd over verschillende zones om hardwarestoringen te kunnen tolereren. Providers garanderen vaak een hoge beschikbaarheid (AWS Lambda wordt bijvoorbeeld standaard ingezet op meerdere beschikbaarheidszones). De ontwikkelaar hoeft geen extra inspanning te leveren om van deze robuustheid te profiteren. Bovendien vergemakkelijkt de stateloze aard failover in het geval van een probleem: een functie-instantie die faalt, heeft geen invloed op andere aanroepen en orkestratiesystemen kunnen mislukte uitvoeringen automatisch opnieuw starten. In combinatie met andere beheerde services (gerepliceerde database, duurzame objectopslag, enz.) is het resultaat een architectuur die inherent bestand is tegen regionale of hardwarefouten, zonder dat failover handmatig geconfigureerd hoeft te worden.
- Efficiëntie en ecodesign. Alleen de strikt noodzakelijke hulpbronnen gebruiken heeft zowel ecologische als technische voordelen. Vanuit technisch oogpunt elimineert het ongebruikte middelen De infrastructuur wordt zoveel mogelijk gedeeld tussen klanten en 'on the fly' toegewezen, wat de algehele efficiëntie van het netwerk verbetert. datacenters. Vanuit het oogpunt van milieuvriendelijk softwareontwerp vermijdt serverless dat servers continu draaien die zelden worden gebruikt, waardoor energieverspilling wordt tegengegaan. De grote leveranciers optimaliseren hun installaties voor energieverbruik, dus het delegeren van computing naar deze platforms kan de CO2-voetafdruk van je applicatie verminderen. Dit is een steeds populairder argument: een goed ontworpen serverloze applicatie minimaliseert het gebruik van CPU en geheugen, wat, vermenigvuldigd op schaal, een lagere impact heeft op het milieu.
Natuurlijk gaan deze voordelen gepaard met tegenpartijen en limieten (hieronder beschreven in de te vermijden valkuilen). Maar in veel scenario's maken de winst in productiviteit, kosten en flexibiliteit serverless een aantrekkelijke keuze in vergelijking met traditionele architecturen op dedicated servers of zelfs beheerde containers.
Waar moet ik beginnen?
Gezien de belofte van serverless is het misschien verleidelijk om er meteen mee aan de slag te gaan. Het is echter belangrijk om een weloverwogen start te maken. Waar begin je als je serverless wilt gaan werken? De eerste stap is een duidelijk begrip van het concept en de use cases. Het is raadzaam om je in te lezen over hoe serverless functies en hun event-modellen werken, en de voorbeelden van de grote leveranciers (AWS, Azure, GCP) te bekijken om te begrijpen hoe deze architectuur verschilt van een traditionele aanpak. Met andere woorden, je moet de "gemoedstoestand serverloos: denk evenementen, staatloosDit betekent dat je niet langer een permanente server hebt om bijvoorbeeld sessies of tijdelijke bestanden op te slaan.
Vervolgens moeten weeen eenvoudige en geschikte initiële use case identificeren om het onder de knie te krijgen. In plaats van een hele kritische applicatie direct over te schakelen op serverless, is het verstandig om te kiezen voor een kleinschalig proefproject. Dit kan bijvoorbeeld de ontwikkeling zijn van een kleine interne API, een gepland automatiseringsscript of geïsoleerde gegevensverwerking. Het doel is om zonder grote risico's vertrouwd te raken met de ontwikkel- en implementatiecyclus en de specifieke functies (logboekbeheer, monitoring, rechtenbeheer). Idealiter zou dit eerste project kenmerken moeten hebben die bevorderlijk zijn voor serverless: een variabele of zeldzame belasting (om te profiteren van pay-per-use), geen noodzaak om een toestand in het geheugen te houden tussen twee executies, en niet-kritische prestaties tot op de milliseconde (om mogelijke "crashes" te tolereren). koude start). Een veelvoorkomend voorbeeld is het maken van een kleine service voor het genereren van PDF-rapporten die op verzoek wordt geactiveerd, of een functie die elke nacht wordt uitgevoerd om een database op te schonen - goed gedefinieerde taken die zijn aangepast aan het serverloze model.
Eindelijk, waar te beginnen omvat ook zijn ontwikkelomgeving voorbereiden. Dit betekent over het algemeen een account openen bij een cloudprovider (of het account van je bedrijf hergebruiken), de juiste commandoregeltools installeren (bijv. AWS CLI, Azure CLI, Google Cloud SDK) en mogelijk een implementatieraamwerk. De meeste platformen bieden gratis of zeer goedkope niveaus om mee te beginnen, zodat je kunt experimenteren zonder budgetbeperkingen. AWS Lambda biedt bijvoorbeeld een miljoen gratis invocaties per maand, wat meer dan genoeg is voor de eerste tests. We raden je daarom aan om gebruik te maken van deze gratis derde partij. Samenvattend beginnen we met training, het kiezen van een klein project, het aanschaffen van de benodigde gereedschappen en accountsDan kunnen we overgaan tot concrete actie.
Aan de slag met serverless: een stappenplan in meerdere fasen
Zodra de basis is gelegd en de beoogde use case is geïdentificeerd, is het tijd om aan de slag te gaan. Om je op weg te helpen, is hier een stapsgewijs stappenplan om een effectieve start te maken met serverless. Deze stap-voor-stap handleiding helpt je om je vaardigheden te ontwikkelen en veelvoorkomende valkuilen te vermijden:
Stap 1: Kies uw leverancier en omgeving
Begin met het selecteren van het serverloze platform dat voor jou het meest zinvol is. De keuze hangt vaak af van je context: of je bedrijf al sterk aanwezig is op AWS, AWS Lambda is een natuurlijke keuze als je in een Microsoft-omgeving werkt, Azure Functies integreert goed; voor specifieke behoeften of een koppeling met Google Cloud, Google-cloudfuncties of Wolkenloop geschikt zijn. Elke grote cloud heeft zijn sterke punten, maar om je op weg te helpen bieden ze allemaal uitgebreide documentatie en kant-en-klare voorbeelden. Als je eenmaal een keuze hebt gemaakt, zorg er dan voor dat je de juiste ontwikkeltools installeert (CLI, SDK) en je toegangsgegevens configureert (API-sleutels, enz.). Bereid je lokale omgeving voor met de taal die je gaat gebruiken (Python, Node.js, C#, enz.). - Kies een ondersteunde taal die je al kent, zodat je niet tegelijkertijd serverless en een nieuwe taal hoeft te leren).
Stap 2: Een initiële "Hello World"-functie implementeren
Begin met een minimaal voorbeeld om je ontwikkelketen te valideren en de volledige cyclus te begrijpen. Maak bijvoorbeeld een kleine functie die simpelweg een "Hello World" bericht of de datum van vandaag retourneert. Gebruik de webconsole of opdrachtregeltools van de provider om deze functie te implementeren. Op AWS Lambda kan dit rechtstreeks via de console in slechts een paar klikken, of via het commando aws lambda creatie-functie. Op Azure kun je VS Code met de Azure Functions extensie gebruiken om een lokaal functieproject te starten en te publiceren. Het doel van deze stap is om te controleren of je het volgende weet je code verpakken, implementeren en uitvoeren in de cloud. Test het aanroepen van je functie: als het bijvoorbeeld een HTTP-functie is, roep dan de publieke URL aan; als het een event-triggered functie is, gebruik dan een testmechanisme (AWS Lambda biedt een testtool in de console). Zodra "Hello World" werkt, heb je al een belangrijke psychologische mijlpaal bereikt: je code draait "ergens in de cloud" zonder dat je een server hebt geconfigureerd!
Stap 3: Een trigger toevoegen en een service integreren
Verrijk je voorbeeld door een echte triggergebeurtenis en mogelijk integratie met een cloudservice. Verbind je functie bijvoorbeeld met een Gateway API om deze te triggeren met een HTTP REST verzoek (typisch geval voor het maken van een serverloze API). Of configureer een tijdstrigger (een cron) als je functie op een geplande manier moet worden uitgevoerd - op Azure Functions is dit een Timer Trigger eenvoudig te configureren, op AWS gebruik je EventBridge (voorheen CloudWatch Events) om de uitvoering te plannen. Je kunt je functie ook koppelen aan een opslaggebeurtenis: bijvoorbeeld een afbeelding die wordt gedropt in een S3-bucket die automatisch een Lambda-afbeeldingsverwerkingsfunctie activeert. Profiteer van deze stap om een beheerde service, zoals een database of een externe API, aan te roepen vanuit de functie, zodat je begrijpt hoe je uitgaande oproepen en machtigingen moet beheren. Je functie kan bijvoorbeeld een record schrijven naar DynamoDB (AWS NoSQL-database) of in Brandstore op GCP, of stuur een bericht naar een wachtrij (Azure Service Bus, AWS SQS). Je leert hoe je beveiligingsrollen configureert (IAM op AWS, Identity/Access Management equivalent op GCP/Azure) om je functie de benodigde rechten te geven, zonder meer open te stellen dan nodig is. Deze fase consolideert uw controle over de interacties tussen de functie en het ecosysteem.
Fase 4: Structureren en implementeren met behulp van een raamwerk
Zodra je verder gaat dan een eenvoudige functie, is het een goede gewoonte om de implementatie te automatiseren met behulp van beschrijvende code (Infrastructure as Code). Gebruik een tool zoals Serverloos raamwerk, AWS SAM (Serverloos Toepassingsmodel), Terraformof de native tool van je cloud (Azure ARM/Bicep, Google Cloud Deployment Manager). Neem je project en transformeer het zodat de configuratie (triggers, gekoppelde resources) wordt beschreven in een bestand (YAML, JSON of HCL afhankelijk van de tool) en de volledige implementatie kan worden gedaan door een enkele opdracht. Met Serverless Framework schrijf je bijvoorbeeld een bestand met de naam serverless.yml commando, dat de functie definieert, de runtime en de gebeurtenis die de functie activeert, dan is de serverloze implementatie maakt alles automatisch aan. Deze stap lijkt misschien een extra inspanning, maar het laat je wennen aan het beheren van je code + configuratie op een geversioneerde manier, en zal het veel gemakkelijker maken om te evolueren naar verschillende functies en omgevingen (staging, productie). Dit is ook het moment om uw code in modules te organiseren, afhankelijkheden te beheren (gebruik bijvoorbeeld een vereisten.txt in Python of een pakket.json in Node.js om de bibliotheken in te sluiten die nodig zijn voor de functie).
Stap 5: Testen, bewaken en optimaliseren
Zodra je functie (of kleine set functies) is ingezet via een framework, zorg er dan voor dat je de test- en bewakingstools geschikt. Test indien mogelijk lokaal: de meeste frameworks bieden emulators of lokale testtools om uitvoering te simuleren (bijvoorbeeld de serverloos lokaal aanroepen kunt u een Lambda lokaal testen). Stel unit tests in voor de logica van je functies en integratietests die de functie in de cloud daadwerkelijk aanroepen om het gedrag ervan te controleren. Maak jezelf vertrouwd met de : CloudWatch-logboeken voor AWS Lambda, Inzichten in toepassingen voor Azure Functions, enz. Controleer of je functie nuttige logs schrijft (bijvoorbeeld via console.log of afdrukken) en dat je deze logs kunt raadplegen in het geval van een probleem. Houd ook de basismetriek in de gaten: aantal invocaties, gemiddelde duur, eventuele fouten of time-outs. In deze fase leer je hoe je debuggen in een serverloze omgevingDit is een beetje anders dan traditioneel debuggen op een server (je kunt niet gewoon verbinding maken met een machine op afstand). Maak van de gelegenheid gebruik om de configuratie te optimaliseren: pas bijvoorbeeld het geheugen aan dat is toegewezen aan de functie (meer geheugen kan de CPU-uitvoering versnellen ten koste van hogere kosten per eenheid - er is vaak een optimaal punt te vinden). Observeer de koude start (koude start): als u een merkbare vertraging opmerkt bij de eerste aanroep na een periode van inactiviteit, overweeg dan oplossingen om dit te beperken (een functie "warm" houden door regelmatig aanroepen te doen, of op AWS Lambda, het inschakelen van Bevoorrade Concurrency om een permanent actieve instantie vooraf toe te wijzen als dat echt nodig is).
Fase 6: De architectuur uitbreiden en industrialiseren
Als je een eerste proefproject met succes hebt afgerond, kun je geleidelijk aan uitbreiding van het gebruik van serverless naar andere onderdelen van je systeem. Identificeer andere functionaliteiten of microservices in je applicatie die baat zouden kunnen hebben bij migratie naar serverless. Bijvoorbeeld, migreer na een eenvoudige API misschien beeldverwerking, of zet een asynchroon notificatiesysteem op via functies. Bouw beetje bij beetje aan een meer complete architectuur, terwijl je zorgt voor algehele consistentie. In dit stadium moet je ook het volgende overwegen industrialiseer je CI/CD-pijplijnen voor je functies: integreer deployment in je workflows (bijvoorbeeld, deploy de functie automatisch op het testplatform elke keer als je de bijbehorende branch commit). Zorg ervoor dat de configuratiebeheerstrategie (bijvoorbeeld omgevingsvariabelen) en beveiligingsstrategie (encryptie van geheimenDit betekent dat je er geavanceerder gebruik van kunt maken in de productie. Documenteer tot slot de best practices in je bedrijfscontext, train je collega's en deel feedback. De adoptie van serverless kan een culturele verandering met zich meebrengen (infrastructuur beheerd door code, grotere afhankelijkheid van een leverancier), dus het is belangrijk om het team te ondersteunen bij deze overgang.
Door dit stappenplan te volgen, evolueert u geleidelijk van een beginner naar een doorgewinterde serverless beoefenaar. Elke stap consolideert je vaardigheden en zorgt ervoor dat je geen stappen overslaat, waardoor het risico op fouten bij de overstap naar deze nieuwe aanpak afneemt.
Welk serverless platform moet je kiezen?
De keuze van het platform is een belangrijk punt als het gaat om serverless. Er zijn veel talrijke serverloze aanbiedingen en de keuze zal afhangen van technische, strategische en soms persoonlijke criteria. De drie belangrijkste cloudproviders - Amazon Web Services (AWS), Microsoft Azure, Google cloudplatform (GCP) - domineren grotendeels het landschap, met volwassen oplossingen die geïntegreerd zijn in hun respectieve ecosystemen. Maar we mogen het bestaan van andere spelers en gespecialiseerde platformen niet vergeten, die geschikt kunnen zijn voor bepaalde toepassingen.
Hier volgt een overzicht van de belangrijkste serverless platformen en de factoren waarmee rekening moet worden gehouden:
- AWS Lambda (AWS) AWS Lambda is de pionier en het meest gebruikte aanbod op de markt. AWS Lambda profiteert van een zeer groot ecosysteem van geïntegreerde services (API Gateway om er een web-API van te maken, S3 om het toevoegen van bestanden te triggeren, DynamoDB Streams, CloudWatch Events, enz.) De community rond AWS Lambda is enorm, wat leidt tot talloze voorbeelden, tutorials en tools van derden (Serverless Framework is geboren met AWS Lambda als eerste doel). AWS biedt ook aanvullende diensten zoals AWS Step Functions voor het orkestreren van meerdere Lambda's in een workflow, of Amazon EventBridge voor applicatieoverschrijdend eventbeheer. Als je op zoek bent naar veelzijdigheid en volwassenheid, dan is Lambda een uitstekende keuze. Wat de beperkingen betreft, legt AWS Lambda een maximale uitvoeringstijd op (15 minuten per aanroep) en heeft het in het verleden last gehad van koude start iets langer voor bepaalde runtimes (bijv. Java of .NET). Maar AWS heeft optimalisaties geïntroduceerd (Provisioned Concurrency) en zelfs de mogelijkheid om functies verpakken in Docker-images voor meer flexibiliteit.
- Azure Functies (Microsoft Azure) Azure Functions: zeer goed geïntegreerd in het Microsoft ecosysteem, is Azure Functions een natuurlijke keuze voor bedrijven die al gebruik maken van Azure of Microsoft tools (.NET, Visual Studio). Het ondersteunt tal van talen (C#, JavaScript/TypeScript, Python, Java, PowerShell, enz.) en integreert gemakkelijk met andere Azure services (Azure Event Grid voor events, Azure Cosmos DB voor output/input, Azure DevOps voor CI/CD, enz.) Azure Functions is uniek omdat het niet alleen kan worden gehost in 100 % serverloze modus (verbruiksplan op aanvraag), maar ook in toegewijd of premium waardoor je vooraf toegewezen instanties hebt, wat de koude latentie kan verminderen. Voor een .NET-ontwikkelaar of een Microsoft 365-context is dit vaak het ideale platform. De ontwikkelinterface, vooral via Visual Studio Code, is zeer gebruiksvriendelijk voor het maken en implementeren van Functions. Azure heeft zich ook gericht op productiviteit van ontwikkelaars Azure: lokaal debuggen, testen met Azure Functions Core Tools, enz.
- Google cloudfuncties en cloudrun (Google Cloud) Google biedt twee benaderingen. Cloud Functions is het directe equivalent van Lambda/Azure Functions - een beheerde gebeurtenisgestuurde functie. Wolkenloop is een serverloze service voor containers: je implementeert een Docker image (met bijvoorbeeld een kleine webserver of applicatie) en Google draait het serverloos (ook autoscaling en pay-per-use). Cloud Run is erg populair geworden omdat het het gemak van serverless combineert met de flexibiliteit van containers (onbeperkte taalkeuze, de mogelijkheid om binaries op te nemen, enz.)
- Andere platforms Naast de 'Grote Drie' van de cloud zijn er ook serverloze aanbiedingen om te overwegen. Deze omvatten IBM cloudfuncties is gebaseerd op Apache OpenWhisk en biedt ook meertalige FaaS. Oracle cloud heeft een Functieservice (gebaseerd op Fn Project). Alibaba wolk in China heeft Functie Compute. Ook het vermelden waard Cloudflare-werknemers die een originele benadering van serverloosheid biedt door het direct aan de rand (edge computing) zo dicht mogelijk bij gebruikers uit te voeren, wat uitblinkt voor vereisten met zeer lage latency op gedistribueerde content. Cloudflare Workers gebruikt een ander model (isolatie via V8-isolaten) en ondersteunt met name JavaScript/Workers-syntaxis. Dit is een goede keuze voor het dynamisch genereren van webpagina's aan de rand van het netwerk, bijvoorbeeld, of het implementeren van API's die wereldwijd gedistribueerd zijn. Iets anders is dat moderne PaaS-diensten zoals Netlify-functies of Vercel Functies bieden geïntegreerde serverless voor webontwikkelaars, gekoppeld aan de inzet van statische sites.
Dus hoe kies je?
Het belangrijkste criterium is vaak bestaande kennis en het ecosysteem. Als je team al getraind is in AWS en uitgebreid gebruik maakt van de diensten, dan is de kans groot dat AWS Lambda prima werkt (vooral omdat veel tools van derden al compatibel zijn met AWS). Evenzo, onderschat de leveranciersvergrendeling Als je je zorgen maakt over propriëtaire lock-in, moet je weten dat het migreren van een serverloze applicatie van de ene provider naar de andere niet triviaal is. Het kan eenvoudiger zijn om consistent te blijven met je hoofdcloud.
Elk platform heeft zijn eigen specifieke kenmerken (tijds- en geheugenlimieten, ondersteunde formaten, configuratiemodi). Je kunt ze het beste van tevoren bestuderen om te zien welke past bij jouw behoeften. AWS Lambda legt bijvoorbeeld een maximum van 15 minuten per uitvoering op, GCP Cloud Functions 9 minuten, Azure Functions 10 minuten (in termen van verbruik) - als je langere verwerkingstijden plant, zijn Cloud Run of Azure Functions Premium geschikter. Een ander voorbeeld, in termen van opstartprestaties: AWS-functies op een Node.js- of Python-runtime starten zeer snel op, terwijl een Java-functie langer kan duren; Azure Functions biedt een zeer efficiënte .NET-runtime als je codeert in C# omdat het platform is geoptimaliseerd voor .NET.
Kosten en factureringsmodel kan ook een rol spelen: de grote drie zijn in grote lijnen vergelijkbaar in termen van pay-per-use (enkele tientallen centen per miljoen invocaties, plus CPU/memory-tijd). Er kunnen echter verschillen zijn in de opties: Google Cloud Functions kan uitgaande netwerkgesprekken wel of niet meenemen in de facturering, AWS rekent apart voor verkeer via API Gateway, enzovoort. Afhankelijk van je use case (bijvoorbeeld een intensief gebruikte API waarbij de API Gateway de belangrijkste kostenpost kan zijn), kan dit van invloed zijn op de keuze die je maakt.
Kortom, houd bij het kiezen van een serverloos platform rekening met het volgende je technologische omgeving (affiniteit met AWS/Azure/GCP), de gerichte gebruikssituaties (eenvoudige functies vs. complexere containers, globale real-time vereisten, enz. technische gegevens (ondersteunde talen, limieten, prestaties) en, indien nodig, de kosten. Het goede nieuws is dat het heel goed mogelijk is om te slagen met elk van de grote platforms - ze zijn allemaal beproefd. Sommigen kiezen zelfs voor een multi-cloudstrategie, waarbij elk platform wordt benut voor het beste dat het te bieden heeft (bijv. Cloudflare Workers voor de edge + AWS Lambda voor de interne backend). Als beginner is het echter aan te raden om je eerst op één platform te concentreren, om daar je vaardigheden op te bouwen, voordat je uiteindelijk een ander platform verkent.
In een paar jaar tijd is serverless een gevestigde waarde geworden. pijler van modern computergebruik. Door ontwikkelaars te bevrijden van serverbeheer kunnen ze sneller en goedkoper innoveren. Serverless wordt nu toegepast op een breed scala aan use cases: van het web tot data, van automatisering tot IoT, via de machinaal leren. Natuurlijk is er geen pasklare oplossing en heeft serverless zijn beperkingen, maar als het goed beheerd wordt, biedt het een een krachtige hefboom voor transformatie voor informatiesystemen. Dus of je nu een ontwikkelaar, architect of technisch manager bent, het is zeer waarschijnlijk dat je nu - en in de toekomst nog meer - je pad zult kruisen met een serverloze architectuur.
