Serverlös handlar inte om fysisk frånvaro av servrar. Detta är inte en containermördare eller en övergående trend. Detta är ett nytt tillvägagångssätt för att bygga system i molnet. I dagens artikel kommer vi att beröra arkitekturen för serverlösa applikationer, låt oss se vilken roll den serverlösa tjänsteleverantören och öppen källkodsprojekt spelar. Slutligen, låt oss prata om problemen med att använda Serverless.
Jag vill skriva en serverdel av en applikation (eller till och med en onlinebutik). Detta kan vara en chatt, en innehållspubliceringstjänst eller en lastbalanserare. I vilket fall som helst kommer det att finnas mycket huvudvärk: du måste förbereda infrastrukturen, bestämma applikationsberoendena och tänka på värdoperativsystemet. Då måste du uppdatera små komponenter som inte påverkar driften av resten av monoliten. Tja, låt oss inte glömma skalning under belastning.
Vad händer om vi tar tillfälliga behållare, där de nödvändiga beroendena redan är förinstallerade, och själva behållarna är isolerade från varandra och från värdoperativsystemet? Vi kommer att dela upp monoliten i mikrotjänster, som var och en kan uppdateras och skalas oberoende av de andra. Genom att placera koden i en sådan container kan jag köra den på vilken infrastruktur som helst. Redan bättre.
Vad händer om du inte vill konfigurera behållare? Jag vill inte tänka på att skala applikationen. Jag vill inte betala för tomma containrar när belastningen på tjänsten är minimal. Jag vill skriva kod. Fokusera på affärslogik och släpp ut produkter på marknaden med ljusets hastighet.
Sådana tankar ledde mig till serverlös datoranvändning. Serverlös betyder i detta fall inte den fysiska frånvaron av servrar, utan frånvaron av huvudvärk för infrastrukturhantering.
Tanken är att applikationslogik bryts ner i oberoende funktioner. De har en evenemangsstruktur. Varje funktion utför en "mikrouppgift". Allt som krävs av utvecklaren är att ladda in funktionerna i konsolen som tillhandahålls av molnleverantören och korrelera dem med händelsekällor. Koden kommer att exekveras på begäran i en automatiskt förberedd container, och jag betalar endast för exekveringstiden.
Låt oss se hur applikationsutvecklingsprocessen kommer att se ut nu.
Från utvecklarens sida
Tidigare började vi prata om en ansökan till en webbutik. I det traditionella tillvägagångssättet utförs systemets huvudlogik av en monolitisk applikation. Och servern med applikationen körs konstant, även om det inte är någon belastning.
För att gå över till serverlöst delar vi upp applikationen i mikrouppgifter. Vi skriver vår egen funktion för var och en av dem. Funktionerna är oberoende av varandra och lagrar inte tillståndsinformation (tillståndslös). De kan till och med vara skrivna på olika språk. Om en av dem "faller" kommer inte hela applikationen att sluta. Applikationsarkitekturen kommer att se ut så här:
Uppdelningen i funktioner i Serverless liknar att arbeta med mikrotjänster. Men en mikrotjänst kan utföra flera uppgifter, och en funktion bör helst utföra en. Låt oss föreställa oss att uppgiften är att samla in statistik och visa den på användarens begäran. I mikroservicemetoden utförs en uppgift av en tjänst med två ingångspunkter: skriva och läsa. I serverlös datoranvändning kommer dessa att vara två olika funktioner som inte är relaterade till varandra. Utvecklaren sparar beräkningsresurser om till exempel statistik uppdateras oftare än vad den laddas ner.
Serverlösa funktioner måste köras under en kort tidsperiod (timeout), vilket bestäms av tjänsteleverantören. Till exempel, för AWS är timeout 15 minuter. Detta innebär att långlivade funktioner kommer att behöva ändras för att passa kraven - det är detta som skiljer Serverless från andra populära teknologier idag (containrar och Platform as a Service).
Vi tilldelar varje funktion en händelse. En händelse är en utlösande faktor för en åtgärd:
händelse
Åtgärden som funktionen utför
En produktbild har laddats upp till förvaret.
Komprimera bilden och ladda upp till en katalog
Den fysiska butiksadressen har uppdaterats i databasen
Ladda en ny plats i kartor
Kunden betalar för varorna
Starta betalningshanteringen
Händelser kan vara HTTP-förfrågningar, strömmande data, meddelandeköer och så vidare. Händelsekällor är förändringar eller förekomster av data. Dessutom kan funktioner triggas av en timer.
Arkitekturen var utarbetad och applikationen blev nästan serverlös. Därefter går vi till tjänsteleverantören.
Från leverantörens sida
Vanligtvis erbjuds serverlös datoranvändning av molntjänstleverantörer. De heter olika: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Vi kommer att använda tjänsten via leverantörens konsol eller personliga konto. Funktionskoden kan laddas ner på något av följande sätt:
- skriv kod i inbyggda editorer via webbkonsolen,
- ladda ner arkivet med koden,
- arbeta med offentliga eller privata git-arkiv.
Här ställer vi upp de händelser som anropar funktionen. Uppsättningarna av händelser kan skilja sig åt för olika leverantörer.
Leverantören byggde och automatiserade Function as a Service-systemet (FaaS) på sin infrastruktur:
- Funktionskoden hamnar i förråd på leverantörssidan.
- När en händelse inträffar distribueras behållare med en förberedd miljö automatiskt på servern. Varje funktionsinstans har sin egen isolerade behållare.
- Från lagringen skickas funktionen till behållaren, beräknas och returnerar resultatet.
- Antalet parallella händelser växer – antalet containrar växer. Systemet skalas automatiskt. Om användare inte kommer åt funktionen kommer den att vara inaktiv.
- Leverantören ställer in vilotiden för containrar - om funktioner under denna tid inte visas i containern, förstörs den.
På så sätt får vi serverlöst ur lådan. Vi kommer att betala för tjänsten med hjälp av pay-as-you-go-modellen och endast för de funktioner som används, och endast för den tid då de användes.
För att introducera utvecklare till tjänsten erbjuder leverantörer upp till 12 månaders gratis testning, men begränsar den totala beräkningstiden, antalet förfrågningar per månad, pengar eller strömförbrukning.
Den största fördelen med att arbeta med en leverantör är möjligheten att inte oroa sig för infrastruktur (servrar, virtuella maskiner, behållare). Leverantören kan för sin del implementera FaaS både med hjälp av sin egen utveckling och med hjälp av verktyg med öppen källkod. Låt oss prata om dem vidare.
Från sidan med öppen källkod
Gemenskapen med öppen källkod har arbetat aktivt med verktyg utan server under de senaste åren. De största marknadsaktörerna bidrar också till utvecklingen av serverlösa plattformar:
- Google erbjuder utvecklare sitt verktyg med öppen källkod - . IBM, RedHat, Pivotal och SAP deltog i dess utveckling;
- IBM arbetade på en serverlös plattform , som sedan blev ett projekt av Apache Foundation;
- Microsoft delvis öppnade plattformskoden .
Utveckling pågår även i riktning mot serverlösa ramverk. и distribueras i förberedda Kubernetes-kluster, fungerar med både Kubernetes och Docker Swarm. Ramverket fungerar som en slags styrenhet - på begäran förbereder det en runtime-miljö inuti klustret och startar sedan en funktion där.
Ramar lämnar utrymme för att konfigurera verktyget för att passa dina behov. Så i Kubeless kan en utvecklare konfigurera funktionsexekveringstidsgränsen (standardvärdet är 180 sekunder). Fission, i ett försök att lösa kallstartsproblemet, föreslår att vissa containrar körs hela tiden (även om detta medför kostnader för resursavbrott). Och OpenFaaS erbjuder en uppsättning triggers för varje smak och färg: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs och andra.
Instruktioner för att komma igång finns i den officiella dokumentationen av ramarna. Att arbeta med dem kräver att man har lite mer kompetens än när man arbetar med en leverantör – detta är åtminstone möjligheten att lansera ett Kubernetes-kluster via CLI. Inkludera som mest andra verktyg med öppen källkod (till exempel Kafka-köhanteraren).
Oavsett hur vi arbetar med Serverless - genom en leverantör eller med öppen källkod, kommer vi att få ett antal fördelar och nackdelar med Serverless-upplägget.
Ur synvinkel av fördelar och nackdelar
Serverless utvecklar idéerna om en containerinfrastruktur och en mikrotjänstmetod, där team kan arbeta i ett flerspråkigt läge utan att vara bundna till en plattform. Att bygga ett system är förenklat och fel är lättare att rätta till. Mikroservicearkitektur låter dig lägga till ny funktionalitet till systemet mycket snabbare än i fallet med en monolitisk applikation.
Serverlöst minskar utvecklingstiden ytterligare, så att utvecklaren kan fokusera enbart på applikationens affärslogik och kodning. Som ett resultat av detta minskar tiden till marknaden för utveckling.
Som en bonus får vi automatisk skalning för belastning, och vi betalar endast för de resurser som används och endast vid den tidpunkt då de används.
Som all teknik har Serverless nackdelar.
Till exempel kan en sådan nackdel vara kallstartstiden (i genomsnitt upp till 1 sekund för språk som JavaScript, Python, Go, Java, Ruby).
Å ena sidan, i verkligheten, beror kallstartstiden på många variabler: språket som funktionen är skriven på, antalet bibliotek, mängden kod, kommunikation med ytterligare resurser (samma databaser eller autentiseringsservrar). Eftersom utvecklaren kontrollerar dessa variabler kan han minska starttiden. Men å andra sidan kan utvecklaren inte kontrollera starttiden för behållaren - allt beror på leverantören.
En kallstart kan förvandlas till en varmstart när en funktion återanvänder en container som lanserats av en tidigare händelse. Denna situation kommer att uppstå i tre fall:
- om kunder ofta använder tjänsten och antalet samtal till funktionen ökar;
- om leverantören, plattformen eller ramverket tillåter dig att hålla vissa behållare igång hela tiden;
- om utvecklaren kör funktioner på en timer (säg var tredje minut).
För många applikationer är en kallstart inget problem. Här behöver du bygga vidare på tjänstens typ och uppgifter. En startfördröjning på en sekund är inte alltid kritisk för en affärsapplikation, men den kan bli kritisk för medicinska tjänster. I det här fallet kommer det serverlösa tillvägagångssättet förmodligen inte längre att vara lämpligt.
Nästa nackdel med Serverless är den korta livslängden för en funktion (timeout under vilken funktionen måste exekveras).
Men om du måste arbeta med långlivade uppgifter kan du använda en hybridarkitektur - kombinera Serverless med en annan teknik.
Alla system kommer inte att kunna fungera med schemat Serverless.
Vissa applikationer kommer fortfarande att lagra data och status under körning. Vissa arkitekturer kommer att förbli monolitiska och vissa funktioner kommer att vara långlivade. Men (som molnteknik och sedan behållare) är Serverless en teknik med en stor framtid.
I denna anda skulle jag smidigt vilja gå vidare till frågan om att använda det serverlösa tillvägagångssättet.
Från applikationssidan
För 2018, andelen serverlös användning . Bland de företag som redan har implementerat tekniken i sina tjänster finns sådana marknadsjättar som Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samtidigt måste du förstå att Serverless inte är ett universalmedel, utan ett verktyg för att lösa ett visst antal problem:
- Minska stilleståndstid för resurser. Det finns ingen anledning att ständigt ha en virtuell maskin för tjänster som har få samtal.
- Bearbeta data i farten. Komprimera bilder, klipp ut bakgrunder, ändra videokodning, arbeta med IoT-sensorer, utför matematiska operationer.
- "Lima" ihop andra tjänster. Git repository med interna program, chatbot i Slack med Jira och kalender.
- Balansera belastningen. Låt oss ta en närmare titt här.
Låt oss säga att det finns en tjänst som lockar 50 personer. Under den finns en virtuell maskin med svag hårdvara. Då och då ökar belastningen på tjänsten avsevärt. Då klarar inte svag hårdvara.
Du kan inkludera en balanserare i systemet som kommer att fördela belastningen, till exempel, över tre virtuella maskiner. I det här skedet kan vi inte exakt förutsäga belastningen, så vi håller en viss mängd resurser igång "i reserv." Och vi betalar för mycket för driftstopp.
I en sådan situation kan vi optimera systemet genom ett hybridt tillvägagångssätt: vi lämnar en virtuell maskin bakom lastbalanseraren och lägger en länk till Serverless Endpoint med funktioner. Om belastningen överskrider tröskeln, startar balanseraren funktionsinstanser som tar över en del av förfrågningsbehandlingen.
Således kan Serverless användas där det är nödvändigt att behandla ett stort antal förfrågningar inte för ofta, men intensivt. I det här fallet är det mer lönsamt att köra flera funktioner under 15 minuter än att underhålla en virtuell maskin eller server hela tiden.
Med alla fördelarna med serverlös datoranvändning bör du innan implementering först utvärdera applikationslogiken och förstå vilka problem Serverless kan lösa i ett visst fall.
Serverlös och Selectel
På Selectel är vi redan via vår kontrollpanel. Nu bygger vi vår egen FaaS-plattform. Vi vill att utvecklare ska kunna lösa sina problem med hjälp av Serverless genom ett bekvämt, flexibelt gränssnitt.
Om du har idéer om vad den ideala FaaS-plattformen bör vara och hur du vill använda Serverless i dina projekt, dela dem i kommentarerna. Vi tar hänsyn till dina önskemål när vi utvecklar plattformen.
Material som används i artikeln:
Källa: will.com