Serverløs computing - Serverless computing

Serverløs computing er en cloud computing -udførelsesmodel, hvor cloud -udbyderen tildeler maskinressourcer efter behov og tager sig af serverne på vegne af deres kunder. Serverløs computing rummer ikke ressourcer i flygtig hukommelse; computing udføres snarere i korte bursts med resultaterne vedvarende til opbevaring. Når en app ikke er i brug, er der ingen computerressourcer tildelt til appen. Prissætningen er baseret på den faktiske mængde ressourcer, der forbruges af en applikation. Det kan være en form for nytte -computing . "Serverless" er en forkert betegnelse i den forstand, at servere stadig bruges af cloudtjenesteudbydere til at eksekvere kode til udviklere. Udviklere af serverløse applikationer er imidlertid ikke bekymrede over kapacitetsplanlægning , konfiguration, styring, vedligeholdelse, fejltolerance eller skalering af containere, VM'er eller fysiske servere.

Serverløs computing kan forenkle processen med at implementere kode i produktionen. Serverløs kode kan bruges i forbindelse med kode implementeret i traditionelle stilarter, f.eks. Mikrotjenester eller monolit . Alternativt kan applikationer skrives til at være rent serverløse og slet ikke bruge nogen servere. Dette bør ikke forveksles med computere eller netværksmodeller, der ikke kræver, at en egentlig server fungerer, f.eks. Peer-to-peer (P2P).

Serverløse driftstider

Serverløse leverandører tilbyder computerkørselstider, også kendt som FaaS -platforme ( Function as a Service ), som udfører applikationslogik, men ikke gemmer data. Almindelige sprog, der understøttes af serverløse runtimes, er Java , Python og PHP . Generelt kører funktionerne under isolationsgrænser, såsom Linux -containere .

Kommercielle tilbud

Den første "pay as you go" kodeudførelsesplatform var Zimki, der blev udgivet i 2006, men den blev ikke kommercielt vellykket. I 2008 udgav Google Google App Engine , som indeholdt måleregning for applikationer, der brugte en tilpasset Python -ramme, men ikke kunne udføre vilkårlig kode. PiCloud, udgivet i 2010, tilbød FaaS -understøttelse af Python.

Kubeless og Fission er to Open Source FaaS -platforme, der kører med Kubernetes .

Google App Engine, der blev introduceret i 2008, var det første abstrakte serverløse computertilbud. App Engine inkluderede HTTP-funktioner med en 60-sekunders timeout og en blob-butik og datalagring med deres egne timeouts. Ingen i-hukommelse persistens var tilladt. Alle operationer skulle udføres inden for disse grænser, men dette tillod apps indbygget i App Engine at skalere næsten uendeligt og blev brugt til at støtte tidlige kunder, herunder Snapchat , samt mange eksterne og interne Google-apps. Sprogsupport var begrænset til Python ved hjælp af native Python -moduler samt et begrænset udvalg af Python -moduler i C, der blev valgt af Google. Ligesom senere serverløse platforme brugte App Engine også betaling for hvad du bruger fakturering.

AWS Lambda , introduceret af Amazon i 2014, populariserede den abstrakte serverløse computermodel. Det understøttes af en række yderligere AWS serverløse værktøjer såsom AWS Serverless Application Model (AWS SAM) Amazon CloudWatch og andre.

Google Cloud Platform oprettede et andet serverløst tilbud, Google Cloud Functions i 2016.

IBM tilbyder IBM Cloud -funktioner i den offentlige IBM Cloud siden 2016. IBM tilføjede et andet serverløst tilbud, IBM Cloud Code Engine, i 2021.

Microsoft Azure tilbyder Azure-funktioner, der tilbydes både i den offentlige Azure-sky eller lokalt via Azure Stack.

Cloudflare tilbyder Cloudflare Workers siden 2017.

Hurtigt tilbyder Compute@Edge, siden 2019.

Serverløse databaser

Flere serverløse databaser er opstået i de sidste par år. Disse systemer udvider den serverløse udførelsesmodel til RDBMS , hvilket eliminerer behovet for at tilvejebringe eller skalere virtualiseret eller fysisk databasehardware.

Nutanix tilbyder en løsning ved navn Era, der gør et eksisterende RDBMS som Oracle , MariaDB , PostgreSQL eller Microsoft SQL Server til en serverløs service.

Amazon Aurora tilbyder en serverløs version af sine databaser, baseret på MySQL og PostgreSQL, der tilbyder on-demand, automatisk skaleringskonfigurationer.

Azure Data Lake er en meget skalerbar datalagring og analysetjeneste. Tjenesten hostes i Azure , Microsofts offentlige sky. Azure Data Lake Analytics giver en distribueret infrastruktur, der dynamisk kan allokere eller affordele ressourcer, så kunderne kun betaler for de tjenester, de bruger.

Firebase , der også ejes af Google, indeholder en hierarkisk database og er tilgængelig via faste og pay-as-you-go-planer.

Confluent , giver en serverløs implementering af Apache Kafka (et event-streaming- og lagringssystem) på tværs af de tre store cloud-tjenester, som abstraherer infrastruktur, er betaling for brug og autoskalaer.

Fordele

Koste

Serverless kan være mere omkostningseffektivt end at leje eller købe en fast mængde servere, hvilket generelt indebærer betydelige perioder med underudnyttelse eller inaktiv tid. Det kan endda være mere omkostningseffektivt end at tilvejebringe en autoskaleringsgruppe på grund af mere effektiv emballering af de underliggende maskinressourcer.

Dette kan beskrives som pay-as-you-go computing eller bare-kode, da du kun bliver opkrævet baseret på den tid og hukommelse, der er tildelt til at køre din kode; uden tilhørende gebyrer for ledig tid.

Umiddelbare omkostningsfordele er relateret til manglen på driftsomkostninger, herunder: licenser, installation, afhængigheder og personaleomkostninger til vedligeholdelse, support eller patching. Manglen på personaleomkostninger er en fordel, der i vid udstrækning gælder cloud computing.

Elasticitet kontra skalerbarhed

Se også: Skalerbarhed og elasticitet (cloud computing)

Derudover betyder en serverløs arkitektur, at udviklere og operatører ikke behøver at bruge tid på at oprette og indstille politikker eller systemer til autoskaling; cloud -udbyderen er ansvarlig for at skalere kapaciteten til efterspørgslen. Som Google udtrykker det: "fra prototype til produktion til planetskala."

Da cloud -native systemer i sig selv skalerer såvel som op, er disse systemer kendt som elastiske frem for skalerbare.

Små teams af udviklere er i stand til selv at køre kode uden afhængighed af teams af infrastruktur og supportingeniører; flere udviklere bliver DevOps dygtige, og forskellene mellem at være softwareudvikler eller hardwareingeniør udvisker.

Produktivitet

Med funktion som en service er kodeenhederne udsat for omverdenen simple hændelsesdrevne funktioner . Det betyder, at programmøren typisk ikke behøver at bekymre sig om multithreading eller direkte håndtering af HTTP- anmodninger i deres kode, hvilket forenkler opgaven med back-end softwareudvikling.

Ulemper

Ydeevne

Sjældent brugt serverløs kode kan lide af større responslatens end kode, der løbende kører på en dedikeret server, virtuel maskine eller container. Dette skyldes, at cloud -udbyderen i modsætning til med autoskaling typisk "spinder" den serverløse kode fuldstændigt ned, når den ikke er i brug. Det betyder, at hvis runtime (f.eks. Java -runtime) kræver en betydelig mængde tid til at starte, vil det skabe yderligere ventetid.

Ressourcegrænser

Serverløs computing er ikke egnet til nogle computerarbejde, f.eks. Højtydende computing , på grund af de ressourcegrænser, cloud-udbydere pålægger, og også fordi det sandsynligvis ville være billigere at massetilføre det antal servere, der menes at være påkrævet på et givet tidspunkt tidspunkt.

Overvågning og fejlfinding

Diagnostisering af ydeevne eller overdrevne ressourceforbrugsproblemer med serverløs kode kan være vanskeligere end med traditionel serverkode, for selvom hele funktioner kan tidsbestemmes, er der typisk ingen mulighed for at grave mere i detaljer ved at vedhæfte profilere , debuggere eller APM -værktøjer. Desuden er det miljø, hvor koden kører, typisk ikke open source , så dens ydeevneegenskaber kan ikke præcist replikeres i et lokalt miljø .

Sikkerhed

Serverless betragtes undertiden fejlagtigt som mere sikkert end traditionelle arkitekturer. Selvom dette til en vis grad er sandt, fordi OS -sårbarheder bliver taget hånd om af skyudbyderen, er den samlede angrebsoverflade betydeligt større, da der er mange flere komponenter til applikationen sammenlignet med traditionelle arkitekturer, og hver komponent er et indgangspunkt til den serverløse applikation . Desuden bliver de sikkerhedsløsninger, som kunderne plejede at beskytte deres cloud -arbejdsbelastninger, irrelevante, da kunderne ikke kan kontrollere og installere noget på slutpunkt og netværksniveau , såsom et indbrudsdetekterings-/forebyggelsessystem (IDS/IPS).

Dette forstærkes af monokulturegenskaberne for hele servernetværket. (En enkelt fejl kan anvendes globalt.) Ifølge Protego er "løsningen til sikring af serverløse apps et tæt partnerskab mellem udviklere, DevOps og AppSec, også kendt som DevSecOps. Find den balance, hvor udviklere ikke ejer sikkerhed, men de er heller ikke fritaget for ansvar. Tag skridt til at gøre det til alles problem. Opret tværgående teams og arbejd mod en tæt integration mellem sikkerhedsspecialister og udviklingsteam. Samarbejd, så din organisation kan løse sikkerhedsrisici med serverless hastighed. "

Privatliv

Mange serverløse funktionsmiljøer er baseret på proprietære offentlige cloudmiljøer. Her skal nogle konsekvenser for fortrolighed overvejes, såsom delte ressourcer og adgang fra eksterne medarbejdere. Serverløs computing kan dog også udføres i private cloudmiljøer eller endda lokalt ved hjælp af f.eks. Kubernetes- platformen. Dette giver virksomheder fuld kontrol over fortrolighedsmekanismer, ligesom med hosting i traditionelle serveropsætninger.

Standarder

Serverløs computing er omfattet af International Data Center Authority (IDCA) i deres Framework AE360. Den del, der vedrører portabilitet, kan imidlertid være et problem, når forretningslogik flyttes fra en offentlig sky til en anden, som Docker -løsningen blev oprettet til. Cloud Native Computing Foundation (CNCF) arbejder også på at udvikle en specifikation med Oracle.

Leverandørlås

Serverløs computing leveres som en tredjepartstjeneste. Programmer og software, der kører i det serverløse miljø, er som standard låst til en bestemt skyleverandør. Derfor kan serverless forårsage flere problemer under migrering.

Se også

Referencer

Yderligere læsning