Även om serverlösa teknologier snabbt har blivit populära de senaste åren, finns det fortfarande många missuppfattningar och rädslor förknippade med dem. Leverantörsberoende, verktyg, kostnadshantering, kallstart, övervakning och utvecklingslivscykel är alla heta ämnen när det kommer till serverlös teknologi. I den här artikeln kommer vi att utforska några av de ämnen som nämns, samt dela tips och länkar till användbara informationskällor för att hjälpa nybörjare att skapa kraftfulla, flexibla och kostnadseffektiva serverlösa applikationer.
Missuppfattningar om serverlösa teknologier
Många tror att serverlös och serverlös bearbetning (, FaaS) är nästan samma sak. Det gör att skillnaden inte är för stor och det är värt att introducera en nyhet. Även om AWS Lambda var en av stjärnorna i den serverlösa storhetstid och en av de mest populära elementen i den serverlösa arkitekturen, är dock denna arkitektur mycket mer än FaaS.
Grundprincipen bakom serverlösa teknologier är att du inte behöver oroa dig för att hantera och skala din infrastruktur, du betalar bara för det du använder. Många tjänster passar dessa kriterier - AWS DynamoDB, S3, SNS eller SQS, Graphcool, Auth0, Now, Netlify, Firebase och många andra. Generellt sett innebär serverlös att använda den fulla kraften i molnberäkning utan att behöva hantera infrastruktur och optimera den för skalning. Det betyder också att säkerhet på infrastrukturnivå inte längre är ditt problem, vilket är en stor fördel med tanke på svårigheten och komplexiteten att uppfylla säkerhetsstandarder. Slutligen behöver du inte köpa den infrastruktur som du fått.
Serverlös kan betraktas som en "state of mind": en viss mentalitet när man utformar lösningar. Undvik tillvägagångssätt som kräver underhåll av någon infrastruktur. Med ett serverlöst tillvägagångssätt lägger vi tid på att lösa uppgifter som direkt påverkar projektet och ger fördelar för våra användare: vi skapar hållbar affärslogik, utvecklar användargränssnitt och utvecklar adaptiva och pålitliga API:er.
Om det till exempel är möjligt att undvika att hantera och underhålla en sökplattform för fritext, så är det vad vi kommer att göra. Detta tillvägagångssätt för att bygga applikationer kan avsevärt påskynda tiden till marknaden, eftersom du inte längre behöver tänka på att hantera komplex infrastruktur. Eliminera ansvaret och kostnaderna för infrastrukturhantering och fokusera på att bygga de applikationer och tjänster som dina kunder behöver. Patrick Debois kallade detta tillvägagångssätt , används termen i den serverlösa gemenskapen. Funktioner bör ses som en länk till tjänster som distribuerbara moduler (istället för att distribuera ett helt bibliotek eller webbapplikation). Detta ger otrolig granularitet för hantering av distribution och ändringar av applikationen. Om du inte kan distribuera funktioner på det här sättet kan det tyda på att funktionerna utför för många uppgifter och behöver omfaktoreras.
Vissa är förvirrade av beroendet av leverantören när de utvecklar molnapplikationer. Detsamma gäller med serverlösa teknologier, och detta är knappast en missuppfattning. Enligt vår erfarenhet är att bygga serverlösa applikationer på AWS, kombinerat med AWS Lambdas förmåga att bunta ihop andra AWS-tjänster, en del av styrkan med serverlösa arkitekturer. Detta är ett bra exempel på synergi, när resultatet av kombinationen är mer än bara summan av termerna. Att försöka undvika leverantörsberoende kan stöta på ännu fler problem. När du arbetar med behållare är det lättare att hantera ditt eget abstraktionslager mellan molnleverantörer. Men när det kommer till serverlösa lösningar kommer ansträngningen inte att löna sig, särskilt inte om kostnadseffektivitet beaktas från början. Se till att ta reda på hur leverantörer tillhandahåller tjänster. Vissa specialiserade tjänster är beroende av integrationspunkter med andra leverantörer och kan tillhandahålla plug-and-play-anslutning direkt. Det är lättare att tillhandahålla ett Lambda-anrop från en gateway API-slutpunkt än att proxy för begäran till någon container eller EC2-instans. Graphcool ger enkel konfiguration med Auth0, vilket är enklare än att använda tredje parts autentiseringsverktyg.
Att välja rätt leverantör för din serverlösa applikation är ett arkitektoniskt beslut. När du skapar en applikation förväntar du dig inte att en dag återgå till att hantera servrar. Att välja en molnleverantör är inte annorlunda än att välja att använda behållare eller en databas, eller till och med ett programmeringsspråk.
Överväga:
- Vilka tjänster behöver du och varför.
- Vilka tjänster molnleverantörer tillhandahåller och hur du kan kombinera dem med din valda FaaS-lösning.
- Vilka programmeringsspråk stöds (med dynamisk eller statisk typning, kompilerad eller tolkad, vilka är riktmärkena, vad är prestanda vid kallstart, vad är ekosystemet med öppen källkod, etc.).
- Vilka är dina säkerhetskrav (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Hur du hanterar dina CI/CD- och mjukvaruutvecklingscykler.
- Vilka infrastruktur-som-kod-lösningar kan du dra nytta av.
Om du utökar en befintlig applikation och gradvis lägger till serverlös funktionalitet kan detta begränsa de tillgängliga funktionerna något. Men nästan alla serverlösa teknologier tillhandahåller någon form av API (via REST eller meddelandeköer) som låter dig skapa tillägg oberoende av applikationskärnan och med enkel integration. Leta efter tjänster med tydliga API:er, bra dokumentation och en stark community, så kan du inte gå fel. Enkel integration kan ofta vara ett nyckelmått, och är förmodligen en av de främsta anledningarna till att AWS har varit så framgångsrik sedan Lambda släpptes 2015.
När serverlöst är bra
Serverlös teknik kan appliceras nästan överallt. Deras fördelar är dock inte begränsade till endast ett sätt att applicera. Inträdesbarriären för cloud computing idag är så låg tack vare serverlös teknologi. Om utvecklare har en idé, men de inte vet hur de ska hantera molninfrastruktur och optimera kostnaderna, behöver de inte leta efter någon form av ingenjör för att göra det. Om en startup vill bygga en plattform men befarar att kostnaderna kan komma ut över kontroll kan de enkelt vända sig till serverlösa lösningar.
På grund av kostnadsbesparingar och enkel skalning är serverlösa lösningar lika användbara för både interna och externa system, upp till en webbapplikation med en mångmiljonpublik. Konton mäts snarare än i euro, men i cent. Att hyra den enklaste instansen av AWS EC2 (t1.micro) i en månad kommer att kosta €15, även om du inte gör något med den (vem har aldrig glömt att stänga av den?!). I jämförelse, för att nå denna utgiftsnivå under samma tidsperiod, skulle du behöva köra en 512 MB Lambda i 1 sekund cirka 3 miljoner gånger. Och om du inte använder den här funktionen så betalar du ingenting.
Eftersom serverlös i första hand är händelsestyrd är det ganska enkelt att lägga till en serverlös infrastruktur till äldre system. Med hjälp av AWS S3, Lambda och Kinesis kan du till exempel skapa en analystjänst för ett gammalt detaljhandelssystem som kan ta emot data via ett API.
De flesta serverlösa plattformar stöder flera språk. Oftast är det Python, JavaScript, C#, Java och Go. Vanligtvis finns det inga begränsningar för användningen av bibliotek på alla språk, så du kan använda dina favoritbibliotek med öppen källkod. Det är dock tillrådligt att inte missbruka beroenden så att dina funktioner fungerar optimalt och inte förnekar fördelarna med den enorma skalbarheten hos dina serverlösa applikationer. Ju fler paket som behöver lastas i containern, desto längre tid tar kallstarten.
En kallstart är när du först behöver initiera behållaren, körtiden och felhanteraren innan du använder dem. På grund av detta kan förseningen i utförandet av funktioner vara upp till 3 sekunder, och detta är inte det bästa alternativet för otåliga användare. Kallstarter inträffar dock vid det första samtalet efter några minuters viloläge. Så många anser att detta är ett mindre irritationsmoment som kan lösas genom att regelbundet pinga funktionen för att hålla den på tomgång. Eller så ignorerar de denna aspekt helt och hållet.
Även om AWS släpptesSQL-databaser är dock inte idealiska för denna applikation, eftersom de är beroende av anslutningar för att utföra transaktioner, vilket snabbt kan bli en flaskhals med tung trafik på AWS Lambda. Ja, utvecklarna förbättrar ständigt Serverless Aurora, och du bör experimentera med det, men idag NoSQL-lösningar som. Det råder dock ingen tvekan om att denna situation kommer att förändras mycket snart.
Verktygslådan lägger också en hel del restriktioner på, särskilt inom området för lokal testning. Även om det finns lösningar som Docker-Lambda, DynamoDB Local och LocalStack, kräver de hårt arbete och en betydande mängd konfiguration. Alla dessa projekt är dock aktivt utvecklade, så det är bara en tidsfråga innan verktygslådan når den nivå vi behöver.
Effekten av serverlösa teknologier på utvecklingscykeln
Eftersom din infrastruktur bara är en konfiguration kan du definiera och distribuera kod med hjälp av skript, till exempel skalskript. Eller så kan du ta till konfigurations-som-kod-klasslösningar som . Även om den här tjänsten inte tillhandahåller konfiguration för alla områden, tillåter den dig att definiera specifika resurser som ska användas som lambdafunktioner. Det vill säga, där CloudFormation sviker dig kan du skriva din egen resurs (Lambda-funktion) som kommer att täppa till detta gap. På så sätt kan du göra vad som helst, till och med konfigurera beroenden utanför din AWS-miljö.
Eftersom allt bara är konfiguration kan du anpassa dina distributionsskript för specifika miljöer, regioner och användare, speciellt om du använder infrastruktur-som-kod-lösningar som CloudFormation. Du kan till exempel distribuera en kopia av infrastrukturen för varje gren i förvaret så att du kan testa dem helt isolerat under utvecklingen. Detta påskyndar drastiskt feedback för utvecklare när de vill förstå om deras kod fungerar adekvat i en levande miljö. Chefer behöver inte oroa sig för kostnaden för att distribuera flera miljöer, eftersom de bara betalar för faktisk användning.
DevOps har mindre bekymmer eftersom de bara behöver se till att utvecklare har rätt konfiguration. Du behöver inte längre hantera instanser, balanserare eller säkerhetsgrupper. Därför används termen NoOps allt mer, även om det fortfarande är viktigt att kunna konfigurera infrastrukturen, speciellt när det kommer till IAM-konfiguration och molnresursoptimering.
Det finns mycket kraftfulla övervaknings- och visualiseringsverktyg som Epsagon, Thundra, Dashbird och IOPipe. De låter dig övervaka det aktuella tillståndet för dina serverlösa applikationer, tillhandahålla loggning och spårning, fånga prestandamått och arkitekturflaskhalsar, utföra kostnadsanalyser och prognoser och mer. De ger inte bara DevOps-ingenjörer, utvecklare och arkitekter en heltäckande bild av applikationsprestanda, utan tillåter också chefer att övervaka situationen i realtid, med resurskostnader per sekund och kostnadsprognoser. Det är mycket svårare att organisera detta med en hanterad infrastruktur.
Att designa serverlösa applikationer är mycket enklare eftersom du inte behöver distribuera webbservrar, hantera virtuella maskiner eller behållare, patchservrar, operativsystem, internetgateways, etc. Genom att abstrahera bort alla dessa ansvarsområden kan en serverlös arkitektur fokusera på kärnan - lösningen, affärs- och kundbehov.
Även om verktygslådan kan vara bättre (det blir bättre för varje dag), kan utvecklare fokusera på att implementera affärslogiken och på bästa sätt fördela applikationens komplexitet över olika tjänster inom arkitekturen. Serverlös applikationshantering är händelsebaserad och abstraherad av molnleverantören (t.ex. SQS, S3-händelser eller DynamoDB-strömmar). Därför behöver utvecklare bara skriva affärslogik för att svara på vissa händelser, och behöver inte oroa sig för hur man bäst implementerar databaser och meddelandeköer, eller hur man organiserar optimalt arbete med data i specifika hårdvarulagringar.
Kod kan köras och felsökas lokalt, som med alla utvecklingsprocesser. Enhetstestning förblir densamma. Möjligheten att distribuera en hel applikationsinfrastruktur med en anpassad stackkonfiguration gör att utvecklare snabbt kan få viktig feedback utan att tänka på kostnaden för testning eller påverkan på dyra hanterade miljöer.
Verktyg och tekniker för att bygga serverlösa applikationer
Det finns inget specifikt sätt att bygga serverlösa applikationer. Samt en uppsättning tjänster för denna uppgift. AWS är ledande bland kraftfulla serverlösa lösningar idag, men titta också på , и . Om du använder AWS är det rekommenderade tillvägagångssättet för att samla in applikationer (SAM), speciellt när du använder C#, eftersom Visual Studio har bra verktyg. SAM CLI kan göra allt som Visual Studio kan göra, så du kommer inte att förlora något om du byter till en annan IDE eller textredigerare. Självklart fungerar SAM med andra språk också.
Om du skriver på andra språk är Serverless Framework ett utmärkt verktyg med öppen källkod som låter dig konfigurera vad som helst med mycket kraftfulla YAML-konfigurationsfiler. Serverless Framework stöder även olika molntjänster, så vi rekommenderar det till de som letar efter en multimolnlösning. Den har en enorm gemenskap som har skapat ett gäng plugins för alla behov.
För lokal testning är verktygen med öppen källkod Docker-Lambda, Serverless Local, DynamoDB Local och LocalStack väl lämpade. Serverlösa tekniker är fortfarande i sina tidiga utvecklingsstadier, liksom verktygen för dem, så när du ställer in dig för komplexa testscenarier måste du arbeta hårt. Men att bara distribuera stacken i en miljö och testa där är otroligt billigt. Och du behöver inte göra en exakt lokal kopia av molnmiljöer.
Använd AWS Lambda Layers för att minska storleken på distribuerade paket och påskynda nedladdningar.
Använd rätt programmeringsspråk för specifika uppgifter. Olika språk har sina egna fördelar och nackdelar. Det finns många riktmärken, men JavaScript, Python och C# (.NET Core 2.1+) är ledande när det gäller AWS Lambda-prestanda. AWS Lambda introducerade nyligen Runtime API, som låter dig specificera önskat runtime-språk och miljö, så experimentera.
Håll paketstorlekar små för distribution. Ju mindre de är, desto snabbare laddas de. Undvik att använda stora bibliotek, särskilt om du använder ett par funktioner från dem. Om du programmerar i JavaScript, använd ett byggverktyg som Webpack för att optimera ditt bygge och bara inkludera det du verkligen behöver. .NET Core 3.0 har QuickJit och Tiered Compilation som förbättrar prestandan och hjälper mycket vid kallstarter.
Beroendet av serverlösa funktioner på händelser kan göra det svårt att samordna affärslogik till en början. I detta avseende kan meddelandeköer och tillståndsmaskiner vara otroligt användbara. Lambdafunktioner kan anropa varandra, men gör bara detta om du inte förväntar dig ett svar ("eld och glöm") - du vill inte bli fakturerad för att du väntar på att en annan funktion ska slutföra. Meddelandeköer är användbara för att isolera delar av affärslogik, hantera programflaskhalsar och bearbeta transaktioner (med hjälp av FIFO-köer). AWS Lambda-funktioner kan tilldelas SQS-köer som fastnade meddelandeköer som håller reda på misslyckade meddelanden för senare analys. AWS Step Functions (tillståndsmaskiner) är mycket användbara för att hantera komplexa processer som kräver kedja av funktioner. Istället för att en lambdafunktion anropar en annan funktion kan stegfunktioner koordinera tillståndsövergångar, skicka data mellan funktioner och hantera funktionernas globala tillstånd. Detta gör att du kan definiera villkor för ett nytt försök, eller vad du ska göra när ett visst fel inträffar - ett mycket kraftfullt verktyg under vissa förhållanden.
Slutsats
Under de senaste åren har serverlösa teknologier utvecklats i en aldrig tidigare skådad takt. Det finns vissa missuppfattningar förknippade med detta paradigmskifte. Genom att abstrahera infrastruktur och skalningshantering erbjuder serverlösa lösningar betydande fördelar, från förenklad utveckling och DevOps-processer till massiva minskningar av driftskostnaderna.
Även om det serverlösa tillvägagångssättet inte är utan sina nackdelar, finns det robusta designmönster som kan användas för att bygga robusta serverlösa applikationer eller integrera serverlösa element i befintliga arkitekturer.
Källa: will.com