Är det värt att gå över till serverless? Fallgropar och möjligheter

Vad innebär serverless?

Serverless computing (eller Function as a Service, ibland även kallat Lambda Functions) har funnits ett tag. Dags för en överraskning om du inte redan visste det: serverless-teknik körs faktiskt på en server! Men serverless innebär att servern abstraheras bort – den tillhandahålls som en tjänst för dig. Ungefär som en virtuell maskin abstraherar bort hårdvaran.

De mest mogna serverless-teknikerna finns i det publika molnet. Google App Engine, Amazon Lambda och Azure Functions är mycket kraftfulla verktyg. Bland open source-lösningar är Apache OpenWhisk den mest populära.

Hur fungerar en serverless-arkitektur?

Med serverless får du ett ramverk från leverantören för att bygga en applikation. När du bygger en applikation med ramverket tar leverantören hand om att köra den åt dig i en helt förvaltad miljö – därav namnet serverless.

Och här är anledningen till att det kallas serverless: din applikation körs inte när ingen använder den! Det leder naturligt till kostnadsbesparingar och något förenklad drift, eftersom du inte längre ansvarar för att faktiskt köra din kod.

Eftersom molnet ofta är det bästa valet när det gäller att spara resurser, körs din applikation bara vid behov. Illustrationen nedan förklarar vad som händer:

1. En utvecklare laddar upp kod till molnet

2. En användare anropar tjänsten

3. Molnet startar en instans av koden och tillhandahåller applikationen för användaren

4. Användaren är klar med applikationen

5. Molnet stänger ner tjänsten tills nästa användare kommer

Bör du välja serverless? Några saker att tänka på

Precis som all teknik har serverless några begränsningar. Jag brukar tänka att varje tekniskt problem bara är en möjlighet i förklädnad. Låt oss gå igenom några utmaningar med serverless och hur du kan vända dem till möjligheter.

Fakta 1: Ta inte med dina monoliter in i serverless-världen!

Det fungerar helt enkelt inte och är inte rimligt. En stor fördel med serverless är att det tvingar dig att skapa Cloud Native-mjukvara. Du behöver ha inställningen att applikationen kan stängas ner plötsligt.

Försök därför inte flytta din tillståndsfulla applikation till serverless om du inte är redo att verkligen ta steget in i Cloud Native-världen. Förändringen är inte bara teknisk, utan förändrar också hur du utvecklar mjukvara.

Fakta 2: Det kommer att gå långsammare

Serverless är inte avsett för högsta möjliga prestanda. När den första förfrågan kommer in behöver koden laddas in i minnet, eller på den virtuella server som ska hantera förfrågan och som först måste starta. Allt detta kan göra din applikation långsammare.

Lösningen? Använd inte serverless för applikationer som kräver låg latens. Om dina svarstider blir långsammare på grund av serverless är serverless-teknik troligen inte rätt för dig.

Fakta 3: Övervakning och loggning är ett problem

Serverless innebär att dina applikationsinstanser är kortlivade. Vad händer om det uppstår ett problem med din applikation? Du kanske har lagt till korrekt loggning, men eftersom instanserna är så kortlivade kan loggarna vara borta när du får ett klagomål från en användare.

Det öppnar för ännu en möjlighet: investera i Cloud Native-loggning. Skicka dina loggar direkt till en plattform som AWS CloudWatch eller Google Stackdriver, som är avsedd för just detta.

Fakta 4: Serverless medför vendor lock-in

Vendor lock-in är generellt något du behöver ta hänsyn till när du bygger din verksamhet på en molnplattform. Ju mer du investerar i serverless-teknik från en publik molnleverantör, desto mer vendor lock-in skapar du för dig själv.

Det finns ingen universallösning för leverantörsinlåsning. På sätt och vis befinner du dig alltid i någon form av inlåsning. Bara valet av ramverk för din applikation eller ditt operativsystem innebär en form av inlåsning.

Det viktigaste är att du är medveten om att du är inlåst och, om du ser det som ett problem, hanterar det därefter. För serverless kan ett alternativ vara att använda molnoberoende lösningar som Apache OpenWhisk.

Fakta #5: Du behöver fortfarande ta hand om säkerheten

Säkerhet är ingen svart låda som du bara kan köpa från hyllan (jag önskar verkligen att det vore så!). Det gäller även serverless.

Om din serverless-applikation ska använda molntjänster som blob storage måste du vara mycket noggrann när du definierar vilka behörigheter applikationerna har till dina resurser. Se också till att du förstår hur dina serverless-deployments genomförs, så att dålig kod verkligen ersätts av dina korrigeringar.

Förlita dig inte heller på molnleverantören när det gäller säkerhet. Enligt min mening ska ingen annan göra det åt dig.

Serverless: ännu ett sätt att skapa värde för kunderna

Sammanfattningsvis är serverless bara ännu ett verktyg. Det är inte tänkt att ersätta något.

Det ersätter inte containers. Det ersätter inte mikrotjänster. Det är bara ytterligare ett sätt att ge dina kunder en fantastisk upplevelse.

Att komplettera befintlig molninfrastruktur med smarta serverless-tekniker kan vara ett vinnande drag när du bygger tjänster för dina kunder. Eller, om du bygger ett greenfield-projekt, tänk på helheten och fundera på om serverless passar in i vår vision.