Nyckelinsikter
- I flera år har vi blivit lovade att serverlösa beräkningar (serverless) kommer att inleda en ny era utan ett specifikt operativsystem för att köra applikationer. Vi har hört att denna struktur skulle lösa många skalbarhetsproblem. Verkligheten är annorlunda.
- Även om många ser serverlös teknologi som en ny idé, kan dess rötter spåras tillbaka till 2006, när Zimki PaaS och Google App Engine lanserades — i båda fallen används serverlös arkitektur.
- Det finns fyra orsaker till att den serverlösa revolutionen har stannat av: från begränsat språkstöd till prestandaproblem.
- Serverlösa beräkningar är inte helt värdelösa. Långt ifrån. Men de bör inte ses som en direkt ersättning för servrar. För vissa applikationer kan de vara ett användbart verktyg.
Servern är död, länge leve servern!
Så låter stridsropet från anhängarna av den serverlösa revolutionen. Det räcker med att snabbt bläddra igenom branschpressen de senaste åren för att lätt komma fram till att den traditionella servermodellen är död och att vi om några år alla kommer att använda serverlösa arkitekturer.
Som alla inom branschen vet, och som vi även påpekat i vår artikel om , så är det inte så. Trots många artiklar om fördelarna med , har den aldrig blivit verklighet. I själva verket visar , att denna revolution kanske har stannat av.
Vissa av löftena för serverlösa modeller har utan tvivel förverkligats, men inte alla. Långt ifrån alla.
I denna artikel vill jag granska orsakerna till detta tillstånd. Varför är bristen på flexibilitet i de serverlösa modellerna fortfarande ett hinder för deras bredare införande, även om de förblir användbara i specifika, väl definierade omständigheter.
Vad anhängarna av serverlösa beräkningar lovade
Innan vi går in på problemen med serverlösa beräkningar, låt oss se på vad de skulle ha att erbjuda. var många och - ibland - mycket ambitiösa.
För dem som inte är bekanta med termen, här är en kort definition. Serverlösa beräkningar definierar en arkitektur där applikationer (eller delar av applikationer) körs på begäran i körmiljöer som vanligtvis är värd på distans. Dessutom kan serverlösa system också hostas lokalt. Under de senaste åren har skapandet av hållbara serverlösa system varit en huvudfråga för systemadministratörer och SaaS-företag, eftersom (det påstås) denna arkitektur erbjuder flera viktiga fördelar jämfört med den "traditionella" klient-server-modellen:
- Serverlösa modeller kräver inte att användare underhåller sina egna operativsystem eller ens skapar applikationer som är kompatibla med specifika OS. Istället skapar utvecklare gemensam kod, laddar upp den till den serverlösa plattformen och övervakar dess körning.
- Resurser i serverlösa ramverk faktureras vanligtvis per minut (eller till och med sekund). Det innebär att kunderna bara betalar för den tid då koden faktiskt körs. Detta står i kontrast till en traditionell moln-VM, där maskinen är inaktiv större delen av tiden men ändå måste betalas för.
- Problemet med skalbarhet har också lösts. Resurser i serverlösa ramverk tilldelas dynamiskt, så systemet hanterar lätt plötsliga ökningar i efterfrågan.
Kort sagt, serverlösa modeller erbjuder flexibla, kostnadseffektiva, skalbara lösningar. Det är märkligt att vi inte kommit på denna idé tidigare.
Är detta verkligen en ny idé?
Faktum är att idén inte är ny. Konceptet som låter användare betala endast för den tid då koden faktiskt körs har funnits sedan det introducerades inom 2006, och ungefär samtidigt erbjöd Google App Engine en mycket liknande lösning.
Det som vi nu kallar den "serverlösa" modellen är faktiskt äldre än många av de teknologier som idag benämns "molnbaserade", och som i stort sett erbjuder samma sak. Som redan nämnts är serverlösa modeller i grunden bara en fortsättning på affärsmodellen SaaS, som har funnits i flera decennier.
Det är också värt att erkänna att den serverlösa modellen inte är en FaaS-arkitektur, även om det finns en koppling mellan dem. FaaS är i grunden den beräkningsinriktade delen av den serverlösa arkitekturen, men det representerar inte hela systemet.
Vad handlar all denna uppståndelse om? Jo, eftersom internets penetration i utvecklingsländer fortsätter att växa snabbt, ökar samtidigt efterfrågan på beräkningsresurser. I många länder med snabbt växande e-handelssektorer finns det helt enkelt ingen beräkningsinfrastruktur för applikationer på dessa plattformar. Här kommer betalade serverlösa plattformar in i bilden.
Problem med serverlösa modeller
Problemet är att serverlösa modeller har… problem. Missförstå mig inte: jag säger inte att de är dåliga i sig eller att de inte ger betydande värde för vissa företag under vissa omständigheter. Men det centrala påståendet om "revolutionen" — att serverlös arkitektur snabbt skulle ersätta traditionell — kommer aldrig att realiseras.
Det är därför.
Begränsat stöd för programmeringsspråk
De flesta serverlösa plattformar tillåter endast körning av applikationer som är skrivna på specifika språk. Detta begränsar allvarligt flexibiliteten och anpassningsförmågan hos dessa system.
Det antas att serverlösa plattformar stödjer de flesta större språk. AWS Lambda och Azure Functions erbjuder också en wrapper för att köra applikationer och funktioner på icke-stödda språk, även om detta ofta medför prestandakostnader. Så för de flesta organisationer är detta vanligtvis inte ett stort problem. Men här är saken: Det antas att en av fördelarna med serverlösa modeller är att sällan använda och lite kända program kan användas billigare, eftersom du bara betalar för deras körtid. Och sällan använda, lite kända program skrivs ofta på… sällan använda, lite kända programmeringsspråk.
Detta undergräver en av de centrala fördelarna med den serverlösa modellen.
Leverantörsbindning
Det finns ett problem med serverlösa plattformar, eller åtminstone med hur de implementeras idag, nämligen att de vanligtvis inte liknar varandra på operativ nivå. Det saknas standardisering när det kommer till att skriva funktioner, driftsätta och hantera. Detta betyder att migrering av funktioner från en plattform till en annan tar extremt mycket tid.
Den svåraste delen av att övergå till en serverlös modell är inte de beräkningsfunktioner som vanligtvis bara är kodsnuttar, utan hur applikationer är kopplade till anslutna system, såsom objektslagring, identitetshantering och köer. Funktioner kan flyttas, men resten av applikationen kan inte. Detta står i kontrast till de billiga och flexibla plattformar som utlovas.
Vissa hävdar att serverlösa modeller nyligen har dykt upp, och det har inte funnits tillräckligt med tid för att standardisera deras funktion. Men de är inte så nya, som jag redan har påpekat, och många andra molnteknologier, såsom containrar, har redan blivit mycket mer användarvänliga tack vare utvecklingen och den breda implementeringen av bra standarder.
Performance
Det är svårt att mäta den beräkningskapacitet som serverlösa plattformar erbjuder, delvis för att leverantörer strävar efter att hålla informationen hemlig. De flesta hävdar att funktioner på avlägsna, serverlösa plattformar fungerar lika snabbt som på interna servrar, med undantag för några ofrånkomliga fördröjningsproblem.
Men vissa faktorer tyder på motsatsen. Funktioner som tidigare inte har körts på en specifik plattform eller som inte har körts på ett tag behöver viss tid för att initieras. Detta beror förmodligen på att deras kod har flyttats till en mindre tillgänglig lagringsenhet, även om, precis som med benchmark-artiklar, de flesta leverantörer inte kommer att berätta för dig om datamigreringen.
Självklart finns det några sätt att kringgå detta. Ett av dem är att optimera funktioner för det molnbaserade språk som din serverlösa plattform använder, men detta underminerar något påståendet att dessa plattformar är "flexibla."
En annan ansats handlar om att säkerställa regelbunden körning av kritiska prestandaprogram för att hålla dem ”fräscha”. Denna andra ansats står förstås i viss konflikt med påståendet att serverlösa plattformar är mer kostnadseffektiva, eftersom du bara betalar för din programvaras körningstid. Molnleverantörer har implementerat nya metoder för att minska kalla starter, men många av dessa kräver ”skala till ett”, vilket undergräver det ursprungliga värdet av FaaS.
Problemet med ”kalla starter” kan delvis lösas genom att starta serverlösa system på egen hand, men detta medför egna kostnader och förblir en nischlösning för resurssatta team.
Du kan inte köra hela applikationer
Slutligen, kanske den viktigaste anledningen till att serverlös arkitektur inte kommer att ersätta traditionella modeller inom en överskådlig framtid: den kan (vanligtvis) inte användas för att köra hela applikationer.
Mer exakt, det är inte kostnadseffektivt. Din framgångsrika monolit är troligen inte värd att omvandla till ett set av fyrtio uppgifter, kopplade via åtta gateway, fyrtio köer och ett dussin databasinstanser. Av den anledningen passar serverlös teknik bättre för nya utvecklingar. Nästan ingen befintlig applikation (arkitektur) kan migreras. Du kan migrera, men du måste börja från början.
Det innebär att serverlösa plattformar i överväldigande många fall används som ett komplement till interna servrar för att utföra uppgifter som kräver stora beräkningsresurser. Detta skiljer dem tydligt från de två andra formerna av molnteknik - containrar och virtuella maskiner - som erbjuder en helhetlig metod för att utföra fjärrberäkningar. Detta illustrerar en av svårigheterna vid övergången från mikrotjänster till serverlösa system.
Självklart är det inte alltid ett problem. Möjligheten att regelbundet använda enorma beräkningsresurser utan att köpa egen hårdvara kan ge verkliga och långsiktiga fördelar för många organisationer. Men om vissa applikationer körs på interna servrar och andra på serverlösa molnarkitekturer, så kommer hanteringen till en ny nivå av komplexitet.
Länge leve revolutionen?
Trots alla dessa klagomål är jag inte emot serverlösa lösningar som sådana. Jag lovar. Utvecklare måste helt enkelt förstå - särskilt om de för första gången utforskar serverlösa modeller - att denna teknik inte är en direkt ersättning för servrar. Titta istället på våra tips och resurser för och avgöra hur man bäst tillämpar denna modell.
Källa: habr.com
