Open source en serverless - Niet zonder een gezonde community

Serverless computing ontwikkelt zich steeds verder. Met alle closedsource- proprietary serverless systemen die de grote cloudproviders aanbieden, kun je je echter afvragen of dit niet slechts één groot excuus is voor vendorlock-in. Opensource- en serverless systemen als Apache OpenWhisk helpen dit voorkomen. Justin Halsall, developer advocate bij IBM, gaat in op de trend en het belang van een gezonde opensourcecommunity.

Serverless computing wint snel terrein binnen de softwareontwikkeling. Door de extra abstractielaag bij cloudtoepassingen hoeven ontwikkelaars die 'serverless gaan', zich geen zorgen te maken over de infrastructuur terwijl zij hun code ontwikkelen. Zo'n beetje alle grote cloudpartijen hebben inmiddels een eigen serverless computingplatform. De volgende stap in de evolutie is open source en serverless. Justin Halsall spreekt binnenkort tijdens de Developer Night bij IBM Nederland over het fenomeen. Daarbij geeft hij een kijkje achter de schermen van wat IBM doet om open source en serverless met Apache OpenWhisk en Knative verder te brengen.

"Ik denk dat het de belofte van de cloud is", verklaart Halsall de populariteit van serverless computing. "Die luidde namelijk altijd al dat je een applicatie in de cloud kon zetten en dat je verder heel weinig hoefde te managen. Dat is in de praktijk tegengevallen; veel organisaties hebben hun SysOps weliswaar vervangen door DevOps, maar op platformniveau moeten ze nog altijd veel inregelen om applicaties werkend te krijgen. Daarom is serverless zo interessant. Je komt nu een stap dichter bij die oorspronkelijke belofte dat alles in de cloud voor je wordt gedaan." Toch blijft het succes grotendeels afhankelijk van de developercommunity, want met alle closedsource- proprietary serverless systemen die door grote cloudproviders worden aangeboden, kun je je afvragen of dit niet slechts één groot excuus is voor vendor lock-in.

Standaardisatie leidt tot integratie

Zonder standaardisatie is het risico op lock-in reëel, zegt Halsall. "Ik denk dat veel cloudpartijen serverless als strategie zien om klanten aan zich te binden. Doordat iedere vendor een eigen manier heeft om met jouw code om te gaan in de cloud, is het lastig te migreren naar andere platforms en andere partijen." Dit is ook precies waarom open source en serverless zo interessant is. Zo bracht IBM het distributed serverless platform OpenWhisk onder bij de Apache Software Foundation. "Doordat het volledig open source is, kun je het in principe ook in je eigen datacenter draaien. En doordat er een gemeenschap achter zit, is het ook gemakkelijker om systemen met elkaar te koppelen. Bijvoorbeeld Knative, dat door Google is ontwikkeld als aanvulling op Kubernetes. In beginsel was dit niet voor serverless gebouwd, maar vanuit de OpenWhisk-comunity zijn nu veel mensen bezig om Knative te integreren met de backend van OpenWhisk."

Halsall, die opgroeide in Nederland en werkt vanuit New York, besteedt zijn tijd en energie voornamelijk aan developers en start-ups. In het verleden was hij onder meer technology evangelist in Europa en Azië bij de clouddienst SoftLayer, en director of developer programs bij Bottlenose, een start-up die trends op social media analyseert. In zijn rol voor IBM is hij deels developer en deels public speaker. "Oftewel, een public facing developer. Bij IBM is het een vrij nieuwe rol, die dient om onze producten onder de aandacht te brengen en, belangrijker nog, feedback te verzamelen van developers. Die vinden wij heel belangrijk, omdat we daarmee onze producten kunnen verbeteren. Sowieso vind ik het heel tof dat we een deel van onze producten open source hebben gemaakt en breder hebben getrokken dan alleen IBM. Apache OpenWhisk is daar een mooi voorbeeld van. Verschillende grote bedrijven, bijvoorbeeld Adobe, zijn betrokken bij de ontwikkeling van het platform."

IBM en open source

De overname van Red Hat door IBM was vorig jaar groot nieuws in de opensourcegemeenschap en een duidelijke indicatie van de lijn die IBM kiest als het gaat om open source. Waarom is open source zo interessant voor IBM en wat is de rol van het bedrijf binnen deze community? "Stiekem zijn we er al heel lang mee bezig", zegt Halsall daarover. "Als je kijkt naar veel bekende opensourceprojecten, is IBM altijd al erg toegewijd geweest aan open source, op verschillende manieren. Alleen werd daar nooit zoveel over gepraat, iets wat we eigenlijk best meer hadden kunnen doen." Een voorbeeld van zo'n bekend project is NodeJS, waar onenigheid in de community op een gegeven moment leidde tot een fork in het project en de community. "IBM is een belangrijke bemiddelaar geweest in het weer bij elkaar krijgen van de groepen, waardoor de gemeenschap gezond is gebleven."

Serverless computing tijdens Developer Night

Tijdens de Developer Night zal Halsall verder ingaan op de staat van serverless computing en daarnaast laten zien hoe developers aan de verschillende projecten kunnen bijdragen. "Iets wat ik zelf heel belangrijk vind, is ondersteuning bieden in een nieuwe taal. Zelf heb ik geholpen met de ontwikkeling van Ruby, op een moment dat de taal door geen enkele van de grote cloudproviders ondersteund werd, omdat het niet zo hip meer is als bijvoorbeeld Node.js en Go, en niet zo gevestigd als Java. Dat vond ik jammer omdat het wel een grote community was. Daar hebben we toch support voor kunnen creëren, wat druk zet op de andere grote platforms om nu ook met Ruby-support te komen. Een ander voorbeeld is PHP, waarvoor dankzij de community ondersteuning is gekomen in onder andere OpenWhisk. Dat zijn mooie voorbeelden van hoe je als groep ontwikkelaars iets voor elkaar kunt krijgen."

Overigens is Halsall zeker niet de enige interessante spreker tijdens de Developer Night. Zelf ziet hij erg uit naar de presentatie van Sam Aaron. “Ik ken Sam al heel lang, uit de tijd waarin we beiden in Utrecht woonden. Zeker in het begin van de Ruby-community heeft hij daarin een belangrijke rol gespeeld. Inmiddels woont hij in Engeland en heeft hij zijn Sonic Pi programmeertaal voor het maken van muziek verder ontwikkeld. Het is leuk om te zien dat hij ook terugkomt naar Nederland om hier te spreken.”

Open source loont

De opensourcegemeenschap is in staat om veel voor elkaar te krijgen. Hiervan deel uitmaken is voor ontwikkelaars ook heel waardevol voor hun professionele ontwikkeling en contacten. "Het is leuk om bij te dragen, de reacties van anderen te zien die het tof vinden wat jij doet en daardoor naar je toe komen voor advies." Bovendien profiteren werkgevers flink mee van de inspanningen. Halsall denkt dat het voor hen vaak loont om hun medewerkers te ondersteunen en hen in staat te stellen om bijdragen te leveren. Hij noemt banken als voorbeeld. "Cobol is een van de oudste programmeertalen en is in de financiële sector nog veel in gebruik. Het managen van de infrastructuur daaromheen betekent veel werk. Ik ken developers die Cobol in een serverless omgeving draaien, meestal via een Docker-container. Maar als ik een bank was, zou ik willen dat er een first class citizen runtime gedraaid kan worden voor Cobol, zodat ik er minder hoofdpijn van heb."

---

Dit artikel is geen redactioneel artikel, maar een advertorial. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen, daar zullen collega's aanwezig zijn om jouw vragen en/of opmerkingen te bespreken/beantwoorden.

Reacties (69)

[Verwijderd]

Oh, heet 'in de cloud' nu 'serverless'? Het kan al 20 jaar, dat je je mailserver uitbesteedt en op de server van iemand anders werkt en daar al je documenten opslaat, toch? Kijk maar naar bijvoorbeeld Google G Suite (voorheen Google Apps) en Office 365 voor bedrijven. En je eigen apps op die server draait (of op een andere server), of diensten afneemt die je niet meer zelf hoeft te installeren maar die ook ergens in de cloud staan, zoals je boekhoudprogramma of wat dan ook. Of mis ik iets?

[Gopher]

Dat is in theorie cloud. Serverless is toch net een andere definitie. Maar dit kun je het beste even googlen als je oprecht interesse hebt in de termonologie.

Ik zie veel mensen het afdoen als, write only your code (en geen server beheer). Maar eigenlijk is het iets minder simpel dan dat (of juist wel als je het letterlijk neemt). Het gaat met name over kort levende functies, die wat logica uitvoeren en daarna weer gekilled worden, zo hoeft het helemaal niet zo te zijn dat jou applicatie leeft wanneer het niet gebruikt word. Dus niet exact hosting, maar korte instanties van een deel van je applicatie.
Je kunt dus prima dit toepassen naast je grote monolithische applicatie en dan is de vendor lock in niet zo gigantisch, aangezien je gewoon wat JS of Java schrijft (bijvoorbeeld) of zoals TheSec hieronder schrijft een Dockertje.

Het is overigens wel echt iets wat eigenlijk alleen relevant is voor Software (ontwikkeling). Niet echt tools die je gebruikt zoals e-mail, documentenbeheer hoewel deze daar dan weer gebruik van kunnen maken.

[Reactie gewijzigd door Gopher op 22 juli 2024 17:58]

[flowerp]

> Het gaat met name over kort levende functies, die wat logica uitvoeren en daarna weer gekilled worden

Hey, wacht eens even. In 1995 noemde we dat CGI. Het deed precies dat.

> zo hoeft het helemaal niet zo te zijn dat jou applicatie leeft wanneer het niet gebruikt word.

Zo'n beetje vanaf 1996 gingen we juist kijken hoe we applicaties wel konden laten leven, omdat telkens opstarten en killen en het niet- of moeilijk kunnen gebruiken van een snelle in-memory/in-process cache juist voor veel overhead zorgde.

[Gopher]

Yes, maar tijden veranderen, zo is het tegewoordig steeds gemakkelijker om applicaties via loadbalancers automatisch op te schalen, of kleine losse applicaties "micro services of zelfs losse scriptjes" tijdelijk op te starten.

Een verschil met CGI (als ik het niet compleet verkeerd begrijp, want 1996 was ik 8 en ben er wel mee in aanraking geweest maar minimaal), is dat bij bijv. een service als Lamda zo'n mini service geboot word, deze kunnen vaak wat trager starten. Ik geloof dat CGI gewoon 'n script aftrapt, een beetje zoals PHP over het algemeen werkt. Dit kan prima werken, alleen merk je (ondanks dat het tegenwoordig minder is) dat voor elk request weer een nieuwe thread en nieuwe stack opgebouwd moest worden.

Dan is tijdelijk een of enkele services starten veel schaalbaarder.

(Moet wel zeggen, dat 't *vaak* symptoombestrijding is en mensen maar gewoon wat efficienter hun code moeten schrijven)

[flowerp]

> dat voor elk request weer een nieuwe thread en nieuwe stack opgebouwd moest worden.

Een nieuwe thread? Nee hoor, zeker niet.

Gewoon een compleet nieuw process voor elke request

Was gewoon een soort console app die opgestart werd.

[MadEgg]

Als ik dataverwerkingsprocessen draai om Amazon EMR dan is dat niet "serverless" maar maar wel "in de cloud". Als ik datzelfde dataverwerkingsproces draai op Google Dataflow dan is het "serverless". Opeens betaal ik niet voor de cluster met een bepaalde verwerkingscapaciteit maar per CPU cycle en MB RAM, waarbij de beschikbare capaciteit aangepast wordt aan de workload.

Als ik mijn data in Google Cloud SQL stop dan draait het wel "in de cloud" maar niet "serverless" - ik betaal wederom voor de toegewezen hoeveelheid storage en nodes. Stop ik het in plaats daarvan in Google Big Query of Google Firestore dan is het serverless en betaal ik per read/write en per MiB opgeslagen data per tijdseenheid.

Als ik mijn webapplicatie op een Google Compute Instance draai, draait het wel in de cloud maar betaal ik voor de specs van de virtuele machine. Draai ik de applicatie op App Engine of via Google Cloud Functions dan betaal ik opeens per request en per MiB gebruikt geheugen en netwerkverkeer.

Het betaalmodel is heel anders en bij lage load vaak veel goedkoper, tenzij je programmeerfouten maakt, dan kan de boel opeens exploderen. Mooi meegenomen is dat je amper tijd kwijt bent aan de configuratie van de server / cluster. Je kunt soms wat limieten aan de autoscaling meegeven maar de details hoef je je niet mee te bemoeien.

[Verwijderd]

Okay, het een dus een soort 'pay as you go'. MailChimp bijvoorbeeld heeft maandelijkse abonnementen (een paar staffels), maar had eerst ook dat je gebruikt per daadwerkelijk verstuurde mailing (is nu zo te zien wat weggemoffeld). En ik geloof dat Google dat ook met zijn Maps API heeft gedaan, waar het eerst gratis was (en nog steeds geloof ik) moet je nu wel een creditcard invullen en betaal je daarna per impressie ofzo.

Maar dan ga ik het vanzelf merken, ben een online Angular cursus aan het doen en ze gaan ook met Firebase aan de slag dus dan zal het via Google Firestore ook wel duidelijk worden. Ik vroeg me al af hoe je bij zulk soort dingen dan de eventuele fouten in je SQL queries kunt zien, als dat allemaal uitbesteed is, maar dat zal dan ook nog wel duidelijk worden, hoop ik.

[Cartman!]

Je haalt SaaS (Software as a Service) door elkaar met de andere *aaS varianten (Backend, Infrastructure, Functions). Bij SaaS neem je een licentie af (vaak op basis van t aantal gebruikers) en bij de andere varianten neem je iets af waar je vervolgens zelf mee aan de slag gaat.

[Verwijderd]

Of mis ik iets?

Ja, Office 365 betaal je per maand ongeacht gebruik.

Je vergelijking zou alleen opgaan als Office 365 aan zou bieden dat je per geopend word document of per uitgevoerde Excel macro zou betalen.

[Tokkes]

Nee, serverless draait 'in de cloud'.
Net zoals virtuele machines van AWS/GCP/Az/Ali/... dat doen.
Net zoals load balancers, of DNS service.
AWS biedt ook Mechanical Turk aan als Cloud service.
Of Ground Stations voor satellieten.
En de schaal-logica van groepen servers die bijvoorbeeld automatisch bijschalen naarmate load.
En flat object storage zoals S3 of Google Storage.

Al het bovenstaande en meer wordt tegenwoordig aangeboden door minstens 1 Cloud Service Provider en geadverteerd als zijnde een 'clouddienst'. Ergo "de cloud" is een 'umbrella term' voor de verschillende diensten die op een platform worden aangeboden, lijkt me?

[cyberwookie]

Wat is severless eigenlijk? wordt het al ergens gebruikt?

[CAPSLOCK2000]

Het is een (vergaande) vorm van "in de cloud" die ergens tussen PAAS en SAAS in zit.
Het idee is dat niet zelf (bv) PHP en MySQL gaat installeren, maar een omgeving krijgt waarin PHP en SQL klaar staan en direct gebruikt kunnen worden. Als programmeur hoef je niks zelf te installeren, je begint direct met programmeren. Het gaat echter niet zo ver dat het complete (eindgebruiker-klare) applicaties aanlevert (zoals bij SAAS), het gaat om bouwblokken zoals databases, webservers, mailservices en programmeertalen, die niet alleen voorgeinstalleerd zijn maar ook al (gedeeltelijk) geintegreerd zijn.
Het heet "serverless" omdat je niet meer nadenkt over hoeveel VM's of CPU's er onder zitten of op welk OS het draait (zoals bij PAAS), dat is allemaal de zaak van de cloud-provider. Als ontwikkelaar weet je alleen dat je op een bepaalde plek code kan neerzetten en die wordt dan gedraaid.

[Robbierut4]

Zoals jij het uitlegt lijkt het mij gewoon een uitgebreide variant van wat ik heb met shared hosting?
Daar staat ook alles al klaar om gebruikt te worden, kwestie van met 1 knop een wordpress pakket te installeren en klaar. Of eigen code erop te ftp-en natuurlijk.

[Kees]

Behalve als jij ineens heel veel bezoekers krijgt, dan moet je na gaan denken over het schalen van je applicatie, mischien een tweede shared server erbij nemen, of de database op een aparte server etc.

Bij serverless betaal je voor het gebruik, dus als je 1 miljoen queries doet betaal je bv 10 euro, als je 100 miljoen queries doet betaal je 1000 euro, maar je hoeft niet zelf na te denken over snelheid van de opslag, backups van je db server, performance van je db server etc.

Hetzelfde voor de webserver, je hoeft niet meer na te denken over de performance, hoeveel webservers je wil, met welke settings je php moet tunen etc, dat word dan voor je gedaan.

[Sharkoon]

Dat maakt het toch ook weer juist ingewikkeld om je kosten inzichtelijk te krijgen voordat je aan zoiets begint?

[Kees]

Ja klopt. Maar het is, zeker met lage volumes, waarschijnlijk goedkoper dan het zelf op te zetten. Op hogere volumes gaat het wel lonen om het zelf te doen zoals altijd.

[Cergorach]

En zelfs bij hogere volumes zie je vaak dat men korting gaat geven op de gebruikte resources al je tussen x en z afneemt. Dat zorgt er vaak voor dat het alsnog goedkoper is tenzij je een enorme cluster zelf nodig heb...

[Cartman!]

Nee, jij betaalt namelijk altijd voor die (shared) server of ie nu wel of niet gebruikt wordt. Bij serverless betaal je in principe alleen voor het gebruik. Je kunt dus een website hebben die maar 5 cent per maand kost als je slechts een paar bezoekers hebt. Heb je de maand erop 2 keer zoveel bezoekers betaal je bijvoorbeeld 10 cent.

[jeroentjo]

Om iets hieraan te mogen toevoegen: de resource utilization wordt automatisch voor jou geregeld. Bij shared hosting of een traditionele VPS e.d. heb je fixed resources. Bij "serverless" wordt er automatisch voor jou geschaald. Hierdoor is het mogelijk om op bepaalde plekken veel traffic te kunnen verwerken, en op anderen juist niet. Natuurlijk bestaat dit principe al in de vorm van "elastische" servers (EC2 etc), serverless maakt het mogelijk om dit nog verder op te splitsen. Je betaalt daarbij overigens enkel voor het gebruik (duratie van de functie in miliseconden als ik het goed heb). Hierdoor hoef je niet langer "uit voorzorg" een dikke server te huren en betaal je dus naar rato.

[Reactie gewijzigd door jeroentjo op 22 juli 2024 17:58]

[CAPSLOCK2000]

Daar heeft het wel iets van, maar het gaat verder. Wat jij omschrijft levert 1 website op die op 1 server draait en 1 database als backend heeft.

Misschien heb je een goede hoster die alles dubbel heeft uitgevoerd om de beschikbaarheid te verhogen, maar dan houdt het ook wel op. Als die ene webserver niet meer voldoet dan moet je een tweede instantie inrichten en op een of andere manier de load verdelen.
Als je nog meer capaciteit wil dan koop je blokken ter grote van een hele VM bij en die ga je aan elkaar knopen.

In serverless computer gaat dat allemaal naadloos. Je huurt geen webserver, maar je betaalt per commando of per query ofzo. Typisch zijn het geen hele applicaties die je afneemt maar functies. "sorteer deze data", "maak hier een PDF van", "stuur een bericht naar Twitter".

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 17:58]

[3raser]

Serverless is precies het tegenovergestelde dan wat het woord doet vermoeden. Ja, het hebt servers nodig. Het zijn alleen niet jouw servers en je hoeft ze ook niet meer te configureren. Jij hoeft alleen nog maar je code te uploaden en je bent live.

Ik vraag me af in hoeverre je echt geen configuratie meer nodig hebt. Zoveel mensen zoveel wensen. Stel dat je een PHP applicatie hebt die speciale extensies vereist. Zijn er dan serverless servers die daar standaard aan voldoen? Of geef je gewoon door aan je cloud-boer wat je nodig hebt zodat hij het kan installeren? In dat geval lijkt serverless meer op managed VPS.

[Uberprutser]

Daarom is vaak beperkt welke code je kan gebruiken. Bij AWS bijvoorbeeld alleen Node.js, Python, Ruby, Java, Go en .NET en dan alleen bepaalde versies.

[Cartman!]

Met de Runtime API is dat niet langer van toepassing bij AWS: https://docs.aws.amazon.c...test/dg/runtimes-api.html

[MadEgg]

Op Google Cloud heb je Cloud Functions waar je code in Python en Node.JS kunt draaien. Daarbij upload je naast je code een requirements-file met dependencies. Vervolgens zocht Cloud Functions ervoor dat de dependencies beschikbaar zijn als je code gedraaid wordt. Bij het deployen geef je op welke versie / runtime je wilt gebruiken en daarmee heb je dus ook invloed op de versie van de interpreter die gebruikt wordt.

AWS heeft ongetwijfeld iets vergelijkbaars.

[DeathMaster]

Gewoon, in de cloud, dus dat wordt al volop gebruikt. De voordelen lijken me echter beperkt.

[Uberprutser]

Financieel is het vooral interessant.

Ik heb whitepapers gelezen waar bedrijven ruim 70% besparen op de computeresources sinds hun applicaties serverless zijn.

[V3LoXy]

Met de nodige ervaring kan dat zeker waar zijn, uit mijn eigen ervaring weet ik dat het heel snel mis kan gaan. Een domme fout kan heel snel uitdraaien op een hoge factuur, in mijn geval viel het nog mee maar ik heb recent iets soortgelijk gezien waar een bedrijf een rekening kreeg van 30000 euro.

Als je op een gewone server een fout maakt trek je deze in het ergste geval plat, bij "serverless" heb je autoscaling, je trekt daar niet zomaar iets plat - de kosten gaan gewoon omhoog en blijven oplopen. Vooral als je even wil experimenteren met serverless (zoals ik 2 jaar geleden) mis je de ervaring om dat soort situaties te vermijden.

[Reactie gewijzigd door V3LoXy op 22 juli 2024 17:58]

[MadEgg]

Dat soort dingen heb ik ook meerdere malen meegemaakt inderdaad. Datastore / Firebase / Firestore zijn extreem duur bij enige significante belasting en het schaalt gewoon mee dus de kassa heeft al veel te hard gerinkeld voordat je doorhebt dat het geld aan het verdampen is.

Een Memorystore (redis) cache ervoor en de kosten verschrompelden. Maar het kan veel te hard gaan, en je hebt zelden voldoende maatregelen om je budget te beperken.

Serverless is absoluut niet goedkoop. Het is wel makkelijk en je bespaart zeker op personeelskosten van wat systeembeheerders. Maar fouten zoals deze zullen blijven voorkomen en daarmee compenseer je daar wel weer voor.

[Cartman!]

Serverless is absoluut niet goedkoop.

Dat kun je niet zo zeggen, dat hangt puur van je use case af natuurlijk. Je zult per geval moeten bekijken of t wel of niet loont om het te gebruiken.

[Tyrian]

En in de cloud datacentra hangen geen servers?

[Cartman!]

Natuurlijk wel, alleen is dat voor jou als gebruiker ervan irrelevant.

[mkools24]

En in de cloud draait het natuurlijk ook gewoon op servers, alleen jij als klant ziet dat niet.

De voordelen lijken me wel duidelijk, je hoeft voor je dienst geen servers meer te beheren. Bijv SQL as a service of Azure Domain controllers as a service etc.

Ik vind het zelf ideaal maar ik snap tegeljkertijd ook de vendor lock-in bezwaren.

[latka]

Vendor lock-in en een nog verder afnemend begrip van programmeurs voor de onderliggende platformen en abstracties met allerlei (performance) problemen tot gevolg die niet meer verklaard kunnen worden door de bouwer. Ik zie het met Cloud al: er zijn gewoon ontwikkelaars die zich niet realiseren dat cloud=netwerk=latency en dan roepen dat de ADSL lijn te sloom is voor de applicatie terwijl de lichtsnelheid van hier tot het cloud-dc het werkelijke probleem is.

[MewBie]

Oftewel: same shit, different buzzword.

[DeathMaster]

Niet helemaal, het kan zijn voordelen hebben tegenover het runnen/beheren van een klassieke server maar zoals wel vaker als het om de cloud gaat, wordt ook dit weer aangeprezen als de oplossing voor alle problemen, terwijl 95% van alle bedrijven hier geen enkel baat bij zullen noch kunnen hebben.

[dmantione]

Een klassieke fout die in de informatica keer op keer wordt gemaakt is dat het niet belangrijk is wat ergens onder draait. Daardoor hypes als de "cloud" en nu dit soort dingen, omdat de belofte dat het allemaal veel eenvoudiger wordt potentieel veel geld kan besparen en dus hebben beslissingsnemers er altijd wel oren na. De gevolgen van zo'n beslissing blijken vaak later, als iets bijvoorbeeld niet optimaal presteert en daar weer allerlei kosten uit voortvloeien.

[Cartman!]

Waarom is cloud een hype volgens jou? Volgens mij is de populariteit nooit afgenomen, integendeel zelfs. Zelfs serverless computing bij AWS in de vorm van Lambda bestaat al bijna 5 jaar en is daarmee dus niet iets nieuws.

[dmantione]

Cloud een hype noemen gaat me te ver, want er is een duurzame markt ontstaan. Onderdeel van de definitie van een hype is iets dat weer overwaait en dat is bij de cloud niet het geval. Dat gezegd, is de methode om de cloud te verkopen te wijzen op lokale hardware die dure infrastructuur en dure mensen nodig heeft. In praktijk is de cloud in heel veel gevallen zeker niet goedkoper, door het huurmodel zelf, maar al helemaal als de gevolgen van niet-optimale hardware worden meegerekend.

[Cartman!]

Niet-optimale hardware merk je in principe niks van; dat is het hele voordeel van dat de machines voor je verborgen zijn. Mijn 2 collega's beheren 200+ load balanced omgevingen; dat noem ik vrij efficient

[dmantione]

Zeg dat niet te snel: Als je 200 virtuele servers moet huren terwijl het op 1 of 2 fysieke servers past, dan is dat een schoolvoorbeeld van het paard achter de wagen spannen.

[Cartman!]

Zodat we resources moet gaan verdelen voor onze klanten en ze last kunnen krijgen van elkaars traffic? Nee, dankje. Die klanten betalen goed voor een automatisch schalende omgeving ook

Om nog maar te zwijgen dat onze klanten over de hele wereld zitten en de ene dus z'n hosting in Singapore wil, de ander in Frankfurt en weer n ander in Virginia.

[Reactie gewijzigd door Cartman! op 22 juli 2024 17:58]

[dmantione]

Als je kosten op de infrastructuur wilt besparen, is dat inderdaad wat je moet doen. Als je argumenten hebt het niet te doen, prima. Er is geen verplichting kosten te besparen. Maar dat is wel hoe de cloud verkocht wordt en dat is waar ik op wil wijzen.

[Cartman!]

En in veel gevallen gaat dat ook gewoon op.

[Yggdrasil]

Of 'de cloud' goedkoper is hangt vooral af hoe men daar gebruik van maakt. Simpelweg een applicatie uit datacenter op een identieke manier in de cloud draaien kost meestal meer, inderdaad vanwege het OPEX (huren) vs. CAPEX (kopen) principe. Servers die 24x7x365 draaien kun je beter zelf hosten.

Als men applicaties echter 'cloud-native' bouwt, dus rekening houdend met de nieuwe mogelijkheden die cloud-hosting biedt, dan zijn besparingen vrij makkelijk te behalen. Bijv. door gebruik van autoscaling en event-driven API's draai je niet meer dan je op een moment nodig hebt. Natuurlijk is het niet zo simpel als de verkoper het laat klinken, dat is het nooit.

[Uberprutser]

Lees hier maar eens: https://aws.amazon.com/serverless/

[Squixx]

Serverless houd ongeveer het volgende in:
Het draaien van (web)applicaties, zonder het 24/7 huren/kopen/onderhouden van een server.

Bijvoorbeeld een static website op aws S3, waarbij je alleen voor storage & access gebruikt.
Of aws lambda / microsoft functions, waar je betaald per 1.000.000 hits op je functie, maar geen 'statische' run kosten hebt.

Afhankelijk van je use case kan het je redelijk wat geld schelen.

[P_Tingen]

Serverless is eigenlijk een gekke term want je hebt wel degelijk een server, alleen niet in eigendom en ook niet in beheer; wat dat betreft zou HaaS (Hardware as a Service) een betere term zijn. Of Server-as-a-service, maar de afkorting SaaS gebruiken we al en Server-Service geeft nogal een vervelende afkorting

[Cartman!]

Het is juist geen hardware as a service; in t geval van FaaS (Functions) lever je alleen een stukje code en wordt de onderliggende software (OS+Runtime) voor je beheerd. Bij BaaS (Backend) heb je over t algemeen alleen APIs om mee te praten en beheer je zelf hoogstens alleen bepaalde instellingen (bijv parameters voor je relationele database).

[Tokkes]

Server as a Service = IaaS(/PaaS (afhankelijk hoe je "server" interpreteerd). )
HaaS => AWS heeft i3.metal servers beschikbaar. Direct op het metaal, dus = Hardware. Ook hebben ze 'Device Farm'.
FaaS (Functions as a Service) is ideaal als term.

Waar je met IaaS, PaaS, SaaS. HaaS meestal gewoon doorbetaald ook al wordt het niet gebruikt maar dient het wel beschikbaar te zijn (bijvoorbeeld een kleine lokale webshop tussen 2 en 5 's ochtends lokale tijd of (SaaS voorbeeld) je bent op vakantie maar je gebruikt Adobe Creative Cloud niet voor 2 weken - maar je betaald wel door), is dat met FaaS niet zo: je betaald enkel voor de runtime-tijd die nodig was om je functie uit te voeren.

[Ruvero]

Met Zappa kun je hele webapplicaties (bijv Django) serverless draaien via AWS Lambda functies.

[Yggdrasil]

Maar is dat niet een beetje hetzelfde als een lift&shift van servers uit je datacenter naar de cloud? Dat kost je gegarandeerd meer dan het lokaal koste, totdat je ze ombouwt naar cloud-native architectuur.

[Tokkes]

Hoeft niet. Je kan in S3 je static content plaatsen, en dan met AngularJS oid aan de slag en zo met je lambda api endpoints praten. Hoef je geen VM voor op te spinnen.

[Tokkes]

de website http://acloud.guru is geheel serverless opgebouwd.

dmv S3 voor de static content, Auth0 of 0Auth voor autheticatie, DynamoDB en AWS API endpoints en lambdafuncties, alsook de Elastic Transcoder, heb je een leerplatform dat automatisch schaalt naar load/demand en je hoeft er geen enkel linux commando voor te kennen, VM's voor op te spinnen, network flows te configureren/firewall rule table op te stellen....

Kost volgens Ryan K. ook "mere pennies" per uur gekeken HD video door een gebruiker. En daar quote ik hem op uit een face-to-face gesprek, trouwens.

[Reactie gewijzigd door Tokkes op 22 juli 2024 17:58]

[GVeen]

Kan iemand een voorbeeld geven van een typische applicatie waarbij je serverless cloud wil gebruiken?

En, wat wordt bedoeld met "first class citizen runtime"?

[MMaI]

Serverless is vooral bruikbaar als je hele applicatie past binnen één van de Cloud aanbieders. Bijvoorbeeld analytics waarbij je client een standaard hoeveelheid data verstuurd wat vervolgens verwerkt, verrijkt en opgeslagen moet worden is prima serverless te doen met Amazon Kinesis.

Wat serverless in de praktijk meestal betekend is dat iemand anders de server bouwt en onderhoud en jij alleen je code hoeft te schrijven.

Een first class citizen is dat jouw taal zonder verdere vertaling of abstractie uitgevoerd wordt. In het geval van bvb cobol zit er een JavaScript emulatie laag tussen.

Enerzijds is serverless praktisch omdat je geen infrastructuur kennis nodig hebt, aan de andere kant betekent het dat je financieel en technisch afhankelijk bent van waar je cloud provider heen wil. Daarmee is OpenWhisk eigenlijk het slechtste van beide werelden, je hebt de overhead van serverless abstractie, en ook nog infrastructuur nodig.

[Cartman!]

De meest bekende voorbeelden wat erg goed met serverless opgelost kan worden, oa:

- Websites
- APIs
- Chat bots
- Render tools
- Data pipelines

[Yggdrasil]

Met de runtime in serverless wordt bedoeld de taal waarin je je serverless functies kunt draaien. Dit kan bijv. Go, Nodejs, Java of Python zijn.

Met "first class citizen runtime" wordt bedoeld de runtimes die de leverancier van het serverless platform native/actief ondersteund. Hier is dat lijstje voor AWS Lambda. Als je functies werken met een bepaalde runtime (bijv. Nodejs 10) dan hoef je deze zelf niet te onderhouden en hoef je alleen je nodejs code aan te leveren. De cloud provider ervoor dat de runtime geüpdated wordt e.d.

Bij AWS Lambda heb je echter ook nog de optie om een custom runtime te gebruiken. Dat zijn geen first class citizens, dus je moet zelf zorgen dat je zowel de runtime als je functies aanlevert. Het kan een shell-script zijn, een taal die niet ondersteund wordt door het platform of bijv. een niet-ondersteunde versie van een taal die wel ondersteund wordt.

[ViperXL]

Jammer dat zelfs in een adv onwaarheden vertelt worden. Ze gooien het op vendor-lockin maar dat is doorgaans niet waar. Uiteraard heb je dat met specifieke software zoals G-Suite of Office365 wel maar dat is logisch aangezien het een specifiek pakket is. Met bijvoorbeeld MSSQL of Exchange kun je gewoon je data migreren.
Als je een webapplicatie wil draaien kun je kiezen uit party A, B of C maar tegelijkertijd ook gewoon switchen tussen partij A, B of C waarvoor je verder geen aanpassingen hoeft te maken aan je applicatie.

Serverless is inderdaad meer een buzz-word, het is gewoon een container of draait zelf op servers in de backend maar is volledig gemanaged en daar zie je helemaal niks van. Ze geven zelf al aan "veel" aan open-source te doen en proberen met "server-less" en open-source nu een bestaande markt opnieuw aan te boren.

Maar zoals met veel bedrijven zijn ze natuurlijk altijd welkom aangezien dit ons als prosumer/bedrijven meer keuze bied en meer concurrentie geeft.

[Cartman!]

Jammer dat zelfs in een adv onwaarheden vertelt worden. Ze gooien het op vendor-lockin maar dat is doorgaans niet waar. Uiteraard heb je dat met specifieke software zoals G-Suite of Office365 wel maar dat is logisch aangezien het een specifiek pakket is. Met bijvoorbeeld MSSQL of Exchange kun je gewoon je data migreren.

Het gaat hier niet om SaaS (Software as a Service). De vendor lock-in gaat over het maken/gebruiken van specifieke diensten van 1 aanbieder die niet 1 op 1 te vervangen zijn met iets van een concurrent. Denk aan bijvoorbeeld AWS DynamoDB of SQS waar Google of Azure geen drop-in alternatief voor bieden. Anderzijds heb je bij code mogelijk een vendor lock-in (heb je enigszins zelf in de hand) omdat de diverse manieren van hoe je code aangeroepen wordt overal net wat anders is. Die code kun je dus niet weer 1 op 1 van AWS Lambda naar Google Cloud Functions overzetten.

Als je een webapplicatie wil draaien kun je kiezen uit party A, B of C maar tegelijkertijd ook gewoon switchen tussen partij A, B of C waarvoor je verder geen aanpassingen hoeft te maken aan je applicatie.

Zo simpel is dat dus niet

Serverless is inderdaad meer een buzz-word, het is gewoon een container of draait zelf op servers in de backend maar is volledig gemanaged en daar zie je helemaal niks van. Ze geven zelf al aan "veel" aan open-source te doen en proberen met "server-less" en open-source nu een bestaande markt opnieuw aan te boren.

Wel een type managed containers dat in seconden kan schalen van niks naar 10.000 runnende instances; heel "gewoon" noem ik dat persoonlijk niet.

Maar zoals met veel bedrijven zijn ze natuurlijk altijd welkom aangezien dit ons als prosumer/bedrijven meer keuze bied en meer concurrentie geeft.

Zeker goed voor de concurrentie!

[Verwijderd]

"Als je een webapplicatie wil draaien kun je kiezen uit party A, B of C maar tegelijkertijd ook gewoon switchen tussen partij A, B of C waarvoor je verder geen aanpassingen hoeft te maken aan je applicatie."

Nee, in het geval van serverless niet dus. Die web applicatie zal uiteen vallen in het gebruik van een aantal serverless diensten. Op AWS bijvoorbeeld: RDS, S3, Lambda, Cloudfront. Al die diensten zijn AWS-specifiek en je kunt zomaar niet overstappen naar een andere cloud provider.

[Alphyraz]

Bij mij op het werk worden steeds met serverless applicaties gemaakt (AWS lambdas). Echter ben ik nog niet volledig overtuigd van de positieve gevolgen (alleen betalen naar gebruik), want het kost gewoon een hoop meer tijd aan development (nieuwe repositories opzetten, de hele initiële setup van die projecten, etc.). Een hoop daarvan kan wel geoptimaliseerd en geautomatiseerd worden, maar een aantal uur aan developmentkosten zijn mogelijk al hoger dan een aantal maanden kosten besparen met serverless applicaties. Maar de tijd zal het leren.

[Cartman!]

Nieuwe repositories moet je toch voor elk project opzetten, waarom is dat voor serverless apps ineens anders? De initiele setup (deployments) en is een peulenschil met een tool als Serverless Framework.

[Alphyraz]

We werken binnen ons bedrijf veel met applicaties die met elkaar communiceren via queues (SNS/SQS). Om geld te besparen hebben we nu een aantal lambdas draaien die getriggerd worden door SQS messages in plaats van één applicatie die naar meerdere queues luistert. Zo heb je bijvoorbeeld voor vijf verschillende queue messages niet één applicatie die naar al die messages luistert, maar vijf lambdas die elk naar één soort message luistert. Je hoeft zo niet 24/7 een applicatie te draaien die naar al die messages luistert. Je betaalt alleen wanneer er daadwerkelijk messages binnenkomen.

[Cartman!]

Tip: kijk eens naar Kinesis ipv SNS/SQS combinatie...dat zal afhankelijk van de hoeveelheid messages een hoop geld kunnen besparen

[TheSec]

Voor de hobbies ten onder ons heb je het Openfaas project, kan prima op een stel pi's draaien. Geen grote omgeving dus voor nodig om toch met serverless te kunnen spelen of een idee te krijgen hoe het precies achterliggend zou kunnen werken.

https://www.openfaas.com

[Cartman!]

De grote cloud boeren hebben ook Free Tiers waar je 1 miljoen invokes per maand gratis mag doen...ook daar kun je ruim spelen zonder zelf veel moeite te hoeven doen. T gevaar ervan is alleen de vendor lock-in en uiteindelijk toch ook andere (betaalde) services er aan te koppelen. Uit ervaring weet ik dat je met de free tier ieder geval hele leuke dingen kunt doen.

[Erhnam]

Serverless compute is een hogere of een verdere vorm van abstraheren. Waarbij met IaaS (infrastructure as a service) alleen de infrastructuur wordt aangeboden en je zelf verantwoordelijk bent voor de het onderhoud van het OS, gebruikte framework en libraries, werkt het met Serverless anders. Het OS en zelfs de runtime is door de Hosting provider helemaal weggewerkt. Op dit gedeelte hoef je als eindgebruiker geen onderhoud te doen. Het is dus een kwestie van code injecteren, draaien en klaar. Vandaar de term ‘serverless’. Uiteraard worden er onderliggend nog steeds servers gebruikt, alleen als eindgebruiker wordt je hier niet mee geconfronteerd.

Ik zie mensen direct de link met containers leggen, maar Serverless zegt niets of containers worden gebruikt. De Serverless runtime kan in een container draaien, maar dit hoeft niet persé zo te zijn. Serverless kan door de Hosting provider net zo goed rechtstreeks op bare metal worden geïnstalleerd.

In de praktijk is Serverless met name interesssant omdat het tegen een zeer scherp tarief wordt aangeboden. Waarschijnlijk installeren de grote providers op iedere server een stukje Serverless compute of zo de ‘ongebruikte’ resources goedkoop aan te bieden.

[Reactie gewijzigd door Erhnam op 22 juli 2024 17:58]

[Yggdrasil]

De Serverless runtime kan in een container draaien, maar dit hoeft niet persé zo te zijn. Serverless kan door de Hosting provider net zo goed rechtstreeks op bare metal worden geïnstalleerd.

Precies,
Bijv. Amazon is nu bezig om Lambda aan te passen zodat functies gaan draaien op hun micro-VM's genaamd Firecracker. Dit zijn extreem gestripte VM's op bare metal draaien, in een fractie van een seconde starten, slechts 5MB RAM gebruiken en sterk geïsoleerd zijn van elkaar en van de host. Dat maakt het voor hen een stuk efficiënter om dan de EC2 instances die men nu als ondergrond gebruikt.