Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Praktijkvoorbeeld serverless computing

 

Computable Expert

Henri Koppen
Directeur, THINGKS. Expert van Computable voor de topics Digital Transformation en Cloud Computing.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/6169454). © Jaarbeurs IT Media.

6


Lees meer over


 

Reacties

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.

@pavake

ik heb te veel spreiding in kwaliteit mee gemaakt vanuit het bedrijfsleven. er zitten goede kwalitatieve bedrijven bij die hoogwaardig zijn, maar er is eigenlijk heel veel meer pulp dat net zo een glossy folder of web site heeft.

nu is het toepassen van een API of het gebruiken van een S3 bucket als opslag niet echt innovatie te noemen, zeker niet als erg de indruk gewekt wordt dat er niets met encryptie client side gedaan is, of de bucket (zo lijkt het namelijk) open staat en de content zo te scrapen valt. amazon heeft geinnoveerd, henri heeft een handboek bekeken en een flimsy dingetje naar een klant en ongewisse gebruikers doorgeschoven lijkt het wel. en om dat dan nu ineens een nieuwe naam / jas te geven a la serverless, dat zijn de nieuwe kleren van de kijzer gewoon :).

Maar wil de klant een oplossing of een 'innovatie'?
Nazorg en beheer is een ander verhaal... Maar ik weet niet wat hij afgesproken heeft.

Henri heeft een use case en levert een oplossing zonder server "gedoe" voor minder dan een euro per maand aan hosting kosten.

Dan krijgt hij kritiek die uitgaat van volgende aannames :
- klant wil geen afhankelijkheid van aws
- klant wil dat het tonen van fotos beveiligd wordt
- oplossing met servers en die snachts uitzetten en smorgens weer aan kost minder dan 10 euro per jaar
- klant vindt het prima als de web applicatie snachts helemaal niet meer werkt omdat de server uit staat
- klant wil nog meer clientside scripting, dus geeneens een xml/json gegeneerd bestandje op de server
- Henri maakt zich waarschijnlijk :-) schuldig aan het zoeken naar oplossingen in een bepaalde hoek (AWS)
- klant zit vast erg met de patriot act in zn maag betreffende die fotos
- swa ziet veel pulp dus deze serverless oplossing is dat waarschijnlijk ook
- serverless is nieuwe kleren van keizer t.o.v. met server (OS, apache, patches, firewall)
- klant is ongewis.
- het is onduidelijk of de klant een oplossing of innovatie wil en dat is erg relevant als het om 10 euro per jaar gaat.

bespreek deze aannames en waar die opgebaseerd zijn, maar eens met de studenten :-)

@dino

Er mag geen inhoudelijk kritiek zijn dus?

Gisteren heb ik 1400 KM gereden om terug te komen uit Kroatië, dus was het even stil. Ik ga zo mijn auto uitladen, maar hier alvast een serie antwoorden.

Alle mensen is overigens toestemming gevraagd om een foto te gebruiken, dus ook dat proces is afgekaart. Omdat ik het niet relevant vond heb ik het niet vermeld, maar het gaat om 12 groepsfoto's die op een 1080p scherm worden geprojecteerd. Gezichten zijn al nagenoeg niet te herkennen.

Een S3 bucket kun je met een policy afschermen, daarmee kun je instellen dat bronnen alleen van een bepaalde locatie (bijv. publiek IP Adres) gelezen worden en alles daarbuiten er niet bij kan. Versleutelen van foto's levert verder geen enkel voordeel op. Verbinding zelf (data in transit) is overigens wel versleuteld, dus er is zelfs over nagedacht.

Als zaken doen met een Amerikaan bedrijf (patriot act zoals genoemd) een issue is, waarom heeft dat nagenoeg *iedereen* een iPhone of (vaak niet goed up to date) Android?

Overigens noem ik AWS omdat we dit in dit geval gebruikt hebben en om man en paard te noemen waardoor het praktisch is. Het is niet bedoeld als reclame, Azure en Google Cloud Platform hebben ook prima alternatieven waarbij Azure zelf veelal geprezen wordt. Natuurlijk zou OpenWhisk een mogelijkheid zijn (mijn techneuten zijn open source minded), maar dat is een geheel andere aanpak met veel meer implicaties. Ik heb het artikel geschreven om wat kennis te delen niet om AWS te promoten.

Even een kleine 5 euro per maand server gebruiken vind ik geen goede oplossing. Een virtuele server kost namelijk geen 5 euro. Het is ook onderdeel van je "attack surface" geworden, hij moet in beheer en onderhouden worden, heeft credentials nodig, etc. Dus de werkelijke kosten daarvan zijn veel hoger.

Helemaal geen server "compute" gebruiken lijkt geen goede oplossing. De aard van enkel Javascript is namelijk dat je weinig kunt verbergen en dan loop je al snel tegen beperkingen aan met lees en schrijfrechten.

Overigens als je wat scripts prutsen vind, dan heb ik nieuws voor je. De gehele front-end ontwikkeling is één grote ghetto aan script, libraries en frameworks. ReactJS / Angular etc bestaan alleen maar uit wat losse scripts om CSS en Jquery etc. nog buiten beschouwing te laten.

De beschreven oplossing is overigens gemaakt met cyber security in het achterhoofd. Cross-site request forgery, etc. zijn niet aan de orde. Dat Lambda in de basis een script is wat afgevuurd wordt heeft niets te maken met dat het daarom maar wat prutsen is, hier zit een *hele* wereld achter die juist zo mooi is als je erin verdiept. Nogmaals, mijn artikel is om te prikkelen, mogelijkheden te beschrijven en hieraan ook echt invulling te geven. Meer dan de normale bla bla artikelen die allemaal vergezichten beschrijven waarvan het nut nog moet worden aangetoond. Om perspectief te geven, deze oplossing is in de basis binnen 2 dagen gerealiseerd, her-deploybaar, her-bruikbaar en als repository forkbaar om ook andere cases in te zetten.

Wij onderzoeken en gebruiken techniek en daarom leren wij. Niet alles is goed, maar dat merk je pas als je er mee werkt en zo lopen wij ook voorop. Vlieguren maken is de belangrijkste methode om ervaring op te doen, daar zijn geen shortcuts voor.

Zo hebben cloud functions ook aspecten waar je rekening mee moet houden. Uiteindelijk draait alle compute ergens dus als een functie een tijd niet gebruikt wordt heeft deze een opwarm tijd nodig (first execution). Als iets tijdkritisch is zul je hier dus rekening mee moeten houden. Daarnaast is serverless vaak ook een vendor lock-in. Dat is gewoon iets wat je altijd mee moet nemen. Wat je op AWS Lambda bouwt kun je niet snel overzetten naar iets anders.

En nogmaals. Wij zijn AWS gebruikers, dus logisch dat als we iets nieuws willen proberen we AWS een logische keuze is.

Ik zat voor mijn tent en wilde dit artikel schrijven om kennis te delen. Kritiek is prima en zoals beloofd geef ik daar ook antwoord op. Het doel was een server less voorbeeld geven, niet alle ins en outs er omheen, dat viel eigenlijk buiten de scope.

Als je nog meer wilt weten, lees ik dat wel. Bedankt voor de levendige discussie.

"Cross-site request forgery, etc. zijn niet aan de orde."

Een browser kan via een json in de bucket. In die browser kan er een CSRF dus scrapen of zelfs (afh van details) uploaden.

"bucket op ip nr"

Je bucket op ip range dicht zetten betekent nog steeds dat op locatie met misschien de gratis locale wifi gescraped kan worden. Klant moet dit risico weten onafh van oplossing.

"iphone ... android"
Neemt niet weg dat jij dan dus ook maar alles op AWS moet duwen zonder toestemmingen van klant en gefotografeerden. Twee keer fout is niet een keer goed.

De zwakte is dat er geen client side encryptie is, dus data is onveilig in cloud. Zelfs AWS wijst je daar op!

"wij doen AWS dus kijken we naar AWS oplossing"

Is dus tochwel de hamer die overal een spijker in ziet.

"2 dagen werk"

Is dus wel een beetje hap snap prutsen dan.

Swa, Je haalt nu allemaal irrelevante details aan terwijl je niet weet hoe het is opgezet en wat er is afgesproken, dus gissen en speculatie. AWS wijst je op het niet hebben van encryptie *afhankelijk* van hetgeen wat je met de files in de bucket doet. Dropbox sloeg ook de privé bestanden op in S3 buckets, dat is een hele andere use case, hoe je een bucket gebruikt. Met je laatste opmerkingen laat je zien dat je zit te trollen, wat heeft een discussie dan nog voor zin? Jammer, want je geeft wel hints dat je de materie begrijpt.

"Jammer, want je geeft wel hints dat je de materie begrijpt"

Goed bedoeld advies:

Dan denk misschien nog maar eens een extra keertje goed na over de zaak...

Met dank Henry. N.a.v. "Nogmaals, mijn artikel is om te prikkelen, mogelijkheden te beschrijven en hieraan ook echt invulling te geven. Meer dan de normale bla bla artikelen die allemaal vergezichten beschrijven waarvan het nut nog moet worden aangetoond." vind ik het een verademing om zo'n lekker concreet voorbeeld (in dit geval van serverless computing) te lezen. En blijkbaar prikkelt het nog ook.

Dankje Ad,

Het draait naar behoren en werkt echt zoals het bedoeld is. Niemand heeft nog naar een vergelijkbare Docker case gevraagd :-)

Heb ook nog een concept liggen over GraphQL (Google/Bing/DuckDuckGo dat) als alternatief voor REST API's. De eerste resultaten in productie zijn zo goed dat we serieus overwegen om dit de standaard te maken.

Jouw reactie


Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren

Je naam ontbreekt
Je e-mailadres ontbreekt
Je reactie ontbreekt
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×