Viktige punkter

• I flere år nå har vi blitt lovet at serverløs databehandling vil innlede en ny æra uten et spesifikt OS for å kjøre applikasjoner. Vi ble fortalt at denne strukturen ville løse mange skalerbarhetsproblemer. Faktisk er alt annerledes.
• Mens mange ser på serverløs som en ny idé, kan røttene spores tilbake til 2006 med bruken av Zimki PaaS og Google App Engine, som begge bruker serverløs arkitektur.
• Det er fire grunner til at den serverløse revolusjonen har stoppet, alt fra begrenset støtte for programmeringsspråk til ytelsesproblemer.
• Serverløs databehandling er ikke så ubrukelig. Ikke i det hele tatt. De bør imidlertid ikke betraktes som en direkte erstatning for servere. For noen applikasjoner kan de være et hendig verktøy.

Serveren er død, lenge leve serveren!

Dette er kampropet til den serverløse revolusjonen. Bare et raskt blikk på bransjepressen de siste årene, og det er lett å konkludere med at den tradisjonelle servermodellen er død, og at vi i løpet av få år alle vil bruke serverløse arkitekturer.

Som alle i bransjen vet, og som vi også påpekte i vår artikkel om tilstand av serverløs databehandling, dette er feil. Til tross for mange artikler om fordelene serverløs revolusjon, det fant aldri sted. Faktisk, viser nyere studierat denne revolusjonen kan ha kommet til en blindvei.

Noe av løftet om serverløse modeller har absolutt blitt realisert, men ikke alle. Ikke alle.

I denne artikkelen vil jeg se på årsakene til denne tilstanden. Hvorfor mangelen på fleksibilitet til serverløse modeller fortsatt er en barriere for deres bredere bruk, selv om de fortsatt er nyttige under spesifikke, veldefinerte omstendigheter.

Hva adeptene av serverløs databehandling lovet

Før vi kommer inn på utfordringene med serverløs databehandling, la oss se på hva den skulle gi. Løftet om den serverløse revolusjonen var mange og - til tider - veldig ambisiøse.

For de som ikke er kjent med begrepet, her er en rask definisjon. Serverløs databehandling definerer en arkitektur der applikasjoner (eller deler av applikasjoner) kjører på forespørsel i kjøretidsmiljøer som vanligvis er eksternt. I tillegg kan serverløse systemer hostes hjemme. Å bygge spenstige serverløse systemer har vært en stor bekymring for systemadministratorer og SaaS-selskaper de siste årene, ettersom (det hevdes) denne arkitekturen tilbyr flere viktige fordeler i forhold til den "tradisjonelle" klient-server-modellen:

1. Serverløse modeller krever ikke at brukere vedlikeholder sine egne operativsystemer eller til og med oppretter applikasjoner som er kompatible med spesifikke operativsystemer. I stedet lager utviklere delt kode, laster den opp til en serverløs plattform og ser på at den kjører.
2. Ressurser i serverløse rammeverk blir vanligvis fakturert per minutt (eller til og med sekundet). Dette betyr at klienter kun betaler for den tiden de faktisk kjører koden. Dette kan sammenlignes gunstig med en tradisjonell sky-VM, hvor maskinen er inaktiv mesteparten av tiden, men du må betale for det.
3. Skalerbarhetsproblemet ble også løst. Ressurser i serverløse rammeverk er dynamisk tildelt slik at systemet enkelt kan takle plutselige økninger i etterspørselen.

Kort sagt, serverløse modeller gir fleksible, rimelige, skalerbare løsninger. Det er overraskende at vi ikke tenkte på denne ideen før.

Er dette virkelig en ny idé?

Ideen er faktisk ikke ny. Konseptet med å la brukere betale kun for tiden koden faktisk kjører har eksistert siden den ble introdusert av Zimki PaaS i 2006, og omtrent samtidig tilbød Google App Engine en svært lik løsning.

Faktisk er det vi nå kaller den "serverløse" modellen eldre enn mange teknologier som nå kalles "cloud native" som gir mye av det samme. Som nevnt er serverløse modeller i hovedsak bare en utvidelse av SaaS-forretningsmodellen som har eksistert i flere tiår.

Det er også verdt å erkjenne at serverløs ikke er en FaaS-arkitektur, selv om det er en sammenheng mellom de to. FaaS er i hovedsak den datasentrerte delen av en serverløs arkitektur, men den representerer ikke hele systemet.

Så hva er alt oppstyret om? Vel, ettersom internettpenetrasjonsraten fortsetter å skyte i været i utviklingsland, øker også etterspørselen etter dataressurser samtidig. For eksempel har mange land med raskt voksende e-handelssektorer ganske enkelt ikke datainfrastrukturen for applikasjoner på disse plattformene. Det er her betalte serverløse plattformer kommer inn.

Problemer med serverløse modeller

Haken er at serverløse modeller har... problemer. Misforstå meg rett: Jeg sier ikke at de er dårlige i seg selv eller ikke gir betydelig verdi til enkelte selskaper under noen omstendigheter. Men hovedpåstanden til "revolusjonen" - at serverløs arkitektur raskt vil erstatte tradisjonell arkitektur - materialiserer seg aldri.

Derfor.

Begrenset støtte for programmeringsspråk

De fleste serverløse plattformer lar deg bare kjøre applikasjoner som er skrevet på bestemte språk. Dette begrenser sterkt fleksibiliteten og tilpasningsevnen til disse systemene.

Serverløse plattformer anses å støtte de fleste større språk. AWS Lambda- og Azure-funksjoner gir også en innpakning for å kjøre applikasjoner og funksjoner på språk som ikke støttes, selv om dette ofte kommer med en ytelseskostnad. Så for de fleste organisasjoner er denne begrensningen vanligvis ikke en stor sak. Men her er saken. En av fordelene med serverløse modeller skal visstnok være at lite kjente, sjelden brukte programmer kan brukes billigere fordi du kun betaler for tiden de kjører. Og lite kjente, sjeldent brukte programmer er ofte skrevet på... lite kjente, sjeldent brukte programmeringsspråk.

Dette undergraver en av de viktigste fordelene med den serverløse modellen.

Leverandørbinding

Det andre problemet med serverløse plattformer, eller i det minste måten de er implementert på nå, er at de vanligvis ikke ligner hverandre på det operasjonelle nivået. Det er praktisk talt ingen standardisering når det gjelder skrivefunksjoner, distribusjon og administrasjon. Dette betyr at migrering av funksjoner fra en plattform til en annen er ekstremt tidkrevende.

Den vanskeligste delen av å flytte til en serverløs modell er ikke datafunksjonene, som vanligvis bare er kodebiter, men hvordan applikasjoner kommuniserer med tilkoblede systemer som objektlagring, identitetsadministrasjon og køer. Funksjoner kan flyttes, men resten av applikasjonen kan ikke. Dette er det stikk motsatte av de billige og fleksible plattformene som er lovet.

Noen hevder at serverløse modeller er nye og at det ikke har vært tid til å standardisere hvordan de fungerer. Men de er ikke så nye, som jeg nevnte ovenfor, og mange andre skyteknologier, for eksempel containere, har allerede blitt mye mer brukbare takket være utviklingen og utbredt bruk av gode standarder.

Производительность

Databehandlingsytelsen til serverløse plattformer er vanskelig å måle, delvis fordi leverandører har en tendens til å holde informasjon privat. De fleste hevder at funksjoner på eksterne, serverløse plattformer kjører like raskt som de på interne servere, med unntak av noen få uunngåelige ventetider.

Individuelle fakta indikerer imidlertid det motsatte. Funksjoner som ikke tidligere har kjørt på en bestemt plattform eller ikke har kjørt på en stund vil ta litt tid å initialisere. Dette skyldes sannsynligvis det faktum at koden deres har blitt portert til et mindre tilgjengelig lagringsmedium, selv om - som med benchmarks - de fleste leverandører ikke vil fortelle deg om datamigreringen.

Selvfølgelig er det flere måter rundt dette. Den ene er å optimalisere funksjonene for hvilket skyspråk den serverløse plattformen din kjører på, men dette undergraver noe påstanden om at disse plattformene er "smidige".

En annen tilnærming er å sikre at produktivitetskritiske programmer kjøres regelmessig for å holde dem ferske. Denne andre tilnærmingen er selvfølgelig litt av en motsetning til påstanden om at serverløse plattformer er mer kostnadseffektive fordi du kun betaler for tiden programmene dine kjører. Skyleverandører har introdusert nye måter å redusere kaldstart på, men mange av dem krever «skalering til én», noe som undergraver den opprinnelige verdien av FaaS.

Kaldstartproblemet kan delvis løses ved å kjøre serverløse systemer internt, men dette kommer med sine egne kostnader og forblir et nisjealternativ for godt ressurssterke team.

Du kan ikke kjøre hele applikasjoner

Til slutt, kanskje den viktigste grunnen til at serverløse arkitekturer ikke vil erstatte tradisjonelle modeller med det første: de kan (vanligvis) ikke kjøre hele applikasjoner.

Mer presist er det upraktisk fra et kostnadssynspunkt. Din vellykkede monolitt bør sannsynligvis ikke gjøres om til et sett med fire dusin funksjoner forbundet med åtte gatewayer, førti køer og et dusin databaseforekomster. Av denne grunn er serverløs bedre egnet for nye utviklinger. Nesten ingen eksisterende applikasjon (arkitektur) kan migreres. Du kan migrere, men du må starte fra bunnen av.

Dette betyr at i de aller fleste tilfeller brukes serverløse plattformer som et komplement til back-end-servere for å utføre dataintensive oppgaver. Dette gjør dem svært forskjellige fra de to andre formene for skyteknologier – containere og virtuelle maskiner – som tilbyr en helhetlig måte å utføre ekstern databehandling på. Dette illustrerer en av utfordringene ved å gå fra mikrotjenester til serverløse.

Dette er selvfølgelig ikke alltid et problem. Evnen til periodisk å utnytte massive dataressurser uten å måtte kjøpe din egen maskinvare kan gi reelle, varige fordeler for mange organisasjoner. Men når noen applikasjoner ligger på interne servere og andre på serverløse skyarkitekturer, får ledelsen et nytt kompleksitetsnivå.

Lenge leve revolusjonen?

Til tross for alle disse klagene, er jeg ikke imot serverløse løsninger i seg selv. Ærlig talt. Utviklere trenger bare å forstå – spesielt hvis de utforsker serverløse for første gang – at teknologien ikke er en direkte erstatning for servere. Sjekk i stedet tipsene og ressursene våre for lage serverløse applikasjoner og bestemme hvordan modellen best skal brukes.

Kilde: www.habr.com