Serverless handler ikke om det fysiske fraværet av servere. Dette er ikke en containerdreper eller en forbigående trend. Dette er en ny tilnærming til å bygge systemer i skyen. I dagens artikkel vil vi berøre arkitekturen til serverløse applikasjoner, la oss se hvilken rolle den serverløse tjenesteleverandøren og åpen kildekode-prosjekter spiller. Til slutt, la oss snakke om problemene med å bruke serverløs.
Jeg vil skrive en serverdel av en applikasjon (eller til og med en nettbutikk). Dette kan være en chat, en innholdspubliseringstjeneste eller en belastningsbalanser. I alle fall vil det være mye hodepine: du må forberede infrastrukturen, bestemme applikasjonsavhengighetene og tenke på vertsoperativsystemet. Deretter må du oppdatere små komponenter som ikke påvirker driften av resten av monolitten. Vel, la oss ikke glemme skalering under belastning.
Hva om vi tar flyktige beholdere, der de nødvendige avhengighetene allerede er forhåndsinstallert, og selve beholderne er isolert fra hverandre og fra verts-OS? Vi vil dele monolitten inn i mikrotjenester, som hver kan oppdateres og skaleres uavhengig av de andre. Ved å plassere koden i en slik container kan jeg kjøre den på hvilken som helst infrastruktur. Allerede bedre.
Hva om du ikke vil konfigurere beholdere? Jeg vil ikke tenke på å skalere applikasjonen. Jeg vil ikke betale for beholdere som kjører på tomgang når belastningen på tjenesten er minimal. Jeg vil skrive kode. Fokuser på forretningslogikk og bring produkter til markedet med lysets hastighet.
Slike tanker førte meg til serverløs databehandling. Serverløs betyr i dette tilfellet ikke det fysiske fraværet av servere, men fraværet av hodepine for infrastrukturadministrasjon.
Tanken er at applikasjonslogikk brytes ned i uavhengige funksjoner. De har en arrangementsstruktur. Hver funksjon utfører én "mikrooppgave". Alt som kreves av utvikleren er å laste inn funksjonene i konsollen levert av skyleverandøren og korrelere dem med hendelseskilder. Koden vil bli utført på forespørsel i en automatisk klargjort container, og jeg betaler kun for utførelsestiden.
La oss se hvordan applikasjonsutviklingsprosessen vil se ut nå.
Fra utbyggers side
Tidligere begynte vi å snakke om en søknad til en nettbutikk. I den tradisjonelle tilnærmingen utføres hovedlogikken til systemet av en monolitisk applikasjon. Og serveren med applikasjonen kjører konstant, selv om det ikke er last.
For å gå over til serverløs deler vi applikasjonen inn i mikrooppgaver. Vi skriver vår egen funksjon for hver av dem. Funksjonene er uavhengige av hverandre og lagrer ikke tilstandsinformasjon (statsløs). De kan til og med være skrevet på forskjellige språk. Hvis en av dem "faller", vil ikke hele applikasjonen stoppe. Applikasjonsarkitekturen vil se slik ut:
Inndelingen i funksjoner i Serverless ligner på å jobbe med mikrotjenester. Men en mikrotjeneste kan utføre flere oppgaver, og en funksjon bør ideelt sett utføre en. La oss forestille oss at oppgaven er å samle inn statistikk og vise dem på brukerens forespørsel. I mikroservicetilnærmingen utføres en oppgave av én tjeneste med to inngangspunkter: skriving og lesing. I serverløs databehandling vil dette være to forskjellige funksjoner som ikke er relatert til hverandre. Utvikleren sparer dataressurser hvis for eksempel statistikk oppdateres oftere enn den lastes ned.
Serverløse funksjoner må utføres i løpet av kort tid (timeout), som bestemmes av tjenesteleverandøren. For eksempel, for AWS er tidsavbruddet 15 minutter. Dette betyr at funksjoner med lang levetid må endres for å passe kravene – det er dette som skiller Serverless fra andre populære teknologier i dag (containere og Platform as a Service).
Vi tildeler en hendelse til hver funksjon. En hendelse er en utløser for en handling:
event
Handlingen som funksjonen utfører
Et produktbilde er lastet opp til depotet.
Komprimer bildet og last opp til en katalog
Den fysiske butikkadressen er oppdatert i databasen
Last inn en ny plassering i kart
Kunden betaler for varene
Start betalingsbehandlingen
Hendelser kan være HTTP-forespørsler, strømmedata, meldingskøer og så videre. Hendelseskilder er endringer eller forekomster av data. I tillegg kan funksjoner utløses av en timer.
Arkitekturen ble utarbeidet, og applikasjonen ble nesten serverløs. Deretter går vi til tjenesteleverandøren.
Fra leverandørens side
Vanligvis tilbys serverløs databehandling av skytjenesteleverandører. De kalles annerledes: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Vi vil bruke tjenesten gjennom leverandørens konsoll eller personlige konto. Funksjonskode kan lastes ned på en av følgende måter:
- skrive kode i innebygde editorer via nettkonsollen,
- last ned arkivet med koden,
- arbeid med offentlige eller private git-repositories.
Her setter vi opp hendelsene som kaller funksjonen. Settene med hendelser kan variere for ulike leverandører.
Leverandøren bygde og automatiserte Function as a Service (FaaS)-systemet på sin infrastruktur:
- Funksjonskoden havner på leverandørsiden.
- Når en hendelse inntreffer, blir containere med et forberedt miljø automatisk distribuert på serveren. Hver funksjonsforekomst har sin egen isolerte beholder.
- Fra lageret sendes funksjonen til containeren, beregnes og returnerer resultatet.
- Antall parallelle arrangementer vokser – antall containere vokser. Systemet skaleres automatisk. Hvis brukere ikke får tilgang til funksjonen, vil den være inaktiv.
- Leverandøren setter inaktiv tid for containere - hvis funksjoner i løpet av denne tiden ikke vises i containeren, blir den ødelagt.
På denne måten får vi Serverless ut av esken. Vi betaler for tjenesten ved bruk av betal-etter-du-gå-modellen og kun for de funksjonene som brukes, og kun for tiden de ble brukt.
For å introdusere utviklere til tjenesten, tilbyr leverandørene opptil 12 måneders gratis testing, men begrenser total beregningstid, antall forespørsler per måned, midler eller strømforbruk.
Den største fordelen med å jobbe med en leverandør er muligheten til å ikke bekymre deg for infrastruktur (servere, virtuelle maskiner, containere). Leverandøren kan på sin side implementere FaaS både ved hjelp av egne utviklinger og ved bruk av åpen kildekode-verktøy. La oss snakke om dem videre.
Fra åpen kildekode-siden
Åpen kildekode-fellesskapet har jobbet aktivt med serverløse verktøy de siste par årene. De største markedsaktørene bidrar også til utviklingen av serverløse plattformer:
- Google tilbyr utviklere sitt åpen kildekode-verktøy - . IBM, RedHat, Pivotal og SAP deltok i utviklingen;
- IBM jobbet på en serverløs plattform , som deretter ble et prosjekt av Apache Foundation;
- Microsoft delvis åpnet plattformkoden .
Det pågår også utvikling i retning av serverløse rammeverk. и distribuert i forhåndsforberedte Kubernetes-klynger, fungerer med både Kubernetes og Docker Swarm. Rammeverket fungerer som en slags kontroller - på forespørsel forbereder det et kjøretidsmiljø inne i klyngen, og starter deretter en funksjon der.
Rammer gir rom for å konfigurere verktøyet for å passe dine behov. Så, i Kubeless, kan en utvikler konfigurere funksjonens utføringstidsavbrudd (standardverdien er 180 sekunder). Fission, i et forsøk på å løse kaldstartproblemet, foreslår å holde noen containere i gang hele tiden (selv om dette medfører kostnader for nedetid for ressurser). Og OpenFaaS tilbyr et sett med triggere for enhver smak og farge: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs og andre.
Instruksjoner for å komme i gang finner du i den offisielle dokumentasjonen til rammeverket. Å jobbe med dem krever å ha litt mer kompetanse enn når man jobber med en leverandør – dette er i det minste muligheten til å lansere en Kubernetes-klynge via CLI. På det meste kan du inkludere andre åpen kildekode-verktøy (for eksempel Kafka købehandling).
Uansett hvordan vi jobber med Serverless – gjennom en leverandør eller ved bruk av åpen kildekode, vil vi få en rekke fordeler og ulemper med Serverless-tilnærmingen.
Fra synspunkt av fordeler og ulemper
Serverless utvikler ideene om en containerinfrastruktur og en mikrotjenestetilnærming, der team kan jobbe i en flerspråklig modus uten å være knyttet til én plattform. Å bygge et system er forenklet og feil er lettere å rette. Microservice-arkitektur lar deg legge til ny funksjonalitet til systemet mye raskere enn i tilfelle av en monolitisk applikasjon.
Serverløs reduserer utviklingstiden ytterligere, slik at utvikleren kan fokusere utelukkende på applikasjonens forretningslogikk og koding. Som et resultat reduseres tiden til marked for utbygginger.
Som en bonus får vi automatisk skalering for belastning, og vi betaler kun for ressursene som brukes og kun på det tidspunktet de brukes.
Som all teknologi har Serverless ulemper.
For eksempel kan en slik ulempe være kaldstarttiden (i gjennomsnitt opptil 1 sekund for språk som JavaScript, Python, Go, Java, Ruby).
På den ene siden, i virkeligheten, avhenger kaldstarttiden av mange variabler: språket som funksjonen er skrevet på, antall biblioteker, mengde kode, kommunikasjon med ekstra ressurser (de samme databaser eller autentiseringsservere). Siden utvikleren kontrollerer disse variablene, kan han redusere oppstartstiden. Men på den annen side kan ikke utvikleren kontrollere oppstartstiden for containeren - alt avhenger av leverandøren.
En kaldstart kan bli til en varmstart når en funksjon gjenbruker en beholder lansert av en tidligere hendelse. Denne situasjonen vil oppstå i tre tilfeller:
- hvis klienter ofte bruker tjenesten og antallet anrop til funksjonen øker;
- hvis leverandøren, plattformen eller rammeverket lar deg holde noen containere i gang hele tiden;
- hvis utvikleren kjører funksjoner på en timer (si hvert tredje minutt).
For mange bruksområder er kaldstart ikke noe problem. Her må du bygge på typen og oppgavene til tjenesten. En startforsinkelse på et sekund er ikke alltid kritisk for en forretningsapplikasjon, men den kan bli kritisk for medisinske tjenester. I dette tilfellet vil den serverløse tilnærmingen sannsynligvis ikke lenger være egnet.
Den neste ulempen med Serverless er den korte levetiden til en funksjon (tidsavbrudd hvor funksjonen må utføres).
Men hvis du må jobbe med langvarige oppgaver, kan du bruke en hybridarkitektur – kombinere Serverless med en annen teknologi.
Ikke alle systemer vil kunne fungere ved å bruke Serverless-ordningen.
Noen applikasjoner vil fortsatt lagre data og tilstand under kjøring. Noen arkitekturer vil forbli monolitiske og noen funksjoner vil være langvarige. Imidlertid (som skyteknologier og deretter containere), er Serverless en teknologi med en stor fremtid.
På denne måten vil jeg gjerne gå videre til spørsmålet om bruk av serverløs tilnærming.
Fra søknadssiden
For 2018, prosentandelen av serverløs bruk . Blant selskapene som allerede har implementert teknologien i sine tjenester er slike markedsgiganter som Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samtidig må du forstå at Serverless ikke er et universalmiddel, men et verktøy for å løse en viss rekke problemer:
- Reduser nedetid for ressursene. Det er ikke nødvendig å hele tiden ha en virtuell maskin for tjenester som har få samtaler.
- Behandle data på farten. Komprimer bilder, klipp ut bakgrunner, endre videokoding, arbeid med IoT-sensorer, utfør matematiske operasjoner.
- "Lim" andre tjenester sammen. Git repository med interne programmer, chat bot i Slack med Jira og kalender.
- Balanser belastningen. La oss se nærmere her.
La oss si at det er en tjeneste som tiltrekker seg 50 personer. Under den er det en virtuell maskin med svak maskinvare. Fra tid til annen øker belastningen på tjenesten betydelig. Da klarer ikke svak maskinvare.
Du kan inkludere en balanserer i systemet som vil fordele lasten, for eksempel, over tre virtuelle maskiner. På dette stadiet kan vi ikke forutsi belastningen nøyaktig, så vi holder en viss mengde ressurser «i reserve». Og vi betaler for mye for nedetid.
I en slik situasjon kan vi optimere systemet gjennom en hybrid tilnærming: vi legger igjen én virtuell maskin bak lastbalanseren og legger en lenke til det serverløse endepunktet med funksjoner. Hvis belastningen overskrider terskelen, starter balansereren funksjonsinstanser som tar over deler av forespørselsbehandlingen.
Dermed kan Serverless brukes der det er nødvendig å behandle et stort antall forespørsler ikke for ofte, men intensivt. I dette tilfellet er det mer lønnsomt å kjøre flere funksjoner i 15 minutter enn å opprettholde en virtuell maskin eller server hele tiden.
Med alle fordelene med serverløs databehandling, før implementering, bør du først evaluere applikasjonslogikken og forstå hvilke problemer Serverless kan løse i et bestemt tilfelle.
Serverløs og Selectel
Hos Selectel er vi allerede via vårt kontrollpanel. Nå bygger vi vår egen FaaS-plattform. Vi ønsker at utviklere skal kunne løse problemene sine ved å bruke Serverless gjennom et praktisk, fleksibelt grensesnitt.
Hvis du har ideer om hva den ideelle FaaS-plattformen bør være og hvordan du vil bruke Serverless i prosjektene dine, del dem i kommentarfeltet. Vi vil ta hensyn til dine ønsker når vi utvikler plattformen.
Materialer brukt i artikkelen:
Kilde: www.habr.com