AWS Lambda gebruik ik wanneer functionaliteit vooral moet reageren op een gebeurtenis en ik daar geen volledige applicatie of service voor wil onderhouden. Je levert de code, AWS regelt de onderliggende infrastructuur en de functie wordt uitgevoerd wanneer daar aanleiding voor is.
Voor mij zit de kracht vooral in die eenvoud. Niet iedere technische verantwoordelijkheid hoeft uiteindelijk een microservice te worden.
Wat is AWS Lambda?
AWS Lambda is een serverless compute-dienst binnen AWS waarmee code uitgevoerd kan worden zonder zelf servers of containers te beheren.
Een Lambda kan bijvoorbeeld reageren op:
Een bericht op een queue
Een event vanuit een andere AWS-dienst
Een HTTP-request
Een geplande taak
Het verwerken van bestanden
Een intern proces binnen een event-driven architectuur
Je betaalt voornamelijk voor het daadwerkelijke gebruik en AWS schaalt de uitvoering automatisch op basis van de hoeveelheid werk.
Wat vind ik belangrijk bij Lambda?
Houd de verantwoordelijkheid klein
Een Lambda werkt voor mij het beste wanneer deze één duidelijke verantwoordelijkheid heeft.
Wanneer steeds meer businesslogica, afhankelijkheden en uitzonderingen in dezelfde functie terechtkomen, verdwijnt uiteindelijk het voordeel van serverless.
Dan bouw je eigenlijk alsnog een applicatie, maar zonder deze zo te behandelen.
Gebruik events als uitgangspunt
Lambda past goed binnen event-driven architecturen.
Een event vindt plaats, een Lambda reageert daarop en voert een specifieke actie uit. Daardoor kun je relatief eenvoudig processen loskoppelen zonder direct een nieuwe langdurig draaiende service te introduceren.
Denk goed na over fouten
Serverless betekent niet dat foutafhandeling vanzelf geregeld is.
Ik kijk daarom altijd naar zaken zoals:
Retries
Idempotency
Timeouts
Dead-letter queues
Logging
Monitoring
Zeker wanneer Lambda onderdeel wordt van een groter asynchroon proces wil je voorkomen dat dezelfde actie meerdere keren ongecontroleerd wordt uitgevoerd.
Hoe ik AWS Lambda gebruik
Ik gebruik Lambda voornamelijk voor kleine, afgebakende processen binnen een groter systeem.
Bijvoorbeeld wanneer iets moet gebeuren naar aanleiding van een event, maar het niet logisch is om hiervoor een volledige microservice continu beschikbaar te houden.
Ik zie Lambda daarom niet als vervanging voor microservices. Het is voor mij eerder een extra bouwsteen binnen dezelfde architectuur.
Een langdurig bedrijfsproces met veel domeinlogica plaats ik liever in een normale service. Een korte stateless actie die reageert op een gebeurtenis kan juist uitstekend in Lambda.
Die scheiding houdt een architectuur bewust eenvoudig.
Waar ik AWS Lambda heb gebruikt
Bij Marvia heb ik AWS Lambda gebruikt binnen een SaaS-platform waar verschillende AWS-diensten onderdeel waren van de backendarchitectuur. Daar werkte ik onder andere met Lambda, SES en SNS binnen een omgeving waarin microservices en cloud-functionaliteit gecombineerd werden.
Die ervaring heeft mij vooral geleerd dat serverless sterk is wanneer je het gericht inzet. Lambda werd geen doel op zichzelf, maar een oplossing voor processen waarvoor het operationeel niet logisch was om permanent infrastructuur beschikbaar te houden.
AWS is daarna onderdeel gebleven van mijn backendwerk. Ook binnen mijn recente werkzaamheden bij ANWB draaien services op AWS, waardoor cloudarchitectuur nog steeds onderdeel is van de technische keuzes die ik maak.
Mijn ervaring met AWS Lambda
Mijn ervaring met Lambda zit vooral in het combineren ervan met grotere backend- en microservicearchitecturen.
Daar kijk ik tegenwoordig kritischer naar dan vroeger.
Technisch gezien kun je ontzettend veel oplossen met Lambda. Dat betekent alleen niet automatisch dat je dat ook moet doen.
Wanneer een functie steeds meer domeinlogica krijgt, veel interne state nodig heeft of onderdeel wordt van een complex proces, kies ik sneller voor een normale backendservice.
Maar voor kleine event-driven verantwoordelijkheden vind ik Lambda nog steeds een hele sterke oplossing.
Je hoeft niet meer infrastructuur te bouwen dan het probleem daadwerkelijk nodig heeft.
Veelgestelde vragen die ik krijg over AWS Lambda
Wanneer kies je Lambda boven een microservice?
Wanneer de verantwoordelijkheid klein, stateless en event-driven is. Zodra er veel domeinlogica of langdurige processen ontstaan, kies ik liever voor een normale service.
Gebruik je Lambda ook binnen event-driven architecturen?
Ja. Juist daar vind ik Lambda sterk. Een event kan direct een kleine technische verantwoordelijkheid starten zonder dat daar permanent een service voor hoeft te draaien.
Is serverless altijd goedkoper?
Nee. Bij incidentele workloads kan het erg interessant zijn, maar bij constante of zware workloads kan een langdurig draaiende service uiteindelijk logischer zijn.
Wat is volgens jou het grootste risico van Lambda?
Dat een architectuur ongemerkt verandert in tientallen kleine functies waarvan niemand meer goed begrijpt hoe het totale proces loopt. Serverless vraagt nog steeds om structuur.
Zou je een compleet backendplatform bouwen met alleen Lambda?
Technisch kan dat, maar ik zou dat niet als uitgangspunt nemen. Ik combineer liever Lambda, microservices en andere AWS-diensten op basis van de verantwoordelijkheid die opgelost moet worden. De architectuur hoort het probleem te volgen, niet de technologie.