Share
Serverless computing-konseptet er en opptatt kjøringsmodell som forsøker å imøtekomme behovene til moderne, skybasert programvare.
I denne videoen fra kurset mitt, Introduksjon til Serverless, vil jeg introdusere deg til den serverløse arkitekturen. Vi snakker om sine sentrale punkter og sammenligner den med andre modeller for abstrahering av serverfunksjonalitet til skyen.
Først av alt, i et serverfritt system, er det servere. Forhåpentligvis er det ikke en stor overraskelse for deg. Det handler om hvem som styrer dem.
La oss se på et veldig vanlig diagram som viser ulike typer tjenester.
Til venstre har du ditt tradisjonelle lokalsystem. Alt styres av deg, helt ned til den fysiske maskinen og nettverket. Da har du forskjellige nivåer av abstraksjon.
Det første nivået av abstraksjon er infrastruktur som en tjeneste. Her er du ansvarlig for alt fra operativsystemet opp. Eksempler ville være DigitalOcean eller Amazons EC2. Leverandøren bestemmer en forekomst for deg, og fra det tidspunktet er du alene.
Det neste laget av abstraksjon er container som en tjeneste. Det er også en ganske ny spiller som har mye traksjon på grunn av populariteten til Docker. I en AWS-verden vil dette være EC2 Container Services.
Da har vi plattform som en tjeneste, der du ikke er ansvarlig for å administrere operativsystem eller containere. Du er eneansvarlig for søknaden din. Fremtredende eksempler fra denne kategorien er Heroku, AWS Elastic Beanstalk og Google Compute Engine.
Noen år tilbake, ville grafikken være avsluttet her. Men i dag har vi en ny terminologi, det vil si fungere som en tjeneste. I stedet for å kjøre et program som har status, som er sant for alle tradisjonelle webrammer, selv om du bruker REST og andre ting, har du et system som bruker statløse beholdere som er utløste, ephemeral og fullstendig administrert av tjenesten forsørger.
Dette er det som kalles serverless. Det er et annet konsept som kalles back end som en tjeneste som noen ganger også betraktes som en del av serverens arkitektur. Men etter min mening hører det mer til programvare som en tjeneste, som egentlig er det du prøver å bygge.
Så la oss snakke mer om funksjoner som en tjeneste.
Som navnet antyder, er du som utvikler ansvarlig for å skrive utførbare funksjoner som utløses og utføres av hendelser. Dette kan være en ferdig filopplasting til S3 eller en forespørsel gjennom et API-endepunkt. Så langt, så enkelt. For å fullstendig forstå konseptet, skjønner jeg imidlertid om noen viktige områder som definerer funksjoner som en tjeneste.
Den første er staten. Funksjonene er svært begrenset når det gjelder å bevare tilstanden. Generelt bør du anta at du ikke kan gjøre det i det hele tatt. Funksjoner følger mer av et brann og glemme prinsipp. Hvis du vil lagre noe, gjør du det med en ekstern tjeneste, for eksempel fillagring eller en database eller hurtigbuffer server.
Den andre er utførelsesvarighet. Du kan ha et serverprogram som kjører i timer eller dager uten å starte på nytt, avhengig av distribusjonsprosessen. Det samme gjelder for bakgrunnsbehandling. Med funksjoner er kjøretiden begrenset. Det forventes ikke at funksjonen utføres i mer enn noen få sekunder, og AWS Lambda avslutter for eksempel hver funksjon som ikke har gått i gang etter fem minutter. Hvis du har en veldig langvarig oppgave, fungerer det som en tjeneste kanskje ikke passer best.
Da har vi oppstartslatelse. Dette kan være alt mellom noen få millisekunder og minutter. Selvfølgelig avhenger dette av språket og systemet du bruker. Vanligvis starter en Python- eller JavaScript-funksjon på AWS innen millisekunder, men hvis du bruker Java Virtual Machine, kan det ta litt tid før maskinen er spunnet opp - spesielt hvis funksjonen din ikke har blitt utført i løpet av de siste ti minuttene, eller du opplever en plutselig økning i utførelsen.
Dette fører til spørsmål om skalerbarhet og utførelseskostnad, og svaret du leter etter er: ikke bekymre deg for det. Skalering styres av tjenesteleverandøren, og kostnaden er enkel.
Hvis du utfører en funksjon ti ganger, betaler du for nøyaktig disse ti innkallingene. Hvis du kjører 1000 ganger, betaler du for 1000. Det er litt mer komplisert enn det selvfølgelig, men det er kjennetegnet av det.
Å ha et serverløst system kan være svært fordelaktig. Det er flott hvis du har inkonsekvent trafikk, for eksempel en spike på toppen av timen, eller svært få sporadiske forespørsler, da du ikke trenger å allokere ressurser som er inaktiv mesteparten av tiden.
For å samle, serverløse systemer har servere, men de er helt administrert av cloud-leverandører. Funksjoner er kjernen i en serverløs arkitektur, og de utføres ved hjelp av utløsere. Skalering og høy tilgjengelighet er allerede tatt vare på av sky-leverandørene. Hvis du har svært sporadisk etterspørsel, eller et stort, men kort søk, hjelper serverløs deg til å holde kostnadene nede.
I hele kurset, Introduksjon til Serverless, viser jeg deg hvordan du bruker Amazon Web Services til å lage en "serverløs" webapp, komplett med en REST API-backend. Du vil også se hvordan du skal håndtere noen avanserte scenarier som å integrere andre AWS-tjenester og orkestrerende tilstandsbeviste funksjoner. Underveis vil du bygge en kul webtjeneste for å konvertere tekst til tale.
Du kan ta dette kurset med en gang med et abonnement på Envato Elements. For en enkelt månedlig avgift får du tilgang ikke bare til dette kurset, men også til vårt voksende bibliotek med over 1000 videokurser og bransjeledende e-bøker på Envato Tuts+.
I tillegg får du ubegrensede nedlastinger fra det store Envato Elements-biblioteket med 400 000 kreative eiendeler. Lag med unike skrifttyper, bilder, grafikk og maler, og lever bedre bedre prosjekter raskere.
Accentsconagua