Build your own serverless bank

Kun je een eigen serverless bank bouwen? Dat vroeg Ronald Doorn van Schuberg Philis zich met enige regelmaat af, tot hij de mogelijkheid kreeg de koe bij de horens te vatten. Hij bouwde een spaarbank volledig in de AWS-cloud en bewijst daarmee opnieuw dat legacybanken het zwaar gaan krijgen.

Waarom wilde je een eigen bank bouwen?

"Ik begon ooit negen jaar geleden als Unix-beheerder en later kwam daar Windows bij. Intussen werd meer en meer op AWS en Azure gedaan, maar ik had daar geen ervaring mee. Om dat te leren heb ik iets verzonnen dat nuttig is voor Schuberg Philis en waar ik zelf weer van leer. Mijn idee: hoe zou een spaarbank er in een serverless omgeving uitzien? Omdat ik al eerder een opensource- global loadbalancer genaamd Mercury in Golang had geschreven, wilde ik mezelf in deze taal verder ontwikkelen. En omdat Golang destijds het beste werd ondersteund door AWS, koos ik voor AWS."

Waarom een spaarbank?

"Een van de doelen was om een zo goedkoop mogelijke bank te maken en dan heb je een bank nodig waar relatief weinig gebeurt, want elke keer als je een request bij AWS doet, kost dat geld. Een spaarbank is dan een relatief simpel banksysteem met weinig veranderingen in de data, dus weinig requests, waarvoor de cloud een goede oplossing is. Waarom servers aan laten staan die negentig procent van de tijd nietsdoen?"

Inmiddels zit elke bank wel deels in de cloud of zit dat toch iets anders?

“Wat we heel veel zien, zijn bedrijven die van een traditionele manier van banking naar een cloud gaan. Ze nemen dezelfde software over, gooien wat vm'etjes in de cloud, gooien er wat tooling omheen om het te automatiseren en je hebt een cloud based bank. Dat klinkt leuk, maar het blijft dezelfde oude software, die soms nog op Cobol draait. Met het liften en shiften van vm'etjes zeggen dat je een cloudoplossing hebt, lijkt me niet de richting die de bankenwereld wil opgaan."

Leren hoe een bank werkt en hoe je dit voordelig opzet voor de klant

Ronald vertelt dat hij 'eigenlijk een beetje' de vrijheid nam om niet alleen te leren hoe AWS werkt, maar ook hoe een bank werkt, hoe het financiële systeem in elkaar zit en wat daar allemaal bij komt kijken. Hij ging ook kijken hoe hij zelf een bank zou ontwikkelen. Schuberg Philis geeft collega's de tijd voor eigen onderzoek dat uiteindelijk ook door het bedrijf ingezet zou kunnen worden, maar dat is niet verplicht. Ronald had ook andere klanten en voor hen moest uiteraard wel gewoon gewerkt worden. "In eerste instantie ben ik gaan kijken wat de goedkoopste onderdelen zijn binnen AWS die je zou kunnen gebruiken en dan kom je al snel op lambda-functies, Amazon DynamoDB en SQS of simple queue service."

Al snel liep Ronald tegen beperkingen aan waar hij omheen moest werken, zoals een tijdslimiet van vijf "Met het liften en shiften van vm'etjes zeggen dat je een cloudoplossing hebt, lijkt mij niet de richting die de bankenwereld wil opgaan."minuten bij een lambda-request. "Wat ga je doen als iemand via een te trage verbinding een paspoortkopie moet uploaden voor identificatie? Komt niet heel vaak voor, maar als het langer dan vijf minuten duurt, dan stopt het. Uiteindelijk heb ik daar wel een weg omheen gevonden door een tijdelijke S3-bucket te gebruiken via de browser van de gebruiker. Met de tijdelijke specifieke schrijfrechten staat het bestand direct op de goede plek. Dan kun je daar nog triggers achter gooien, bijvoorbeeld het extraheren van informatie als paspoortnummer, geboortedatum en dat soort zaken. Een nieuwe lambda-functie leest dat paspoort en checkt de gegevens met de gegevens die de klant heeft ingegeven."

"Ook het gebruik van Amazon DynamoDB was interessant. Eerst had ik het idee dat het wel zou werken als een MongoDB bijvoorbeeld, maar dat bleek niet zo te zijn." DynamoDB is een niet-relationele of NoSQL-database van Amazon. Ronald geeft als voorbeeld dat de manier van het doen van een data-query anders werkt en dat je het gevaar loopt om voor een simpele query de halve database te moeten ophalen, wat een kostbare grap is. Daarna zou je met behulp van filters het echte resultaat moeten zoeken, omdat je maar maximaal vijf indices kunt gebruiken. "Stel, je wilt alle klanten uit Tilburg. Daar zet je geen index op, maar om ze toch te vinden, moet je de database van alle klanten ophalen en dan zoek je naar Tilburg. Als er twee klanten in Tilburg zitten, dan was dat een dure grap, want je betaalt per kilobyte van de hele gelezen dataset en niet alleen klanten uit Tilburg. Dat moet je dus anders gaan doen."

Voor Ronald was dat een interessante uitdaging, nadenken over je databasemodel in Dynamo en hoe je iets met zo min mogelijk query's voor elkaar kunt krijgen. "Omdat je goed moet nadenken over de data die je erin wil hebben, moet je ook goed nadenken over welke functies je echt nodig hebt, zoals inloggen, wijzigen klantgegevens enzovoort. Na wat spelen kom je er vanzelf achter wat het handigste is om te gebruiken."

Blockchain

"Als je bedenkt hoe een moderne bank eruitziet, moet je wel alle functionele elementen kennen om ze modulair te kunnen maken. Dus, ik dacht, daar kan ik heel mooi blockchain voor gebruiken met smart contracts. Zo kun je veel bankfuncties oplossen zonder dat je de code in je banksoftware schrijft, zoals multisignature-systemen. Dat zit al standaard in blockchain. Als je het ingewikkelder wil maken, zoals met leningen en hypotheken, dan kun je dat met smart contracts doen. Dat is enerzijds generiek, maar anderzijds ook persoonlijk."

Zijn volgende stap was het bouwen van zijn blockchain met lambda-functies in DynamoDB, waar wel het hele blockchainmodel in zit. Ronald onderzocht verschillende blockchains en kwam tot de conclusie dat hij alleen de blockchaintechnologie wilde gebruiken, zoals de blockchain zelf met smart contracts, maar dan zonder het traditionele consensusmodel. "Het hele consensusmodel is leuk als andere partijen, die je mogelijk niet vertrouwt, met die blockchain praten. Maar ik ben als bank de enige gebruiker van de blockchain, dus consensus heb ik niet echt nodig. Als je dat weghaalt, kun je de data opslaan in een blockchain die niet constant hoeft aan te staan om consensus te berekenen."

Zijn volgende stap was het bouwen van zijn blockchain met lambda-functies in DynamoDB, waar wel het hele blockchainmodel in zit. Dat laatste heeft dan vooral te maken met controleerbaarheid of audibility in jargon. Hij gebruikte ook de smart-contractfunctionaliteit samen met de virtuele machines die daarvoor nodig zijn, om ze uit te voeren.

“Het voordeel voor een controleur is dat je nog steeds een blockchain hebt met de hashes die de blokken koppelen, en aantoont dat de blockchain consistent is. Voor een auditor is dat heel fijn. Ook het multisignen van een rekening zit er al in, dus dat hoeft niet geprogrammeerd te worden. Het grootste voordeel zijn de smart contracts, omdat je de logica van nieuwe producten die bij bestaande banken eeuwen duren voordat ze geïmplementeerd kunnen worden, heel makkelijk kunt schrijven en als smart contract uitbrengen. Vervolgens voert het smart contract zichzelf uit op de blockchain.”

Wat zeg je tegen zogenaamde openblockchainpuristen?

"Aanpassingen moeten gedaan worden door een transactie-api, dat wordt geregistreerd in de blockchain. Als je handmatige een entry wil wijzigen, dan moet je een transactie invoeren met alle details met een hash die klopt. Het is ingewikkeld, bij een standaarddatabase is het veel makkelijker om iets te wijzigen. Uiteraard moet je wel functies hebben die controleren dat er niet gerommeld wordt. Je weet al heel snel dat het niet klopt."

"Het wordt een ander verhaal als je de bank wilt koppelen met verschillende banken en verschillende partijen toegang moeten hebben tot je blockchain, maar in dit geval is het zo privé, tja, dan is het gewoon heel handig.”

Het lastigst bij banken zijn alle processen waar je in eerste instantie niet over nadenkt, zoals end-of-dayprocessen en betalingsroutering, waarbij allerlei zaken tussen verschillende banken worden gecommuniceerd. “Zo wordt bij het geld overmaken naar een andere bank de transactie eerst naar een wash-account verplaatst en pas later wordt dat weer overgemaakt naar een andere bank via SEPA en naar een balance-account.”

Met zijn onderzoek naar een modulaire bank heeft Ronald voor zichzelf in ieder geval bewezen dat hij een bank in a box kan bouwen, iets wat velen als te ingewikkeld of als onmogelijk zien. "Gebruik gewoon de modules die je nodig hebt en de rest niet. Druk op de knop en automatisch deployen die hap!"

Schuberg Philis-diner

Op 5 maart 2020 houden we het Schuberg Philis-diner, een meetup waarbij je op het kantoor van Schuberg Philis te Schiphol-Rijk echt een kijkje in de keuken krijgt. Vorig jaar hadden we bijvoorbeeld een workshop Docker & Kubernetes onder begeleiding van Schuberg Philis Engineers. Daarnaast was er een keynote over Security in de cloud. Binnenkort gaan wij aan de slag met het samenstellen van het programma voor het volgende Schuberg Philis-diner. Wil jij hiervan op de hoogte worden gehouden? Vul dan onderstaande poll in. Zodra het definitieve programma bekend is ontvang je één mail van ons.

Bekijk hier het verslag van vorig jaar om een indruk te krijgen.

Wil jij op de hoogte worden gehouden van het Schuberg Philis-diner?

Poll

Ja, houd mij op de hoogte
Nee, ik hoef niet op de hoogte gehouden te worden

De opties zijn uitgeschakeld omdat de deelname gesloten is

Dit artikel is een onderdeel van een artikelenreeks in samenwerking met Schuberg Philis.

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 (83)

[poefpoef]

Natuurlijk weet ik dat hier op Tweakers het accent ligt op de technologie, maar desondanks is de titel van dit stuk wel wat misleidend. Een bank is geen bank zonder regulatory compliance, SoX compliance, risk management, know-your customer processen, noem maar op. Met alleen een systeem om te kunnen sparen maak je geen bank en kom je niet erg ver.

[Meekoh]

Zeker, wij zijn ons daar ook zeker van bewust aangezien we zelf al hele banking omgevingen hebben opgezet. Wij weten precies wat SoX/KYC/PSD2/etc. allemaal inhoud.

Houd er rekening mee dat dit een soort van hobby project is van een collega om zo te leren wat hij allemaal met AWS zou kunnen doen. Een echte bank komt nog veel meer bij kijken. Je zult toch je transacties bij een ABN/ING/etc. moeten krijgen bijv.
Zo zijn er nog veel meer dingen te bedenken

[Haribo112]

Wat een bank vooral tot een bank maakt is dat er uiteindelijk daadwerkelijk ergens geld uit komt rollen dat ik weer kan uitgeven bij derde partijen. Ik heb nou niet het gevoel dat dat met deze 'bank' mogelijk is....

[MSalters]

Het gaat hier om een spaarbank. Dat is dus geen geld wat je direct kunt uitgeven. Het is veel simpeler; je kunt geld van en naar betaalrekeningen overmaken. Dan heb je alleen maar SEPA clearing diensten nodig, en dat vrij standaard in te kopen.

Uiteraard moet je aan de achterkant al dat spaargeld nog wel beleggen, maar dat is geen technisch probleem.

[Meekoh]

En gek genoeg is dat wel hoe veel spaarbanken werken. Het spaargeld diens als tegenhanger van bijv. Hypotheken, het geld dat eruit komt is dus vaak een hypotheek.

[Warsaalk]

Interessant artikel! Ik ben zelf ook bezig met het schrijven van een software die draait op serverless en deels DynamoDB als database. Het is een hele uitdaging om van het traditionele SQL denken over te schakelen naar DynamoDB.

Het concept van serverless vind ik helemaal geweldig, het draait inderdaad op servers bij AWS, maar daar moet je jezelf niets van aantrekken. Je heb er heel weinig beheer aan en moet je niets aantrekken van nodige server resources want het schaalt als een gek. En daarbij betaal je alleen wat je gebruikt, wat goed is voor het kostenplaatje.

We hebben een applicatie omgezet van een standaard PHP / SQL implementatie naar Serverless en DynamoDB. De kosten waren 1/10de tegenover de vorige omgeving en daarbij kwam nog dat we zelf niets moesten schalen en downtime quasi onbestaande is.

[Douweegbertje]

Ik doe zelf ook van alles met de cloud, daarnaast doe ik diverse "opdrachten" om klanten te helpen met een soort devops transitie. Doch wil ik even een weerwoord plaatsen dat:

Je heb er heel weinig beheer aan

Nope, je hebt een verschuiving van beheer naar andere functies/werkzaamheden
Serverless, oh we hebben geen servers meer.. nee maar wel services en overige zaken die geregeld moeten worden. Soms heb je onderaan de streep zelfs meer werk...

je niets aantrekken van nodige server resources

Je moet je juist iets aantrekken van wat je gaat gebruiken en hoe je dat gaat gebruiken.

wat goed is voor het kostenplaatje.

Nou dat is nog maar te zien, zie bovenstaande en er zijn enorm veel cases waarin domweg een simpele vps goedkoper gaat zijn afhankelijk wat je doet. Ik heb namelijk genoeg gezien waarin serverless domweg 10x zo duur is dan een eigen simpele setup met een vps.. sterker nog, ik heb serieuze problemen gezien met serverless implementaties m.b.t. financiën.

Mijn persoonlijke ervaring is dat je de cloud op een bepaalde manier kan gebruiken waarin het gemak groter word en de kosten lager. Dat is echter iets wat niet een gegeven is of altijd van toepassing gaat zijn. De cloud / serverless is niet een magische oplossing voor al je problemen. Zeker op het moment dat we het hebben over grote applicaties en high traffic kom je er al snel achter dat alles enorm duur is en dat "as a service" nog duurder is.

Dit omdat eigenlijk de instap heel goedkoop/makkelijk is, zeker als je dus praat over een simpele website. Dat is nu net hun verdien model, dat je je lam betaald als je echt zwaar resources nodig hebt

[Reactie gewijzigd door Douweegbertje op 22 juli 2024 15:49]

[Warsaalk]

Ik volg je wel in de punten die je aanhaalt. Het zal zeker niet in alle gevallen een voordeel zijn.

In mijn geval was het zeker wel een win win situatie, vooral omdat de vroegere database de bottelneck was, DynamoDB heeft ook veel te maken met waarom de kosten lager liggen.

Het serverless deel kreeg ook minder te verduren dan de vroegere linuxservers, doordat de applicatie logica nu vooral in de front-end verwerkt zit en niet meer in de back-end, zoals het renderen van html. Maar was daarom niet oninteressant om te gebruiken voor het relatief klein aantal functies dat er op draaide. In mijn geval haalde het heel wat kopzorgen weg.

Maar het nieuwe project dat ik aan het uitvoeren ben heeft wel een stuk meer functies en services. Daarbij ga ik nu wel wat beter letten op wat dit betekent qua kosten

[Reactie gewijzigd door Warsaalk op 22 juli 2024 15:49]

[MadEgg]

Interessant artikel! Ik ben zelf ook bezig met het schrijven van een software die draait op serverless en deels DynamoDB als database. Het is een hele uitdaging om van het traditionele SQL denken over te schakelen naar DynamoDB.

Het concept van serverless vind ik helemaal geweldig, het draait inderdaad op servers bij AWS, maar daar moet je jezelf niets van aantrekken. Je heb er heel weinig beheer aan en moet je niets aantrekken van nodige server resources want het schaalt als een gek. En daarbij betaal je alleen wat je gebruikt, wat goed is voor het kostenplaatje.

We hebben een applicatie omgezet van een standaard PHP / SQL implementatie naar Serverless en DynamoDB. De kosten waren 1/10de tegenover de vorige omgeving en daarbij kwam nog dat we zelf niets moesten schalen en downtime quasi onbestaande is.

Daar staat tegenover dat bij een foutje in de code met als gevolg een service die op hol slaat het verbruik enorm kan stijgen, mede door het automatisch upscalen, waardoor de kosten de pan uitrijzen. Op het moment dat je dat doorhebt ben je vaak al een flinke kostenpost verder.

[Gropah]

Dat valt, als je het goed hebt ingesteld, wel op te vangen door policies om niet oneindig hoog te gaan schalen.

[MadEgg]

Zou je zeggen. Valt in de praktijk toch tegen - al meerdere malen verrassingen binnen mijn team gehad van enkele duizenden euro's. Gelukkig (tot nu toe) nooit door mijn toedoen Ok, dat is op Google Cloud, niet AWS. Maar daar heb ik ook wel ervaren dat je wel een budget alert kan instellen, maar niet een budget limit.

Scaling kan je inderdaad beperken maar dat is niet altijd wenselijk - als daardoor andere zaken vertraagd worden schiet dat zijn doel ook voorbij.

[Meekoh]

Ik kan je wel vertellen dat Wat cost management betreft Google echt wel een beetje achterloopt op AWS/Azure. Die bieden veel betere beschermings opties tegen dit soort fuckups.

[MadEgg]

Hoe werkt dat dan precies?

Het laatste wat ik wil is dat de productie-diensten automatisch worden afgeschoten / geblokkeerd omdat een budget overschreden wordt. Wel zou ik geattendeerd willen worden als een proces plotseling veel meer resources dan gebruikelijk gebruikt of als een nieuw proces boven bepaalde grenzen uitkomt. En dit alles zonder allerlei grenzen handmatig in te moeten stellen, natuurlijk, dat zou een hele adminstratie op zich worden.

[Meekoh]

Wij hebben binnen het bedrijf met alle drie genoemde providers wel iets lopen.
Ikzelf richt mij meer op Azure, dus ik zal daarover wat toelichten.

Natuurlijk willen we niet dat Productie, zomaar wordt stilgelegd doordat er ineens een grotere load is.
Echter wanneer je gaat up of out scalen dan stel je daar zeker grensen aan, dit kun je gewoon monitoren.
Je kunt zo ook alerten op items die heel snel groeien, zodra je het weet kun je erop acteren.

Met Azure Policies en Blueprints kun je bijvoorbeeld afdwingen dat bepaalde diensten niet eens mogen gebruikt worden (zo kan niet iemand per ongeluk een prijzige API Management Gateway deployen, of een hele dikke VM of iets dergelijks).

Maar ook de Azure Advisor zal je vertellen wanneer resources over-provisioned zijn.

Maargoed, the bottom line is dat dit allemaal staat of valt met Monitoring.

[Bert2000]

Durf te googlen.

https://aws.amazon.com/aws-cost-management/aws-budgets/

[MadEgg]

Ja, maar dat kan op GCP ook. @Meekoh stelt dat het beter geregeld is op AWS.

Als een proces wat normaal €10k per maand kost opeens €15k gebruikt wil ik daar niet de boel voor blokkeren. Dat zou namelijk ook best kunnen omdat er veel meer klanten zijn en dus waarschijnlijk meer omzet. Niets mis mee. Maar als het een fuckup is die aan het licht komt door een speciale set aan omstandigheden dan is dat zonde van het geld en wil ik daar zo snel mogelijk van op de hoogte gesteld worden.

[Gropah]

En daarbij betaal je alleen wat je gebruikt, wat goed is voor het kostenplaatje.

Dat is alleen goed voor je kostenplaatje als je geen constant gebruik hebt en je serverinhuur daar op afstemt. Als je gebruik wel redelijk constant is, dan is het zeer waarschijnlijk goedkoper om servers in te huren of lokaal te draaien.

[Warsaalk]

Inderdaad dat is waar, serverless is ook niet geschikt voor alle use cases. De applicatie waar ik over sprak was een webapplicatie die vooral hogere pieken had overdag en 's nachts bijna niets. En het diende als API voor die applicatie.

[MadEgg]

Dat hij de consensus niet relevant acht haalt wel het concept van de blockchain onderuit. Het wordt mij niet duidelijk waarom hij dan alsnog blockchain wil gebruiken. Juist het feit dat je er niet mee kunt rommelen is een voordeel, maar dan moet het wel controleerbaar zijn. Met hashes is het lastiger om wijzigingen te doen maar niet onmogelijk. En dat kan natuurlijk geautomatiseerd worden.

Een rudimentaire vorm van blockchain zie je bijvoorbeeld in git waarbij elke commit een hash heeft en een parent. Je kunt niet de parent wijzigen zonder alle commits daarna ook te herschrijven. En toch kan dit eenvoudigweg, er zijn genoeg (automatische) manieren om git-history te schrijven. Dit levert pas problemen op zodra je je repository naast die van een ander ziet. Dan zal er consensus moeten komen, ofwel geaccepteerd worden dat er een fork is. Dat geeft de zekerheid dat er niet ongemerkt mee gerommeld is. De private blockchain is hoogstens nuttig als je je eigen werknemers niet vertrouwt. Voor de klant maakt dit geen bal uit.

[TERW_DAN]

Kun je een eigen serverless bank bouwen?

Hij bouwde een spaarbank volledig in de AWS-cloud

Dus je bouwt een serverless bank.... .op een server.

Ofwel, je hebt gewoon gefaald in de uitvoering.

[Ayazis]

Serverless is een term die je niet al te letterlijk moet nemen. Uiteindelijk heb je altijd servers nodig waar je code op draait. De term serverless doelt op het feit dat je die server niet in eigen beheer hebt zoals de traditionele manier altijd was (pre-cloud).

Traditionally, we’ve built and deployed web applications where we have some degree of control over the HTTP requests that are made to our server. Our application runs on that server and we are responsible for provisioning and managing the resources for it.

Serverless computing (or serverless for short), is an execution model where the cloud provider (AWS, Azure, or Google Cloud) is responsible for executing a piece of code by dynamically allocating the resources. And only charging for the amount of resources used to run the code.
bron: https://serverless-stack....s/what-is-serverless.html

[MSalters]

Nee, dit is niet juist. Serverless verschilt van pre-could inderdaad in de zin dat je geen hardware meer bezit. Alleen zit er nog een stap tussen pre-cloud en serverless, en dat is de welbekende (virtual) server in de cloud. In die tussenvorm heb je nog wel klassieke servers, met een OS en dergelijke.

Serverless gaat een stap verder. In zo'n imgeving heb je uiteraard nog steeds servers, en die staan dus in de cloud. Het OS beheer etcetera is jouw probleem niet meer; jij upload alleen maar code. De cloud provider kan die code dan dynamisch aan servers toewijzen.

Je hoeft dus ook niet specifiek na te denken hoe groot je server moet zijn; dat is een probleem van de hoster geworden. Die moet de scaling maar verzorgen. Uiteraard werkt dat alleen als de hoster een goede inschatting kan doen van de hoeveelheid werk die een API call gemiddeld oplevert, vandaar dus dat vorobeeld over het uploaden van een paspoort foto.

Serverless is vooral gepusht door hosters omdat je dan vast aan hun zit. Een virtual server in de cloud kun je vaak perfect terug migreren naar je eigen datacenter. Een serverless omgeving heeft veel onzichtbare infrastructuur waar je afhankelijk van wordt.

[raptorix]

Dat hangt er vanaf, de meeste serverless code is prima onder te brengen als alternatieve applicatie (ook in de cloud), overigens heb ik me zelf redelijk verdiept in serverless computing (en er over gepresenteerd), veel mensen hebben het idee dat serverless een vervanging dan wel alternatief is voor Microservices, dit is uiteraard een misverstand. Serverless is met name geschikt als additie op je bestaande omgeving, zie ze vooral als handige werkpaardjes die een geisoleerde taak kan doen en die redelijk los staat van je domein.

Kortom als jij een bestelling maakt voor een klant, zorg er dan voor dat de bestelling zelf vastgestelt word in je applicatie, het mailen/ftpén/loggen kun je uiteraard prima door een Microservice laten doen, maar houd je businesslogic bij elkaar.
Overigens las ik dat Azure nu Durable Functions heeft welke je statefull en gechained kunt gebruiken, wellicht dat er handige toepassingen zijn, maar ik denk dat het gevaar op "misbruik" aanzienlijk is.

[Ayazis]

Ja precies. Volgens mij is dat wat ik ook zeg...?

[Randleman]

Het serverless principe betekend niet dat er geen server meer nodig is.. De hele comment sectie gaat hier zometeen vol mee staan omdat dit nieuw is voor mensen lol.

Ofwel, een snelle google en je had deze comment niet hoeven plaatsen

[Reactie gewijzigd door Randleman op 22 juli 2024 15:49]

[TERW_DAN]

Nee de commentsectie gaat hiermee vol staan omdat iedereen de buzzwordbullshit een beetje moe aan het worden is.
De gemiddelde tweaker weet echt wel het verschil tussen je serverpark hebben met een zooi servers in een rack, of dat je een clouddienst afneemt.

[Fluttershy]

Alsof iedere Tweakert een infra/hardware nerd is...

Er zijn ook hen die hier zitten voor cameras, smartphones, gaming, etc.

Dan is het best wel arrogant om aan te nemen dat iedere Tweaker dan wel intiem bekend zal zijn met de term 'serverless'.

[Byron010]

Hij zegt gemiddelde tweaker, niet iedere tweaker, en hij benoemt het verschil tussen zelf fysieke servers hebben of een clouddienst afnemen. Juist daarom dat de term serverless niet nodig is en alleen een buzzword is. Daar is echt niks arrogants aan...

[PatrickH89]

Tja, je kunt het serverless noemen of FaaS, maar uiteindelijk moet het beestje een naampje hebben toch? Ik zie in deze niet zo'n probleem.

[Ikheetchris]

CGI? Ik heb de service van Amazon nooit gebruikt, maar als het gewoon een programmaatje is dat wordt uitgevoerd wanneer er een HTTP-verzoek wordt gemaakt en op basis daarvan een HTTP-antwoord teruggeeft, dan lijkt het wat mij betreft aardig op de Common Gateway Interface (of een van de varianten daarop).

Serverless zou ik eerder willen gebruiken voor dingen die geen server nodig hebben. Denk bijvoorbeeld aan SQLite, dat in tegenstelling tot veel andere DBMS'en geen server nodig heeft.

[Reactie gewijzigd door Ikheetchris op 22 juli 2024 15:49]

[Randleman]

Nice safe

Een clouddienst neem je af ja. Je neemt geen servers af. Google maar even wat het principe inhoudt..

[Reactie gewijzigd door Randleman op 22 juli 2024 15:49]

[PageFault]

Waar je vervolgens een VM in draait

[Randleman]

Nee hoor, dat doe je dus niet zelf. Je deployed de code, de provider doet de rest.

[PageFault]

In een echte cloud solution wel, maar aan heel veel reacties te zien en hoe sommige bedrijven het uitvoeren, ziet de cloud er meer uit als een hosted VM omgeving, dan daadwerkelijk een cloud solution zoals jij omschrijft inclusief load balancing, schaalbaarheid etc.

[Br3wmaster]

Eens, het zou leuk zijn als mensen zich misschien iets meer verdiepen in het onderwerp voordat ze hier een comment dumpen die slaat als een tang op een varken.

[Jantje2000]

Met serverless wordt bedoeld dat je alleen betaald voor de tijd dat jij daadwerkelijk nodig hebt. Zo heb je onder andere in Azure bijvoorbeeld een serverless database. Uiteraard draait deze database gewoon op een server, maar er wordt alleen gefactureerd voor de seconden dat je daadwerkelijk data opvroeg.

In AWS heb je lambda's, in Azure heb je Azure Functions. Dit zijn zogenaamde serverless oplossingen. Het draait wel op een server, maar het is de bedoeling dat een function maar een paar seconden draait, waarbij je alleen voor deze seconden hoeft te betalen.

[blinchik]

Voor "de tijd dat jij nodig hebt" is heel relatief. Zo gebeurt er vaak veel meer dan zelfs de programmeur weet - 's nachts lopen er database backups (en je wil echt niet enkel op snapshots van Amazon vertrouwen, je wil echte database dumps), de database statistieken worden bijgewerkt, ... Een website wordt misschien maar 10 keer per minuut geraadpleegd maar mag de rest van de tijd echt niet af staan.

Lamda's zijn leuk voor programmeurs maar je hebt een volledige lock-in bij Amazon, ook pricing-wise natuurlijk. Je betaalt niet alleen voor Lamda's, maar ook voor data-traffiek (iemand maakt ook gebruik van je app), storage (meestal heeft een applicatie een database of data nodig, en dan betaal je bv. ook voor redshift). Bij grotere projecten wordt het niet meer zo heel overzichtelijk na een tijd, waar je geld naartoe gaat. Vergeet ook niet dat je 100% afhankelijk bent van deze technologieen en je je app niet zomaar kan verplaatsen naar een andere cloud. Als Amazon morgen zegt, traffiek wordt 10x zo duur, of die lamda wordt 10x zo duur, kan je alleen maar "Ja meneer Amazon" antwoorden en betalen.

Zelf ben ik daarom toch meer fan van VM's gedeployed met bv. een Java stack, die je van Amazon naar de Google, Vmware of Microsoft cloud kan verhuizen of zelfs self-hosted kan laten draaien. Qua disaster-recovery zit je opeens ook een stuk relaxter in een multi-cloud verhaal.

Ik begrijp dat programmeurs niet over al deze zaken nadenken, en het sneller/makkelijker is ready made functies aan te roepen, maar je moet toch wel bewust zijn van deze nadelen ook.

[Meekoh]

En toch is het een ontwikkeling die wel plaats vind. Kijk maar eens naar een banking product als Ohpen, dat al volledig in AWS draait.
Deze manier van denken is gek genoeg juist korte termijn denken. Je kunt het risico bewust accepteren dat je een lockin hebt, zolang je maar van te voren hebt doorgerekend wat je kosten worden om er weer uit te stappen. De kosten van wegmigreren kunnen best nog weleens wegvallen ten opzichte van de lagere kosten die je maandelijks hebt.

Bij een aantal projecten is dat ook exact wat ik om mij heen zie. Migratie kosten heb je hoe dan ook op moment X, want er komt een nieuwe versie van een product, nieuwe linux/Windows/SQL/Oracle/whatever versie etc.
Dus ook om je lambda's op te zetten naar iets anders, Azure of Containers of iets dergelijks, kun je vergelijken met dezelfde migratie kosten. En dan kan dus de kosten besparing weleens groter uitpakken dan de migratie kosten.

[blinchik]

Ja zeker, voor korte termijn denken, startups die moeten concurreren met iets dat al lang bestaat is het zeker een goede oplossing omdat grotere investeringen vanaf het begin niet kunnen. Maar management en programmeurs zijn vaak niet op de hoogte van bovenstaande risico's of willen deze niet horen, en men moet er wel van bewust zijn en dit in de strategie laten passen. De kosten van wegmigreren worden dan ook meestal in het begin zeker niet mee ingecalculeerd.

Ik heb al redelijk wat migratieprojecten achter de rug, je Java stack hernieuwen en alles op een nieuwe distributie zetten kost meestal slechts enkele dagen tijd, alhoewel je ook met deprecated frameworks kan zitten die moeten herschreven worden uiteraard.

We hebben ook bij enkele bedrijven stukken teruggemigreerd van cloud naar on-premise (applicaties die niet cloud ready waren met fat clients, maar alles moest in de cloud van het voormalige management). De AWS stukken zijn daar meestal als "legacy" blijven draaien omdat alles moet worden herschreven.

[Reactie gewijzigd door blinchik op 22 juli 2024 15:49]

[Deveon]

Letterlijk serverless is onmogelijk. De term betekent iets anders. Je hebt nog wel servers nodig, maar geen specifieke server. In de cloud draaien duizenden generieke servers die jou verzoek kunnen oppakken en je betaalt alleen voor de tijd dat het kost om uit te voeren.

[heuveltje]

jawel. dat heet p2p
Of je dat ook hier kunt implementeren is een 2e.
maar als dat niet lukt, noem het dan ook niet serverloos.

[Deveon]

Zelfs bij p2p is er technisch gezien een server en een client. Er is altijd een vraag en een aanbod, een opdrachtgever en een opdrachtnemer.

[MSalters]

Waarom zou dat zo zijn? BitTorrent is een klassiek voorbeeld van een p2p applicatie zonder servers en clients. Ja, er is vraag en aanbod, maar alle partijen implementeren beide kanten.

Nu is er voor computing niet direct zo'n uniforme opzet denkbaar. De rekenkracht van een cloud zijn uiteindelijk een heleboel CPU's in een heleboel servers. "Serverless" beschrijft wat je huurt, en dat is niet de server maar de computing, de storage en het dataverkeer.

[Deveon]

Leuk dat je torrent als voorbeeld geeft. Maar juist daar kan je uploaden (de service) beperken en als je de data in eerste instantie niet heb kan je deze ook niet aanbieden. Overigens werkt NiceHash wel met het verkopen en inkopen van pure rekenkracht en voor wetenschappelijk doeleind wordt dit al veel langer gefaciliteerd.

Elke server is tegenwoordig ook wel een cliënt, zeker aangezien het internet ook bijna volledig serverless is.

[Cartman!]

Jouw draadloze internet gaat uiteindelijk ook over een draadje naar buiten...heb je daar dan ook gefaald?

[fastbikkel]

Het is de context waar het om gaat.
Cloud bekt ook lekker, maar ook dat is gewoon een server.
Het gaat erom of het verkoopt :-)
Net als dat "shared platforms" ook een beetje uit de gratie zijn geraakt, nu noemt men dat veelal "multi tenant". Komt op hetzelfde neer, maar hiermee voorkom je vragen.

Ik heb echt helemaal niets met die termen als ICT'er.

[Illegal_Alien]

Even heel erg kort door de bocht: Een "cloud" is nog steeds een server .

[Tadango]

Ja, gewoon de server van iemand anders, meer niet. Een cloud server kan gewoon om de hoek staan zelfs Cloud betekend alleen geen hardware onderhoud, meer niet. Dus ja, je kan alles in de cloud...... niets bijzonders.

[Verwijderd]

Ja, gewoon de server van iemand anders, meer niet. Een cloud server kan gewoon om de hoek staan zelfs Cloud betekend alleen geen hardware onderhoud, meer niet. Dus ja, je kan alles in de cloud...... niets bijzonders.

Dat kun je inderdaad doen: gewoon je Windows server van je lokale VMWare omgeving migreren naar Azure. (Om maar een voorbeeldscenario te noemen.)

Maar eigenlijk had je die Windows server alleen maar draaien omdat je dan SQL kon installeren, waar dan weer je database binnen draait. Wat je echt nodig hebt is (toegang tot) die database.
Wat je dus ook kan doen in plaats van die hele inrichting verhuizen naar Azure alleen de toegang tot de database afnemen. Alles eromheen is niet jouw zorg; het maakt je niet oud op welk OS, welke hardware, of hoe die SQL is opgebouwd. Als deze maar voldoet aan de door jou gestelde eisen voor beveiliging, functionaliteit, prestaties, en uptime.

[Tadango]

Klopt, meer software as a service idee. Maar een SQL cluster had je lokaal ook kunnen maken op linux machines btw....

[Micahve]

Er is nog wel hardware onderhoud, alleen jij als gebruiker betaald daarvoor in de prijs per seconde dat je de server gebruikt.

Je hoeft zelf geen onderhoud te doen, maar het wordt zeker gefactureerd in de prijs

[Tadango]

Klopt, alleen vaak is het efficiënter en goedkoper, zoals alles wat op grote schaal gebeurd.

[Micahve]

Inderdaad, zeker als je het zo efficiënt inricht als in dit artikel hierboven!

Alleen wat je wel mist is zelf een hardware probleem kunnen oplossen, je legt natuurlijk al je eieren in de mand van de server beheerder, dus het is dan best frustrerend als het niet werkt en je er zelf niks aan kan doen!

Maar over het algemeen, zeker voor kleine-middelgrote servers is het veel efficiënter en goedkoper om het in te huren, maar voor de grote server bazen zoals: Google, Twitter, Amazon, enz. Is het natuurlijk goedkoper, of in ieder geval beter voor hun dat ze hun eigen servers hebben

Want hoe meer data troughput hoe duurder het wordt, dus voor Google die natuurlijk miljarden search requests per dag krijgt is het vrij duur om al hun data op te stallen bij een server bedrijf, En Twitter heeft constant met uploads en downloads te maken die door de hele server heen en weer gaat.

Zo zie je maar weer dat je altijd goed moet kijken wat voor jou de beste oplossing is, voor de een zal dat cloud servers zijn en voor de ander juist weer fysieke servers

[MSalters]

Waarom zou het voor kleine servers goedkoper zijn? Wij hebben de berekening gedaan; onze server hier heeft een effectieve belasting van 80%. De cloud zou goedkoper zijn bij een gemiddelde belasting van 20%. Maar voor een site als T.net is de gemiddelde belasting waarschijnlijk wél 20% van de piekbelasting.

Voor grote bedrijven zoals Philips geldt waarschijnlijk weer dat ze met een on-premise cloud dezelfde schaalvoordelen boeken. Met honderden servers is de gemiddelde load waarschijnlijk al vrij constant, daarvoor hoef je niet naar de miljoenen servers toe.

[Micahve]

Als je een kleine server hebt, en dan vaak weinig trafic hebt naar je server, bijvoorbeeld een kleine website.
Dan is het een stuk duurder om zelf alle onderhoud te doen dan een klein servertje te huren in de cloud.

Maar als je zo groot bent als bijvoorbeeld Twitter, met gigantische trafic dan is een cloudserver huren juist duurder. Aangezien je meer betaald hoe meer trafic er is.

Als uw servers constant op 80% draaien hoe handeld U een piek?

En je levert als bedrijf natuurlijk ook veel in als je naar de Cloud gaat.
Al je controle over de hardware is foetsie en je bent afhankelijk van de expertise van het bedrijf.

Cloud heeft zijn voordelen, maar ook zijn nadelen.

Phillips zal waarschijnlijk haar eigen servers hebben om het feit dat het verschil(of geen verschil) in kosten zo klein is dat ze beter af zijn met haar eigen servers.

Met kleine servers bedoel ik ook echt klein, je lokale snackbar heeft vaak een eigen website, en het zou voor die snackbar vrij duur zijn om een eigen server te onderhouden

[MSalters]

Ik heb een hele simpele manier om die pieken op te lossen. Dan duurt het gewoon wat langer. Niet alle server taken zijn interactief. Mijn server draait dus ook zelden op 80%. Dat is het gemiddelde, dat komt omdat de server op 100% draait tot alle werk af is, en daarna op 1%.

[Micahve]

Ja dat is dan idd een oplossing haha

Alleen als jij een Twitter was, dan zou je veel boze gebruikers hebben hahaha

[Randleman]

Ja? Het serverless principe betekend niet dat je geen servers meer nodig hebt.

[sympa]

Met "server" wordt hier bedoeld dat er pas iets gaat draaien (lambda-functie) and een klant iets doet. Dan heb je dus 'geen server' maar alleen een 'PHP'-scriptje op een shared server. En je betaalt per transactie en niet voor hosting.
Daarom gata het ook mis bij die trag eupload, maar die doet de klant dus direct naar de opslagunit. Dat is natuurlijk een server, maar het is niet een server van of voor de bank.

[Deveon]

Een cloud tot een server is als een leaseauto tot een auto. Je bereikt er hetzelfde mee, maar bijkomende zaken worden uit handen genomen. Enige verschil is wel dat je in een Cloud betaalt voor gebruik en niet beschikbaarheid zoals traditioneel het geval was fysieke hardware.

[Rule]

https://en.wikipedia.org/wiki/Serverless_computing

Serverless computing is a cloud-computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.[1] It can be a form of utility computing.

This should not be confused with computing or networking models that do not require an actual server to function, like peer-to-peer (P2P).

[Reactie gewijzigd door Rule op 22 juli 2024 15:49]

[PcDealer]

Hij bouwde een spaarbank volledig in de AWS-cloud en bewijst daarmee opnieuw dat legacybanken het zwaar gaan krijgen.

Nogal een boude uitspraak. Hoezo opnieuw en waarom krijgen de traditionele banken het zwaar hierdoor?

[WokBoy]

Traditionele banken zijn (nog) van het zelf inkopen van hardware, racken en inrichten, virtualiseren, patchen en voorzien van de benodigde software. Clusters erop, backups, security maatregelen... alle dingen die AWS (en Azure en GCP en noem maar op) voor jou regelen. Daar komt nog bovenop het jongleren met software die specifieke runtime versies eist (denk java 5/6/7tot op specifieke minor versies, en ellende als rbenv/pyenv), waar je met iets Lamba niet veel over na hoeft te denken...

Als jij bij wijze van spreken met een Terraform plannetje en wat scripts op pay-per-use basis de infra kunt bouwen ben je a) sneller en b) veel, heel veel goedkoper uit.

Edit: bovendien wordt een disaster recovery echt veel simpeler, of dat nu door het verplaatsen van je diensten naar een andere regio of het desnoods volledig opnieuw opbouwen met dat terraform scriptje is.

[Reactie gewijzigd door WokBoy op 22 juli 2024 15:49]

[Bert2000]

Dit is onzin.

Veel banken maken al gebruik van public cloud diensten. Natuurlijk nog niet voor alle diensten maar je zult verbaasd zijn als je ziet hoeveel wel al.

De term "traditionele bank" vind ik dan ook ernstig achterhaald.

[Reactie gewijzigd door Bert2000 op 22 juli 2024 15:49]

[Meekoh]

En dat is ook waar we het over hebben. Zo'n Spaarbank backend is typisch het systeem dat bij een "traditionele bank" een oudere backend is. (Zelfs bij relatief nieuwe spelers als Moneyou bijv.)

Er wordt niet gesteld dat public cloud in zijn geheel niet gebruikt wordt.

[Meekoh]

Scherp! Waarom opnieuw weet ik ook niet, om eerlijk te zijn.
Echter 2 dingen:
1. Veel oudere banken hebben nog steeds die oude core banking systems draaien. Denk aan Thaler, etc. Ik zie zelfs dat de relatief nieuwere pakketten ook al steeds groter en lomper worden (Matrix van FiveDegrees) en moeite hebben om zo goedkoop mogelijk te draaien. Ik ken zelfs banken die nog op VAX hardware draaien met OpenVMS (wel rete stabiel!). Maar qua kosten om te laten draaien vrij prijzig.
2. Met name bij spaarbanken geld dat ze hun kostenpost zo laag mogelijk willen maken. Als ik naar de spaarbanken kijk, waar ik qua infra mee te maken heb (gehad) dan zie je dat er gedurende de dag vrij weinig echte load is. Spaarbanken hebben geen realtime transacties (nog), het zijn altijd batchprocessen die piepen veroorzaken op bepaalde momenten. Als je het kostenplaatje in je achterhoofd houd dan kun je juist in een pay-per-use model flink op je kosten besparen.

En er zijn ook al "nieuwere" banking software providers die op exact dit pad zitten, kijk bijv. maar eens naar Ohpen.

[IVEL]

Interessant concept wat stof tot nadenken geeft.

Is de opzet hiervan beschikbaar als opensource project om van te leren en mee verder te experimenteren? Het zou fijn zijn als dit gedeeld kan worden via GitHub bijvoorbeeld.

[Meekoh]

Ga ik voor je uitzoeken

[whiner]

Moeten klant gegevens niet beschermd worden ?
Leuk zon oneindig schaalbare cloudserver, maar alle data van je klanten staan bij Amazon / Google / Microsoft.

[Meekoh]

Die staan daar inderdaad encrypted zondar dat Amazon/Google/Microsoft toegang tot de key heeft.
Sterker nog, dat moet vanwege PCI compliancy waar banken aan moeten voldoen (card issuers dan).

[0vestel0]

Super interessant artikel.
Termen als Serverless en Cloud blijven leuk. Mijn opvatting. There is no Cloud. It's just someone else's Computer.

[michielRB]

Het is dat er .Adv voor staat maar wat een tendentieus clickbait topic.... /sad