Virksomhederne skifter til en serverløs arkitektur. Det resulterer i en kortere tid til markedet, reducerer driftsomkostningerne og udviklere kan fokusere på at forbedre applikationer I stedet for at forvalte infrastrukturer.
Hvis du er ny på dette koncept, spørger du måske: Hvad er en serverløs applikation? Dybest set er det software, der kører i et miljø, hvor du ikke behøver at administrere nogen servere. Værten, der leverer det, er fuldt ansvarlig for at styre al infrastruktur og operationelle opgaver.
En af løsningerne, der adresserer dette, er AWS Lambda. Ifølge En rapport fra Datadog, på mindre end 5 år AWS Lambda bruges af halvdelen af AWS-brugerne og er mest almindelig i de største miljøer.
Som praktikant hos Imaginær sky, Jeg havde et projekt i hænderne: en applikation kaldet Dwipper. Det bestod af et socialt netværk til at dele brusetanker (svarende til Twitter). Jeg havde brug for at have en backend, der understøtter alle de væsentlige operationer som godkendelse og behandling af data. AWS Lambda kunne tilbyde alt, hvad jeg havde brug for til backend med integrationen af andre tjenester, AWS tilbyder, såsom Cognito, API Gateway, DynamoDB, CloudWatch, CodeCommit og CodePipeline. Jeg behøvede ikke engang at bekymre mig om administration af servere. Men inden jeg går direkte til den udviklede applikation, vil jeg have dig til at forstå, hvad AWS Lambda er.
AWS Lambda, leveret af AWS (Amazon Web Services), er en serverløs databehandlingstjeneste der giver dig mulighed for at køre kode uden at skulle bekymre dig om infrastrukturen eller administrere servere. Kode udført på AWS Lambda kaldes Lambda-funktion, og når den først er oprettet, er den klar til at køre, når den udløses.
Denne funktion kan knyttes til en bestemt AWS-ressource. For eksempel AWS SNS (Simple Notification Service), det er en meddelelsestjeneste. Så snart denne ressource ændres, udfører Lambda din funktion og administrerer det, der er nødvendigt.
Den første ting at gøre er at Opret en AWS-konto. Hvis du ikke har en, skal du konfigurere den. Amazon IAM (Identity and Access Management) giver brugeradministration og tilladelser i AWS. Hvis du arbejder som et team, skal du muligvis oprette en IAM-bruger for at give de nødvendige tilladelser til din AWS-konsol, eller hvis din applikation skal foretage API-opkald til AWS.
Det næste skridt er at opsæt din serverløse backend, vælg hvilke tjenester du har brug for, konfigurer dem og til sidst til opret dit Git-lager så du kan begynde at arbejde på din ansøgning.
Nu kan du starte med at skrive kode på ethvert sprog understøttet af AWS Lambda og uploade det. Du kan også skrive din kode i kodeditoren, som Lambda leverer. Derefter konfigurerer du din kode til at blive udløst fra andre AWS-tjenester eller aktivitet i appen. Lambda modtager din anmodning og kører kun din kode, når den udløses.
AWS Lambda giver dig en masse fordele, som du sandsynligvis bør vide, før du vælger en anden serverløs computertjeneste. Hvis du allerede har spurgt dig selv Hvorfor bruge AWS Lambda, tag et kig på de vigtigste fordele nedenfor.
Indtil videre, AWS Lambda understøtter ikke alle programmeringssprog. Men det understøtter Java, Go, PowerShell, Node.js, C #, Python og Ruby-kode. For hver enkelt af dem leverer AWS en SDK, der gør det lettere for dig at skrive dine Lambda-funktioner og integrere dem med andre AWS-tjenester. Det giver også en Runtime API, som giver dig mulighed for at bruge eventuelle yderligere programmeringssprog til at oprette dine funktioner.
I AWS, du betaler kun for den beregningstid, du bruger. Du behøver ikke betale for tjenesten for at hoste din kode. I stedet fakturerer AWS Lambda dig baseret på, hvornår denne kode udføres. Du opkræves baseret på antallet af anmodninger og varigheden, så dette udelukker de ubrugte minutter af servertid.
Når dine funktioner kører på AWS-infrastruktur, tager den sig af servere for dig. På denne måde har udviklere mere tid til at bruge på at forbedre produktet i stedet for at udføre operationelle opgaver såsom styring af netværkslaget eller tage sig af skalerbarhed.
Lad os forestille os, at din applikation fra det ene øjeblik til det andet får masser af nye brugere. Dette kan være et problem, hvis serveren ikke er parat til at håndtere et stort antal anmodninger. Med AWS Lambda behøver du ikke bekymre dig om det, da applikationen skaleres præcist med størrelsen af arbejdsbyrden. Det skalerer automatisk dine funktioner i henhold til deres behov, så forskellige dele af din applikation kan skaleres forskelligt i henhold til aktuelle brugsniveauer.
AWS Lambda integreres med AWS-tjenester som DynamoDB, API Gateway, Cognito og mange flere. Hver af disse tjenester sender data til din funktion i JSON som en begivenhed, som Lambda-runtimes først konverterer til et objekt og sender det derefter til din funktion. Alt dette giver dig mulighed for at opbygge en applikation, der er fuldt funktionel inden for dine Lambda-funktioner.
Som enhver anden computerplatform er AWS Lambda bedre egnet til nogle scenarier på grund af dens egenskaber. Først vil vi dække i hvilke scenarier det ville være en passende computertjeneste, og kontrollere, hvad AWS Lambda plejede at være, som du kan se nedenfor:
Forestil dig, at du har et program til at uploade billeder og ændre størrelsen på dem til en række forskellige størrelser. Din applikation gemmer disse billeder i en Amazon S3-spand, så sandsynligvis er der en Lambda-funktion, der udfører dette job med at ændre størrelse på billeder. Amazon S3 er en af de understøttede AWS-begivenhedskilder, der kan offentliggøre objektoprettede begivenheder og påkalde din Lambda-funktion. Alt dette er helt automatisk, og der er ingen servere at administrere. Din Lambda-funktionskode kan læse billedobjektet fra S3-spand, oprette størrelsen på versionen og til sidst gemme det i en anden S3-spand.
Forestil dig, at du bygger et program, der har data, som du skal gemme. Du kan bruge DynamoDB til det, en fuldt administreret databasetjeneste, der håndterer skrivning af en opdatering og sletning af elementer i en tabel.
Forestil dig, at du bygger et websted, og du vil være vært for backend-login på Lambda. Lambda er fremragende til dette, da webfrontend kan sende anmodninger til Lambda-funktioner over HTTP-slutpunkter ved hjælp af Amazon API Gateway.
Ligesom websteder kan Amazon API Gateway være nyttigt til mobile applikationer, men det slutter ikke her. Du kan for eksempel oprette en Lambda-funktion til at behandle klik i din applikation.
Ud over disse scenarier, hvor denne service passer bedre, er det godt at huske på de begrænsninger, som Lambda bærer, og indse, om det faktisk er den bedste service at integrere i dit produkt.
Serverløse funktioner betyder, at du har at gøre med en kold starttid. Når en funktion udløses, kan der være en lille mængde tid, der venter mellem begyndelsen af opkaldet, og når det kører. Hvis denne funktion ikke er blevet brugt i de sidste 15 minutter, kan denne tid være meget høj, 5 sekunder eller mere.
Dette kan være et potentielt problem at overveje, hvis dine arbejdsbelastninger er tidsfølsomme. Nogle løsninger forsøger at undgå det, for eksempel holde dine funktioner små og fokuserede, som kolde starttider øges lineært med hukommelse og kodestørrelse.
Lambda-funktionerne har nogle grænser såsom køretid, hukommelse, størrelse og samtidighed. Den maksimale tid, en funktion kan køre, er 15 minutter, hvilket gør Lambda uegnet til langvarige arbejdsbelastninger. Hvis din funktion typisk tager mere end 15 minutter, er AWS Lambda muligvis ikke en god løsning. Mængden af RAM, der er tilgængelig for Lambda-funktionerne, spænder fra 128 MB til 3,008 MB, i trin på 64 MB. Der er også en grænse på 75 GB for alle AWS Lambda-funktioner, der er blevet implementeret. For at undgå denne grænse skal du sørge for, at du ikke beholder gamle versioner af dine Lambda-funktioner. Som standard er den samtidige udførelse for alle AWS Lambda-funktioner inden for en enkelt AWS-konto er begrænset til 1000. Enhver Lambda-udførelse, der udløses over denne grænse, vil blive tvunget til at vente, indtil andre funktioner er færdige med at køre. For at undgå dette kan du anmode om en grænsestigning ved at kontakte AWS support.
Ved første øjekast kan betalingen kun for det, du bruger, give betydelige omkostningsbesparelser, men det er måske ikke sådan hver gang. Flere faktorer bestemmer omkostningerne ved dine Lambda-funktioner, og det er ikke let at finde ud af disse omkostninger.
Hvis belastningen for din applikation øges, øges dette proportionalt og kan ende med at blive en høj pris. Du skal huske på, at enhver anden tjeneste, du beslutter at bruge sammen med dine Lambda-funktioner, som API Gateway, CloudWatch eller enhver anden, vil øge disse omkostninger. Så du bør overveje hvor meget du forventer, at din applikation skal skaleres.
AWS Lambda er ikke den eneste serverløse service, du kan vælge til dit projekt. På dette emne kan du se andre alternativer til Lambda, der ligner det meget. Med et par forskelle kan du overveje, når du vælger, hvilken serverløs tjeneste der skal bruges.
AWS Lambda og Azure Functions understøtter begge Node.js, Python og C#, men Azure Functions understøtter også F# og PHP. De understøtter også automatisk skalering.
AWS Lambda har en ligetil programmeringsmodel, mens Azure Functions har en mere sofistikeret, baseret på udløsere og bindinger. Bindingssystemet giver ekstra fleksibilitet, men det bringer også en vis kompleksitet. Begge tjenester kan køre flere udførelser af den samme funktion samtidigt.
Hvis du vil tilføje HTTP-integration, har du med AWS Lambda en ekstra omkostning, som vi allerede har set, betaler du for yderligere tjenester. På den anden side leveres Azure Functions med HTTP-slutpunktsintegration, og der er ingen ekstra omkostninger.
AWS Lambda og Google Cloud Functions understøtter begge Node.js, Python og Go. Lambda giver mulighed for ubegrænsede funktioner, mens Google Cloud Functions kun tillader 1000 funktioner pr. projekt. De understøtter også automatisk skalering.
Med hensyn til den maksimale udførelsestid for en funktion forbliver AWS Lambda foran med seks minutter mere end Google Cloud Functions.
Med hensyn til betaling, ligesom AWS Lambda, med Cloud Functions du betaler kun for din funktions udførelsestid. Du faktureres ikke, når din funktion er inaktiv.
AWS Lambda og Kubernetes er to forskellige virkeligheder. Mens Lambda handler om at blive serverløs, handler Kubernetes om containere.
På AWS Lambda administrerer du ikke infrastrukturen, og du kan ikke installere ekstra software. På Kubernetes skal du administrere infrastrukturen, og du kan installere yderligere software.
Det er blot nogle af de væsentlige og vigtigste forskelle mellem dem begge. Afslutningsvis, hvis du vil have Fuldstændig kontrol med miljøet, gå efter en containertjeneste som Kubernetes. Hvis du vil have noget mere håndterbar og fokusere mere på at forbedre selve produktet, du bør vælge en serverløs tjeneste som AWS Lambda.
AWS Cognito er en tjeneste til styring af godkendelse. Du kan tilføje brugertilmelding og login hurtigt og nemt. Det understøtter stadig login med sociale identitetsudbydere, såsom Amazon, Google og Facebook. Det giver endda en brugerpool-funktion, der hjælper dig med at administrere brugerkonti.
Denne Amazon-tjeneste håndterer alle de opgaver, der er involveret i at acceptere og behandle API-opkald. Det giver udviklere mulighed for at definere HTTP-slutpunkterne og forbinde dem med den tilsvarende backend. API Gateway kan også validere, om brugeren er godkendt ved at tilføje en autorisator til en slutpunktskortlægning, der er forbundet til en Cognito-brugerpulje, hvilket betyder, at kun brugere i brugerpuljen kan få adgang til slutpunktet.
AWS DynamoDB er en fuldt administreret database, der kan skaleres automatisk og giver mulighed for at oprette databasetabeller, der kan gemme og hente enhver mængde data.
Cloudwatch er en tjeneste til at overvåge alle dine AWS-ressourcer, applikationer og tjenester, der kører på AWS. Det indsamler data i form af logfiler, målinger og begivenheder, som du kan kontrollere for hurtigt at løse problemer og holde din applikation kørende uden problemer.
CodeCommit er en kildekontroltjeneste, der hjælper teams med at samarbejde om softwareudvikling, så de kan importere og hoste private Git-kodelagre sikkert.
AWS CodePipeline er en kontinuerlig leveringstjeneste, der automatiserer bygge-, test- og implementeringsfaserne i din udgivelsesproces, hver gang der er en kodeændring baseret på, hvordan du definerede arbejdsgangen.
Som nævnt tidligere integrerede vi nogle andre tjenester med AWS Lambda for at opbygge vores backend. Vores applikation Dwipper består af et socialt netværk til at dele tanker, kaldet Dwipps, hvor brugerne skal registrere sig for at begynde at dele, hvad de tænker på. De opbyggede funktionaliteter er:
Vi integrerede DynamoDB som vores database, hvor vi gemmer alle de Dwipps oprettet af brugere fra vores applikation, samt redigerer og sletter dem.
Til godkendelse var AWS Cognito løsningen. Det gav en nem styring af brugergodkendelse, der var nødvendig for klienter til at registrere deres e-mail, og genererede nemt tokens for hver bruger, hver gang de logger ind for at få adgang til specifikt indhold.
For at oprette REST API og generere de nødvendige slutpunkter til hele flowet i vores applikation integrerede vi Amazon API Gateway. Vi var nødt til at konfigurere AWS Lambda til at køre vores kode som svar på HTTP-anmodninger ved hjælp af API Gateway, som kan validere det token, der genereres under login, og injicere brugerdataene i en lambda-miljøudførelse.
Fra og med godkendelsen brugte vi Cognito-brugerpuljer i vores funktion til at oprette en ny brugerkonto. Med hensyn til registreringen beder den om e-mail og adgangskode, og funktionen får disse værdier, sender dem til Cognito og returnerer svaret, om brugeren er blevet registreret med succes eller ej. Slutpunktet er konfigureret i en separat fil med de andre slutpunkter, hvor vi sætter dens funktion. For login-funktionen får vi adgang til Cognito igen og sender brugerdataene. Hvis brugeren eksisterer, returnerer Cognito et token, der er nødvendigt for brugerens adgang til programmets indhold.
En afgørende funktion er at vise alle Dwipps fra alle brugere. Til denne skal vi få adgang til DynamoDB for at få den specifikke tabel og returnere alt dens indhold. Funktionen til at oprette en Dwipp er stort set den samme, men i stedet for at få alle elementer fra tabellen, vil vi indsætte et nyt element der. Det unikke id for hver Dwipp oprettes med uuidv4, en JavaScript-pakke, der hjælper med at oprette id'er. ID'et og indholdet af den nye Dwipp sendes til den pågældende tabel med hvert felt i sin kolonne. Brugeren skal have et token, der blev genereret under login, API Gateway validerer dette token og injicerer brugerdataene i miljøet for lambda-udførelsen. På denne måde kan vi identificere brugeren, der forsøger at oprette en ny Dwipp.
For at stemme på en Dwipp bruger vi den samme tabel som før. Men for de foretrukne Dwipps var vi nødt til at oprette en ny tabel. For den første tabel har vi en funktion, der kontrollerer den aktuelle brugers e-mail-adresse, og hvis den allerede har stemt op på Dwipp, der er registreret i tabellen. Hvis ja, falder antallet af opstemmer med en, og e-mail-adressen fjernes fra listen. Hvis ikke, øges det med en, og e-mail-adressen tilføjes.
Hvad angår funktionen til at markere en Dwipp som favorit, kontrollerer vi, om den Dwipp allerede er i favorit-Dwipps-tabellen. Hvis det er der, bekræfter vi, om brugeren allerede har favoriseret det før. Hvis ikke, tilføjes en ny favorit Dwipp til den pågældende tabel. Oplysningerne om brugere, der favoriserede en bestemt Dwipp, opbevares også i tabellen.
Med alle de tilgængelige og nemme at integrere tjenester byggede vi en fungerende applikation med godkendelse og nogle funktionaliteter på mindre end en måned.
I starten var vores idé at bruge både AWS Lambda og Google Cloud Functions. Vi har besluttet os for AWS, da det giver værktøjer til brugeroprettelse og godkendelse, mens Google Cloud Functions ikke gør det. Alt lever op til forventningerne, da alle de krævede funktionaliteter var mulige at implementere med kun AWS.
Det kan virke som en stor ting at forstå alle disse tjenester ved første øjekast, men AWS leverer komplet dokumentation afklaring af hver af dem og nyttige eksempler. Hvis du tager lidt tid på at forstå det, begynde at prøve det og teste det, vil du hurtigt være i stand til at oprette en fuld fungerende backend til din applikation: fri for server- og infrastrukturstyring på kort tid og med reducerede omkostninger.
Fandt du denne artikel nyttig? Du kan måske også lide disse!
Jeg stræber efter at være en mobilapplikationsudvikler. En af mine interesser vedrører kunstig intelligens, mens min sande lidenskab er at rejse rundt i verden.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
