Nederlandse banken riskeren systeemuitval door groeiende IT-afhankelijkheid VS

Nederlandse banken en financiële instellingen zijn digitaal afhankelijk van grote Amerikaanse techbedrijven, wat tot concentratie- en systeemrisico’s kan leiden. Verstoring bij één leverancier kan grote delen van de financiële sector raken, waarschuwen de AFM en DNB in een rapport.

De financiële sector in Nederland loopt een groeiend risico door de toenemende afhankelijkheid van een klein aantal niet-Europese IT-leveranciers. Dat stellen de Autoriteit Financiële Markten en De Nederlandsche Bank in een gezamenlijk rapport. Het gaat daarbij om kritieke processen, schrijven de twee toezichthouders.

Steeds meer instellingen besteden IT‑taken uit aan externe partijen, zoals cloud-, software- en AI‑dienstverleners, constateren de Nederlandse toezichthouders. De verschuiving van on-premises IT-infrastructuren naar cloudgebaseerde diensten zorgt voor grote afhankelijkheid. "Waar banken eerder met meerdere leveranciers werkten, wordt nu de volledige IT-stack aan één techbedrijf toevertrouwd."

Dominantie van hyperscalers en geopolitieke druk

"Een paar grote, wereldwijd opererende digitale dienstverleners, de zogeheten hyperscalers, zijn de afgelopen jaren het hele speelveld gaan domineren", aldus het rapport. Het gaat niet alleen om technische aspecten; internationale verhoudingen zijn ook bepalend. "Door recente geopolitieke ontwikkelingen worden de risico’s van deze digitale afhankelijkheid urgenter", stellen de toezichthouders.

Het is 'in het huidige gure geopolitieke klimaat' namelijk mogelijk 'dat statelijke actoren deze afhankelijkheid van digitale dienstverlening misbruiken als politiek pressiemiddel of instrument in een handelsconflict', aldus de AFM en DNB. "Denk bijvoorbeeld aan een situatie waarin essentiële IT-dienstverlening door sancties plotseling wordt stopgezet, of aan een hybride aanval waarbij cyberaanvallen en fysieke schade aan infrastructuur leiden tot de verstoring van kritieke en vitale processen." Financiële instellingen zijn zich bewust van deze risico's, blijkt uit het rapport, maar moeten meer actie ondernemen.

De AFM en DNB waarschuwen voor fundamentele problemen door digitale afhankelijkheid. Dat leidt tot twee soorten risico's: concentratie- en systeemrisico's. Bij concentratierisico liggen te veel middelen bij één of enkele partijen, in dit geval IT-dienstverleners. "Storingen en cyberincidenten bij IT-dienstverleners kunnen daardoor meerdere instellingen tegelijkertijd raken."

Het tweede soort risico gaat een stap verder: bij systeemrisico in de financiële sector kan de hele Nederlandse economie worden geraakt. "Afhankelijkheden beperken zich niet langer tot individuele instellingen, maar kunnen zich, mede via ketens van dienstverleners, opstapelen tot risico’s op systeemniveau." Daardoor hangt de stabiliteit van het financiële stelsel ook af van de robuustheid van externe leveranciers, waarschuwen de toezichthouders.

Weerbaarheid en Europese alternatieven

Zij willen met deze waarschuwing financiële instellingen aansporen hun digitale weerbaarheid verder te versterken. De AFM en DNB benadrukken ook het belang van Europese digitale autonomie. Daarvoor zijn 'volwaardige Europese alternatieven' nodig. Dat vraagt om een sterker innovatie- en investeringsklimaat voor Europese techbedrijven. "Digitale afhankelijkheid is een complex vraagstuk, dat niet op korte termijn is op te lossen."

Reacties (69)

[Knallmeister]

Eigenlijk zou dit oud nieuws moeten zijn, maar het is helaas zeer actueel. Als er een (1) voordeel van Trump in het Witte Huis is, dan is het dat hij Europa wakker heeft geschud, alhoewel ik van mening ben dat we nog tamelijk slaapdronken zijn.

Hoe gaan we die afhankelijkheid van die Amerikaanse Techsector doorbreken: Allereerst worden er vele hectoliters koffie gedronken, en dan klopt de overlegsector zich op de borst. Vervolgens zal er niet echt veel veranderen.

Cynisch? welnee.

[Reactie gewijzigd door Knallmeister op 20 oktober 2025 17:25]

[NoTechSupport]

Daarom is wetgeving belangrijk. Het is onredelijk te verwachten dat individuele bedrijven (zelfs in kritische sectoren) allemaal op eigen houtje tot de conclusie komen dat ze de gigantische investering moeten doen om al die infrastructuur, die in veel gevallen nog geen 10jaar in de cloud draait, terug on prem te zetten (terug server ruimte in gebruik nemen, hardware aankopen, soms experts aannemen). Het grappige is dat naar de cloud gaan vooral consumptie gestimuleerd heeft, waardoor geen geld gewonnen is, maar terug komen naar on prem wel een serieus prijskaartje zal hebben.

[Reactie gewijzigd door NoTechSupport op 21 oktober 2025 08:33]

[Andy1562]

Ik ben het hier mee eens. Alles is azure azure azure hier en als het dat niet is, dan aws. Ik bedoel fijn werken hoor daar niet van

[A11ert]

Nou ik maak me op dit moment ook zorgen afhankelijkheid van "China" in onze tech industrie. Misschien moeten we als Europa daar ook eens over nadenken.

[Dooxed]

Hoe zie jij die afhankelijkheid? Bedoel je als de producent van alle spullen die we nodig hebben?

[A11ert]

China fabriceerd bijna alle hardware. Zelfs als je een product koopt van een merk uit Europa, Amerika of een ander land. Dan is de kans nog steeds groot dat het product in China gemaakt is.

Bijna alle hardware komt uit China. En ook de grondstoffen om deze producten te maken komen vaak uit China. Dus we zijn aardig van hun afhankelijk.

[TMT]

en het gebeurt niet alleen in de banksector maar ook in andere kritieke sectoren...

PS: waarom bestaan er geen kiloliters heb ik me altijd afgevraagd

[Ronwiel]

37signals, het bedrijfs achter projectmanagementsoftware Basecamp, heeft er veel over gepubliceerd. Wel interessant om te lezen dat hun verhuizing naar eigen hardware een hoop geld heeft bespaard. https://basecamp.com/cloud-exit

[R1]

het gaat verder dan alleen een cloud exit.

In je "eigen" datacenter huur je soms ook een kooi bij Equinix, gaat je data over het Cisco netwerk, en draaien je VMs op VMware/ IBM RedHat, op Dell/HP servers met Intel/AMD CPU en EMC storage.De afhankelijkheid is er dan ook als je geen updates meer krijgt.

Zelfs binnen de EU moet je je afvragen wie je kunt vertrouwen, nu en na verkiezingen in een land; niet ieder EU land is je vriend (Orban, AfD, Front National)

[eheijnen]

En daar komen ze NU pas achter....
Dat zijn zij en vele anderen al decennia...

[Glashelder]

Het meest hilarische is dat DNB ook gewoon in Azure zit…

Als Azure Engineer zijnde vind ik dit echt een onbegrijpelijke ontwikkeling gezien de huidige geopolitieke ontwikkelingen. Eigenlijk is niets in Azure echt nodig. Ja, veel ontwikkelingen zijn echt super handig, maar voor je bedrijfsprocessen zijn echt wel on premise alternatieven. Het kost je wel wat meer geld, niet alleen aan hardware maar ook gewoon aan FTE. Nou en?

We blijven onszelf wijsmaken dat we al die snufjes echt nodig hebben.

[swhnld]

Ik ben het niet met je eens dat on-prem duurder hoeft te zijn. Het hangt allemaal van schaal en verstand af.

Schaal, een aanbieder van een cloud oplossing moet ook servers draaien en beheren. Voor een bedrijfje met 50 mensen is dat te duur misschien om zelf te doen en huur je bij een ander, maar een bedrijf met 50.000 mensen, dan spreek je over een hele andere schaal, dan kan de berekening ineens anders uitpakken.

Verstand, sommige mensen zien uitbesteden (/cloud) als de heilige graal. Magisch is alles geregeld. Tot je nadenkt en kleine lettertjes leest. Je bent immers nog steeds aansprakelijk als bedrijf bij een data lek, je hebt nog steeds backups nodig en moet kunnen aantonen dat die werken, je hebt nog steeds uitwijkplannen nodig en moet die testen. En hoe ga je een omgeving niet onder je controle uitzetten als er ingebroken is om schade te beperken, rij even langs bij Amazon of Microsoft?

Er is wetgeving voldoende in opkomst, NIS2, CRA, DORA, het valt mij tegen dat DNB niet zelf het goede voorbeeld geeft en de financiële instellingen waarschuwen dat hun vergunningen in gevaar komen als ze hun verantwoordelijkheid niet nemen. Advies nu is maar contant geld in huis te halen, want vertrouwen in eigen kunnen is er niet.

[downtime]

Contant geld in huis halen is natuurlijk zinloos aangezien je daarmee wel bij de supermarkt kunt betalen maar de supermarkt zelf z'n leveranciers en personeel alleen maar digitaal kan betalen. Je voorkomt er geen lege winkelschappen mee, zeker niet als er paniek ontstaat. Wat doe je dan nog met je contante geld?

[fenrirs]

Melk, vlees, aardappels, groenten en eieren bij de boer, meel bij de molen en zelfs gasflessen kan je hier in het dorp contant betalen.
OK, gaat maar een beperkte tijd goed, maar we komen een eind, zelfs als de stroom uitvalt.

[Grrrrrene]

Ook daar geldt: de boer, de molen of het gasvulstation zal spoedig tot stilstand komen, als toeleveranciers niet betaald kunnen worden, omdat het bankensysteem is uitgevallen.

Een eigen moestuin is dan een beter idee. Kun je nu alvast beginnen met zaden hamsteren en genoeg vierkante meter aan moestuin prepareren in je tuin Zorg dat je water kunt filteren en je bent redelijk zelfvoorzienend.

[Reactie gewijzigd door Grrrrrene op 21 oktober 2025 08:01]

[fenrirs]

OK, gaat maar een beperkte tijd goed,

Lezen is moeilijk. Moestuin en kas staat al sinds jaren en water filteren is ook mogelijk

[Reactie gewijzigd door fenrirs op 21 oktober 2025 08:46]

[Dooxed]

Ja prima, we hebben tijdelijk iets te eten en te drinken. Fijn voor de mensen met toegang tot een moestuin. En de rest? De meeste mensen wonen in steden, de grote voedselstromen gaan van landbouw richting de stad. Als de diesel op is stopt dat en is er te weinig eten.

[Grrrrrene]

Volkstuintje?

In de stad wonen is natuurlijk ook gewoon een keuze die op onze huidige maatschappij is gericht. Iedereen wil dicht bij de winkels, het centrum, hun werk wonen, met goed openbaar vervoer en andere voorzieningen. Als de maatschappij zoals we die kennen instort door hierboven omschreven chaos, is de stad volgens mij de laatste plek waar je wil wonen. Met de huidige spelregels is de stad voor velen een prima plek om te wonen.

[NoTechSupport]

In extreme gevallen zal er in een kwestie van uren, misschien dagen, overgeschakeld worden naar cash voor de hele keten.

[fireboy]

Als bank plat ligt, waar haal jij je cash dan vandaan? Bij lokaal bank filiaal? Oh wacht die zijn er helemaal niet meer En welke er nog wel is kan ook niks voor je betekenen als ict plat ligt

[Grrrrrene]

Was het advies niet om NU alvast wat contant geld in huis te halen, voor als de pinautomaten er een paar dagen uit liggen? Jij verwacht een oplossing voor mensen die zich niet voorbereiden. Als de waterleiding eruit ligt, moet je ook slim omgaan met het water wat je nog hebt of putten uit waterflessen die je eerder al hebt ingekocht. De eerder aangehaalde moestuin gaat je ook niet helpen als je NU voedsel nodig hebt en geen moestuintje hebt.

[downtime]

Grapjas. Waar moeten al die biljetten en muntstukken vandaan komen? Denk je dat DNB gewoon honderden miljarden ongebruikte euro's op de plank heeft liggen? Die moeten dan eerst gemaakt worden.

[Grrrrrene]

Contant geld kan nooit het girale geld volledig compenseren natuurlijk, daarvoor is er niet genoeg in omloop. Maar de eerste levensbehoeften zijn maar een fractie van het totale geld wat in omloop is. Ik denk niet dat er iemand in zo'n situatie naar de Mercedes-dealer gaat om een nieuwe auto te kopen, met contant geld. Dat kan ook wel iets later. Maar een krop sla, een paar aardappelen, evt een stukje vlees en wat te drinken, daar heb je wél nu behoefte aan en dat kan prima contant afgerekend worden met de hoeveelheid contant geld die we hebben.

En sowieso: het is vrij onwaarschijnlijk dat het bankensysteem er maandenlang uit ligt. Bij een hack gaat het eerder om uren, eventueel dagen lijkt me. Die tijd is prima te overbruggen. Ik heb genoeg eten in huis om het een ruime week uit te zingen (als ik creatief ben, vast langer), dus ik heb misschien wel helemaal geen contant geld nodig als pinnen een paar dagen niet kan. En dan is er altijd nog op rekening kopen...

[IntrCpT3R]

Dat klopt niet helemaal. Hoewel schaal en verstand inderdaad belangrijke factoren zijn, gaat het in de praktijk om veel meer dan dat. De technologische ontwikkelingen gaan tegenwoordig zó snel dat het voor de meeste organisaties onmogelijk is om alles nog on-premises bij te houden. Nieuwe oplossingen, frameworks, AI-integraties en beveiligingsvereisten volgen elkaar in razend tempo op. Bedrijven die te sterk vasthouden aan hun on-prem strategie, lopen daardoor structureel achter de feiten aan.

Je kunt natuurlijk zeggen dat je controle houdt door alles zelf te draaien, maar ik zie in de praktijk steeds vaker dat organisaties die volledig on-prem blijven, juist in hun innovatie worden geremd. Ze besteden enorm veel tijd en geld aan onderhoud, hardwarevervanging, upgraden van software en compliance, terwijl bedrijven die (gedeeltelijk) de cloud omarmen veel sneller kunnen inspelen op veranderingen.

Ook het argument dat cloud per definitie duurder of risicovoller zou zijn, klopt maar gedeeltelijk. Natuurlijk blijft de uiteindelijke verantwoordelijkheid bij het bedrijf liggen, maar dat geldt in elke situatie of je nu on-prem of in de cloud werkt. Het verschil is dat grote cloudproviders continu investeren in beveiliging, schaalbaarheid en compliance op een niveau dat voor de meeste bedrijven niet haalbaar is. Dat zorgt juist voor meer weerbaarheid, niet minder.

En ja, Amerikaanse techbedrijven waren eerder met grootschalige cloudadoptie en we zien daar nu de effecten van: zij hebben een enorme voorsprong op het gebied van schaal en innovatiekracht. Dat betekent echter niet dat we dat als risico moeten zien, maar als een signaal dat we hier sneller moeten schakelen.

Het is prima om kritisch te blijven op wetgeving zoals NIS2, DORA en CRA die dwingen terecht tot beter risicomanagement maar het idee dat de oplossing ligt in “alles weer zelf doen” is achterhaald. De toekomst ligt eerder in een slimme, hybride aanpak waarin bedrijven gebruikmaken van cloud waar het waarde toevoegt, en on-prem behouden waar dat echt noodzakelijk is.

[jaapio88]

Laten we nu hier niet heel hard gaan roepen dat we het beter weten. Want wij - techneuten - zijn er schuldig aan dat alle bedrijven denken dat ze in de public cloud beter af zijn. Wij bedachten dat al die super nuttige speciale versies van databases beter paste dan de databases waar we al decennia mee werkte.

Het is zeker waar dat de business zich heeft laten verleiden door de leugens dat het goedkoper is. Maar ik denk dat we onszelf ook wel even goed in de spiegel moeten aankijken. Met de mededeling, 'ik ben er mede schuldig aan dat we nieuwe technologieën wilde gebruiken zonder 24/7 shifts'

[Tielenaar]

Techneuten zijn toch niet degenen die dit soort beslissingen nemen? Dat zijn kostenplaatjes die door hogerop worden afgewogen en beslist.

Je kiest als team of als bedrijf voor een bepaalde oplossing omdat die op dat moment het beste is voor langdurig gebruik.

Ik ken genoeg techneuten (zoals ik) die liever lang bij bestaande tech blijven zitten omdat daar gewoon de ervaring zit.

[Barsonax]

Ik zie het ook bij de DNB dat ze behoorlijk vast zitten in het Azure moeras. Dat vastzitten hoeft natuurlijk niet perse want je kan ook voor technieken kiezen die niet perse vastzitten aan Azure maar portable zijn zodat je ook naar andere clouds kan.

Dan heb je tenminste een exit strategie omdat als partij x niet meer betrouwbaar is je relatief makkelijk kan switchen.

Binnen Europa zijn er tegenwoordig alternatieven zoals scaleway die toch een behoorlijke set aan bouwblokken (denk aan managed databases, S3, identity, networking, kubernetes) hebben. Veel applicaties zouden daar in passen.

[Reactie gewijzigd door Barsonax op 20 oktober 2025 16:42]

[bzzzt]

Dat vastzitten hoeft natuurlijk niet perse want je kan ook voor technieken kiezen die niet perse vastzitten aan Azure maar portable zijn zodat je ook naar andere clouds kan.

Ik denk dat je onderschat hoeveel kosten je 'er bij' pakt als je dit serieus probeert te doen. Je bent dan feitelijk je eigen cloud infrastructuur aan het optuigen terwijl je die van je cloud provider 'out of the box' kan gebruiken. Daarmee gooi je de besparing die je kan doen door niet meer zelf allerlei services te managen voor een groot deel overboord. Ook niet onbelangrijk: je hebt aanzienlijk meer capabele mensen nodig en die worden op een bepaald moment ook een bottleneck voor wat je nog kan doen...

[Barsonax]

Juist die specifieke Azure zaken is waar we ons als engineers ons handen vol aan hebben. Je kan het bijv al niet lokaal draaien, dat bemoeilijkt dan ook weer automatische testen (want dat moet je eerst uitrollen in Azure..).

We zouden een stuk productiever zijn als we open componenten zouden gebruiken zoals bijv PostgreSQL die je gewoon wel lokaal kan draaien.

Het is anders als je een kant en klaar product afneemt maar dan moet je je eraan aanpassen en niet eindeloos customizen.

[bzzzt]

Juist die specifieke Azure zaken is waar we ons als engineers ons handen vol aan hebben. Je kan het bijv al niet lokaal draaien, dat bemoeilijkt dan ook weer automatische testen (want dat moet je eerst uitrollen in Azure..).

Dan draai je je testomgeving toch ook in Azure?

We zouden een stuk productiever zijn als we open componenten zouden gebruiken zoals bijv PostgreSQL die je gewoon wel lokaal kan draaien.

Denk je? PostgreSQL voor een productieserver is echt niet iets wat je er 'even' bij doet als je enig nivo van performance, monitoring, failover en backups wil hebben. Dan heb je domweg een full-time DBA nodig, en die zijn heel zeldzaam. Een managed database afnemen is echt serieus minder werk en bovenstaande zaken zijn op een redelijke manier geregeld.

[Barsonax]

Dan draai je je testomgeving toch ook in Azure?

Ja tuurlijk kan je het in azure draaien maar dat is toch veel te veel gedoe? Is vele malen trager, de deployment duurt al langer dan het draaien van testen duurt. Daarbij moet je ineens locks gaan zetten op je build zodat builds niet elkaar in de weg zitten. Dit kost weer allemaal meer tijd en centen en is gewoon suboptimaal.


Veel betere oplossing is om een testcontainer op te spinnen en daar je testen tegenaan te draaien maar dat kan natuurlijk niet voor gesloten componenten. De enige testen die ik wel tegen azure zou willen draaien gaan er dan meer over of de configuratie wel allemaal klopt.

En nee met mocking ben je er ook niet want dan sla je feitelijk je hele database laag over dus weet je ook niet of die werkt.

Denk je? PostgreSQL voor een productieserver is echt niet iets wat je er 'even' bij doet als je enig nivo van performance, monitoring, failover en backups wil hebben. Dan heb je domweg een full-time DBA nodig, en die zijn heel zeldzaam. Een managed database afnemen is echt serieus minder werk en bovenstaande zaken zijn op een redelijke manier geregeld.

Als je die in productie draait dan draai je toch gewoon een managed PostgreSQL? Waarom zou je die dan ineens zelf willen managen want wat je zegt klopt als je zelf een databasse server op productie niveau wilt draaien dan komt daar best wat bij kijken. Het mooie van PostgreSQL is dat je het op zoveel plekken kan draaien, lokaal maar ook bij andere partijen zoals bijv scaleway.

[Reactie gewijzigd door Barsonax op 21 oktober 2025 20:42]

[bzzzt]

[...]

Ja tuurlijk kan je het in azure draaien maar dat is toch veel te veel gedoe? Is vele malen trager, de deployment duurt al langer dan het draaien van testen duurt. Daarbij moet je ineens locks gaan zetten op je build zodat builds niet elkaar in de weg zitten. Dit kost weer allemaal meer tijd en centen en is gewoon suboptimaal.

Ok, wist niet dat het zo brak werkte. Vind het wel bijzonder dat dit kennelijk wel geaccepteerd wordt voor een set productieomgevingen.

Veel betere oplossing is om een testcontainer op te spinnen en daar je testen tegenaan te draaien maar dat kan natuurlijk niet voor gesloten componenten. De enige testen die ik wel tegen azure zou willen draaien gaan er dan meer over of de configuratie wel allemaal klopt.

Als je code een 100% afhankelijkheid heeft op bepaalde services is een integratietest de enige manier om iets zinnigs te zeggen over de kwaliteit.

En nee met mocking ben je er ook niet want dan sla je feitelijk je hele database laag over dus weet je ook niet of die werkt.

Klopt, maar je kan wel bijvoorbeeld uitvoer van je database laag mocken om te verifiëren of business logica wel goed werkt.

Als je die in productie draait dan draai je toch gewoon een managed PostgreSQL? Waarom zou je die dan ineens zelf willen managen want wat je zegt klopt als je zelf een databasse server op productie niveau wilt draaien dan komt daar best wat bij kijken. Het mooie van PostgreSQL is dat je het op zoveel plekken kan draaien, lokaal maar ook bij andere partijen zoals bijv scaleway.

Dan gebruik je toch lekker PostgreSQL lokaal en in de cloud? Zie het probleem dan niet zo.

[Barsonax]

Ok, wist niet dat het zo brak werkte. Vind het wel bijzonder dat dit kennelijk wel geaccepteerd wordt voor een set productieomgevingen.

Dat een productie deploy een paar minuten duurt is vrij acceptabel, die doe je niet continu in je inner dev loop. Het draaien van testen daarintegen is wel iets wat ik heel vaak wil doen.

Als je code een 100% afhankelijkheid heeft op bepaalde services is een integratietest de enige manier om iets zinnigs te zeggen over de kwaliteit.

Het mooie is dat als je die afhankelijkheid in een container kan draaien dat je hetzelfde gedrag krijgt. Afhankelijk van welke dev je het vraagt is het opspinnnen van een testcontainer (https://testcontainers.com/) en applicatie waartegen je je testen draait een integratie test.

Klopt, maar je kan wel bijvoorbeeld uitvoer van je database laag mocken om te verifiëren of business logica wel goed werkt.

Dat kan maar je ziet in veel applicaties dat het vaak juist mis gaat bij de queries. Door die dan feitelijk over te slaan mis je een flink deel van de code waar bugs in zitten. Daarbij is het mocken en vooral het onderhouden hiervan niet altijd triviaal. Tenzij het niet anders kan doe ik dat ook niet meer. Je hebt eigenlijk 2 (productieve) opties:
- Je trekt de betreffende code echt los van je database zodat je het kan unit testen. Let op dit is niet simpelweg een interface ertussen zetten maar de IO naar de randen van je systeem brengen zodat de kern echt los is. Dit is niet altijd mogelijk of het waard.
- Je test de betreffende code met een integratie test wat tegenwoordig met testcontainers een prima optie is.

Dan gebruik je toch lekker PostgreSQL lokaal en in de cloud? Zie het probleem dan niet zo.

Als we konden kiezen hadden we dat al lang gedaan, zie mijn eerdere berichten.

[Orangelights23]

Daar komen ze niet achter hoor, dit is voor de zoveelste keer gerapporteerd. Groeten, een CISO bij een bank die inmiddels draait op Europese alternatieven.

[William_H]

Benieuwd welke europese alternatieven jullie gebruiken. Misschien dat jullie een voortrekkersrol kunnen aannemen.

[Barsonax]

Toevallig op scaleway of een andere partij? Ben benieuwd hoe dit ging en bevalt.

[Guru Evi]

De meeste tech-bedrijven zijn wel in meerdere clouds aanwezig. Dus als AWS uitvalt, kan Google of Azure overnemen. Als het met Nederlandse banken zo karig gesteld is dat 1 provider een probleem geeft, dan moeten ze misschien eens wat geld uitgeven aan een betere IT zaak.

Dat is net als vroeger, een "cloud" is 1 datacenter. 2 verschillende "clouds" zijn 2 datacenters etc.

Waar die zich precies bevinden zou in principe geen verschil uitmaken, zolang het verschillende geografische regios zijn in de 2 aparte 'clouds'.

Moesten ze een "Europese" cloud willen kunnen de banken wel evengoed hun eigen datacentra terug opzetten, de meeste banken zullen wel meer rekenkracht nodig dan een klein Europees datacenter kan leveren, en grote clouds bestaan niet want kleine bedrijven die groot willen worden, worden uit de markt getrapt door regeltjes voor alles tussen watergebruik en werknemers in de EU.

[Reactie gewijzigd door Guru Evi op 21 oktober 2025 00:39]

[jeanj]

Het meervoudig uitvoeren van applicaties kost geld, en meestal richt men als men dat doet, puur op het platform waar men al op zit en gebruikt de redundacy van het platform. Een ander platform hierbij betrekken vereist als eerste expertise van een tweede platfrom, en moet je het zodanig inrichten dat je redundant bent over de platformen heen. De kosten hiervoor zijn zeker een verdubbeling van de kosten (want 2 platforms is meer dan 1), en liggen waarschijnlijk wel hoger door de complexiteit.

Technisch kan het wel, er zijn genoeg tools beschikbaar om dit te doen, en het zou ook verstandig zijn om te doen als er een (niet financiële) business case voor is

[Guru Evi]

Met IaC is dit heel gemakkelijk te doen. Het voordeel van de cloud is dat, indien niet in gebruik de tweede infra (indien niet nodig) weinig tot niets kost als we spreken over HA failover.

Echter in de meeste systemen heb je sowieso meerdere instances nodig. Het is dan imho beter als je vb Redis in 3 verschillende cloud instances moet draaien, ze niet allemaal in dezelfde cloud te zetten. Zoals we net gezien hebben met AWS, veel van een cloud hangt af van 1 dienst in 1 regio, haal die er uit en het hele stapeltje valt.

Er zijn meer en meer mensen die nu uitvinden dat gespecialiseerde diensten veel duurder uitvallen dan zelf een VM te bouwen. Mensen mispakken zich aan serverless of zelfs de observability en krijgen een rekening van jewelste. Ik las onlangs nog van een bedrijf dat inzage wou krijgen in hun rekening, ze steken de cloud-native CloudWatch en CloudTrails aan en de rekening werd onverwachts verdubbeld voor wat effectief Prometheus en Grafana kan doen op een paar VMs.

[Reactie gewijzigd door Guru Evi op 21 oktober 2025 14:01]

[jeanj]

Daarom zeg ik ook technisch is dit zeker te doen. De grootste problemen zie ik bij de volgende zaken

1. de business applicaties zijn niet geschikt om over verschillende clouds te draaien. Nou zou je 1 cloud primair maken en de andere secudair of in een soort standby modus
2. de business data (realtime) synchroniseren over de verschillende clouds, dat zal ook een hassle zijn.
3. De beheer tooling synchroniseren over de verschillende clouds is ook een issue. Stel je hebt een monitoring ot ticket systeem, die gaat down in Cloud 1, wanneer gaat deze up in cloud 2, is de data synchroon?

Nogmaals technisch vast mogelijk, maar wegen die kosten op tegen het binnen een grote cloud als Azure geografisch spreiden?

Daarnaast, wat wil je er mee bereiken, onafhankelijk zijn van als Cloud 1 down gaat, en door kunnen draaien in Cloud 2 voor een beschikbaarheid van bijna 100%. Als je die 100% wil dan kan je het beter in eigen hand houden en zelf ook de infra beheren (of in ieder geval onder eigen regie hebben, en dat is bij een cloud provider zeker niet het geval)

Maar als ik het zwart in zie, laat het weten, ik leer nog graag bij

[Reactie gewijzigd door jeanj op 21 oktober 2025 17:28]

[Guru Evi]

Ik zie cloud enkel als een provider van VMs en data (een datacenter), niet als een reeks gespecialiseerde diensten. Als je een database hebt moet je die toch zowiezo synchroon hebben, of dit nu 2 instances in 1 cloud of 2 instances in 2 clouds is, het is "evenveel" werk, behalve als je natuurlijk een cloud-native database gebruikt en 'vertrouwt' dat de provider dit doet voor je (maar dat kost dan wel stukken veel meer in per-transactie kosten en je bent voor eeuwig en een dag "locked in" hun oplossing).

Al mijn IaC scripts zijn onafhankelijk van de onderliggende hardware. Als je een cloud instance hebt, of een hardware of een VMware VM, Een paar aanpassingen zijn nodig in Terraform per platform (vb. PXE boot vs image) maar 'de rest' (de deployment zelf) in Ansible verandert niet veel.

Veel cloud-native providers beginnen dit nu ook in te zien en volgen hetzelfde pad. Een van de software om je S3 cloud data te beheren (Qumolo) gebruikt gewoon EKS instances voor de data zelf zodat de S3 transactie kosten wegvallen. Opeens is "S3 in de cloud" 3x goedkoper en dan replicatie kan potentieel op block-level naar on-prem of Azure, dus je betaalt ipv transactiekosten voor de bandbreedte, die bandbreedte is een vaste maandelijkse kost die kan gemakkelijk tussen meerdere clouds of datacentra liggen. Er zijn andere producten die langzaam aan hetzelfde pad volgen omdat de grootste kost in de cloud niet je data of machines zijn, het zijn transactiekosten.

[Reactie gewijzigd door Guru Evi op 21 oktober 2025 19:57]

[Simon Weel]

Alles wat niet core business heet wordt afgestoten. Dat is al heel lang bezig. Mijn vader werkte in de zuivel. Ze hadden hun eigen vrachtwagenpark met tankwagens e.d. En toen kwam Bereschot en die zei: die vrachtwagens, dat heeft toch niks met zuivel te maken? Die moet je wegdoen en dan inhuren wanneer je ze nodig hebt. En dat idee is de afgelopen 50 - 60 jaar door het hele bedrijfsleven doorgevoerd, tot de paperclips aan toen - die kan je ook huren. Of neem mijn eigen bedrijfstak de bouw. Vroeger had een aannemer personeel die alles deed. Nu heeft een aannemer een coordinator die alle ZZP's moet coördineren - zelf bouwen ze niets meer. Maarja, op een dag zegt de helft van de ZZP'ers: nee, nu even niet. En dan heb je een probleem. Een zelfgekozen probleem.

[Pasteis]

Probleem is vooral dat men te weinig bij risico’s stilstaat. Of te veel vanuit een optimistisch gedachtegoed denken.

En ik snap het, want beleidsmakers en aandeelhouders zijn moeilijk te overtuigen als het hen geld of voordeel kost.

[magician2000]

En als je dan wijst waar apen en beren de weg op kunnen springen ben je maar lastig en negatief, terwijl je simpelweg wilt (laten) weten wat je kan verwachten.


Als vervolgens, doordat er niet geluisterd werd naar de specialist(en) de boel in elkaar stort, zitten ze de personen die er niets aan kunnen doen op de nek om het maar zo snel mogelijk weer op te lossen.


Beide meegemaakt. En zeker het tweede voorbeeld heeft toen ongeveer 25 tot 50 keer het bedrag gekost wat een tijdige investering was. Met als saillant detail dat de investering toen alsnog met spoed en tegen flink hogere kosten gedaan moest worden.

[JayPe]

Just-in-time versus geen betere raad dan voorraad.

Chips die niet geleverd kunnen worden en een opdrogende bevoorradingsketen.. hmm.

Misschien wegen de besparingen die er de afgelopen jaren mee gemaakt zijn ook wel gewoon op tegen de crisis waar de auto-industrie nu in dreigt te belanden. Maar dan wel graag als een gecalculeerd risico.

Net zoals de DNB, of zoals vandaag de AWS storing liet zien: Heel veel services. Als we gewend zijn dat alles altijd werkt, zijn we dan extra onthand als het ineens niet meer werkt?

Darwin zei niet: De sterkste overleeft. Maar die zich het best kan aanpassen aan de veranderende omstandigheden.

[Falcon10]

Het is een issue dat reeds een decennia, en langer, geleden begonnen is, met het enige verschil dat toen veel nog on-prem draaide, en ondanks dat de infrastructuur ook grotendeels op bijvoorbeeld Micorosft software draaide, kon je indien er enige sancties zouden zijn vanuit de VS je infrastrctuur draaiende houden (al was het dan tegen het contract of regelgeving in en zonder securityupdates).

Nu kan men gewoon de toegang tot je hele infrastructuur afzetten, zonder dat je er iets aan kan doen (zie die rechter bij het Gerechtshof in Den Haag). Dit soort risico's heeft men in het verleden over het oog gekeken (bewust/onbewust), of geminimaliseerd.

Echter met alle geopolitieke spanningen en afhankelijkheid die deze systemen nu hebben in het ganse eocomische systeem van Europa, is het nu een probleem. ( en terecht). Dit komt nog eens dubbel zo hard naar boven in wetgevingen zoals DORA, NIS2, CER, ...

Probleem is dat je niet "snel" even overschakeld van MS/Google/AWS/Oracle naar .... Want er is niets Europees dat het zo direct aan kan/support heeft/etc. Dit is minstens een 10 jaren plan eer we hier aan kunnen beginnen.

Onlangs nog een op een Cyberevent geweest, en daar was eenbepaalde onderzoeker, die het in de mond durfde te nemen door te zeggen: "Misschien dat we terug meer on-prem moeten gaan".

[Pinkys Brain]

Waar een wil is, is een weg. De wil is het probleem.

Er is niets fundamenteel anders dan 10 jaar terug ... er is niets fundamenteels waar Azure/AWS voor nodig is. Vooral 365 bespaart wat geld voor de IT, maar dat is over het hele bedrijf gezien ook niet fundamenteel.

Amerikaanse software kom je niet omheen, Amerikaanse SaaS wel.

[KorporaalTimmer]

De EU stond destijds toe dat Microsoft Nokia kwam slopen en opbreken. Als ze daar iets beter over nagedacht hadden dan zou Europa nog steeds eigen telefoons, tablets en ook een eigen OS hebben. Vervolgens had de EU boetes kunnen opleggen aan elk bedrijf dat het OS niet ondersteunde en we hadden veel minder problemen gehad. Dat het nu te laat is dat weet iedereen.

[Heloise]

Dat lijkt me wel erg simpel gedacht en ook niet zoals ik dat begrepen heb.

Het was Nokia die, kort gezegd, gewoon niet met de tijd was meegegaan, en producten (telefoons) bleef maken die niet langer bij hun klanten in de smaak vielen omdat die elders “betere” konden kopen (en daar dan ook nog meer geld voor wilden betalen).

[bzzzt]

Klopt, het verhaal van de problemen van Nokia is vooral dat de 'vernieuwers' tegengehouden werden door de oude garde die zich helemaal blindstaarde op de oude Symbian toestellen.

De ex-Microsoft directeur heeft ze hooguit een laatste zetje gegeven...

[rustycrab]

Laat dit nou een keer de schakeling zijn voor deze grote partijen om een beetje te verdiepen en de wil te hebben om van deze big tech af te stappen.

Misschien groter op laten bloeien wat de voordelen zijn van FOSS alternatieven en Linux wel degelijk een goed alternatief is.

[Reactie gewijzigd door rustycrab op 20 oktober 2025 18:31]

[Bedge85]

Hopelijk komt dit rapport van de toezichthouder ook aan bij de fiscus: nieuws: Ook fiscus kan geen EU-alternatief voor Microsoft vinden en zet migratie door

[gpon]

Niet alleen Nederland maar de halve wereld is afhankelijk van een handjevol Big Tech bedrijven uit de USA. Waarom? Gewoon gemakzucht. In China hebben ze dit veel slimmer aangepakt door werkelijk voor elke westerse oplossing een lokaal alternatief te creëren. Maar zij hebben ook de middelen en mankracht om dit op touw te zetten. In Europa is er simpelweg teveel verdeeldheid onder de lidstaten om die afhankelijk te doorbreken. Waar EU-lidstaten zitten te bekvechten is Amerika de lachende derde.

Trump hoeft maar de stekker eruit te trekken en alle banken en overheid infra ligt op zijn gat.

[sircampalot]

Deze waarschuwing valt wel heel toevallig samen met de grote storing bij AWS.
Zou de waarschuwing al die tijd wachtend op de plank hebben gelegen?