{"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\/da\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless i sm\u00e5 bidder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless betyder ikke fysisk frav\u00e6r af servere. Det er ikke en \"dr\u00e6ber\" til containere eller en kortvarig trend. Det er en ny tilgang til opbygning af systemer i skyen. I dagens artikel vil vi se p\u00e5 arkitekturen af Serverless-applikationer, overveje hvilken rolle Serverless-tjenesteudbyderen spiller, samt open-source projekter. I slutningen vil vi tale om anvendelsen af Serverless.
\n<\/a><\/noindex>
\nJeg \u00f8nsker at skrive backend-delen af en applikation (selv en online-butiks). Det kan v\u00e6re en chat, en service til publicering af indhold eller en belastningsbalancer. Uanset hvad vil der v\u00e6re en del hovedpine: jeg skal forberede infrastrukturen, definere afh\u00e6ngighederne af applikationen, t\u00e6nke over operativsystemet p\u00e5 v\u00e6rten. Derefter skal jeg opdatere sm\u00e5 komponenter, som ikke p\u00e5virker resten af monolitten. Og vi skal ikke glemme skalerbarheden under belastning.<\/p>\n

Hvad hvis jeg tager efemere containere, hvor de n\u00f8dvendige afh\u00e6ngigheder allerede er forudinstalleret, og hvor containerne er isolerede fra hinanden og fra v\u00e6rts-OS? Vi kan opdele monolitten i mikrotjenester, hver af dem kan opdateres og skaleres uafh\u00e6ngigt af de andre. Ved at placere koden i en s\u00e5dan container kan jeg k\u00f8re den p\u00e5 enhver infrastruktur. Det er allerede bedre. <\/p>\n

Og hvis man ikke \u00f8nsker at konfigurere containere? Ikke \u00f8nsker at t\u00e6nke p\u00e5 skalerbarhed af applikationen. Ikke \u00f8nsker at betale for inaktive startede containere, n\u00e5r belastningen p\u00e5 tjenesten er minimal. Man \u00f8nsker at skrive kode. Fokusere p\u00e5 forretningslogik og bringe produkter til markedet med lysens hastighed. <\/p>\n

Disse tanker f\u00f8rte mig til serverl\u00f8se beregninger. Serverless betyder i dette tilf\u00e6lde ikke fysisk frav\u00e6r af servere, men frav\u00e6r af hovedpine ved at administrere infrastrukturen.<\/em><\/p>\n

Ideen er, at applikationens logik opdeles i uafh\u00e6ngige funktioner. De har en begivenhedsbaseret struktur. Hver funktion udf\u00f8rer en \"mikroopgave\". Alt hvad der kr\u00e6ves af udvikleren er at uploade funktionerne i den cloud-udbyderens console og koble dem til begivenhedskilder. Koden vil blive k\u00f8rt ved anmodning i en automatisk forberedt container, og jeg betaler kun for k\u00f8rselstiden. <\/p>\n

Lad os finde ud af, hvordan udviklingsprocessen for applikationen nu vil se ud.<\/p>\n

Fra udviklerens side<\/h2>\n

\nTidligere begyndte vi at tale om applikationen til onlinebutikken. I den traditionelle tilgang udf\u00f8rer en monolitisk applikation hovedlogikken i systemet. Serveren med applikationen k\u00f8rer konstant, selv n\u00e5r der ikke er nogen belastning.<\/p>\n

For at overg\u00e5 til serverless opdeler vi applikationen i mikroupgaver.<\/strong> For hver enkelt skriver vi en funktion. Funktionerne er uafh\u00e6ngige af hinanden og gemmer ikke tilstand (stateless). De kan endda v\u00e6re skrevet i forskellige sprog. Hvis en af dem \"g\u00e5r ned\", stopper applikationen ikke helt. Applikationens arkitektur vil se s\u00e5dan ud:<\/p>\n

\"Serverless
\nOpdeling i funktioner i Serverless ligner arbejdet med mikrotjenester. Men en mikrotjeneste kan udf\u00f8re flere opgaver, mens en funktion ideelt set skal udf\u00f8re \u00e9n. Lad os forestille os, at opgaven er at indsamle statistik og pr\u00e6sentere den p\u00e5 anmodning fra brugeren. I den mikrotjeneste-baserede tilgang udf\u00f8rer \u00e9n tjeneste opgaven med to indgangspunkter: til skrivning og til l\u00e6sning. I serverless beregninger vil dette v\u00e6re to forskellige funktioner, der ikke er forbundet med hinanden. Udvikleren sparer beregningsressourcer, hvis for eksempel statistikken opdateres oftere, end den eksporteres. <\/p>\n

Serverless-funktioner skal udf\u00f8res inden for en kort tidsramme (timeout), som defineres af tjenesteudbyderen. For eksempel er timeout for AWS 15 minutter. Det betyder, at langvarige funktioner (long-lived) skal \u00e6ndres i henhold til kravene - dette adskiller Serverless fra andre popul\u00e6re teknologier i dag (containere og Platform as a Service).<\/p>\n

Vi tildeler et h\u00e6ndelse til hver funktion.<\/strong> En h\u00e6ndelse er en trigger for handling:<\/p>\n

Begivenhed<\/strong>
\nHandlingen, som funktionen udf\u00f8rer<\/strong><\/p>\n

Et billede af produktet er blevet uploadet til lageret
\nKompresser billedet og upload det til kataloget<\/p>\n

Adressen til den fysiske butik er blevet opdateret i databasen
\nIndl\u00e6s den nye placering p\u00e5 kortene<\/p>\n

Klienten betaler for varen
\nStart behandling af betalingen<\/p>\n

H\u00e6ndelser kan v\u00e6re HTTP-anmodninger, streamingdata, meddelelsesk\u00f8er osv. H\u00e6ndelseskilder er \u00e6ndringer eller tilf\u00f8jelser af data. Derudover kan funktioner startes p\u00e5 en timer.<\/p>\n

Arkitekturen er arbejdet igennem, og applikationen er n\u00e6sten blevet serverless. Vi g\u00e5r videre til tjenesteudbyderen.<\/p>\n

Fra tjenesteudgiverens side<\/h2>\n

\nNormalt tilbydes serverless beregninger af cloud-tjenesteudbydere. De kaldes forskellige: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

Vi vil bruge tjenesten gennem konsollen eller udbyderens brugerpanel. Funktionskoden kan uploades p\u00e5 en af f\u00f8lgende m\u00e5der:<\/p>\n