Laten we proberen dit duidelijk te maken. Ten eerste is het concept op zichzelf tegenstrijdig. Immers, hoe wil je optreden zonder dat er op zijn minst een server bij betrokken is? Er staan dus wel degelijk servers aan de basis van deze dienst. Waar het op neerkomt is dat functionaliteit op een abstract niveau beschikbaar wordt gesteld ten behoeve van de ontwikkelaars. Daardoor hoeven zij zich geen zorgen meer te maken over infrastructurele en operationele zaken. Hierdoor kunnen zij zich volledig concentreren op het schrijven van code.
Veel van de huidige functionaliteiten zoals inloggen, zelfs single sign-on functionaliteit of inloggen met een social media account is beschikbaar voor gebruik in een project. Als een dergelijke bouwsteen in productiesystemen wordt gebruikt, wordt onderhoud belangrijk. Onderhoud betekent niets meer of minder dan het bijhouden van afhankelijkheden in deze (open) source. Denk hierbij aan opgeloste bugs, softwarefouten en verbeteringen door voortschrijdend inzicht.
De code die in een nieuw project wordt geproduceerd, is dus klaar om te worden gedeeld, en wordt hergebruikt via bibliotheken. De "eigen" code is daardoor klein, beperkt en gemakkelijk te lezen en te onderhouden. Een valkuil is om verouderde open source blokken te gebruiken, of om meer afhankelijkheden in het project te gebruiken zonder toegevoegde waarde. Als de eigen code beperkt blijft, kunnen deze bouwblokken worden opgedeeld in aparte services of programma's. De logica hiervan is niet nieuw, problemen worden zo opgedeeld in deelproblemen. Afzonderlijke oplossingen voor elk deelprobleem worden gecombineerd tot een eindresultaat. Dit heeft geleid tot een concept om blokken code afzonderlijk te laten uitvoeren in plaats van alle code in een groot programma. Liever tien functies die tien deelproblemen oplossen dan een groot programma dat alles oplost. Dat is precies de basis van functies of services zoals ze nu worden gebruikt. Een serverloze functie is niets meer dan een stukje code, met als doel een deeloplossing. Voorbeeld is het bevestigen van een nieuw ingelogde gebruiker. Als deze gebruiker zijn gegevens invoert, worden deze verwerkt in een functie, die vervolgens andere functies aanroept, zoals gebruiker aanmaken, e-mail sturen ter bevestiging en een omgeving klaarzetten voor de gebruiker. Elke andere functie is dus ook een apart stuk code, dat onafhankelijk kan worden aangeroepen en waarbij de functies niet van elkaar weten.
Waarom is dit belangrijk?
Ten eerste de snelheid en flexibiliteit van de ontwikkeling. Elke gedeeltelijke oplossing kan gemakkelijk worden vervangen zonder ingewikkelde tests of het aanvaarden van grote stukken programmacode. Elke functie kan afzonderlijk worden gebruikt, als de snelheid of de prestaties moeten worden aangepast kan dit onmiddellijk worden gedaan, opnieuw zonder afhankelijk te zijn van andere functies. Bovendien kan de code op elke omgeving worden uitgevoerd, ongeacht geografie of leverancier. Een serverless applicatie kan bijvoorbeeld op meerdere cloud providers tegelijk draaien!
Al deze voordelen gaan gepaard met een aantal nadelen, zoals een grote complexiteit en een levenscyclus per functie die moet worden bijgehouden. Deze toegenomen complexiteit wordt nu aangeboden tegen zeer concurrerende prijzen, vaak worden de functies alleen in rekening gebracht wanneer ze worden gebruikt. Aan de andere kant betekent dit dat een enkele opstartsequentie van broncode als traag wordt ervaren.
In conclusie: serverloos is schaalbaar, flexibel en kan uitgerold worden op verhoogde snelheid. De ontwikkelingskosten, de snelheid van bezorgen en simpel software onderhoud kunnen deze nieuwe manier van software systeem versnellen in de cloud. Onthoud dat dit betekent dat de eenmalige opstart van het benodigde code programma wordt ervaren als een slow 'server' response: het reageert langzaam bij de eerste start.
Meer over Minimum & Viable in een apart bericht!