{"id":33935,"date":"2019-10-31T21:55:27","date_gmt":"2019-10-31T18:55:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/serverless-po-stoechkam\/"},"modified":"2019-10-31T21:55:27","modified_gmt":"2019-10-31T18:55:27","slug":"serverless-po-stoechkam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless i rackene","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless \u2015 det handlar ikke om fysisk frav\u00e6r av servere. Det er ikke en \u00abmorder\u00bb av containere og ikke en forbig\u00e5ende trend. Det er en ny tiln\u00e6rming til systembygging i skyen. I dagens artikkel skal vi ber\u00f8re arkitekturen til Serverless-applikasjoner, se hvilken rolle Serverless-tjenesteleverand\u00f8ren spiller og open-source prosjekter. Til slutt vil vi snakke om bruken av Serverless.
\n<\/a><\/noindex>
\nJeg vil skrive serverdelen av en applikasjon (til og med en nettbutikk). Det kan v\u00e6re en chat, en tjeneste for publisering av innhold, eller en lastbalanserer. Uansett vil det bli en del hodebry: jeg m\u00e5 forberede infrastrukturen, definere avhengigheter til applikasjonen, tenke p\u00e5 operativsystemet til vertsmaskinen. S\u00e5 m\u00e5 jeg oppdatere sm\u00e5 komponenter som ikke p\u00e5virker resten av monolitten. Og vi skal ikke glemme om skalering under belastning.<\/p>\n

Hva om vi tar ephemeral containere, hvor n\u00f8dvendige avhengigheter allerede er forh\u00e5ndsinstallert, og der disse containerne er isolert fra hverandre og fra vertssystemet? Vi kan dele monolitten opp i mikrotjenester, hvor hver kan oppdateres og skaleres uavhengig av de andre. Ved \u00e5 plassere koden i en slik container, kan jeg kj\u00f8re den p\u00e5 hvilken som helst infrastruktur. Det ser allerede bedre ut. <\/p>\n

Men hvis jeg ikke \u00f8nsker \u00e5 konfigurere containere? Jeg \u00f8nsker ikke \u00e5 tenke p\u00e5 skalering av applikasjonen. Jeg vil ikke betale for stillest\u00e5ende containere n\u00e5r belastningen p\u00e5 tjenesten er minimal. Jeg \u00f8nsker \u00e5 skrive kode. Fokuser p\u00e5 forretningslogikken og lansere produkter p\u00e5 markedet med lysets hastighet. <\/p>\n

Disse tankene f\u00f8rte meg til serverl\u00f8se beregninger. Serverless i dette tilfellet betyr ikke fysisk frav\u00e6r av servere, men frav\u00e6r av hodebry med \u00e5 administrere infrastrukturen.<\/em><\/p>\n

Ideen er at logikken til applikasjonen brytes ned i uavhengige funksjoner. De har en hendelsesstruktur. Hver av funksjonene utf\u00f8rer en \u00abmikrooppgave\u00bb. Alt som kreves fra utvikleren er \u00e5 laste opp funksjoner til den konsollen som tilbys av skyleverand\u00f8ren og knytte dem til hendelseskilder. Koden vil bli kj\u00f8rt p\u00e5 foresp\u00f8rsel i en automatisk tilberedt container, og jeg betaler bare for kj\u00f8retiden. <\/p>\n

La oss se p\u00e5 hvordan utviklingsprosessen for applikasjonen n\u00e5 vil se ut.<\/p>\n

Fra utviklerens side<\/h2>\n

\nTidligere begynte vi \u00e5 snakke om applikasjonen for nettbutikken. I den tradisjonelle tiln\u00e6rmingen utf\u00f8rer en monolitisk applikasjon hovedlogikken i systemet. Serveren med applikasjonen kj\u00f8rer hele tiden, selv n\u00e5r det ikke er noen belastning.<\/p>\n

For \u00e5 g\u00e5 over til serverless, deler vi applikasjonen opp i mikrooppgaver.<\/strong> For hver av dem skriver vi v\u00e5r egen funksjon. Funksjonene er uavhengige av hverandre og lagrer ikke statusinformasjon (stateless). De kan til og med v\u00e6re skrevet p\u00e5 forskjellige spr\u00e5k. Hvis en av dem \"feiler\", stopper ikke applikasjonen helt opp. Arkitekturen til applikasjonen vil se slik ut:<\/p>\n

\"Serverless
\nDelingen i funksjoner i Serverless ligner arbeidet med mikrotjenester. Men en mikrotjeneste kan utf\u00f8re flere oppgaver, mens en funksjon i ideelt fall b\u00f8r utf\u00f8re \u00e9n. La oss anta at det er oppgaven \u00e5 samle statistikk og vise den p\u00e5 foresp\u00f8rsel fra brukeren. I den mikrotjenestebaserte tiln\u00e6rmingen utf\u00f8rer \u00e9n tjeneste oppgaven med to inngangspunkter: for skriving og for lesing. I serverless computing vil dette v\u00e6re to forskjellige funksjoner, som ikke er koblet sammen. Utvikleren sparer beregningsressurser hvis, for eksempel, statistikken oppdateres oftere enn den lastes ned. <\/p>\n

Serverless-funksjoner m\u00e5 utf\u00f8res innenfor en kort tidsramme (timeout) som bestemmes av tjenesteleverand\u00f8ren. For eksempel er timeout for AWS 15 minutter. Det betyr at langvarige funksjoner m\u00e5 endres i henhold til kravene \u2013 dette er hva som skiller Serverless fra andre popul\u00e6re teknologier i dag (containere og Platform as a Service).<\/p>\n

Vi tildeler hvert funksjon et hendelse.<\/strong> En hendelse er et trigger for handling:<\/p>\n

Hendelse<\/strong>
\nHandling som funksjonen utf\u00f8rer<\/strong><\/p>\n

Et bilde av produktet er lastet opp til lagringen
\nKomprimere bildet og laste det opp til katalogen<\/p>\n

Adressen til den fysiske butikken har blitt oppdatert i databasen
\nLaste det nye stedet inn i kartene<\/p>\n

Kunden betaler for varen
\nStarte betalingsbehandlingen<\/p>\n

Hendelser kan v\u00e6re HTTP-foresp\u00f8rsler, str\u00f8mmer av data, meldingsk\u00f8er og s\u00e5 videre. Kilder til hendelser er endringen eller opprettelsen av data. I tillegg kan funksjoner kj\u00f8res p\u00e5 timer.<\/p>\n

Arkitekturen er utviklet, og applikasjonen har nesten blitt serverless. N\u00e5 g\u00e5r vi videre til tjenesteleverand\u00f8ren.<\/p>\n

Fra leverand\u00f8rens side<\/h2>\n

\nVanligvis tilbys serverless computing av leverand\u00f8rer av skyl\u00f8sninger. De kalles forskjellige ting: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

Vi vil bruke tjenesten gjennom konsollen eller kundesenteret til leverand\u00f8ren. Funksjonskoden kan lastes opp p\u00e5 en av f\u00f8lgende m\u00e5ter:<\/p>\n