Serverløs handler ikke om det fysiske fravær af servere. Dette er ikke en containerdræber eller en forbigående tendens. Dette er en ny tilgang til at bygge systemer i skyen. I dagens artikel vil vi berøre arkitekturen af serverløse applikationer, lad os se, hvilken rolle den serverløse tjenesteudbyder og open source-projekter spiller. Lad os endelig tale om problemerne med at bruge serverløs.
Jeg vil skrive en serverdel af en applikation (eller endda en onlinebutik). Dette kan være en chat, en indholdsudgivelsestjeneste eller en load balancer. Under alle omstændigheder vil der være en masse hovedpine: du bliver nødt til at forberede infrastrukturen, bestemme applikationsafhængighederne og tænke på værtsoperativsystemet. Så bliver du nødt til at opdatere små komponenter, der ikke påvirker driften af resten af monolitten. Nå, lad os ikke glemme skalering under belastning.
Hvad hvis vi tager flygtige beholdere, hvor de nødvendige afhængigheder allerede er forudinstalleret, og selve beholderne er isoleret fra hinanden og fra værts-operativsystemet? Vi vil opdele monolitten i mikrotjenester, som hver især kan opdateres og skaleres uafhængigt af de andre. Ved at placere koden i sådan en container, kan jeg køre den på enhver infrastruktur. Allerede bedre.
Hvad hvis du ikke vil konfigurere containere? Jeg vil ikke tænke på at skalere applikationen. Jeg vil ikke betale for tomgangsløbende containere, når belastningen på tjenesten er minimal. Jeg vil skrive kode. Fokuser på forretningslogik og bring produkter på markedet med lysets hastighed.
Sådanne tanker førte mig til serverløs computing. Serverløs betyder i dette tilfælde ikke det fysiske fravær af servere, men fraværet af infrastrukturstyringshovedpine.
Tanken er, at applikationslogik er opdelt i uafhængige funktioner. De har en begivenhedsstruktur. Hver funktion udfører én "mikrotaske". Det eneste, der kræves af udvikleren, er at indlæse funktionerne i konsollen leveret af cloud-udbyderen og korrelere dem med hændelseskilder. Koden vil blive eksekveret efter ønske i en automatisk forberedt container, og jeg betaler kun for eksekveringstiden.
Lad os se, hvordan applikationsudviklingsprocessen vil se ud nu.
Fra udviklerens side
Tidligere begyndte vi at tale om en ansøgning til en netbutik. I den traditionelle tilgang udføres systemets hovedlogik af en monolitisk applikation. Og serveren med applikationen kører konstant, selvom der ikke er nogen belastning.
For at flytte til serverløs opdeler vi applikationen i mikroopgaver. Vi skriver vores egen funktion til hver af dem. Funktionerne er uafhængige af hinanden og gemmer ikke tilstandsinformation (statsløs). De kan endda være skrevet på forskellige sprog. Hvis en af dem "falder", stopper hele applikationen ikke. Applikationsarkitekturen vil se sådan ud:
Opdelingen i funktioner i Serverless svarer til at arbejde med mikrotjenester. Men en mikroservice kan udføre flere opgaver, og en funktion bør ideelt set udføre en. Lad os forestille os, at opgaven er at indsamle statistik og vise dem på brugerens anmodning. I mikroservicetilgangen udføres en opgave af én tjeneste med to indgangspunkter: skrivning og læsning. I serverløs computing vil disse være to forskellige funktioner, der ikke er relateret til hinanden. Udvikleren sparer computerressourcer, hvis f.eks. statistikker opdateres oftere, end de downloades.
Serverløse funktioner skal udføres i en kort periode (timeout), som bestemmes af tjenesteudbyderen. For AWS er timeout f.eks. 15 minutter. Det betyder, at langlivede funktioner skal ændres, så de passer til kravene - det er det, der adskiller Serverless fra andre populære teknologier i dag (containere og Platform as a Service).
Vi tildeler en begivenhed til hver funktion. En hændelse er en trigger for en handling:
begivenhed
Den handling, som funktionen udfører
Et produktbillede er blevet uploadet til lageret.
Komprimer billedet og upload til en mappe
Den fysiske butiksadresse er blevet opdateret i databasen
Indlæs en ny placering i kort
Kunden betaler for varerne
Start betalingsbehandlingen
Hændelser kan være HTTP-anmodninger, streamingdata, beskedkøer og så videre. Hændelseskilder er ændringer eller forekomster af data. Derudover kan funktioner udløses af en timer.
Arkitekturen blev udarbejdet, og applikationen blev næsten serverløs. Dernæst går vi til tjenesteudbyderen.
Fra udbyderens side
Typisk tilbydes serverløs computing af cloud-tjenesteudbydere. De kaldes forskelligt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Vi vil bruge tjenesten via udbyderens konsol eller personlige konto. Funktionskode kan downloades på en af følgende måder:
- skrive kode i indbyggede editorer via webkonsollen,
- download arkivet med koden,
- arbejde med offentlige eller private git-depoter.
Her opsætter vi de begivenheder, der kalder funktionen. Begivenhedssættene kan variere for forskellige udbydere.
Udbyderen byggede og automatiserede Function as a Service (FaaS) systemet på sin infrastruktur:
- Funktionskoden ender på lager på udbydersiden.
- Når en hændelse opstår, implementeres containere med et forberedt miljø automatisk på serveren. Hver funktionsforekomst har sin egen isolerede beholder.
- Fra lageret sendes funktionen til containeren, beregnes og returnerer resultatet.
- Antallet af parallelle begivenheder vokser – antallet af containere vokser. Systemet skalerer automatisk. Hvis brugere ikke får adgang til funktionen, vil den være inaktiv.
- Udbyderen indstiller tomgangstiden for containere - hvis der i dette tidsrum ikke vises funktioner i containeren, ødelægges den.
På denne måde får vi serverløs ud af boksen. Vi betaler for tjenesten ved hjælp af pay-as-you-go-modellen og kun for de funktioner, der bruges, og kun for det tidspunkt, hvor de blev brugt.
For at introducere udviklere til tjenesten tilbyder udbydere op til 12 måneders gratis test, men begrænser den samlede beregningstid, antallet af anmodninger pr. måned, midler eller strømforbrug.
Den største fordel ved at arbejde med en udbyder er muligheden for ikke at bekymre sig om infrastruktur (servere, virtuelle maskiner, containere). Udbyderen kan på sin side implementere FaaS både ved hjælp af sine egne udviklinger og ved hjælp af open source-værktøjer. Lad os tale om dem yderligere.
Fra open source-siden
Open source-fællesskabet har arbejdet aktivt på serverløse værktøjer i de sidste par år. De største markedsaktører bidrager også til udviklingen af serverløse platforme:
- Google tilbyder udviklere sit open source-værktøj - . IBM, RedHat, Pivotal og SAP deltog i dens udvikling;
- IBM arbejdede på en serverløs platform , som derefter blev et projekt af Apache Foundation;
- microsoft delvist åbnet platformkoden .
Der er også udvikling i retning af serverløse frameworks. и implementeret i forud forberedte Kubernetes-klynger, fungerer med både Kubernetes og Docker Swarm. Frameworket fungerer som en slags controller - efter anmodning forbereder det et runtime-miljø inde i klyngen, og starter derefter en funktion der.
Rammer giver plads til at konfigurere værktøjet, så det passer til dine behov. Så i Kubeless kan en udvikler konfigurere funktionsudførelsestimeout (standardværdien er 180 sekunder). Fission, i et forsøg på at løse koldstartsproblemet, foreslår at holde nogle containere kørende hele tiden (selvom dette medfører omkostninger til ressourcenedetid). Og OpenFaaS tilbyder et sæt triggere for enhver smag og farve: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT'er og andre.
Vejledning til at komme i gang kan findes i den officielle dokumentation af rammerne. At arbejde med dem kræver at have lidt flere færdigheder, end når man arbejder med en udbyder – det er i hvert fald muligheden for at starte en Kubernetes-klynge via CLI. Inkluder højst andre open source-værktøjer (for eksempel Kafka-kømanageren).
Uanset hvordan vi arbejder med Serverless - gennem en udbyder eller ved hjælp af open source, vil vi modtage en række fordele og ulemper ved Serverless tilgangen.
Ud fra et synspunkt om fordele og ulemper
Serverless udvikler ideerne om en containerinfrastruktur og en mikroservicetilgang, hvor teams kan arbejde i en flersproget tilstand uden at være bundet til én platform. Opbygning af et system er forenklet, og fejl er nemmere at rette. Mikroservicearkitektur giver dig mulighed for at tilføje ny funktionalitet til systemet meget hurtigere end i tilfælde af en monolitisk applikation.
Serverløs reducerer udviklingstiden endnu mere, giver udvikleren mulighed for udelukkende at fokusere på applikationens forretningslogik og kodning. Som følge heraf reduceres tiden til markedet for udviklinger.
Som en bonus får vi automatisk skalering for belastning, og vi betaler kun for de anvendte ressourcer og kun på det tidspunkt, hvor de bliver brugt.
Som enhver teknologi har Serverless ulemper.
For eksempel kan en sådan ulempe være koldstartstiden (i gennemsnit op til 1 sekund for sprog som JavaScript, Python, Go, Java, Ruby).
På den ene side afhænger koldstartstiden i virkeligheden af mange variabler: sproget, som funktionen er skrevet på, antallet af biblioteker, mængden af kode, kommunikation med yderligere ressourcer (de samme databaser eller godkendelsesservere). Da udvikleren kontrollerer disse variabler, kan han reducere opstartstiden. Men på den anden side kan udvikleren ikke styre containerens opstartstid – det hele afhænger af udbyderen.
En kold start kan blive til en varm start, når en funktion genbruger en container, der er lanceret af en tidligere begivenhed. Denne situation vil opstå i tre tilfælde:
- hvis klienter ofte bruger tjenesten, og antallet af opkald til funktionen stiger;
- hvis udbyderen, platformen eller rammeværket giver dig mulighed for at holde nogle containere kørende hele tiden;
- hvis udvikleren kører funktioner på en timer (f.eks. hvert 3. minut).
For mange applikationer er en koldstart ikke et problem. Her skal du bygge videre på ydelsens type og opgaver. En startforsinkelse på et sekund er ikke altid kritisk for en forretningsapplikation, men den kan blive kritisk for medicinske tjenester. I dette tilfælde vil den serverløse tilgang sandsynligvis ikke længere være egnet.
Den næste ulempe ved Serverless er den korte levetid for en funktion (timeout, hvor funktionen skal udføres).
Men hvis du skal arbejde med langvarige opgaver, kan du bruge en hybrid arkitektur – kombinere Serverless med en anden teknologi.
Ikke alle systemer vil være i stand til at arbejde ved hjælp af Serverless-ordningen.
Nogle applikationer vil stadig gemme data og tilstand under udførelse. Nogle arkitekturer vil forblive monolitiske, og nogle funktioner vil have lang levetid. Men (ligesom cloud-teknologier og derefter containere) er Serverless en teknologi med en stor fremtid.
I denne forbindelse vil jeg gerne gå glat videre til spørgsmålet om at bruge den serverløse tilgang.
Fra ansøgningssiden
For 2018, procentdelen af serverløs brug . Blandt de virksomheder, der allerede har implementeret teknologien i deres tjenester, er sådanne markedsgiganter som Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samtidig skal du forstå, at Serverless ikke er et vidundermiddel, men et værktøj til at løse en række problemer:
- Reducer nedetid for ressourcer. Der er ingen grund til konstant at have en virtuel maskine til tjenester, der har få opkald.
- Behandle data på farten. Komprimer billeder, klip baggrunde ud, skift videokodning, arbejd med IoT-sensorer, udfør matematiske operationer.
- "Lim" andre tjenester sammen. Git repository med interne programmer, chatbot i Slack med Jira og kalender.
- Afbalancere belastningen. Lad os se nærmere her.
Lad os sige, at der er en tjeneste, der tiltrækker 50 mennesker. Under den er der en virtuel maskine med svag hardware. Fra tid til anden stiger belastningen på tjenesten markant. Så kan svag hardware ikke klare sig.
Du kan inkludere en balancer i systemet, der vil fordele belastningen, f.eks. over tre virtuelle maskiner. På dette stadium kan vi ikke præcist forudsige belastningen, så vi holder en vis mængde ressourcer kørende "i reserve". Og vi betaler for meget for nedetid.
I en sådan situation kan vi optimere systemet gennem en hybrid tilgang: Vi efterlader én virtuel maskine bag load balanceren og sætter et link til det serverløse endepunkt med funktioner. Hvis belastningen overstiger tærsklen, starter balanceren funktionsforekomster, der overtager en del af anmodningsbehandlingen.
Serverless kan således bruges, hvor det er nødvendigt at behandle et stort antal forespørgsler ikke for ofte, men intensivt. I dette tilfælde er det mere rentabelt at køre flere funktioner i 15 minutter end at vedligeholde en virtuel maskine eller server hele tiden.
Med alle fordelene ved serverløs computing bør du inden implementering først evaluere applikationslogikken og forstå, hvilke problemer Serverless kan løse i et bestemt tilfælde.
Serverløs og Selectel
Hos Selectel er vi allerede via vores kontrolpanel. Nu bygger vi vores egen FaaS platform. Vi ønsker, at udviklere skal være i stand til at løse deres problemer ved hjælp af Serverless gennem en praktisk, fleksibel grænseflade.
Hvis du har ideer til, hvad den ideelle FaaS-platform skal være, og hvordan du vil bruge Serverless i dine projekter, så del dem i kommentarerne. Vi tager dine ønsker i betragtning, når vi udvikler platformen.
Materialer brugt i artiklen:
Kilde: www.habr.com