Serverløs databehandling - Serverless computing

Server computing er en cloud computing gjennomføringsmodell der skyen leverandøren allokerer maskinressurser ved behov, å ta vare på serverne på vegne av sine kunder. Serverløs databehandling har ikke ressurser i flyktig minne; databehandling er heller gjort i korte utbrudd med resultatene vedvarende til lagring. Når en app ikke er i bruk, er det ingen beregningsressurser tildelt appen. Prisen er basert på den faktiske mengden ressurser som brukes av en applikasjon. Det kan være en form for nytte -databehandling . "Serverless" er et misvisende navn i den forstand at servere fremdeles brukes av skytjenesteleverandører for å utføre kode for utviklere. Utviklere av serverløse applikasjoner er imidlertid ikke opptatt av kapasitetsplanlegging , konfigurasjon, administrasjon, vedlikehold, feiltoleranse eller skalering av containere, VM -er eller fysiske servere.

Serverløs databehandling kan forenkle prosessen med å distribuere kode til produksjon. Serverløs kode kan brukes i forbindelse med kode distribuert i tradisjonelle stiler, for eksempel mikrotjenester eller monolitter . Alternativt kan applikasjoner skrives for å være rent serverløse og ikke bruke serverer i det hele tatt. Dette bør ikke forveksles med databehandling eller nettverksmodeller som ikke krever at en faktisk server fungerer, for eksempel peer-to-peer (P2P).

Serverløse kjøretider

Serverløse leverandører tilbyr datakjøretider, også kjent som FaaS -plattformer ( Function as a Service ), som utfører applikasjonslogikk, men ikke lagrer data. Vanlige språk som støttes av serverløse kjøretider er Java , Python og PHP . Vanligvis kjører funksjonene under isolasjonsgrenser, for eksempel Linux -containere .

Kommersielle tilbud

Den første plattformen for "pay as you go" kode var Zimki, utgitt i 2006, men den var ikke kommersielt vellykket. I 2008 ga Google ut Google App Engine , som inneholdt måleregning for applikasjoner som brukte et tilpasset Python -rammeverk, men ikke kunne utføre vilkårlig kode. PiCloud, utgitt i 2010, tilbød FaaS -støtte for Python.

Kubeless og Fission er to Open Source FaaS -plattformer som kjøres med Kubernetes .

Google App Engine, introdusert i 2008, var det første abstrakte serverløse datatilbudet. App Engine inkluderte HTTP-funksjoner med en 60-sekunders timeout, og en blob-butikk og datalagring med egne tidsavbrudd. Ingen utholdenhet i minnet var tillatt. Alle operasjoner måtte utføres innenfor disse grensene, men dette tillot apper innebygd i App Engine å skalere nesten uendelig og ble brukt til å støtte tidlige kunder, inkludert Snapchat , samt mange eksterne og interne Google-apper. Språkstøtte var begrenset til Python ved hjelp av native Python -moduler, samt et begrenset utvalg av Python -moduler i C som ble valgt av Google. Som senere serverløse plattformer brukte App Engine også betaling for hva du bruker.

AWS Lambda , introdusert av Amazon i 2014, populariserte den abstrakte serverløse datamodellen. Det støttes av en rekke ekstra AWS serverløse verktøy som AWS Serverless Application Model (AWS SAM) Amazon CloudWatch og andre.

Google Cloud Platform opprettet et annet serverfritt tilbud, Google Cloud Functions i 2016.

IBM tilbyr IBM Cloud Functions i den offentlige IBM Cloud siden 2016. IBM la til et annet serverfritt tilbud, IBM Cloud Code Engine, i 2021.

Microsoft Azure tilbyr Azure Functions, som tilbys både i den offentlige Azure-skyen eller lokalt via Azure Stack.

Cloudflare tilbyr Cloudflare Workers, siden 2017.

Tilbyr Compute@Edge raskt , siden 2019.

Serverløse databaser

Flere serverløse databaser har dukket opp de siste årene. Disse systemene utvider den serverløse utførelsesmodellen til RDBMS , noe som eliminerer behovet for å skaffe eller skalere virtualisert eller fysisk databasemaskinvare.

Nutanix tilbyr en løsning som heter Era som gjør et eksisterende RDBMS som Oracle , MariaDB , PostgreSQL eller Microsoft SQL Server til en serverløs tjeneste.

Amazon Aurora tilbyr en serverløs versjon av sine databaser, basert på MySQL og PostgreSQL, og tilbyr on-demand, automatisk skaleringskonfigurasjoner.

Azure Data Lake er en svært skalerbar datalagring og analysetjeneste. Tjenesten er vert i Azure , Microsofts offentlige sky. Azure Data Lake Analytics gir en distribuert infrastruktur som dynamisk kan tildele eller fjerne allokering av ressurser slik at kundene betaler for bare tjenestene de bruker.

Firebase , også eid av Google, inkluderer en hierarkisk database og er tilgjengelig via faste og betal-etter-gå-planer.

Confluent gir en serverløs implementering av Apache Kafka (et hendelses-streaming- og lagringssystem) på tvers av de tre store nettskyene, som tar ut infrastruktur, er betaling for bruk og autoskalaer.

Fordeler

Koste

Serverless kan være mer kostnadseffektivt enn å leie eller kjøpe en fast mengde servere, som vanligvis innebærer betydelige perioder med underutnyttelse eller ledig tid. Det kan til og med være mer kostnadseffektivt enn å etablere en autoskaleringsgruppe , på grunn av mer effektiv emballasje av de underliggende maskinressursene.

Dette kan beskrives som pay-as-you-go-databehandling eller bare-kode, ettersom du belastes utelukkende basert på tiden og minnet som er tildelt for å kjøre koden; uten tilhørende avgifter for ledig tid.

Umiddelbare kostnadsfordeler er knyttet til mangel på driftskostnader, inkludert: lisenser, installasjon, avhengigheter og personalkostnader for vedlikehold, støtte eller oppdatering. Mangel på personellkostnad er en fordel som i stor grad gjelder cloud computing.

Elastisitet kontra skalerbarhet

Se også: Skalerbarhet og elastisitet (cloud computing)

I tillegg betyr en serverløs arkitektur at utviklere og operatører ikke trenger å bruke tid på å sette opp og justere retningslinjer eller systemer for autoskaling; skyleverandøren er ansvarlig for å skalere kapasiteten til etterspørselen. Som Google uttrykker det: "fra prototype til produksjon til planetskala."

Ettersom sky -native systemer iboende skalerer så vel som opp, er disse systemene kjent som elastiske i stedet for skalerbare.

Små team med utviklere er i stand til å kjøre kode selv uten avhengighet av team av infrastruktur og supportingeniører; flere utviklere blir DevOps dyktige og skillene mellom å være en programvareutvikler eller maskinvareingeniør blir uskarpe.

Produktivitet

Med funksjon som en tjeneste er kodeenhetene som er utsatt for omverdenen enkle hendelsesdrevne funksjoner . Dette betyr at programmereren vanligvis ikke trenger å bekymre seg for multithreading eller direkte håndtering av HTTP- forespørsler i koden, noe som forenkler oppgaven med back-end programvareutvikling.

Ulemper

Opptreden

Sjeldent brukte administrasjonsserver koden kan lide av større respons ventetid enn kode som er kontinuerlig løpende på en dedikert server, virtuell maskin eller beholder. Dette er fordi, i motsetning til med automatisk skalering, skyleverandøren vanligvis "spinner ned" den serverløse koden helt når den ikke er i bruk. Dette betyr at hvis kjøretiden (for eksempel Java -kjøretiden) krever betydelig tid for å starte opp, vil det skape ytterligere ventetid.

Ressursgrenser

Serverløs databehandling er ikke egnet for noen databehandlingsbelastninger, for eksempel høyytelsesdatamaskin , på grunn av ressursgrensene som skyleverandører pålegger, og også fordi det sannsynligvis vil være billigere å bulk-tilveiebringe antallet servere som antas å være nødvendig på et gitt tidspunkt tidspunkt.

Overvåking og feilsøking

Det kan være vanskeligere å diagnostisere ytelse eller overdreven ressursbruk med serverløs kode enn med tradisjonell serverkode, for selv om hele funksjoner kan tidsbestemmes, er det vanligvis ingen mulighet til å grave nærmere inn ved å legge ved profiler , debuggere eller APM -verktøy. Videre er miljøet som koden kjører vanligvis ikke åpen kildekode , så ytelsesegenskapene kan ikke nøyaktig replikeres i et lokalt miljø .

Sikkerhet

Serverless blir noen ganger feilaktig betraktet som sikrere enn tradisjonelle arkitekturer. Selv om dette til en viss grad er sant fordi OS -sårbarhetene blir ivaretatt av skyleverandøren, er den totale angrepsflaten betydelig større ettersom det er mange flere komponenter i programmet sammenlignet med tradisjonelle arkitekturer, og hver komponent er et inngangspunkt til den serverløse applikasjonen . Videre blir sikkerhetsløsningene kundene pleide å beskytte cloud -arbeidsmengden irrelevant, ettersom kundene ikke kan kontrollere og installere noe på endepunkt og nettverksnivå , for eksempel et system for inntrengingsdeteksjon/forebygging (IDS/IPS).

Dette forsterkes av monokulturegenskapene til hele servernettverket. (En enkelt feil kan brukes globalt.) Ifølge Protego er "løsningen for å sikre serverløse apper et nært partnerskap mellom utviklere, DevOps og AppSec, også kjent som DevSecOps. Finn balansen der utviklere ikke eier sikkerhet, men de er ikke frikjent fra ansvaret heller. Ta skritt for å gjøre det til et problem for alle. Lag tverrfunksjonelle team og arbeid mot en tett integrering mellom sikkerhetsspesialister og utviklingsteam. Samarbeid slik at organisasjonen din kan løse sikkerhetsrisikoen med serverless hastighet. "

Personvern

Mange serverløse funksjonsmiljøer er basert på proprietære offentlige skymiljøer. Her må noen personvernimplikasjoner vurderes, for eksempel delte ressurser og tilgang fra eksterne ansatte. Imidlertid kan serverløs databehandling også utføres på private skymiljøer eller til og med lokalt, ved for eksempel å bruke Kubernetes- plattformen. Dette gir bedrifter full kontroll over personvernmekanismer, akkurat som med hosting i tradisjonelle serveroppsett.

Standarder

Serverløs databehandling dekkes av International Data Center Authority (IDCA) i rammeverket AE360. Imidlertid kan delen knyttet til portabilitet være et problem når du flytter forretningslogikk fra en offentlig sky til en annen som Docker -løsningen ble opprettet for. Cloud Native Computing Foundation (CNCF) jobber også med å utvikle en spesifikasjon med Oracle.

Leverandørlås

Serverløs databehandling tilbys som en tredjepartstjeneste. Programmer og programvare som kjører i det serverløse miljøet er som standard låst til en bestemt skyleverandør. Derfor kan serverless forårsake flere problemer under overføringen.

Se også

Referanser

Videre lesning