Centrale punkter
- I flere år nu er vi blevet lovet, at serverløs computing (serverløs) vil åbne en ny æra uden et specifikt OS til at køre applikationer. Vi fik at vide, at en sådan struktur ville løse en masse skalerbarhedsproblemer. Faktisk er alt anderledes.
- Mens mange ser serverløs teknologi som en ny idé, kan dens rødder spores tilbage til 2006 med Zimki PaaS og Google App Engine, som begge bruger en serverløs arkitektur.
- Der er fire grunde til, at den serverløse revolution er gået i stå, fra begrænset programmeringssprogunderstøttelse til ydeevneproblemer.
- Serverløs computing er ikke så ubrugelig. Langt fra. De skal dog ikke ses som en direkte erstatning for servere. Til nogle applikationer kan de være et praktisk værktøj.
Serveren er død, længe leve serveren!
Dette er kampråbet fra tilhængerne af den serverløse revolution. Et hurtigt blik på branchepressen gennem de sidste par år er nok til at konkludere, at den traditionelle servermodel er død, og at vi om få år alle vil bruge serverløse arkitekturer.
Som alle i branchen ved, og som vi også påpegede i vores artikel om , det er forkert. Trods mange artikler om meritter , det fandt aldrig sted. Faktisk, at denne revolution kan være nået en blindgyde.
Nogle af løfterne for serverløse modeller er helt sikkert gået i opfyldelse, men ikke alle. Ikke alle.
I denne artikel vil jeg overveje årsagerne til denne tilstand. Hvorfor manglen på fleksibilitet af serverløse modeller stadig er en hindring for deres bredere anvendelse, selvom de forbliver nyttige under specifikke, veldefinerede omstændigheder.
Hvad eksperterne inden for serverløs computing lovede
Før vi går videre til problemerne med serverløs computing, lad os se, hvad de havde at levere. var mange og - til tider - meget ambitiøse.
For dem, der ikke kender begrebet, er her en kort definition. Serverløs computing definerer en arkitektur, hvor applikationer (eller dele af applikationer) kører efter behov i runtime-miljøer, der typisk hostes eksternt. Derudover kan serverløse systemer hostes. Opbygning af robuste serverløse systemer har været en stor bekymring for systemadministratorer og SaaS-virksomheder i løbet af de sidste par år, da (det hævdes) denne arkitektur tilbyder flere vigtige fordele i forhold til den "traditionelle" klient/server-model:
- Serverløse modeller kræver ikke, at brugerne vedligeholder deres egne operativsystemer eller endda bygger applikationer, der er kompatible med specifikke operativsystemer. I stedet opretter udviklere delt kode, uploader den til en serverløs platform og ser den køre.
- Ressourcer i serverløse rammer faktureres normalt pr. minut (eller endda sekunder). Det betyder, at kunder kun betaler for den tid, de rent faktisk udfører koden. Dette kan sammenlignes med den traditionelle cloud-VM, hvor maskinen er inaktiv det meste af tiden, men du skal betale for det.
- Problemet med skalerbarhed blev også løst. Ressourcer i serverløse frameworks tildeles dynamisk, så systemet nemt kan klare pludselige stigninger i efterspørgslen.
Kort sagt giver serverløse modeller fleksible, billige, skalerbare løsninger. Jeg er overrasket over, at vi ikke tænkte på denne idé tidligere.
Er dette virkelig en ny idé?
Faktisk er ideen ikke ny. Konceptet med at tillade brugere kun at betale for den tid, koden faktisk kører, har eksisteret siden den blev introduceret under i 2006, og omkring samme tid kom Google App Engine med en meget lignende løsning.
Faktisk er det, vi nu kalder den "serverløse" model, ældre end mange af de teknologier, der nu kaldes "cloud native", der giver næsten det samme. Som nævnt er serverløse modeller i det væsentlige blot en udvidelse af SaaS-forretningsmodellen, der har eksisteret i årtier.
Det er også værd at erkende, at den serverløse model ikke er en FaaS-arkitektur, selvom der er en sammenhæng mellem de to. FaaS er i bund og grund den computercentrerede del af en serverløs arkitektur, men det repræsenterer ikke hele systemet.
Så hvorfor al denne hype? Nå, efterhånden som hastigheden af internetpenetration i udviklingslande fortsætter med at stige, stiger efterspørgslen efter computerressourcer også. For eksempel har mange lande med hurtigt voksende e-handelssektorer simpelthen ikke computerinfrastrukturen til applikationer på disse platforme. Det er her betalte serverløse platforme kommer ind.
Problemer med serverløse modeller
Fangsten er, at serverløse modeller har... problemer. Misforstå mig ikke: Jeg siger ikke, at de er dårlige i sig selv eller ikke giver betydelig værdi til nogle virksomheder under nogle omstændigheder. Men hovedpåstanden fra "revolutionen" - at den serverløse arkitektur hurtigt vil erstatte den traditionelle - bliver aldrig til noget.
Derfor.
Begrænset understøttelse af programmeringssprog
De fleste serverløse platforme tillader kun applikationer skrevet på bestemte sprog at køre. Dette begrænser i høj grad disse systemers fleksibilitet og tilpasningsevne.
Serverløse platforme anses for at understøtte de fleste større sprog. AWS Lambda- og Azure-funktioner giver også en indpakning til at køre applikationer og funktioner på ikke-understøttede sprog, selvom dette ofte koster en ydeevne. Så for de fleste organisationer er denne begrænsning normalt ikke en stor sag. Men her er sagen. En af fordelene ved serverløse modeller skulle være, at obskure, sjældent brugte programmer kan bruges billigere, fordi du kun betaler for den tid, de kører. Og obskure, sjældent brugte programmer er ofte skrevet i... obskure, sjældent brugte programmeringssprog.
Dette underminerer en af de vigtigste fordele ved den serverløse model.
Binding til en leverandør
Det andet problem med serverløse platforme, eller i det mindste den måde, de er implementeret på i øjeblikket, er, at de normalt ikke ligner hinanden på det operationelle niveau. Der er praktisk talt ingen standardisering med hensyn til skrivefunktioner, implementering og styring. Det betyder, at migrering af funktioner fra en platform til en anden er ekstremt tidskrævende.
Den sværeste del af at flytte til en serverløs model er ikke de beregningsmæssige funktioner, som normalt kun er kodestykker, men hvordan applikationer kommunikerer med forbundne systemer såsom objektlagring, identitetsstyring og køer. Funktioner kan flyttes, men resten af applikationen kan ikke. Dette er det stik modsatte af de lovede billige og fleksible platforme.
Nogle hævder, at serverløse modeller er nye, og at der ikke har været tid til at standardisere, hvordan de fungerer. Men de er ikke så nye, som jeg bemærkede ovenfor, og mange andre cloud-teknologier såsom containere er allerede blevet meget mere bekvemme på grund af udviklingen og den udbredte vedtagelse af gode standarder.
Ydelse
Databehandlingsydelse på serverløse platforme er svær at måle, blandt andet fordi leverandører har en tendens til at holde information hemmelig. De fleste hævder, at funktioner på eksterne, serverløse platforme kører lige så hurtigt, som de gør på interne servere, bortset fra nogle få uundgåelige latency-problemer.
Individuelle fakta indikerer dog det modsatte. Funktioner, der ikke tidligere har kørt på en bestemt platform eller ikke har kørt i nogen tid, vil tage noget tid at initialisere. Dette skyldes sandsynligvis det faktum, at deres kode er blevet porteret til et mindre tilgængeligt lagermedie, selvom - som med benchmarks - de fleste leverandører ikke vil fortælle dig om datamigreringen.
Der er selvfølgelig flere måder at komme uden om dette. Den ene er at optimere funktioner til hvilket cloud-sprog din serverløse platform kører på, men det underminerer noget påstanden om, at disse platforme er "agile".
En anden tilgang er at sikre, at præstationskritiske programmer kører regelmæssigt for at holde dem "friske". Denne anden tilgang er selvfølgelig lidt i modstrid med påstanden om, at serverløse platforme er mere omkostningseffektive, fordi du kun betaler for den tid, dine programmer kører. Cloud-udbydere har introduceret nye måder at reducere kolde lanceringer på, men mange af dem kræver "skalering til én", hvilket underminerer den oprindelige værdi af FaaS.
Koldstartsproblemet kan delvist løses ved at køre serverløse systemer internt, men dette kommer for egen regning og forbliver en nichemulighed for teams med gode ressourcer.
Du kan ikke køre hele applikationer
Endelig er den måske vigtigste grund til, at serverløse arkitekturer ikke vil erstatte traditionelle modeller i den nærmeste fremtid, at de (generelt) ikke kan køre hele applikationer.
Mere præcist er det upraktisk ud fra et omkostningssynspunkt. Din succesfulde monolit burde sandsynligvis ikke omdannes til et sæt på fire dusin funktioner, der er bundet sammen af otte gateways, fyrre køer og et dusin databaseforekomster. Af denne grund er serverløs bedre egnet til nye udviklinger. Stort set ingen eksisterende applikation (arkitektur) kan porteres. Du kan migrere, men du skal starte fra bunden.
Det betyder, at i langt de fleste tilfælde bruges serverløse platforme som et supplement til back-end-servere til at udføre beregningsintensive opgaver. Dette er meget forskelligt fra de to andre former for cloud computing, containere og virtuelle maskiner, som tilbyder en holistisk måde at udføre remote computing på. Dette illustrerer en af udfordringerne ved at migrere fra mikrotjenester til serverløse systemer.
Det er selvfølgelig ikke altid et problem. Evnen til periodisk at bruge enorme computerressourcer uden at købe din egen hardware kan give reelle og varige fordele for mange organisationer. Men hvis nogle applikationer er på interne servere, og andre er på serverløse cloud-arkitekturer, så går ledelsen ind på et nyt kompleksitetsniveau.
Længe leve revolutionen?
På trods af alle disse klager er jeg ikke modstander af serverløse løsninger i sig selv. Ærligt talt. Det er bare, at udviklere skal forstå - især hvis de udforsker serverløse modeller for første gang - at denne teknologi ikke er en direkte erstatning for servere. Tjek i stedet vores tips og ressourcer vedr og beslutte, hvordan man bedst anvender denne model.
Kilde: www.habr.com