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.
@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.