Na virtualisatie via docker containers naar microservices lijkt serverless computing een eindpunt. Serverless klinkt abstract en daarom is het lastig om te vatten wat er nu zo belangrijk aan is. Laatst kregen wij een verzoek waarbij ik direct inzag dat serverless hier een mooie oplossing voor zou zijn.
De klantwens was om de mensen die de praktijkcursus gevolgd hebben op een groepsfoto te zetten samen met een embleem om hiermee nieuwe bezoekers te verwelkomen op een fotomuur om hiermee social proof te leveren.
Een standaard applicatie hiervoor kon ik niet vinden en vaak komt er van alles bij kijken. Data opslag, applicatiebeheer, beheer van een (deel van) een server en waarom zou je een server aan moeten houden als er in de nacht geen behoefte aan is?
Technische beschrijving
Hier volgt een wat technische beschrijving die hopelijk voor niet techneuten ook goed te volgen is. De basis is een S3 bucket van Amazon Web Services (AWS). Dat is in feite een oneindige data opslag waarbij ieder object een link heeft om dat object aan te roepen. Dit kunnen foto’s zijn, maar ook html-bestanden. Door een instelling van de S3 bucket kan deze ook direct als een statische website dienen. Statisch betekent dat er geen code op een server wordt uitgevoerd, maar dat de pagina gewoon zonder aanpassingen geserveerd wordt aan een browser en eventuele Javascript-code op het device van de gebruiker wordt uitgevoerd. Deze S3 bucket gebruik ik voor de opslag van de foto’s en voor het aanbieden van de internetpagina waarop de foto’s willekeurig getoond zullen worden aan het publiek.
Maar hoe zorgen we ervoor dat er willekeurige foto’s getoond worden op een statische html-pagina? Zoals gezegd kan er wel javascript op de browser zelf uitgevoerd worden. Deze kijkt naar een json-bestand in dezelfde S3 bucket waarin staat welke foto’s getoond moeten worden. Json is net als xml een manier om structuur aan data te geven. Iedere twee minuten haalt Javascript het json-bestand op om de foto’s te tonen. De crux zit hem dus in om steeds dat json-bestand aan te passen met andere foto’s. Hiervoor is iets nodig dat code uitvoert en normaliter is dat een virtuele server of container. In ons geval gebruiken we een andere dienst van AWS namelijk Lambda. In Lambda kun je scripts uploaden die afgaan als er een bepaalde gebeurtenis plaatsvind. Bijvoorbeeld als er een bestand geüpload wordt naar een S3 bucket of als er een bericht wordt ingeschoten naar een AWS Simple Notification Service (SNS) topic, een andere dienst van AWS. Zo’n bericht kan bijvoorbeeld afgevuurd worden door Javascript in een browser. Lambda past dus iedere keer het json-bestand aan wat door de javascript op de pagina gebruikt wordt om willekeurig foto’s op te halen.
Hiervoor is dus geen enkele server nodig en de maandelijkse kosten hiervoor liggen nog onder de euro. Door er nog wat alarmen op te plaatsen, bijvoorbeeld als er een fout optreedt of de pagina niet goed opbouwt is ook het beheer in de basis geregeld.
Nu bleef er nog één uitdaging over, de foto’s van het de camera in een S3 bucket uploaden. Dit valt eigenlijk buiten de scope, maar hiervoor heb ik zelf een console scriptje geschreven dat op de computer draait die gebruikt wordt om de foto’s van de camera af te krijgen. Deze kijkt iedere keer of er foto’s bestaan in de Afbeeldingen-map en upload deze automatisch en verwijderd deze daarna. Als er meer dan zeven dagen geen nieuwe foto’s in de S3 bucket zijn bijgekomen gaat hier ook nog een alarm van af.
Krachtige oplossing
De gemaakte oplossing is krachtig, vereist nagenoeg geen beheer en je betaalt alleen voor noodzakelijke kosten die bovendien minimaal zijn. Een Lambda script, SQS Queue en S3 bucket moeten voor beheer gewoon als configuratie-items behandeld worden.
Dit is slechts een beperkt voorbeeld maar wel een echt praktijkvoorbeeld en zo kan ik er nog wel een paar geven. Ik besef me overigens dat serverless niet per se een vervanging is voor virtuele servers, het zijn gewoon verschillende dingen. Serverless is ook geen silver bullet die bijvoorbeeld virtuele servers overbodig maakt, zie het meer als nog een tool in het arsenaal om dingen eenvoudiger te doen.
Ik reageer altijd op reacties, hopelijk kan ik je inspireren om het ook toe te passen. Ik heb ook een case voor Docker Containers, bij voldoende interesse zal ik deze ook schrijven.
In dit design wordt niets ge-queue-ed.
Het begrip ‘serverless’ is hiermee voor mij wel wat duidelijker geworden, waarvoor dank.
Wat ik altijd lastig is bij dit soort kretologie is dat het sterk afhangt van het abstractie niveau waarop je werkt / kijkt.
Immers, de AWS omgeving zelf draait uiteindelijk toch ergens op een server.
Colocation is datacentrumless
IaaS is hardwareless
PaaS is infrasctructureless, maar serverless zal wel lekkerder bekken ofzo
SaaS is applicationless
Lambda is SaaS for developers : infrastructureless, serverless maar ook hourless (billing), wel API-full en PaaS.
Ik hoop dat het nu onduidelijk is.
Dino, je eerste reactie is scherp! Ik had een aanpassing gedaan, in onze oplossing gebruiken we helemaal geen SQS. Met ReactJS kun je ook gewoon een Lambda functie activeren. Ook je 2e reactie is leuk en daarmee direct een bruggetje naar PaVaKe. Azure noemt het Cloud Functions en dat is al direct een betere beschrijving aangezien Serverless vooral beschrijft wat het niet is (net als No-SQL).
Het gaat me ook niet om de buzz en hype. Daarom probeer ik ook een zo down to earth artikel te schrijven. waarbij je zelf wel kunt bepalen wat het waard is.
Ik lees veel over mogelijkheden en om ze goed te begrijpen pas ik ze toe waar mogelijk en je ziet een tendens waar ik eigenlijk al jaren over schrijf. Het vereenvoudigen van IT die je flexibel maakt tegen veel lagere kosten als nu in de enterprise gehanteerd wordt.
Er komt een moment dat “AI” (geen echte AI maar vergaande patroonherkenning en toepassing) heel veel over kan nemen juist omdat alles met software te besturen valt. 30 jaar geleden voorspelde men dat code grafisch zou worden. Dat is niet gebeurd en gaat nagenoeg niet gebeuren, code is gewoon noodzakelijk, maar het produceren van code kan wel sneller en makkelijker zonder terug te vallen om de lompe code generatoren van nu.
Hier gaat makkelijk nog vijftien jaar overheen, maar het is onvermijdelijk….
Ten slotte: Serverless in deze context gaat erom dat je niet de server hoeft te beheren die de compute uitvoert. Er zijn servers, maar ze zijn niet meer relevant in het uitvoeren van compute….
De constructie heeft wel een beetje een hoog pruts gehalte met alarmpjes en scriptjes en een afhankelijkheid van AWS (patriot act dingetje) waar de klant nu mee zit en zich waarschijnlijk niet van bewust is en de personen op de fotos al helemaal niet. als een van mijn studenten dit zo zou afleveren zou dat geen voldoende opleveren! ik vind het ook een beetje een ‘ik heb een hamer nu dus alles is een spijker’ dingetje.
Hey Swa, prutsen is een eerste stap naar een creatief concept. Ik ben dan ook heel nieuwsgierig hoe jouw studenten dan wel een voldoende kunnen halen. Je hebt de moeite genomen om te reageren, hopelijk neem je ook de moeite een alternatieve oplossing aan te dragen.
Cloud functies zoals AWS Lambda betekenen inderdaad een vendor lock-in, misschien dat het daarom zo goedkoop is.
Je schrijft over de Patriot Act, kun je ook het probleem beschrijven wat jij nu ziet? Of is dit meer dat je in het algemeen tegen cloud-diensten bent uit de VS?
Dat hamer en spijker ding kunnen we evalueren als we het over alternatieven hebben gehad.
Misschien interpreteer ik het artikel en de beschreven toepassing helemaal verkeerd. Maar als het bedoeld is om illustratief te zijn voor de “eenvoud” van het gebruik van Amazon diensten… ik weet het niet…
Als ik het goed begrijp is de klantvraag om groepsfoto’s die zijn voorzien van een logo naar een vooraf bepaalde, extern opslag medium te sturen (in dit voorbeeld een Amazon S3 bucket).
Vervolgens wordt er een statische webpagina voorzien van (bijvoorbeeld) 3 willekeurige gekozen foto’s uit dit opslag medium. Deze pagina wordt vervolgens elke 2 minuten ververst en voorzien van 3 nieuwe/andere foto’s.
Als dat klopt en je werkt al met een bucket van verwijzingen naar de foto-bestanden, dan is het toch veel eenvoudiger om het javascript elke 2 minuten 3 nieuwe getallen te laten bepalen met een random integer generator. Die 3 getallen zijn elk een verwijzing naar 3 foto’s in dat S3 bucket.
Het bereik waarmee die integer generator werkt hangt natuurlijk af van het totaal aantal beschikbare foto’s. Het totaal aantal foto’s en de datum van de laatst toegevoegde foto(‘s) wordt opgeslagen in een klein tekstbestandje (kan in XML formaat – maar is niet perse nodig).
Aan de andere kant – het zou zomaar kunnen dat er een API-call is waarmee je kunt opvragen hoeveel bestanden er in een bepaalde bucket zitten; in dit voorbeeld dus het bucket met de foto bestanden.
Ook zou het kunnen dat er een API-call is die een timestamp teruggeeft van de laatst toegevoegde foto.
Als beiden kloppen, dan hoef je niet eens te werken met een tekstbestandje; een aanroep naar beide API’s vanuit het javascript is al voldoende om de klantvraag in te kunnen vullen.
Maar goed – doorredenerend op het gebruik van een tekstbestandje: dat wordt vervolgens bij iedere refresh van de pagina opnieuw ingelezen. Op die manier worden nieuwe foto’s automatisch meegenomen.
Ik heb geen ervaring met S3 buckets en de bijbehorende API; ik zal dus vast ergens wat gemist hebben.
Maar hoe helpt de inzet van allemaal die AWS diensten nu om zoiets als dit voorbeeld eenvoudig(er) te bouwen en te beheren?
😉
Lees https://en.wikipedia.org/wiki/Patriot_Act
Verder nogmaals de vraag, weet de klant en de mensen van wie foto’s genomen hebben dat hun data bij een derde partij in een land met grijpgrage wetgeving is?
Mijn studenten moeten minstens rekening houden hiermee en een vorm van client side encryptie toepassen als ze een cloud oplossing gebruikt wordt. niet duidelijk uit je verhaal is of er uberhaupt maar iets tegen cross site request foregries gedaan wordt:
https://en.wikipedia.org/wiki/Cross-site_request_forgery
Maar goed, het gaat niet om mijn studenten, het gaat om het werk dat jij hier ten toon stelt dat naar een betalende klant is gegaan :).
@swa: waar eindigt prutsen en begint innovatie?
Je reactie doet me helaas denken aan de een beoordeling van een student die bij mij afgestudeerd is; een van de docenten had opmerkingen waardoor ik sterk het gevoel kreeg dat hij de aansluiting met het bedrijfsleven volledig kwijt was
Ik kan me ook niet vinden in de reactie van Swa. Ik vond het wel een leuke case om te lezen.
Het enige waar Henri zich waarschijnlijk schuldig aanmaakt, is dat hij te snel de oplossing in een bepaalde hoek zoekt. (AWS) Alhoewel het in dit geval best kan allemaal.
Maar een server in de nacht aanhouden? Waarom? Je kan apparatuur gewoon op een bepaalde tijd opstarten en neer brengen. Daarnaast kosten kleinere servers niets meer. Het is wel meer gedoe. Het zou aan de opdrachtgever moeten zijn wat die wil gedoe of een rekening.