Jag har ett hobbyprojekt som jag kodat på (när jag haft tid) i snart ett år. Jag kommer nästan helt säkert aldrig att bli klar med det eftersom hela grejen är att jag har det för att lära mig mer om saker jag inte gjort förut.
Länge var det en webbapp skriven med javascript och react. Den biten finns kvar men på serversidan hade jag ett REST-API där jag kodat rubbet i python med en mysql i botten.
Det är egentligen inget fel på det (även om postgres nog är ett något starkare alternativ än mysql) och python är toppen. Fast det känns lite 2015, så jag bestämde mig för att skriva om hela rubbet i något modernare.
I dag vill man skriva saker som går att skala upp utan att utvecklaren behöver göra det möjligt med allt vad det innebär för att hålla multipla implementationer i synk, acceptera samma inloggningstokens och inte minst hantera ännu fler instanser (oavsett om det är processer i virtuella maskiner eller docker containers i någon hanterad miljö).
Det är här “Serverless” kommer in.
Serverless?
I botten av “serverless” ligger oftast docker eller liknande teknik. Nedan använder jag AWS-termer men Google Cloud Platform (GCP) och Azure har motsvarande grejer.
Till att börja med så är Serverless inte alls utan servrar. Den stora grejen är att det är FaaS (Functions as a Service) där du utvecklar varje API som en funktion med t.ex AWS Lambdas och sen t.ex. kopplar den till en sk API end-point i API Gateway. API Gateway kan redan allt om ditt API om du har importerat en Swagger/OAS3-spec. Faktiskt till den nivå att du kan be den kolla på det som skickas till API:et och se att det är API-mässigt korrekt. Om de inte matchar specen så skickar den tillbaka en felkod och du slipper en massa arbete för att säkerställa att du fått in de data som du behöver och kan instället lägga kraften på att kontrollera att själva datat stämmer.
Du skriver typiskt din funktion i Node (javascript) och den är helt utan state som ett REST-API bör vara. Allt det här lever sedan hos en molnaktör som typiskt tar betalt för hur mycket det används och inte för själva servrarna som måste snurra året runt, varje dag i veckan oavsett om du inte har några användare alls eller 100000 användare. Det är upp till moln-leverantören att starta funktionen på den sorts servrar som är lagom stora och på så många servrar som behövs.
Det är, enkelt uttryckt, genialiskt! När man som jag har ett litet hobbyhack bara för att det är riktigt roligt att koda på något hela tiden så behöver man inte betala för en massa servrar att köra databaser, webbserver osv på. Det känns som om jag kommer att klara mig rätt bra på det som “free tier” i AWS så länge jag bara jobbar med det själv. Om man däremot gör något och har för avsikt att på sikt ta över världen så kan man skala upp från inga användare till nästan hur många som helst utan att riskera att ramla in i ett läge där man underdimensionerat sin hårdvara eller behöver skriva om allting för att kunna leva bakom en lastbalanserare. Det värsta som kan hända är att räkningarna till moln-leverantören sticker iväg uppåt men har man så många användare så har man säkert inte jättesvårt att bygga en intäktsström (och om det är svårt så har man nog satsat på fel häst och bör tänka om).
En liten bieffekt är att hela modellen tvingar dig att skriva saker som någon annan kan deploya på det sätt som krävs för att det ska skala upp.
Naturligtvis är det så att om tjänsten har en relationsdatabas i botten så behöver du fortfarnade tänka på index, databasstruktur, frågor och annat för att du inte ska bygga in flaskhalsar som skalar dåligt men hela modellen med serverless uppmuntrar till att även när det gäller databaser använda den mer skalbara modell du får med NoSQL-lösningar som DynamoDB.
Just därför har jag fått en bra möjlighet att köra en NoSQL-databas, eller faktiskt inte bara köra utan även konvertera en typisk RDBMS-setup till en NoSQL-modell med betydligt färre tabeller men mer data. Det är en otrolig omställning för någon som växten upp och skolades i en relationsdatabas-värld där allt skulle vara normaliserat till NF3.
Men låser du inte in dig hos en leverantör?
Jo, typ… Det finns bra lösningar där ute för att koda lokalt och kunna deploya det mesta till olika leverantörer (Azure, AWS, GCP) men så fort du börjar binda fast dig i specifica lösningar för databaser eller köer för att skicka meddelanden så blir du snabbt fastlåst i en miljö. Jag har aldrig gillat att låsas fast, men i det här fallet så ger det så otroligt mycket mervärde att “gå med Amazon” (eller vem man nu väljer) att det är värt det. Skulle de skicka sin prislista till månen ska jag fundera på om det kan vara värt att skriva om sakerna så att de fungerar hos GCP eller någon annan provider men att det fungerar, skalar och har en rimlig prislista är gott nog för mig.