Infrastruktur på nettet kan føles som et salig kaos til tider. Tjenester i øst og vest, med kronglete konfigureringer, tilpasninger og overvåking.
Hadde det ikke vært digg om det var en tjeneste som bare fikset alt for oss? Når vi tar opp disse temaene blir ofte AWS Lambda trukket frem. Men hva i huleste er det egentlig? Og hva brukes det til?
Vi satt oss ned med Lambda-ekspert Erlend Ekern, for å få svar på alle spørsmål vi hadde.
- Hørt flere historier om skyhøye regninger fordi man glemte å skru av ting
#1. Erlend, hvordan ville du forklart AWS Lambda til en nyutdannet utvikler? 🤔
AWS Lambda er en skyløsning i Amazon Web Services som lar deg eksekvere kode uten å måtte ta stilling til infrastrukturen ("serveren") den kjører på. Dette kaller man typisk «Function-as-a-Service» (FaaS), og de fleste store skyleverandører har dette som en del av sitt tjenestetilbud.
AWS Lambda faller inn under paraplybegrepet «serverless» som omhandler arkitekturer og tjenester som abstraherer bort typisk infrastrukturarbeid, automatisk skalerer og som kun belaster deg for faktisk bruk - slik at man som utvikler kan løse forretningsproblemer raskt, effektivt og billig.
Ved å bruke AWS Lambda trenger man som utvikler i prinsippet kun å tenke på selve koden man ønsker å kjøre, mens AWS tar seg av hvor og hvordan.
Det er flere fordeler med AWS Lambda sammenlignet med typiske serverapplikasjoner, og de største man ofte trekker frem er: ingen serverforvaltning, «pay-as-you-go», som vil si at man kun betaler når koden vår faktisk kjører, og automatisk og i praksis uendelig skalering.
Hvis man for eksempel ønsker å kjøre noe kode hver gang et bilde lastes opp til AWS Simple Storage Service (S3), så trenger man kun å skrive koden man ønsker å kjøre, og deretter laste opp koden til en AWS Lambda-funksjon og knytte funksjonen opp mot AWS S3. Hvert bilde som lastes opp til AWS S3 vil da starte en egen, uavhengig gjennomkjøring av koden vår, og AWS vil automatisk håndtere skalering og vi betaler kun hvis funksjonen vår faktisk har blitt kjørt.
Om det i dette eksempelet er ett bilde som blir lastet opp om dagen eller én million har lite å si, AWS håndterer skaleringen av funksjonen vår og belaster oss kun når koden vår kjører.
#2. De fleste har nok skrevet vanlige server-applikasjonen og kjørt på heroku, GCP og lignende. Hvorfor skal man velge AWS Lambda istedenfor? 👋
I teorien er det mulig å migrere enhver "tradisjonell" serverapplikasjon til AWS Lambda, men om det er hensiktsmessig og kosteffektivt er avhengig av hva slags applikasjon det er snakk om, og hvordan trafikkmønsteret ser ut.
Man kan bruke AWS Lambda til veldig mye forskjellig, men det er i utgangspunktet designet for hendelses- og «stateless»-baserte applikasjoner hvor en gitt invokasjon av AWS Lambda-funksjonen er uavhengig av en annen, og hvor man på så måte kan dra stor nytte av horisontal skalering -- det vil si, skalering som baserer seg på øke antall samtidig kjørende instanser av funksjonen.
Eksempler på slike applikasjoner er «backend»-applikasjoner som tar i mot HTTP-forespørsler, applikasjoner som prosesserer data eller agerer på ulike hendelser eller «triggere».
Tjenester som Heroku faller under kategorien «Platform-as-a-Service» (PaaS) som ligger på et litt lavere abstraksjonsnivå enn AWS Lambda. I en slik tjeneste må man som utvikler ha et forhold til skalering, og man betaler faste kostnader for infrastrukturen selv om applikasjonen ikke nødvendigvis har noe trafikk.
Slik leverer Sanity 3 milliarder spørringer i måneden
Hvis man allerede bruker Heroku, GCP eller Azure og har større arbeidslaster kjørende der, så er det ikke nødvendigvis noe åpenbar verdi i å flytte en spesifikk applikasjon over til AWS Lambda. AWS Lambda gir vanligvis mest verdi hvis man allerede bruker AWS og integrerer AWS Lambda mot andre AWS-tjenester.
Det er et par begrensninger knyttet til AWS Lambda som man bør være klar over før man tar det i bruk. En invokasjon av en AWS Lambda-funksjon har en maksimal kjøretid på femten minutter, så hvis man har behov for noe utover dette er det andre tjenester man typisk vil se på.
«AWS Lambda er ikke magi, og bak kulissene kjøres koden vår på en fysisk server et sted»
AWS Lambda er ikke magi, og bak kulissene kjøres koden vår på en fysisk server et sted, og dette fører til at det er en ventetid på et par hundre millisekund fra en forespørsel har kommet inn til koden vår faktisk kjører. Hvis man har behov for ekstremt lav ventetid er AWS Lambda eller FaaS sannsynligvis ikke den mest optimale tilnærmingen.
Uavhengig av om AWS Lambda er noe man har tenkt å ta i bruk i nær fremtid eller ei så kan det være nyttig å ha kjennskap til hvordan det fungerer, hvilke problemer det løser og hvordan kostnadsbildet eventuelt endrer seg sammenlignet med mer tradisjonelle tilnærminger. Da har man et ekstra verktøy i verktøykassen som en dag kan vise seg å være veldig nyttig.
#3. Hva bruker dere AWS Lambda til på arbeidsplassen din? 💡
Som del av et plattformteam bruker jeg AWS Lambda veldig mye som bindeledd mellom forskjellige AWS-tjenester.
Hvis AWS ikke allerede har en tjeneste som tilbyr funksjonaliteten jeg trenger for å løse et gitt problem, så er det naturlig å implementere dette selv i en AWS Lambda-funksjon som er integrert mot andre AWS-tjenester.
Eksempler på bruk av AWS Lambda-funksjoner er rutinemessige arbeidslaster (for eksempel periodisk innsamling av metrikker), agering på filopplasting til AWS S3, videresending av AWS-hendelser til Slack, API-kall fra AWS API Gateway, dataprosseringsflyter og lignende.
I disse tilfellene er det billigere og mer naturlig å bruke AWS Lambda og en Serverless-arkitektur fremfor å spinne opp en virtuell server som kjører 24/7 og må vedlikeholdes.
#4. Hvordan jobber man med AWS Lambda? Trenger man å lære et spesielt språk? Rammeverk? 🥸
Man trenger ikke å lære seg noen spesielle språk da AWS Lambda har offisiell støtte for populære språk som Java, Go, PowerShell, Node.js, C#, Python og Ruby.
Man kan arbeide med AWS Lambda på ganske mange forskjellige måter. Serverless Framework er et av de mer populære tredjeparts-rammeverkene som gjør det veldig enkelt å opprette AWS Lambda-funksjoner og integrere dem mot andre AWS-tjenester som man ofte bruker disse funksjonene sammen med (eksempelvis AWS API Gateway).
AWS har på sin side et offisielt rammeverk kalt AWS Serverless Application Model (SAM) som også er relativt populært. Hvis man allerede bruker et IaC-verktøy som Terraform eller AWS Cloud Development Kit (CDK), så er det også mulig å bruke disse verktøyene fremfor dedikerte rammeverk for å begrense antall teknologier man må forholde seg til. Selv bruker jeg i hovedsak Terraform fremfor et eget rammeverk for å arbeide med AWS Lambda.
Slik driftes store deler av buss- og hurtigbåt-trafikken i Rogaland
Min arbeidsflyt går i stor grad ut på å utvikle og kjøre koden lokalt først for å verifisere essensiell funksjonalitet, og deretter bruke Terraform for å lage en ZIP-fil av koden og opprette selve Lambda-funksjonen i AWS. Hvis funksjonen min er avhengig av opprettelse av andre ressurser i skyen (for eksempel en AWS S3-bøtte), så pleier jeg typisk å provisjonere disse ut i et utviklermiljø ved hjelp av IaC.
Hvis man ikke har brukt AWS Lambda tidligere kan det være greit å starte med å skrive kode direkte i AWS sitt webgrensesnitt for å få en oversikt over hvordan ting henger sammen, og også gjøre «feedback-loopen» litt kortere.
Når man begynner å skjønne tegninga kan det være hensiktsmessig å ta i bruk CI/CD, IaC, og så videre for å sørge for høyere robusthet, kvalitet og reproduserbarhet av applikasjonen.
(Hvis man er interessert i å kikke litt på hva som finnes der ute av rammeverk relatert til AWS Lambda, så kan det være verdt å ta en tur innom https://github.com/anaibol/awesome-serverless#frameworks).
#5. Hva er mest tidkrevende i arbeid med AWS Lambda? ⏰
Ved å bruke AWS Lambda slipper man å tenke på ting som servervedlikehold og skalering, men det er andre utfordringer som dukker opp.
Økosystemet rundt AWS Lambda er noe fragmentert da det i dag finnes veldig mange forskjellige verktøy man kan bruke for å oppnå samme resultat, og utviklersamfunnet har ikke helt landet på et standardisert oppsett eller rammeverk.
- Timeføring er så utrolig kjedelig!
Applikasjons- og kodestruktur er et annet område som kan være litt vanskelig å navigere og hvor det finnes mange ulike meninger. Når er det naturlig å splitte koden i flere AWS Lambda-funksjoner fremfor å ha mye logikk i en stor AWS Lambda-funksjon (en "monolitt")? Det er fordeler og ulemper med forskjellige fremgangsmåter her.
Videre er monitorering et annet aspekt som kan være utfordrende, spesielt hvis man har veldig mange funksjoner og ønsker å effektivt feilsøke på tvers av disse. Også testing kan være mer utfordrende sammenlignet med en tradisjonell serverapplikasjon, spesielt hvis man integrerer mot mange andre AWS Lambda-funksjoner og AWS-tjenester.
#6. Er det noen spesielle bruksområder AWS Lambda er skikkelig gode på? 🥇
AWS Lambda er generelt veldig godt egnet til arbeidslaster med lavt eller variabelt trafikkmønster som kan parallelliseres. Da drar man nytte av kostnadsmodellen til AWS Lambda og den uendelige horisontale skaleringen den tilbyr. Eksempler på slike arbeidslaster er HTTP-forespørsler, automatiske arbeidsflyter som kjøres på en tidsplan, CPU-intensiv dataprosessering, og så videre.
Ved å bruke AWS Lambda kan man fokusere mer på kode og forretningsproblemer da typiske utfordringer rundt servervedlikehold og skalering blir tatt hånd om av AWS.
Til slutt er det verdt å nevne at AWS Lambda og serverless-løsninger kan være veldig nyttige om man ønsker å pilotere en idé og se hvordan markedet responderer. Kostnad og «time-to-market» er generelt lavere for denne type arkitekturer sammenlignet med en pilot basert på mer tradisjonelle serverapplikasjoner.
#7. Har AWS Lambda noen konkurrenter? 💪
De fleste andre store skyleverandører har tilsvarende løsninger.
Google Cloud Platform (GCP) har Google Cloud Functions, og Azure har tilsvarende, men AWS Lambda blir ofte ansett som den mest modne av disse tre.
Hva er greia med Azure?
For arbeidslaster som for eksempel overstiger femten minutter kan en «container» i AWS Fargate være et godt alternativ til AWS Lambda.
#8. Får man noe gevinst av å ha andre produkter på AWS? ✈️
Man får definitivt gevinst av å ha andre produkter på AWS.
Ved å bruke AWS Lambda sammen med andre AWS-tjenester kan man bygge opp en fullstendig serverless-arkitektur som skalerer automatisk, hvor man kun betaler for faktisk bruk og hvor man ikke trenger å ha et forhold til tradisjonell infrastruktur.
Man kan bygge opp et fullstendig brukervendt API ved å bruke AWS API Gateway, AWS Lambda og AWS DynamoDB, konstruere en kompleks dataprosesseringsflyt ved å ta i bruk AWS Step Functions, AWS Lambda og AWS S3, kjøre automatiserte arbeidslaster som samler inn metrikker eller sjekker «compliance» på en daglig basis, og så videre.