Företagen byter till en serverlös arkitektur. Det resulterar i en kortare tid till marknaden, minskar driftskostnaderna och utvecklare kan fokusera på att förbättra applikationer Istället för att förvalta infrastruktur.
Om du är ny på detta koncept kanske du frågar: Vad är en serverlös applikation? I grund och botten är det programvara som körs i en miljö där du inte behöver hantera några servrar. Värden som tillhandahåller det är fullt ansvarig för att hantera all infrastruktur och operativa uppgifter.
En av lösningarna som tar itu med detta är AWS Lambda. Enligt En rapport från Datadog, på mindre än 5 år AWS Lambda används av hälften av AWS-användarna och är vanligast i de största miljöerna.
Som trainee på Imaginärt moln, Jag hade ett projekt i händerna: en applikation som heter Dwipper. Det bestod av ett socialt nätverk för att dela duschtankar (liknande Twitter). Jag behövde ha en backend som stöder alla viktiga operationer som autentisering och bearbetning av data. AWS Lambda kunde erbjuda allt jag behövde för backend med integrationen av andra tjänster AWS erbjuder, till exempel Cognito, API Gateway, DynamoDB, CloudWatch, CodeCommit och CodePipeline. Jag behövde inte ens oroa mig för att hantera servrar. Men innan jag går direkt till den utvecklade applikationen vill jag att du ska förstå vad AWS Lambda är.
AWS Lambda, som tillhandahålls av AWS (Amazon Web Services), är en serverlös datortjänst som låter dig köra kod utan att behöva oroa dig för infrastrukturen eller hantera servrar. Kod som körs på AWS Lambda kallas Lambda-funktion och när den väl har skapats är den redo att köras när den utlöses.
Denna funktion kan associeras med en specifik AWS-resurs. Till exempel AWS SNS (Simple Notification Service), det är en meddelandetjänst. Så snart den här resursen ändras, kör Lambda din funktion och hanterar vad som behövs.
Det första du behöver göra är att skapa ett AWS-konto. Om du inte har en måste du konfigurera den. Amazon IAM (Identity and Access Management) tillhandahåller användarhantering och behörigheter i AWS. Om du arbetar som ett team kan du behöva skapa en IAM-användare för att ge nödvändiga behörigheter till din AWS-konsol eller om din applikation behöver ringa API-samtal till AWS.
Nästa steg är att konfigurera din serverlösa backend, välj vilka tjänster du behöver, konfigurera dem och slutligen till skapa ditt Git-arkiv så att du kan börja arbeta med din ansökan.
Nu kan du börja med att skriva kod på vilket språk som helst som stöds av AWS Lambda och ladda upp det. Du kan också skriva din kod i kodredigeraren som Lambda tillhandahåller. Sedan ställer du in din kod så att den utlöses från andra AWS-tjänster eller aktivitet i appen. Lambda tar emot din begäran och kör din kod endast när den utlöses.
AWS Lambda ger dig många fördelar som du förmodligen borde veta innan du väljer någon annan serverlös datortjänst. Om du redan har frågat dig själv Varför använda AWS Lambda, ta en titt på de viktigaste fördelarna nedan.
För tillfället, AWS Lambda stöder inte alla programmeringsspråk. Men det stöder Java, Go, PowerShell, Node.js, C #, Python och Ruby-kod. För var och en av dem tillhandahåller AWS en SDK som gör det lättare för dig att skriva dina Lambda-funktioner och integrera dem med andra AWS-tjänster. Det tillhandahåller också ett Runtime API, som låter dig använda ytterligare programmeringsspråk för att skapa dina funktioner.
I AWS, du betalar bara för den beräkningstid du förbrukar. Du behöver inte betala för tjänsten för att vara värd för din kod. Istället fakturerar AWS Lambda dig baserat på när den koden körs. Du debiteras baserat på antalet förfrågningar och varaktighet, så detta utesluter de oanvända minuterna av servertid.
När dina funktioner körs på AWS-infrastruktur tar den hand om servrar åt dig. På så sätt har utvecklare mer tid att spendera på att förbättra produkten istället för att utföra operativa uppgifter som att hantera nätverkslagret eller ta hand om skalbarhet.
Låt oss föreställa oss att från ett ögonblick till ett annat får din applikation massor av nya användare. Detta kan vara ett problem om servern inte är beredd att hantera ett stort antal förfrågningar. Med AWS Lambda behöver du inte oroa dig för det, eftersom applikationen skalas exakt med storleken på arbetsbelastningen. Det skalar automatiskt dina funktioner efter deras behov, så olika delar av din applikation kan skalas olika beroende på nuvarande användningsnivåer.
AWS Lambda integreras med AWS-tjänster som DynamoDB, API Gateway, Cognito och många fler. Var och en av dessa tjänster skickar data till din funktion i JSON som en händelse som Lambda-körtider konverterar först till ett objekt och skickar det efter till din funktion. Allt detta gör att du kan bygga en applikation som är fullt fungerande inom dina Lambda-funktioner.
Liksom alla andra datorplattformar är AWS Lambda bättre lämpad för vissa scenarier på grund av dess egenskaper. Först kommer vi att täcka i vilka scenarier det skulle vara en lämplig datortjänst och kontrollera vad AWS Lambda brukade vara, som du kan se nedan:
Föreställ dig att du har en applikation för att ladda upp bilder och ändra storlek på dem till en mängd olika storlekar. Din applikation lagrar dessa bilder i en Amazon S3-hink, så förmodligen finns det en Lambda-funktion som gör det här jobbet med att ändra storlek på bilder. Amazon S3 är en av de AWS-händelsekällor som stöds som kan publicera objektskapade händelser och åberopa din Lambda-funktion. Allt detta är helt automatiskt, och det finns inga servrar att hantera. Din Lambda-funktionskod kan läsa bildobjektet från S3-hinken, skapa storleksversionen och slutligen spara den i en annan S3-hink.
Tänk dig att du bygger ett program som har data som du behöver lagra. Du kan använda DynamoDB för det, en fullständigt hanterad databastjänst, hantera skriva en uppdatering och ta bort objekt i en tabell.
Föreställ dig att du bygger en webbplats och du vill vara värd för backend-inloggningen på Lambda. Lambda är utmärkt för detta, eftersom webbgränssnittet kan skicka förfrågningar till Lambda-funktioner över HTTP-slutpunkter med Amazon API Gateway.
Liksom webbplatser kan Amazon API Gateway vara användbart för mobilapplikationer, men det slutar inte här. Du kan till exempel skapa en Lambda-funktion för att bearbeta klick i ditt program.
Utöver dessa scenarier där den här tjänsten passar bättre är det bra att komma ihåg de begränsningar som Lambda bär och inse om det faktiskt är den bästa tjänsten att integrera i din produkt.
Serverlösa funktioner innebär att du kommer att ha att göra med en kall starttid. När en funktion utlöses kan det finnas en liten tid att vänta mellan början av samtalet och när det körs. Om den här funktionen inte har använts under de senaste 15 minuterna kan den här tiden vara mycket hög, 5 sekunder eller mer.
Detta kan vara ett potentiellt problem att överväga om dina arbetsbelastningar är tidskänsliga. Vissa lösningar försöker undvika det, till exempel hålla dina funktioner små och fokuserade, som kallstarttiderna ökar linjärt med minne och kodstorlek.
Lambda-funktionerna har vissa gränser som körtid, minne, storlek och samtidighet. Den maximala tiden en funktion kan köras är 15 minuter, vilket gör Lambda olämplig för långvariga arbetsbelastningar. Om din funktion vanligtvis tar mer än 15 minuter kanske AWS Lambda inte är en bra lösning. Mängden RAM-minne som är tillgängligt för Lambda-funktionerna sträcker sig från 128 MB till 3 008 MB, i steg om 64 MB. Det finns en gräns på 75 GB också för alla AWS Lambda-funktioner som har distribuerats. För att undvika denna gräns, se till att du inte behåller gamla versioner av dina Lambda-funktioner. Som standard är den samtidiga exekveringen för alla AWS Lambda-funktioner inom ett enda AWS-konto är begränsade till 1000. Alla Lambda-körningar som utlöses över denna gräns kommer att tvingas vänta tills andra funktioner är färdiga. För att undvika detta kan du begära en gränsökning genom att kontakta AWS support.
Vid första anblicken kan lönen bara för det du använder ge betydande kostnadsbesparingar, men det kanske inte är så varje gång. Flera faktorer avgör kostnaden för dina Lambda-funktioner och det är inte lätt att räkna ut denna kostnad.
Om belastningen för din applikation ökar kommer detta att öka proportionellt och kan bli en hög kostnad. Du måste ha i åtanke att alla andra tjänster du väljer att använda tillsammans med dina Lambda-funktioner, som API Gateway, CloudWatch eller någon annan, kommer att lägga till den kostnaden. Så du bör överväga hur mycket du förväntar dig att din applikation ska skalas.
AWS Lambda är inte den enda serverlösa tjänsten som du kan välja för ditt projekt. På det här ämnet kan du se andra alternativ till Lambda, som mycket liknar det. Med ett par skillnader kanske du vill överväga när du väljer vilken serverlös tjänst som ska användas.
AWS Lambda och Azure Functions stöder båda Node.js, Python och C# men Azure Functions stöder också F# och PHP. De stöder också automatisk skalning.
AWS Lambda har en enkel programmeringsmodell, medan Azure Functions har en mer sofistikerad, baserad på triggers och bindningar. Bindningssystemet ger extra flexibilitet, men det ger också viss komplexitet. Båda tjänsterna kan köra flera exekveringar av samma funktion samtidigt.
Om du vill lägga till HTTP-integration, med AWS Lambda kommer du att ha en extra kostnad, som vi redan såg betalar du för ytterligare tjänster. Å andra sidan kommer Azure Functions med HTTP-slutpunktintegration och det finns ingen extra kostnad.
AWS Lambda och Google Cloud Functions stöder båda Node.js, Python och Go. Lambda tillåter obegränsade funktioner, medan Google Cloud Functions tillåter bara 1000 funktioner per projekt. De stöder också automatisk skalning.
När det gäller den maximala körtiden för en funktion ligger AWS Lambda före med sex minuter mer än Google Cloud Functions.
När det gäller betalning, precis som AWS Lambda, med Cloud Functions du betalar endast för din funktions exekveringstid. Du faktureras inte när funktionen är inaktiv.
AWS Lambda och Kubernetes är två olika verkligheter. Medan Lambda handlar om att bli serverlös, handlar Kubernetes om containrar.
På AWS Lambda hanterar du inte infrastrukturen och du kan inte installera någon extra programvara. På Kubernetes måste du hantera infrastrukturen och du kan installera ytterligare programvara.
Det är bara några av de betydande och viktigaste skillnaderna mellan dem båda. Sammanfattningsvis, om du vill ha Fullständig kontroll över miljön, gå till en containertjänst som Kubernetes. Om du vill ha något mer hanterbar och fokusera mer på att förbättra själva produkten, du bör välja en serverlös tjänst som AWS Lambda.
AWS Cognito är en tjänst för att hantera autentisering. Du kan lägga till användarregistrering och inloggning snabbt och enkelt. Det stöder fortfarande inloggning med sociala identitetsleverantörer, som Amazon, Google och Facebook. Det ger till och med en användarpoolfunktion som hjälper dig att hantera användarkonton.
Denna Amazon-tjänst hanterar alla uppgifter som är involverade i att acceptera och bearbeta API-samtal. Det gör det möjligt för utvecklare att definiera HTTP-slutpunkterna och ansluta dem till motsvarande backend. API Gateway kan också validera om användaren är autentiserad genom att lägga till en behörighetsmappning i en slutpunktsmappning som är ansluten till en Cognito-användarpool, vilket innebär att endast användare i användarpoolen kan komma åt slutpunkten.
AWS DynamoDB är en helt hanterad databas som kan skalas automatiskt och gör det möjligt att skapa databastabeller som kan lagra och hämta vilken mängd data som helst.
Cloudwatch är en tjänst för att övervaka alla dina AWS-resurser, applikationer och tjänster som körs på AWS. Den samlar in data i form av loggar, mätvärden och händelser som du kan kontrollera för att snabbt lösa problem och hålla din applikation igång utan problem.
CodeCommit är en källkontrolltjänst som hjälper team att samarbeta om mjukvaruutveckling, så att de kan importera och vara värd för privata Git-kodförvar på ett säkert sätt.
AWS CodePipeline är en kontinuerlig leveranstjänst som automatiserar bygg-, test- och distributionsfaserna i din release-process varje gång det sker en kodändring baserat på hur du definierade arbetsflödet.
Som nämnts tidigare integrerade vi några andra tjänster med AWS Lambda för att bygga vår backend. Vår applikation Dwipper består av ett socialt nätverk för att dela tankar, kallad Dwipps, där användare måste registrera sig för att börja dela vad de tänker på. Funktionerna som byggs är:
Vi integrerade DynamoDB som vår databas, där vi lagrar alla Dwipps som skapats av användare från vår applikation, samt redigerar och tar bort dem.
För autentisering var AWS Cognito lösningen. Det gav en enkel hantering av användarautentisering som behövdes för kunder att registrera sin e-post, vilket genererade tokens enkelt för varje användare varje gång de loggar in för att få tillgång till specifikt innehåll.
För att skapa REST API och generera nödvändiga slutpunkter för hela flödet av vår applikation integrerade vi Amazon API Gateway. Vi var tvungna att konfigurera AWS Lambda för att köra vår kod som svar på HTTP-förfrågningar med API Gateway, som kan validera token som genererades under inloggning och injicera användardata i en lambdamiljökörning.
Från och med autentiseringen använde vi Cognito User Pools i vår funktion för att skapa ett nytt användarkonto. När det gäller registreringen ber den om e-post och lösenord och funktionen får dessa värden, skickar dem till Cognito och returnerar svaret oavsett om användaren har registrerats framgångsrikt eller inte. Slutpunkten är konfigurerad i en separat fil med de andra slutpunkterna, där vi sätter dess funktion. För inloggningsfunktionen öppnar vi Cognito igen och skickar användardata. Om användaren finns returnerar Cognito en token som behövs för användarens åtkomst till programmets innehåll.
En avgörande funktion är att visa alla Dwipps från alla användare. För den här måste vi komma åt DynamoDB, för att få den specifika tabellen och returnera allt dess innehåll. Funktionen för att skapa en Dwipp är i princip densamma, men istället för att få alla objekt från tabellen vill vi infoga ett nytt objekt där. Det unika ID:t för varje Dwipp skapas med uuidv4, ett JavaScript-paket som hjälper till att skapa ID:n. ID och innehåll för den nya Dwipp skickas till den tabellen med varje fält i sin kolumn. Användaren måste ha en token som genererades under inloggningen, API Gateway validerar denna token och injicerar användardata i miljön för lambda-körningen. På så sätt kan vi identifiera användaren som försöker skapa en ny Dwipp.
För att rösta upp en Dwipp använder vi samma tabell som tidigare. Men för favoriterna Dwipps var vi tvungna att skapa ett nytt bord. För den första tabellen har vi en funktion som kontrollerar den aktuella användarens e-postadress och om den redan har röstat upp Dwipp som är registrerad i tabellen. Om ja, antalet upvotes minskar med en och e-postadressen tas bort från listan. Om inte, ökar den med en och e-postadressen läggs till.
När det gäller funktionen att markera en Dwipp som favorit kontrollerar vi om den Dwipp redan finns i favoritbordet Dwipps. Om det finns där bekräftar vi om den användaren redan har favoriserat det tidigare. Om inte, en ny favorit Dwipp läggs till i tabellen. Informationen om användare som favoriserade en specifik Dwipp förvaras också i tabellen.
Med alla tillgängliga och lättintegrerade tjänster byggde vi en fungerande applikation med autentisering och vissa funktioner på mindre än en månad.
I början var vår idé att använda både AWS Lambda och Google Cloud Functions. Vi har bestämt oss för AWS eftersom det tillhandahåller verktyg för användarskapande och autentisering, medan Google Cloud Functions inte gör det. Allt lever upp till förväntningarna eftersom alla nödvändiga funktioner var möjliga att implementera med endast AWS.
Det kan verka som en stor sak att förstå alla dessa tjänster vid första anblicken, men AWS tillhandahåller fullständig dokumentation klargöra var och en av dem och användbara exempel. Om du tar lite tid att förstå det, börja prova det och testa det, kommer du snabbt att kunna skapa en fullständig fungerande backend för din applikation: fri från server- och infrastrukturhantering, på kort tid och till en reducerad kostnad.
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Jag strävar efter att bli en mobilapplikationsutvecklare. Ett av mina intressen handlar om artificiell intelligens, medan min sanna passion är att resa runt i världen.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
