Nyckelord
- Sedan flera år tillbaka har vi blivit lovade att serverlös datoranvändning (serverlös) kommer att öppna en ny era utan ett specifikt OS för att köra applikationer. Vi fick höra att en sådan struktur skulle lösa många skalbarhetsproblem. Faktum är att allt är annorlunda.
- Medan många ser serverlös teknologi som en ny idé, kan dess rötter spåras tillbaka till 2006 med Zimki PaaS och Google App Engine, som båda använder en serverlös arkitektur.
- Det finns fyra anledningar till att den serverlösa revolutionen har avstannat, från begränsat stöd för programmeringsspråk till prestandaproblem.
- Serverlös datoranvändning är inte så värdelös. Långt ifrån. De ska dock inte ses som en direkt ersättning för servrar. För vissa applikationer kan de vara ett praktiskt verktyg.
Servern är död, länge leve servern!
Detta är stridsropet från den serverlösa revolutionens anhängare. En snabb blick på branschpressen under de senaste åren räcker för att dra slutsatsen att den traditionella servermodellen är död och att vi om några år alla kommer att använda serverlösa arkitekturer.
Som alla i branschen vet, och som vi också påpekade i vår artikel om , detta är fel. Trots många artiklar om meriter , det ägde aldrig rum. Faktiskt, att denna revolution kan ha nått en återvändsgränd.
Några av löftena för serverlösa modeller har verkligen gått i uppfyllelse, men inte alla. Inte Alla.
I den här artikeln vill jag överväga orsakerna till detta tillstånd. Varför bristen på flexibilitet hos serverlösa modeller fortfarande är ett hinder för deras bredare användning, även om de fortfarande är användbara under specifika, väldefinierade omständigheter.
Vad adepterna för serverlös datoranvändning lovade
Innan vi går vidare till problemen med serverlös datoranvändning, låt oss se vad de hade att tillhandahålla. var många och - ibland - mycket ambitiösa.
För de som inte känner till termen, här är en kort definition. Serverlös datoranvändning definierar en arkitektur där applikationer (eller delar av applikationer) körs på begäran i runtime-miljöer som vanligtvis finns på distans. Dessutom kan serverlösa system vara värd. Att bygga robusta serverlösa system har varit ett stort problem för systemadministratörer och SaaS-företag under de senaste åren, eftersom (det hävdas) denna arkitektur erbjuder flera viktiga fördelar jämfört med den "traditionella" klient/server-modellen:
- Serverlösa modeller kräver inte att användarna underhåller sina egna operativsystem eller ens bygger applikationer som är kompatibla med specifika operativsystem. Istället skapar utvecklare delad kod, laddar upp den till en serverlös plattform och ser hur den körs.
- Resurser i serverlösa ramverk faktureras vanligtvis per minut (eller till och med sekunder). Detta innebär att klienter endast betalar för den tid de faktiskt kör koden. Detta kan jämföras med den traditionella moln-VM, där maskinen är inaktiv för det mesta, men du måste betala för det.
- Problemet med skalbarhet löstes också. Resurser i serverlösa ramverk tilldelas dynamiskt så att systemet enkelt kan hantera plötsliga toppar i efterfrågan.
Kort sagt, serverlösa modeller ger flexibla, skalbara lösningar till låg kostnad. Jag är förvånad över att vi inte tänkte på den här idén tidigare.
Är detta verkligen en ny idé?
Idén är faktiskt inte ny. Konceptet att tillåta användare att bara betala för den tid koden faktiskt körs har funnits sedan den introducerades under 2006, och ungefär samtidigt, kom Google App Engine med en mycket liknande lösning.
Faktum är att det vi nu kallar den "serverlösa" modellen är äldre än många av de teknologier som nu kallas "molnbaserade" som ger nästan samma sak. Som nämnts är serverlösa modeller i huvudsak bara en förlängning av SaaS affärsmodell som har funnits i decennier.
Det är också värt att inse att den serverlösa modellen inte är en FaaS-arkitektur, även om det finns ett samband mellan de två. FaaS är i huvudsak den beräkningscentrerade delen av en serverlös arkitektur, men det representerar inte hela systemet.
Så varför all denna hype? Tja, eftersom hastigheten på internetpenetration i utvecklingsländer fortsätter att skjuta i höjden, ökar också efterfrågan på datorresurser. Till exempel har många länder med snabbt växande e-handelssektorer helt enkelt inte datorinfrastrukturen för applikationer på dessa plattformar. Det är här betalda serverlösa plattformar kommer in.
Problem med serverlösa modeller
Haken är att serverlösa modeller har… problem. Missförstå mig rätt: jag säger inte att de är dåliga i sig själva eller inte ger betydande värde för vissa företag under vissa omständigheter. Men "revolutionens" huvudpåstående - att den serverlösa arkitekturen snabbt kommer att ersätta den traditionella - kommer aldrig att förverkligas.
Det är därför.
Begränsat stöd för programmeringsspråk
De flesta serverlösa plattformar tillåter bara applikationer skrivna på vissa språk att köras. Detta begränsar kraftigt flexibiliteten och anpassningsförmågan hos dessa system.
Serverlösa plattformar anses stödja de flesta större språk. AWS Lambda och Azure Functions tillhandahåller också ett omslag för att köra applikationer och funktioner på språk som inte stöds, även om detta ofta kostar en prestanda. Så för de flesta organisationer är denna begränsning vanligtvis inte en stor sak. Men här är grejen. En av fördelarna med serverlösa modeller ska vara att obskyra, sällan använda program kan användas billigare eftersom du bara betalar för den tid de körs. Och obskyra, sällan använda program skrivs ofta i... obskyra, sällan använda programmeringsspråk.
Detta undergräver en av de viktigaste fördelarna med den serverlösa modellen.
Bindande till en leverantör
Det andra problemet med serverlösa plattformar, eller åtminstone hur de är implementerade för närvarande, är att de vanligtvis inte ser lika ut på operativ nivå. Det finns praktiskt taget ingen standardisering när det gäller skrivfunktioner, driftsättning och hantering. Detta innebär att det är extremt tidskrävande att migrera funktioner från en plattform till en annan.
Den svåraste delen med att flytta till en serverlös modell är inte beräkningsfunktionerna, som vanligtvis bara är kodavsnitt, utan hur applikationer kommunicerar med anslutna system som objektlagring, identitetshantering och köer. Funktioner kan flyttas, men resten av programmet kan inte. Detta är raka motsatsen till de utlovade billiga och flexibla plattformarna.
Vissa hävdar att serverlösa modeller är nya och att det inte har funnits tid att standardisera hur de fungerar. Men de är inte så nya, som jag noterade ovan, och många andra molntekniker som behållare har redan blivit mycket mer bekväma på grund av utvecklingen och det breda antagandet av goda standarder.
Производительность
Datorprestanda för serverlösa plattformar är svår att mäta, delvis på grund av att leverantörer tenderar att hålla information hemlig. De flesta hävdar att funktioner på fjärranslutna, serverlösa plattformar går lika snabbt som de gör på interna servrar, med undantag för några oundvikliga latensproblem.
Vissa bevis tyder dock på något annat. Funktioner som inte tidigare har körts på en viss plattform, eller som inte har körts på en tid, tar lite tid att initiera. Detta beror troligen på att deras kod har porterats till något mindre tillgängligt lagringsmedium, även om - som med benchmarks - de flesta leverantörer inte kommer att berätta om portering av data.
Naturligtvis finns det flera sätt att komma runt detta. En är att optimera funktioner för vilket molnspråk din serverlösa plattform körs på, men det undergräver något påståendet att dessa plattformar är "agila".
Ett annat tillvägagångssätt är att se till att prestandakritiska program körs regelbundet för att hålla dem "fräscha". Detta andra tillvägagångssätt strider förstås lite mot påståendet att serverlösa plattformar är mer kostnadseffektiva eftersom du bara betalar för den tid dina program körs. Molnleverantörer har introducerat nya sätt att minska kalla lanseringar, men många av dem kräver "skala till ett", vilket undergräver det ursprungliga värdet av FaaS.
Kallstartsproblemet kan delvis lösas genom att köra serverlösa system internt, men detta kommer på egen bekostnad och förblir ett nischalternativ för team med goda resurser.
Du kan inte köra hela applikationer
Slutligen, kanske den viktigaste anledningen till att serverlösa arkitekturer inte kommer att ersätta traditionella modeller när som helst snart är att de (i allmänhet) inte kan köra hela applikationer.
Mer exakt är det opraktiskt ur kostnadssynpunkt. Din framgångsrika monolit borde förmodligen inte förvandlas till en uppsättning av fyra dussin funktioner sammanbundna av åtta gateways, fyrtio köer och ett dussin databasinstanser. Av denna anledning är serverlös bättre lämpad för nya utvecklingar. Praktiskt taget ingen befintlig applikation (arkitektur) kan portas. Du kan migrera, men du måste börja från början.
Detta innebär att i de allra flesta fall används serverlösa plattformar som ett komplement till back-end-servrar för att utföra beräkningsintensiva uppgifter. Detta skiljer sig mycket från de andra två formerna av molnberäkning, behållare och virtuella maskiner, som erbjuder ett holistiskt sätt att utföra fjärrdatorn. Detta illustrerar en av utmaningarna med att migrera från mikrotjänster till serverlösa system.
Naturligtvis är detta inte alltid ett problem. Möjligheten att periodvis använda enorma datorresurser utan att köpa din egen hårdvara kan ge verkliga och bestående fördelar för många organisationer. Men om vissa applikationer finns på interna servrar och andra är på serverlösa molnarkitekturer, går hanteringen in på en ny nivå av komplexitet.
Länge leve revolutionen?
Trots alla dessa klagomål är jag inte emot serverlösa lösningar i sig. Ärligt. Det är bara det att utvecklare måste förstå - speciellt om de utforskar serverlösa modeller för första gången - att den här tekniken inte är en direkt ersättning för servrar. Kolla istället in våra tips och resurser på och bestäm hur den här modellen bäst ska tillämpas.
Källa: will.com