Nøglepunkter
- I flere år har man lovet os, at serverløse beregninger (serverless) vil åbne en ny æra uden et specifikt operativsystem til at køre applikationer. Man har sagt, at en sådan struktur vil løse mange skalerbarhedsproblemer. I virkeligheden er det helt anderledes.
- Selvom mange betragter serverløs teknologi som en ny idé, kan dens rødder spores helt tilbage til 2006, da Zimki PaaS og Google App Engine dukkede op - i begge tilfælde anvendes en serverløs arkitektur.
- Der er fire grunde til, at den serverløse revolution er kørt fast: fra begrænset sprogunderstøttelse til præstationsproblemer.
- Serverløse beregninger er ikke så ubrugelige. Slet ikke. Men de bør ikke betragtes som en direkte erstatning for servere. For visse applikationer kan de være et praktisk værktøj.
Serveren er død, længe leve serveren!
Sådan lyder kamprop fra tilhængerne af den serverløse revolution. En hurtig gennemgang af branchepressen de seneste par år viser klart, at den traditionelle servermodel er død, og at vi om få år alle vil bruge serverløse arkitekturer.
Som enhver i branchen ved, og som vi også nævnte i vores artikel om , er det ikke tilfældet. På trods af adskillige artikler om fordelene ved , har den ikke helt manifesteret sig. Faktisk viser , at denne revolution muligvis er kørt fast.
Nogle af de lovede fordele ved serverløse modeller er uden tvivl blevet realiseret, men ikke alle. Langt fra alle.
I denne artikel vil jeg undersøge årsagerne til denne tilstand. Hvorfor er den manglende fleksibilitet i serverløse modeller stadig en hindring for deres bredere adoption, selvom de forbliver nyttige under specifikke, klart definerede omstændigheder.
Hvad tilhængerne af serverløse beregninger lovede
Før vi dykker ned i problemerne med serverløse beregninger, lad os se på, hvad de skulle have leveret. var talrige og - nogle gange - meget ambitiøse.
For those unfamiliar with the term, here is a brief definition. Serverless computing defines an architecture where applications (or parts of applications) run on demand in environments that are typically hosted remotely. Furthermore, serverless systems can also be hosted internally. Over the past few years, creating robust serverless systems has been a primary concern for system administrators and SaaS companies, as this architecture is said to offer several key advantages over the 'traditional' client-server model:
- Serverless models do not require users to maintain their own operating systems or even create applications that are compatible with specific OSes. Instead, developers create shared code, upload it to a serverless platform, and monitor its execution.
- Resources in serverless frameworks are generally billed by the minute (or even by the second). This means customers only pay for the time during which their code is actually running. This is a notable advantage over a traditional cloud VM, where machines sit idle most of the time, but payment is still required.
- The scalability issue has also been addressed. Resources in serverless frameworks are allocated dynamically, so the system can handle sudden spikes in demand effortlessly.
In short, serverless models provide flexible, cost-effective, scalable solutions. It’s surprising that we didn’t come up with this idea sooner.
Is this really a new idea?
In fact, the idea is not new. The concept of allowing users to pay only for the time that their code is actually running has existed since it was introduced under in 2006, and around the same time, Google App Engine offered a very similar solution.
What we now call the 'serverless' model is actually older than many technologies that are currently referred to as 'cloud-native', which provide almost the same functionality. As noted, serverless models are essentially just an extension of the SaaS business model that has existed for several decades.
Det er også værd at anerkende, at den serverløse model ikke er en FaaS-arkitektur, selvom der er en forbindelse mellem dem. FaaS er i bund og grund en beregningsorienteret del af den serverløse arkitektur, men den repræsenterer ikke hele systemet som helhed.
Hvad er så al denne opstandelse? Tja, efterhånden som internettets udbredelse i udviklingslande fortsætter med at vokse hurtigt, stiger efterspørgslen efter beregningsressourcer samtidig. For eksempel er der i mange lande med hurtigt voksende e-handelssektorer simpelthen ikke nogen beregningsinfrastruktur til applikationer på disse platforme. Det er her, betalte serverløse platforme kommer ind i billedet.
Problemer med serverløse modeller
Problemet 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 for nogle virksomheder under visse omstændigheder. Men den centrale påstand om 'revolutionen' - at den serverløse arkitektur hurtigt vil erstatte den traditionelle - vil aldrig blive realiseret.
Det er derfor.
Begrænset sprogunderstøttelse
De fleste serverløse platforme tillader kun at køre de applikationer, der er skrevet i bestemte sprog. Dette begrænser alvorligt fleksibiliteten og tilpasningsevnen i disse systemer.
Det menes, at serverløse platforme understøtter de fleste af de store sprog. AWS Lambda og Azure Functions giver også en skalering til at køre applikationer og funktioner på ikke-understøttede sprog, selvom dette ofte kommer med præstationsomkostninger. For de fleste organisationer har denne begrænsning dog ikke stor betydning. Men her er sagen. Det antages, at en af fordelene ved serverløse modeller er, at sjældent anvendte programmer kan bruges billigere, da du kun betaler for den tid, de kører. Og sjældent anvendte programmer er ofte skrevet i... sjældent anvendte programmeringssprog.
Dette underminerer et af de centrale fordele ved den serverløse model.
Leverandørbinding
Det andet problem med serverløse platforme, eller i det mindste hvordan de implementeres i øjeblikket, er, at de normalt ikke ligner hinanden på operationsniveau. Der er praktisk talt ingen standardisering, når det kommer til at skrive funktioner, implementering og administration. Det betyder, at migrering af funktioner fra en platform til en anden tager ekstremt lang tid.
Den sværeste del af overgangen til en serverløs model er ikke de beregningsmæssige funktioner, der normalt blot er små kodefragmenter, men hvordan applikationer er forbundet med tilsluttede systemer såsom objektlagring, identitetsstyring og køer. Funktioner kan flyttes, men resten af applikationen kan ikke. Dette er det komplette modsatte af de lovede billige og fleksible platforme.
Nogle hævder, at serverløse modeller er dukket op for nylig, og at der ikke har været tid til at standardisere deres drift. Men de er ikke så nye, som jeg tidligere har bemærket, og mange andre cloud-teknologier, såsom containere, er allerede blevet meget mere brugervenlige takket være udviklingen og den brede adoption af gode standarder.
Ydeevne
Beregningseffektiviteten af serverløse platforme er svær at måle, delvist fordi leverandørerne ønsker at holde informationerne hemmelige. De fleste hævder, at funktioner på eksterne, serverløse platforme kører lige så hurtigt som på interne servere, med Undtagelse af nogle uundgåelige forsinkelsesproblemer.
Men enkelte fakta tyder på det modsatte. Funktioner, der tidligere ikke blev kørt på en bestemt platform eller ikke har været i drift i et stykke tid, kræver en vis tid til at initialisere. Dette skyldes sandsynligvis, at deres kode blev flyttet til et mindre tilgængeligt lagermedium, selvom – ligesom med benchmarks – de fleste leverandører ikke vil fortælle dig om datamigrering.
Selvfølgelig er der flere måder at omgå dette på. En af dem er at optimere funktioner til ethvert cloud-sprog, som din serverløse platform kører på, men dette underminerer faktisk påstanden om, at disse platforme er 'fleksible'.
En anden tilgang er at sikre, at kritisk vigtige programmer til ydeevne køres regelmæssigt, så de forbliver "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. Cloududbydere har indført nye metoder til at reducere kolde opstarter, men mange af dem kræver "scale to one", hvilket underminerer den oprindelige værdi af FaaS.
Problemet med "kolde opstarter" kan delvist løses ved at drive serverløse systemer på egen hånd, men det medfører egne omkostninger og forbliver en niche-løsning 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: de kan (normalt) ikke køre hele applikationer.
Mere præcist er det ikke økonomisk forsvarligt. Din succesfulde monolit er sandsynligvis ikke værd at omdanne til et sæt af fyrre funktioner knyttet af otte gateways, fyrre køer og et dusin databaser. Af denne grund er serverless bedre egnet til nyudviklinger. Næsten ingen eksisterende applikation (arkitektur) kan overføres. Du kan migrere, men du skal starte forfra.
Dette betyder, at serverløse platforme i de fleste tilfælde bruges som et supplement til interne servere til opgaver, der kræver store beregninger. Dette adskiller dem markant fra de to andre former for cloud-teknologier – containere og virtuelle maskiner, der tilbyder en samlet måde at udføre fjernberegninger på. Dette illustrerer en af de udfordringer, der er forbundet med overgangen fra mikrotjenester til serverløse systemer.
Selvfølgelig er det ikke altid et problem. Muligheden for periodisk at bruge enorme beregningsressourcer uden at købe eget udstyr kan give reel og langvarig fordel for mange organisationer. Men hvis nogle applikationer kører på interne servere, mens andre er på serverløse skyarkitekturer, så bliver administrationen mere kompleks.
Leve revolutionen?
På trods af alle disse klager er jeg ikke imod serverløse løsninger som sådan. Jeg mener det virkelig. Bare udviklere skal forstå – især hvis de først undersøger serverløse modeller – at denne teknologi ikke er en direkte erstatning for servere. I stedet kan du finde vores råd og ressourcer om og beslutte, hvordan denne model bedst anvendes.
Kilde: habr.com
