Tweede Kamer wil unaniem dat SIDN .nl-domeininfrastructuur niet naar AWS overzet

De Nederlandse Tweede Kamer is unaniem akkoord gegaan met een motie om de infrastructuur rondom het .nl-domein in Nederland te blijven houden. Wat de gevolgen van die stemming zijn, is nog niet duidelijk, maar de uitslag geeft een stevig signaal af.

Alle partijen in de Tweede Kamer stemden voor een motie om 'het .nl-domein weer volledig in Nederland te krijgen'. Die motie werd vorige week ingediend. Het gaat specifiek om plannen van de Stichting Domeinregistratie Nederland om een deel van haar infrastructuur naar clouddiensten van AWS te verplaatsen. SIDN is verantwoordelijk voor het beheer van het .nl-domein en wil het domeinregistratiesysteem en zijn eigen ict-infrastructuur naar de Amazon Web Services-cloud verplaatsen omdat dat goedkoper en makkelijker te beheren is. Door de huidige geopolitieke situatie, specifiek de rol van de Amerikaanse overheid, zijn steeds meer politici tegen die plannen. Twee belangrijke kanttekeningen daarbij zijn overigens wel dat de autoritatieve nameservers voor het .nl-niet worden verplaatst en dat de AWS-servers in Europa staan.

De gehele Tweede Kamer roept nu op die migratie naar AWS in zijn geheel tegen te houden. De motie zelf is daarvoor geen verplichting; het is een oproep aan het kabinet om stappen te zetten tegen die migratie. Het is maar de vraag hoe dat kan. Daarvoor zou er bijvoorbeeld een besluit van de minister nodig zijn, of mogelijk een wetswijziging. Het kabinet kan de motie in theorie ook negeren, al lijkt dat onwaarschijnlijk gezien de unanimiteit van de stemming.

De Kamer stemde daarnaast nog voor meerdere andere moties die onder andere door Barbara Kathmann van GroenLinks-PvdA, Jesse Six-Dijkstra van NSC en Martijn Buijsse van de VVD werden ingediend. Die moties draaiden onder andere om 'te stoppen met onnodige ict-migraties naar Amerikaanse techgiganten', het starten van een aanbesteding voor een Nederlandse 'rijkscloud' en het uitvoeren van een risicoanalyse en een exitstrategie voor clouddiensten van Amerikaanse techbedrijven. Ook andere partijen zoals Volt dienden moties in die werden aangenomen, waaronder de oproep om in Europees verband versneld te investeren in een eigen clouddienst.

Update, 18.03 uur - In het artikel stond aanvankelijk dat SIDN zijn dns-resolver in eigen beheer zou houden, maar zoals PaultheWEiRD opmerkt heeft SIDN alleen autoritatieve nameservers.

Reacties (238)

[ronaldvr]

Wat wel vaker gebeurt is dat de politiek (en dat geldt overigens niet alléén in de politiek) een 'wil' uitspreekt zonder daar budget aan toe te kennen.
Wil je geen AWS? Maak dan geld vrij om SIDN te ondersteunen. Wil je dat de treinen beter rijden? Investeer dan in onderhoud en materieel..
En dat kan uiteraard alleen maar als je niet 'de markt' tot heilige koe maakt, en beseft dat sommige zaken nutsvoorzieningen zijn waar niet direct winst gemaakt hoeft te worden of kán worden. (En dat de 'winst' op een ander vlak ligt dan monetair)

[Spykie]

SIDN heeft voldoende liquide middelen om zichzelf te ondersteunen.

[ronaldvr]

Errmmm kan je een jaarverslag lezen? Ik denk het niet...

Nettoresultaat na belastingen
2023: -372.535
2022 -1.761.390

Zie je die minnetjes? Dat betekent dat men jaar op jaar verlies lijdt. Dat men (nog) voldoende liquide middelen heeft is geen reden om dit te roepen want dat blijft dus op deze manier niet tot het einde der tijden zo...

[VySio]

Als je enkel naar resultaat kijkt dan kan je geen jaarverslagen beoordelen. Investeringen gaan bijvoorbeeld van het resultaat af (zie kopje investeringen). Als uitgaand geld nuttig besteedt wordt dan is een negatieve kasstroom (wat belangrijker is dan resultaat) helemaal niet zo erg.

Over het algemeen zijn de meeste groeibedrijven niet winstgevend en hebben hoge investeringen.

[Zeerob]

Een investering gaat niet van het resultaat af. Alleen de afschrijving op een investering gaat van het resultaat af.

[Digitist]

Heel simpel, dan moet de prijs gewoon omhoog die SIDN aan haar klanten rekent.

[NielsFL]

Sowieso heb ik het idee dat de SIDN gewoon veel te veel doet. We hebben het inmiddels over 8+ BV's en meerdere stichtingen. Terug naar "Stichting Internet Domeinregistratie Nederland" wat mij betreft en daar een rendabel bedrag rekenen.

[magician2000]

Met meer dan 6.000.000 geregistreerde domeinnamen moet dat mogelijk zijn en hoeft dat geen hoge kostenpost te worden voor de eindgebruiker. Maar ja, dan moeten die dus ook bij willen dragen aan iets goeds en niet gaan lopen klagen.

[ronaldvr]

Degene op wie ik reageerde had het er over dat men 'voldoende liquide middelen had' en dat is dus niet het enige dat telt dat klopt. Maar óók als je investeert gaat dat uiteindelijk -als je niet regelmatig een positief resultaat hebt- een keer richting bankroet.

[deadinspace]

Over het algemeen zijn de meeste groeibedrijven niet winstgevend en hebben hoge investeringen.

Maar is SIDN een groeibedrijf met hoge investeringen dan?

[VySio]

Nee, ik snap dat het zo leest. Het was gewoon een algemene opmerking in relatie dat winstgevendheid lang niet altijd het complete verhaal verteld. En een groeibedrijf is een voorbeeld hiervan.

[Die_ene_gast]

Het komt bedrijven altijd goed uit dat de winsten 0 of negatief zijn, scheelt belastingen.

[ronaldvr]

Hrmpfff dat geldt voor *sommige* bedrijven wellicht inderdaad, maar dat is in dit geval dus niet aan de orde.

Toelichting: Ja er zijn bedrijven die de zogenaamde "The Double Irish With a Dutch Sandwich: A Tax Avoidance Technique Used by Large Corporations" route nemen, maar zoals het artikel zegt: Dat is alleen zinvol als je een multinational bent. En dat laatste keer dat ik keek ging dat niet op voor SIDN

[Vexxon]

Het gaat nu om NIET overzetten naar AWS, het niet overzetten kost geen geld lijkt me.
Om het wel over te zetten naar iets kost wellicht meer dan het overzetten naar AWS

[JayPe]

Niet overzetten betekent géén besparingen doordat beheer blijkbaar goedkoper/eenvoudiger is bij AWS (zo men claimed in het bericht). Dus 'kost' niet overzetten naar AWS wel degelijk geld. Als SIDN qua beheerbudget te krap zit, moeten er mogelijk gewooon weg kosten bespaard worden. Verlieslatend blijven is geen optie, zonder toegekend, toerijkend budget

[Llopigat]

Ja goed om dit nu een halt toe te roepen. 3 maanden geleden was het nog niet zo'n punt. Maar nu heeft Amerika bewezen helemaal van de pot gerukt te zijn en dat heeft de situatie compleet veranderd.

Bovendien, er zijn zat partijen in Europa die AWS-compatible clouddiensten aanbieden. Zoals Scaleway.

Ik ben zelf ook op zoek naar een vervanger voor mijn email die nu bij Microsoft 365 draait. Moet wel eigen domein ondersteunen. Proton wil ik alleen niet. Te duur en hun crypto gedoe maakt het allemaal erg lastig met een lokale bridge die je moet draaien. Terwijl het eigenlijk helemaal niks toevoegt omdat alle mail toch unencrypted over internet binnen komt. Door hun encryptie kunnen ze zogenaamd mijn mail niet zien maar het komt niettemin gewoon unencrypted binnen zeilen op hun server En een gewone webhoster ook niet want ik had er verschillende voor M365 en er was altijd geklooi mee. Dus dat is nog een beetje lastig.

[Reactie gewijzigd door Llopigat op 19 maart 2025 11:29]

[DennusB]

Nee hoor, Scaleway kan VM's leveren en wat serverless functions, dan stopt het wel. AWS heeft 250+ services die een enorme versnelling kunnen betekenen voor je migratie/development-snelheid en kwaliteit. Er is geen enkele Europese providers die maar in de buurt komt.

[Llopigat]

Maar gebruikt zoiets als SIDN die allemaal wel?

AWS is 1 grote vergaarbak van allerlei diensten ja, maar er zit ontzettend veel overlap in en elke dienst is alsof het door een totaal ander team is gebouwd. Dus het nodigt niet uit om veel services te gebruiken. Bovendien is de betalingsstructuur expres heel ondoorzichtig dus dat is ook iets waarom je niet al te veel services wil aanspreken daar.

Scaleway ondersteunt de belangrijksten zoals S3 en serverless.

[Reactie gewijzigd door Llopigat op 19 maart 2025 11:31]

[DennusB]

Dan heb je er niet genoeg ervaring mee ben ik bang, ja er is overlap tussen services maar het nodigt juist uit voor goede service-selectie. Daarnaast gebruiken ze dat soort services nu niet, omdat ze hun eigen ijzer draaien. Gebruik gaan maken van dit soort services kan hun "product" enorm verbeteren, qua veiligheid maar zeker ook qua beschikbaarheid.

Edit : Serverless is niet een verhuisbaar stuk infra of zo. AWS heeft een compleet andere implementatie dan Scaleway.

[Reactie gewijzigd door DennusB op 19 maart 2025 11:32]

[EraYaN]

Als jij je serverless gewoon rond iets als Knative opzet dan kun je overigens heel gemakkelijk verhuizen. Maar het moet gezegd worden dat deze jongens nou ook weer niet zulke ingewikkelde dingen hoeven doen. Je kunt echt nog wel een team bij elkaar rapen die het gewoon runnen regelen. Sowieso twijfel ik aan de need voor serverless, hoe groot kunnen de spikes nou eenmaal zijn voor domein aanvragen en wijzigen.

En men vergeet nog wel eens dat je met wat moderne hardware echt HEEL VEEL requests kan verwerken, en duur hoeft die niet te zijn. Gooi er 100k tegenaan en je bent al best wel ver met wat moderne EPYC based platforms of zelfs ARM.

[DennusB]

Knative = K8S, K8S = CNCF = Amerikaans.

[EraYaN]

Waar dacht je dat de Linux foundation vandaan komt? Je kunt ook overdrijven... Anders is het heel gouw uit met bruikbare OS'en en dependencies.

[closefuture]

Maar was is je punt dan? Dat SIDN niet zonder Amerikaanse cloud gehost kan worden?

[DennusB]

Mijn punt is dat ik begrijp waarom ze de migratie naar AWS wilde starten. Ik ben ook voorstander van voorzichtigheid dus ben ook blij met het besluit hoor

[NielsFL]

Als AWS gebruiker moet ik constant schakelen tussen allerlei regio's en dashboards voor de verschillende producten. Het mag dan 1 bedrijf zijn, het is bepaald niet 1 dienst. Afgezien van de mooie verzamelfactuur is het voordeel ten opzichte van een combinatie van meerdere derden nihil.

Het probleem zit hem naar mijn idee vooral in de consultants. Die zijn vaak gecertificeerd in 1 bepaalde cloud provider, waar ze dan ook nog eens "kortingen" en snoepreisjes van krijgen. Die gaan er niet zo snel producten van derden bij betrekken, zelfs niet van andere grote Amerikaanse providers.

[DennusB]

Ik heb ook nooit gezegd dat het 1 dienst is, ze hebben ondertussen 250+ services! Voor zowat elke use case wel iets wat je KAN gebruiken.

Daarnaast zou t leuk zijn als AWS mijn “snoepreisjes” zou betalen, maar helaas

[Ablaze]

Het is sowieso geen goed idee om al die services te gebruiken vanwege vendor lock in.

[Jay-v]

Dat is naar mijn mening (voor een groot deel) onzin. Het overgrote deel is gewoon een managed open source oplossing die je ook elders kan (self)hosten.

Containers, databases, NAS storage, blob storage, jupyter notebooks etc.

AWS maakt het gewoon een stuk makkelijker.

[Reactie gewijzigd door Jay-v op 19 maart 2025 13:10]

[GeroldM]

Kwaliteit, als je het hebt over code, dan is dat meer een 'mind-set' dan dat je er tools in de cloud voor nodig hebt.

Maakt de cloud dat makkelijker? Ja, dat zal vast zo zijn. Maar dat maakt het geen keiharde eis. Zo'n beetje alle tools waarvan je gebruik kunt maken in de cloud, daar is ook een variant van te krijgen die je zelf kan draaien (cloud, hybride of on-prem).

Ja, je moet er wat tijd in steken, maar dan kun je grotendeels dezelfde structuur en procedures toepassen als cloud-aanbieders. En ja, met het beleid dat de VS nu bezigt is zelfredzaamheid geen keuze meer maar een must. Dus wordt het even aanpakken. Ondertussen hebben velen al behoorlijk wat meegekregen over hoe AWS/Google, Azure hun cloud-aanbiedingen in de markt zetten. Wat een goede leidraad zal zijn voor Europa om zaken net zo of zelfs beter op te zetten.

Dat jij zo vast wil houden aan AWS, dat geeft mij de indruk dat je veel tijd/geld/moeite geinvesteerd hebt in je AWS papieren en daardoor niets wil. AWS is niet de beste tool voor alle use-cases, net zoals Google en Azure en on-prem dat niet zijn. Denk dus dat je inzicht"'juist stuk 'gereedschap' bij juiste use-case" een beetje teveel richting AWS is gestuwd.

Trump/Musk/'Zuck'/Bezos/Altman hebben al duidelijk aangegeven dat zij compleet niet te vertrouwen zijn als het gaat om gebruikers. Het enige waarop je bj hen kan vertrouwen is hun lust op (meer) geld.

[ApexAlpha]

Bovendien, er zijn zat partijen in Europa die AWS-compatible clouddiensten aanbieden. Zoals Scaleway.

Sorry maar dit is echt onjuist.

Scaleway, OVH en andere Europese aanbieders verkopen hosting. Dat is echt heel wat anders dan de managed services bij Azure of AWS.

Beetje alsof je op zoek bent naar meubels en mensen je hout gaan verkopen.

[Llopigat]

Scaleway doet meer dan dat hoor. S3 compatible storage, Lambda-achtige serverless, managed inference, load balancer, managed DB. Compute ook in alle soorten en maten. En allemaal dynamisch aan te maken met API's zodat je je scaling kan doen. Alles betaald per uur, niet per maand enz.

Sterker nog, volgens mij doen ze helemaal geen traditionele hosting. Daar zie ik niks van terug.

[Reactie gewijzigd door Llopigat op 19 maart 2025 13:15]

[ApexAlpha]

Ja het wordt wel beter maar je kan echt nog niet zeggen dat er Europese aanbieders zijn die echt compatible zijn met alle diensten van AWS.

[Llopigat]

Nee maar dat hoeft ook niet. Niet iedereen heeft alle AWS diensten nodig, en bovendien zit er enorm veel overlap in functionaliteit.

Als je het zo brengt is het niet meer dan "We hebben in Europa geen AWS". Als je alles aan AWS afmeet dan is iets anders natuurlijk nooit genoeg.

[Htbaa]

AWS zal ongetwijfeld meer bieden, maar Scaleway verkoopt niet alleen 'hosting'. Tal van services ook, zoals object storage, docker image registries, serverless functions, managed databases, kubernetes etc.

[Argantonis]

Dit is gewoon klinkklare onzin en wordt met +2 gewaardeerd hier. Dat ze niet op hetzelfde niveau zitten voor hetzelfde bedrag, ok, maar het is absoluut niet alleen hosting.

[Reactie gewijzigd door Argantonis op 19 maart 2025 15:32]

[K0L3N]

Tegenhouden is makkelijk, maar gaan ze dan ook genoeg budget regelen om het fatsoenlijk op een andere manier te doen.

[Snow_King]

Ze hebben 22 miljoen per jaar. Budget bij SIDN is echt geen probleem, al doet Roelof (directeur) altijd geloven dat het wel het probleem is.

SIDN hun registratie systeem is niet zo spannend. 6 miljoen entries in een database, alleen maken ze het vaak veel spannender dan nodig.

[wanjakrah]

Een kleine nuance is dat er bij het runnen van een country toplevel domain meer komt kijken dan alleen maar het technisch operationele deel. Maar je hoeft inderdaad geen medelijden te hebben met ze. Persoonlijk lijkt het me juist voor een stichting als SIDN goed als ze nog actiever Europese industrie en open internet standaarden gaan ondersteunen.

[Snow_King]

Nah, het valt echt wel mee. Voor 22 miljoen per jaar kan je dat prima runnen. Het is geen rocket-science, echt niet. Maar ze doen dat wel geloven en maken het allemaal veel groter dan nodig is.

[piertje]

AWS goedkoper? wat is de huidige oplossing?

[Antiloop]

waarschijnlijk in het beginsel goedkoper op papier, en achteraf duurder door dat dingen tegenvallen of dat er zaken weggelaten zijn om zo een mooi plaatje te schetsen

[ronaldvr]

Inderdaad, dit voorbeeld kwam ik onlangs ergens tegen:
https://tech.ahrefs.com/h...9dd930af8?gi=d0204db85aa1

But the costs of these outsourced cloud benefits are sometimes high. They’re so high we were concerned about whether our business could exist if our infrastructure was 100% in the cloud. This inspired us to make an actual comparison based on facts. And here they are:

[joeri1]

Als je CPU/RAM/Storage in AWS 1-op-1 vergelijkt met een conventioneel datacenter, denk Hetzner, dan ben je in AWS nooit goedkoper uit. Naar de Cloud gaan is dan misschien ook niet de juiste keuze.

Men vergeet echter de voordelen, extra services, die AWS bied, en, bijvoorbeeld, Hetzner niet heeft. Het zijn die services waar je juist geld mee kunt besparen. Ook kan verdere automatisering ervoor zorgen dat je met minder personeel dezelfde/vergelijkbare infrastructuur kunt draaien.

[david-v]

Heel goed verwoord en inderdaad juist. Ook SIDN verplaatst niet alles naar de cloud. Maar dat snappen ze niet in Den Haag. Dus dit bericht hebben ze maar de wereld in gestuurd met hun Office 365 abbo bij het ministerie....zucht

[Powermage]

Het punt is ook niet zozeer kosten, het punt is willen we een zeer kritieke infra van Nederland in een amerikaanse public cloud omgeving moeten stoppen....

En kosten, stel nu dat Sidn forst weet te besparen met AWS, laten we zeggen dat dit 40% is.
Hoeveel goedkoper zal je .nl domeinnaam nu echt worden? dat zal echt een paar cent op het geheel zijn, imho een verwaarloosbaar bedrag voor goede onafhankelijkheid.

[david-v]

De kritieke infra, ofwel de core systemen van SIDN blijven in Nederland. Dit gaat voor zover ik begrepen heb over de administratieve systemen. Kosten kan een aspect zijn, maar flexibiliteit en beveiliging kan ook een aspect zijn.

[coolkil]

Het nadeel is dan weer dat je alle kennis die je had op het gebiedt van generieke infrastructuur helemaal verliest… je kan dus ook moeilijk weer uit de public cloud mocht je dat ooit weer willen.

[DennusB]

Ja, als je je cloud omgeving niet goed inricht kan het heel duur worden inderdaad!

[Raizio]

Hoe zouden ze het dan moeten inrichten volgens mij, volgens het voorbeeld in de link?

[DennusB]

Ze zetten alles op EC2 instances, gewoon doodsimpele lift & shift dus. Optimalisatie bereik je door het integreren met services die je werk makkelijker, sneller en/of veiliger maken. "Cloud Native" services dus. Daarnaast is geen rekening gehouden met Savings Plans, die je op EC2 zo een 70% korting kunnen opleveren.

[Reactie gewijzigd door DennusB op 19 maart 2025 12:01]

[Gwaihir]

Zo integreren met dergelijke services levert je vermoedelijk ook een zéér zware vendor lock-in op? Lastige afweging hoor!

[DennusB]

Helemaal eens, de vendor lock-in is het grootste "probleem", maar zit uiteraard op veel meer levels. Client devices, netwerk apparatuur etc.

[lariekoek]

Denk dat er maar weinig usecases echt goedkoper zijn. Enige voordeel van cloud is de mogelijkheid om snel en veel te schalen. Dan behaal je winst in tijd en direct cost omdat je geen grote aanschaf hoeft te doen.
Over t is het meestal onzinnig veel duurder.

[DennusB]

Ik werk al 10+ jaar in de Public Cloud space en ik kan je uit ervaring vertellen dat het echt niet "onzinnig veel duurder" is.

[closefuture]

Ik werk al 10+ jaar in de Public Cloud space en ik kan je uit ervaring vertellen dat het echt niet "onzinnig veel duurder" is.

Slechts "veel duurder" of slechts "duurder"?

[3raser]

Maar het is dus wel duurder.

[lariekoek]

Cute, ik zit ook al ruim 20 jaar in de tech. Kan je uit ervaring vertellen dat ik nog nooit de overstap cloud heb hoeven maken omdat het financieel loont, zeker niet over t.
Met uitzondering als je vaak en snel moet op/af schalen.

Je betaald gewoon keihard voor convenience en de mogelijkheid om aanschafkost/afschrijving eigen hardware zo uit te spreiden.
De bijkomstigheid is dat het met verloop van tijd onmiskenbaar véél duurder is.

[Reactie gewijzigd door lariekoek op 19 maart 2025 12:46]

[Mosterd]

Het grote probleem is dat @DennusB wel gelijk heeft maar dat al die optimalisaties vaak het proces bemoeilijken.

Het hele cloud concept is gemaakt voor gemak, behalve het kostenbesparing stukje, daarvoor moet je ineens specifieke saving plans onderzoeken en gebruiken, een andere service gebruiken dan de meest logisch klinkende service (zo heb je compute nodig en denk je “ah, dan haal ik compute” en komt er een cloud wizard je vertellen dat je ook je microservice kan omprogrammeren zodat hij in FaaS kan, want goedkoper), enzovoorts.

Dus ja, het kan en zal vast wel even goedkoop zijn, maar met een boel onlogische omwegen en dan nog heb je vaak niet de snelheden die je met een geconfigureerde dedi zou hebben.

“Ja maar bij een dedi moet je alles zelf doen”
Ja en met die omwegen om kosten te besparen speel ik dus kiet.

“Dan hoort je applicatie niet in de cloud te draaien”
Tja wat dan wel. Zou het haast als ”big enterprise only” willen noteren want zelfs de oprichter van Ruby on Rails is er van af gegaan. Als hun dan al te klein zijn om er op te draaien dan gaat dat voor velen gelden vrees ik.

[DennusB]

Hangt er natuurlijk helemaal vanaf wat voor soort project je doet. Als je greenfield aan de slag kan is het implementeren van de services vaak een logische keuze. Maar ik ben het met je eens dat het wellicht niet altijd beter is; als je in 2025 bijvoorbeeld nog monolithische java applicaties maakt met Oracle als database, dan moet je misschien niet naar de cloud.

[Reactie gewijzigd door DennusB op 19 maart 2025 15:23]

[Mosterd]

Je ziet nu ook veel diensten opspringen zoals Kamal en Coolify die eigenlijk de taken overnemen van cloud diensten maar dan open source zijn.

Daardoor constateer ik dat er wel vraag is voor cloud als concept maar dat de huidige providers gewoon teveel geld vragen voor de logische weg. Dan hosten mensen liever zelf hun diensten op dedicated servers met een cloud-achtig raamwerk erop.

Ik bekritiseer ook niet zozeer het concept “cloud”, die is zeker belangrijk voor redundantie en stabiliteit, plus ik zou zelf ook voor belangrijke services altijd een mixed use adviseren. Maar als ik kijk naar bedrijven die uit de cloud stappen zie ik wel dat het een cashcow is geweest de afgelopen decennia.

[david-v]

Het hele cloud concept is gemaakt voor gemak

Het is een van de voordelen, maar je laat een peuter ook niet in een server ruimte spelen met een water pistool.

Je moet wel weten wat je aan het doen bent, waarom, en welke keuzes je hebt. Dat heb je bij on premises net zo goed. Je moet on premises beslissingen nemen over de architectuur, netwerken, beveiliging, licenties en kosten. In de cloud moet je dat ook doen.

Met andere woorden, lift & shift en zonder nadenken gebruik maken van de cloud omdat het zo makkelijk en snel gaat is net wat ik zei, het loslaten van een peuter met een waterpistool

[!GN!T!ON]

Ligt ook aan de service, veel services (i.i.g. binnen Google Cloud, waar ik zelf het meeste ervaring mee heb) zijn gebaseerd op opensource producten denk Kubernetes, CloudSQL (MySQL & Postgress). Mocht een product binnen de cloud stoppen dan kan je altijd 1 'laag' naar beneden gaan van managed service naar managed infrastructure (container/vm) en dat product zelf draaien binnen de Cloud.

Dit geld natuurlijk niet voor alles, maar wel veel en je kan er ook specifiek rekening meehouden.

[Raizio]

Helaas is dat voor een hoop applicaties makkelijker gezegd dan gedaan. Ook een complete rewrite van een enorme monolith kost jaren aan tijd en geld.
Uiteindelijk is het wel de route die genomen moet worden, dat ben ik met je eens.
Tot die tijd zijn Cloud VMs zeker duur en verrassend traag vergelijken met eigen ijzer.

[DennusB]

Vooral goed kijken naar dingen als Reserved Instances en Savingsplans, je schaaft zo 70% van je EC2 kosten af! Scheelt toch aanzienlijk

[david-v]

In de eerste alinea gaat het wat mij betreft al fout

Infrastructure as a service (IaaS) cloud provides multiple advantages

Met andere woorden, we verplaatsen het ijzer van A naar cloud. En dan tot de conclusie komen dat dat duurder is....duh. huren van ijzer is duurder dan kopen. Nou, open deur wat mij betreft.

Hoeveel IAAS wij op onze workloads hebben?

0.

Ik kan je verzekeren dat in ons geval het een stuk goedkoper is.

[closefuture]

Ja, als je je cloud omgeving niet goed inricht kan het heel duur worden inderdaad!

"Your holding it wrong". Dat is ook altijd het argument bij alle ERP / CRM implementaties; Je hebt het pakket verkeerd ingericht. Er zijn plenty voorbeelden van waar cloud veel duurder is zoals Tweakers zelf ook beschreef.

[DennusB]

Yep, omdat ook Tweakers de mist in ging door een lift&shift te willen doen en dat is over het algemeen het slechtste scenario voor een cloud migratie.

[coolkil]

Kan zijn maar all in gaan op een cloud provider z’n specifieke tooling geeft een giga vendor lock misschien nog wel meer dan on-prem…

[Piemol]

Of als de applicatie niet is geoptimaliseerd voor 'the cloud'.
Ik had eens een applicatie naar Azure laten migreren, welke elke x minuten een héél simpele taak liet draaien (kijken of er nieuwe berichten zijn, en zo ja dan er iets mee doen). Daar zat volgens mij ook iets als een 'sleep()' in omdat de taak zelf maar elke 5 minuten gestart werd. Géén probleem op een eigen VPS, maar in de cloud héél duur door veel CPU cycles (of hoe dat toen ook heette).
Na een jaar weer terug gemigreerd vanwege de hoge kosten, de simpele taak aanpassen zou speciaal voor ons moeten gebeuren dus dat werd ook heel kostbaar.

[Djerro123]

Wat een raar artikel.

Ze vergelijken bare metal, waar ze eerst zeggen dat hun 20 servers hetzelfde kost als 2 servers in AWS, daarna zeggen ze dat ze 850 servers hebben (huh?) en doen ze de hele calculatie keer 850.

Echt onnavolgbaar deze calculatie. Maar als je 400.000.000 weet uit te geven aan public cloud, dan is het *waarschijnlijk* geen goed idee om dat uitte besteden en heb je absoluut de schaal dit zelf te doen.

Maar wat ik zeg is eigenlijk: wat een bagger slecht artikel!

En ja, lift and shift is duurder in PC als je infra cost vergelijkt, nogal wiedes zou ik zeggen. En ja, ik vind dat we onze afhankelijkheid moeten minderen. Maar laten we nou niet doen alsof voor veel bedrijven de Public Cloud geen uitkomst was zeg, dat is ook echt onzin.

[Coolstart]

Idd verbaasd me niets. Tegenover 10jaar geleden is er nu veel veranderd.

Je kan als bedrijf nu zonder veel problemen een 100+ core CPU kopen met meer een terrabyte ECC reg RAM en een 10Gbit uplink op een glasvezel. Voor minder dan €15.000. Schrijf dat af op 3jaar en je betaald €420/maand.

Beetje kort heel door de bocht maar daar draai je heel Tweakers op.

Ik ken iemand die amateuristisch een kleine service via een Mac mini m4 pro, 64Gb ram, 500mbit glasvezel uplink. Dat ding is eigenlijk een mini server op een paar vierkante centimeter.

En met 120Gbit Thunderbolt 5 optie komen er zeker wel krachtige uitbreidingsmigelijkheden zoals raid SSD.

[MMaster23]

En toch mist deze vergelijking zoveel onderdelen:

- Kosten voor aanschaf (procurement), installatie en onderhoud van fysieke en logische installaties
- Kosten voor software en licenties (sure, FOSS is gratis maar niet vergelijkbaar met de AWS/Azure stack aan APIs en features)
- Kosten voor het designen en ontwikkelen van eigen software features wanneer je niet op AWS/Azure features kunt bouwen
- Kosten voor infrastructurele beschikbaarheid (clustering, failover, reserved capacity)
- AWS is zo geschaald dat ze aan hun maximale piek kunnen voldoen, dat is onrealistisch.
- Pieken in lokale infrastructuur zullen voor minder prestaties leveren dan theoretisch toe te schrijven is (100x nvme zal niet 100x 4gbyte/sec of 750k IOPS sustained, altijd zijn. In cloud betaal je ook voor prestatiegarantie (ook al moet je request dan over NOG meer hw gescaled worden).
- Dit systeem lijkt niet multi-regional te zijn en multi-regional willen schalen zal je enorm veel moeite kosten.
- Zie maar eens personeel te vinden om jouw hardware en software stack te onderhouden en engineren. Terwijl AWS en Azure engineers duidelijk en gecertificeerd zijn. Recruitment zal moeilijker zijn.

Ook mis ik veel over hoe resistent de omgeving is? Wat als er lokale verstoringen zijn in stroom en netwerk? Wat als er een cyber/DDOS aanval is? Wat als je ineens een peak in demand hebt (door uitverkoop, of speciale events? Ga je de infrastructuur schalen voor die ene peak? Of ga je gewoon een denial verkopen in zo'n geval?

Ik heb jaren lang datacenters mogen scalen en inrichten en werk nu exclusief met cloud. Ja puur euro voor euro per mhz, zal de cloud nooit winnen. Maar de schaalbaarheid, uniformiteit, veiligheid en rekbaarheid, is echt ongekend. En dat gaat je nog vele miljoenen kosten. Dit is niet de eerste "we hebben zelf hw gekocht want cloud is zo duur" post die ik voorbij zie komen, en allemaal hebben ze dezelfde oogkleppen.

[ronaldvr]

Ja dat kan allemaal waar zijn, maar wáárom dan? Al die 'features' heb je die nu echt nodig?

[GeroldM]

Je draagt de reden (om naar cloud over te stappen) aan over lokale problemen met stroom en/of netwerken. Als ik een probleem met lokale stroom/internet verbindingen heb, dan ik niet communiceren met een server in NL of in de VS. Een generator en alles on-prem, dan kan ik tenminste nog door (als bedrijf zijnde).

En als je denkt dat je risico spreidt door de cloud, in feite heb je een systeem gebouwd welke om kan vallen door problemen met stroom/internet op je eigen locatie, maar ook op de locatie van het NL datacenter. Of het datacenter in de EU/VS. En mogelijke problemen met de knooppunten tussen jouw locatie en het datacenter waar je gebruik van maakt.

Begrijp me goed, on-prem is niet de juiste oplossing voor alle gebruiksscenarios, net zoals cloud dat niet is. Zelf neig ik altijd meer naar on-prem, want de cloud-frameworks waarmee ik aan de slag, kan werken net zo goed on-prem als hybrid/cloud. En doen echt niet zoveel onder voor wat de cloud aan services biedt.

Daarnaast is er nu ook genoeg AI/LLM voorhanden, dat je vlot genoeg je procedures om kunt zetten in bruikbare en schaalbare code op je eigen cloud-framework, dus blijft alleen het echte probleem over, hardware op of neerschalen wanneer dat nodig is. Dat is waar het gemiddelde datacenter veel meer budget zal hebben/krijgen dan ikzelf.

[vDorst]

Duurder omdat je ook voor geblokkeerde request betaald, zie deze blog: How an empty S3 bucket can make your AWS bill explode.

[DennusB]

In de meerderheid van de cases is AWS inderdaad goedkoper, door het gebruik van serverless infracstructuur & auto-scaling kan je al veel besparen. Dat gaat je met oud-ijzer niet lukken.

[SillieWous]

Makkelijker en goedkoper zijn twee verschillende dingen. Sowieso is “oud ijzer” lang niet de enige optie.

[closefuture]

In de meerderheid van de cases is AWS inderdaad goedkoper,

Zei hij zonder enige onderbouwing of te verwijzen naar feiten...

[Ed Vertijsment]

Een vps begint al van €5 in de maand, zeg een paar stuks of een grote en voor wat ik lees dat ze neer willen zetten ben je er wel. Heb je geen aws voor nodig (en ik betwijfel ten zeerste of het goedkoper is).

Al die abstractie is niet gratis.

[DennusB]

De abstractie is niet gratis, maar haalt wel een heel stuk operationele overhead (en ja, dat kost ook geld) bij de organisatie weg = meer geld voor innovatie en verbetering.

[Ed Vertijsment]

Nee, het vervangt dat omdat je in plaats van een systeembeheerder een cloud engineer nodig hebt, in mijn ervaring is de laatste route vaak juist veie malen duurder.

[DennusB]

Dan verschillen we daar van ervaring, je hebt inderdaad minder "oldskool" systeembeheerders nodig die eindloos je Windows updates zitten te installeren en meer "Cloud engineers" die snappen hoe de services van de hyperscalers werken, kost ook geld, maar in the end pakt het in mijn ervaring goedkoper uit!

[Ed Vertijsment]

Nu ga je uit van Windows, en handmatige updates…

Anyhow, ja mijn ervaring is volledig anders.

Ik zie dat cloud based systemen voor veel toepassingen:

- Geen meerwaarde bieden.
- Duurder zijn.
- Complexer zijn.
- Niet betrouwbaarder zijn.
- trager zijn

Vooral dat laatste omdat vaak genoeg (vooral bij k8s achtige toestanden). De nodes waar het spul op draait veel kleiner zijn dan het “oud ijzer” (waar die spullenboel uiteindelijk ook gewoon op draait) waardoor enige headroom en performance vaak vrij ver te zoeken is.

Sure, het schaalt internationaal (maar dat kan “oud ijzer” ook); maar of dat nu het belangrijkst is voor een registratietooltje voor een Nederlands domein?

[stefanhendriks]

Ik heb audits meegemaakt waarin mij werd gevraagd hoe het kon dat de hosting zo goedkoop was (een factor 10x goedkoper). Dat was omdat we het zelf deden ¯\_(ツ)_/¯ . Dat waren ze niet meer gewend...

Dus ik herken dit helemaal. En je kunt best veel zelf doen; in die zin is cloud een beetje een abstractie die alle 'OPS' geneuzel voor je verbergt. Het moet alleen nog steeds gebeuren (maar iemand anders zijn probleem ofzo). Dat vertrouwen moet je maar hebben. (en ervoor willen betalen). Die abstracties kosten geld. In die zin is het vreemd dat 'cloud' goedkoper kan zijn. Dat zal alleen werken door de enorme schaal waardoor je betere marges hebt.

[Ed Vertijsment]

Factor 10 herken ik ook, van microservices + cloud naar monolith + vps gemigreerd. Hiervoor moest een groot deel van de applicatie herschreven worden. Factor 10 ofzo goedkoper om te hosten, en de werkzaamheden waren binnen 1 maand terugverdiend.

Waar het eigenlijk om ging was stabiliteit, die ging vooral (net als performance) omhoog.

[stefanhendriks]

Hail the Majestic Monolith

[Ed Vertijsment]

Uiteindelijk is een microservice based architecture een monolith met meer network calls.

Wat mensen vergeten is dat geen van deze namen echt boeit. Wat imo belangrijker is, is hoe je code organiseert. En het opsplitsen daarvan, net zoals schalen is voor zowel monoliths als microservices prima mogelijk.

[Reactie gewijzigd door Ed Vertijsment op 19 maart 2025 13:57]

[stefanhendriks]

In de ideale wereld is alles 1 monolith en heb je intern mooi netjes modules die je los kan trekken (en met weinig moeite deployable kan maken).

Maar zodra je die kant op gaat heb je meteen een multiplier qua monitoring en log aggregatie. Allemaal dingen die je niet hebt bij 1 instance/monolith.

Daarnaast: schalen kan ook met meerdere instances van een monolith. Microservices architectuur hoeft niet persee ;-)

[Reactie gewijzigd door stefanhendriks op 19 maart 2025 13:09]

[Ed Vertijsment]

In de ideale wereld is alles 1 monolith en heb je intern mooi netjes modules die je los kan trekken (en met weinig moeite deployable kan maken).

Ideal verschilt per case, er zijn situaties waar microservices en cloud sense maken, maar imo is te vaak de hype de reden dat het wordt ingezet.

Maar zodra je die kant op gaat heb je meteen een multiplier qua monitoring en log aggregatie. Allemaal dingen die je niet hebt bij 1 instance/monolith.

Dat hoeft niet perse een uitdaging te zijn. Kan gewoon meekomen met je standaard deployment scripts (die je als het goed is al hebt liggen van de eerste deployment).

Daarnaast: schalen kan ook met meerdere instances van een monolith. Microservices architectuur hoeft niet persee ;-)

Eens, maar er zijn zaken waar dit minder goed werkt. Het hangt er net vanaf.

Mijn opvang is dat netto in de meeste situaties die ik gezien heb microservices beter schalen zodra het gebruik internationaal gaat, ten koste van single user performance. En dat je niet moet beginnen met microservices maar er naartoe kan zodra je tegen limieten aanloopt.

[Reactie gewijzigd door Ed Vertijsment op 19 maart 2025 13:17]

[stefanhendriks]

Is microservices niet vooral zinvol als bepaalde onderdelen onevenredig veel load te verduren krijgen? DIe kan je dan apart schalen. Anders is horizontaal schalen met een loadbalancer ervoor prima voor 99% van je gevallen. Verder denk ik dat je OPS wel degelijk meer een wissel trekt, het is meer dan alleen een scriptje anders uitvoeren. Alles wordt n^<aantal services> complexer. Denk aan bijv per omgeving in je OTAP. Denk aan monitoring & alerting. Het uitrollen (of wat als uitrollen niet lukt). Het lokaal kunnen draaien. Ja, je kunt met 'docker compose' in principe je hele swikkie aan mircoservices booten maar je moet er verdomd zeker van zijn dat je de juiste versies draait. In die zin is KISS en YAGNI goed om in achterhoofd te houden. Alleen de complexiteit opzoeken als het echt niet anders kan.

Anyway, volgens mij zijn we het voor het grote deels eens met elkaar en wijken we enorm af van het originele punt

[Ed Vertijsment]

Je hoort

En je eerste punt is volgens mij idd de beste use case voor microservices.

[roffeltjes]

Cloud engineers zijn bepaald niet goedkoop...

[stefanhendriks]

Ik snap deze redenatie niet, want zelfs de oldskool systeembeheerders worden nog steeds betaald, maar dan zitten ze bij AWS toch? Ja de schaal doet iets; en Amazon zal er vast wat van subsidieren.

Tot nu toe zijn alle cloud oplossingen die ik heb gezien, niet per see goedkoper. Maar wat je wel hebt is een aantal voordelen mbt verantwoordelijkheden. Het is een beetje buy vs do-it-yourself. Want, los van de uren die iemand kost om het zelf te doen zitten er een hoop operationele extra kosten bij (zoals HR, communicatie binnen team, etc.). In die zin zal cloud een voordeel kunnen zijn.

Het blijft alleen een lastige discussie zonder harde cijfers...

[DennusB]

Ja, met het verschil dat AWS zo ongeveer alles wegautomatiseert aan de "achterkant", dat scheelt dus wel degelijk in de kosten.

[Ed Vertijsment]

Nee, je betaald er alleen aws voor in plaats van je medewerkers (als je de cloud engineers even weg laat)

En het implementeren van aws zelf is nog steeds niet automatisch.

[GertMenkel]

De cloud is goedkoper vanwege schaalvoordeel mits je alle cloudvoordelen anders zou nabouwen in je eigen datacenters. Dat wil zeggen, instant failover tussen twee fysieke locaties met drie andere dubbellocaties standby mocht je backuplocatie ook down gaan. Ook moet je genoeg opslag en capaciteit inkopen om ineens duizend keer zoveel load aan te kunnen zonder verkeer te droppen. Als je dat allemaal opzet, zit je bij cloudproviders goedkoper, omdat hun hele functie is dat te doen op grote schaal.

Voor de meeste bedrijven zijn driekwart van die voordelen nice to haves. Zodra je bedrijf schaalt, wordt het verschil in prijs al snel zo groot dat een klein team systeembeheerders uitkan. De automatische scaling kan zelfs een nadeel zijn, want bij een gerichte DDoS kun je daarmee snel ineens met een gigantische rekening zitten.

Het grappigste wat ik van de cloud voorbij zie komen is dat mensen voor kostenbesparing naar de cloud gaan, doorhebben dat alles zelf regelen toch best duur is, en een derde partij inhuren voor een flinke som geld om de cloud voor ze te managen.

[stefanhendriks]

classic. Ik heb ook een keer gezien dat - door automatisch schalen - de kosten van cloud door het dak vlogen door een enorme toename aan verkeer. Soms is 'sorry we zijn even niet bereikbaar' wenselijker dan een dikke rekening...

[coolkil]

Ondanks dat ik met regelmaat even in een prompt duik is het merendeel van mijn beheerwerk toch echt geautomatiseerd in ansible of iets dergelijks…. Dat werkt zowel onprem als in de cloud de keren dat ik inlog is om te checken hoe het draait. Snel een log te bekijken. Of om te kijken of mijn ansible playbook echt helemaal het gewenste resultaat gaf. Niks handmatige updates of configuratie.

[camper69]

Bij de kleinere organisaties is dat zo. Bij grotere organisaties zijn er enorme besparingen te realiseren door zelf meer te doen. Dus meer geld voor innovatie en verbetering.

Ik denk dat bijv. Tweakers met gemak 5 tot 10 keer zoveel kwijt zou zijn bij AWS.

[DennusB]

Als ze een simpele lift-en-shift zouden doen wel ja, maar dat is dan ook veruit de slechte manier om naar de cloud te migreren

[camper69]

Lift en shift zou heel dom zijn, maar zelfs op de meest efficiënte manier in de Cloud ben je vele malen duurder uit. Ik denk wel dat je als klein of beginnend bedrijf vrijwel altijd zou moeten kiezen voor de Cloud. Maar lopen de kosten op, kan het bizar veel geld opleveren door wat spulletjes zelf te beheren.

En de cloud propaganda machine doet alsof dat heel erg moeilijk is. Juist sinds de komst van LLM's en gebruik van Linux is dat vele malen eenvoudiger geworden.

[Cartman!]

Tot er iets met je ene VPS aan de hand is en dan hang je. Het voordeel van cloud is dat, mits je het goed doet, de boel gewoon kan blijven draaien en schalen zonder dat je het hoeft te beheren. Ook ben je zelf verantwoordelijk voor OS updates/patches, laat AWS dat maar voor me regelen allemaal.

[Ed Vertijsment]

Heb je ook spullen voor, load balancers en failovers. Wat dat betreft heeft cloud niets nieuws gebracht.

[Cartman!]

Zeker, maar dat ga je dus niet met 5 euro per maand redden.

Bovendien; met serverless compute zijn dat dus precies de dingen waar ik me niet mee bezig hoef te houden en zit allemaal inbegrepen in de kosten. Pay per use.

[Ed Vertijsment]

Nee, niet €5, maar dat red je aws ook niet mee.

Bovendien; met serverless compute zijn dat dus precies de dingen waar ik me niet mee bezig hoef te houden en zit allemaal inbegrepen in de kosten. Pay per use.

Nee, je baas (of jijzelf) betaald Amazon in plaats van jou die dat ook weer een marge op wil.

[Cartman!]

Voor 5 euro per maand kan ik miljoenen requests uitvoeren met Lambda, geen enkel probleem. Het schaalt het terug naar 0 in de nacht en als ik 100k concurrent users heb dan schaalt het ook automatisch mee. Zij verzorgen dat het over 3 datacenters wordt verspreid, patches, alles. Dat prijspunt is zeer moeilijk tot niet te evenaren.

Dat Amazon er alsnog aan verdient is logisch, daar heb ik geen enkele moeite mee.

[Ed Vertijsment]

Maar met lambda ben je er nog niet.

[DennusB]

Wie zegt dat? Hangt toch helemaal af van je usecase?

[Cartman!]

Stel ik heb een database nodig, dan pak ik DynamoDB die ook een pay per use pricing model ondersteunt. Kan ik nog steeds zoveel requests per maand afhandelen. Load balancing etc regelt AWS allemaal voor me, dat is het mooie er aan.

[GertMenkel]

Serverless lijkt vooral goedkoper te zijn zolang je vlak bij de gratis voet blijft, die prijzen stijgen razendsnel. Auto scaling is wel een dingetje (al kan ik me niet voorstellen dat SIDN ineens 1000x dezelfde load moet verwerken zonder downtime) maar daar heb je gelukkig geen AWS voor nodig. Ik denk niet dat AWS je veel geld gaat besparen, maar andere cloudboeren kunnen zeker goedkoper zijn dan alles in eigen beheer nemen.

Ik vraag me bij SIDN dan wel weer af of hier een cent te winnen valt puur en alleen door de bizarre kosten die Amazon durft te vragen voor netwerkverkeer.

[PatrickH89]

Ik betwijfel of je dit kunt zeggen. Als je zit met grote pieken en grote dalen kun je waarschijnlijk best wat besparen met FaaS en dergelijke, maar met wat kleinere pieken en wat kleinere dalen zal het feest wel meevallen. Relatief is het een stuk duurder, maar dat zelfgekochte ijzer kun je niet eens even afschalen dus het hangt vooral af van de schalingsbehoefte. En heel belangrijk dat je goed afweegt voor elke service die je kiest of het de moeite waard is. Anders wordt het heel snel heel erg duur.

[Fishbeast]

Over het algemeen zijn de hosting-kosten niet de grootste post, maar juist de kosten die het draaiende houden van infrastructuur met zich mee brengt.
Een cloud-native systeem opzetten kan initieel meer kosten met zich meebrengen, maar heeft daarna vele malen lagere opex kosten, omdat je niet meer druk hoeft te maken over patching, kapotte disks, afschrijving van hardware etc.

Maar, los van de kosten op de korte termijn: een cloud native systeem is vaak veel flexibeler (uiteraard, dit valt of staat met de passendheid van de inrichting op de businesscase) aan te passen op veranderende/evoluerende behoeftes van de business, wat uiteindelijk veel meer waard is. Het doet minder pijn om afscheid te nemen van dingen (geen hardware met nog jaren afschrijving te gaan) of juist nieuwe initiatieven te starten (er hoeft geen hardware aangekocht/gereserveerd te worden, geen lange termijn commitment nodig).
Ik zou als SIDN-zijnde ook zeker kijken naar een EU cloudprovider die hogere abstracties kan leveren die in de buurt komen van de dienstverlening van een AWS of Azure.

[Bierkameel]

Ze huren heel wat racks bij Eurofiber in Arnhem, geen idee of ze ook repliceren naar andere Eurofiber sites.

[Koen Hendriks]

Gaat vooral om expertise en kennis van medewerkes om de huidige infra werkend te houden en eventueel op te schalen waar nodig. Nu is het zoals ik heb begrepen vooral 'maatwerk'.

Echter is AWS heel erg bekend en bijna een standaard geworden (of dat goed/gewenst is of niet laat ik even in het midden). Het is makkelijker en goedkoper om personeel te krijgen die is 'opgeleid' of 'getraint' met AWS dan met een eigen hosting / netwerk infrastructuur.

[roffeltjes]

Goedkoop en Cloudengineer zijn voor mij geen bekende combinatie.

[smitae]

Tja, goedkoper of duurder is maar een deel van vraag/antwoord. In de basis gaat het hier om security, toegang tot data, ownership etc. Dat kost per defintiie geld.

Wil je voor het "gemak/kosten/etc" afhankelijk zijn van een buitenlandse partij of wil je zelf voor een groter deel in control zijn. Het gemak waarmee we momenteel onze basis infra uit handen geven(gegeven hebben) aan partijen die mogelijk op termijn niet betrouwbaar zijn, om wat voor reden dan ook, beetje vreemd.

Het is in de basis gewoon geen technische vraag, het is in eerste instantie een business requirements vraag. Als je die goede duidelijk hebt kun je keuzes gaan maken hoe je het gaat opzetten.

[Scribe]

Unaniem en de Tweede Kamer? Kan me de laatste keer dat dat gebeurd is niet herinneren

Goed om te zien dat iedereen het hier mee eens is. Als Amazom hier de macht krijgt over Nederlandse domeinnamen zou dat echt te triest voor woorden zijn.

[Robbaman]

Nu kun je je afvragen of ze met deze stap echt "de macht krijgt over Nederlandse domeinnamen".

Natuurlijk kunnen ze de machines uitzetten of op andere manier saboteren, maar ik neem toch aan dat dergelijke infrastructuur zodanig is opgezet dat de beheerder van de infrastructuur geen toegang heeft tot de daadwerkelijke services die op die infrastructuur draaien.

[Scribe]

Ik wil geen doemdenker zijn, maar sabotage voor zulke kritieke infrastructuur zou gewoon niet mogelijk moeten zijn door een buitenlandse entiteit, punt.
Een verstoring van de volledige .nl domeininfrastructuur zou een ontwrichting zijn van de samenleving die we ons gewoon niet kunnen veroorloven.
Verder zou het ook een beetje een middelvinger zijn naar de Nederalndse techindustrie. We moeten gewoon zorgen dat wij binnen ons land een fatsoenlijke cloudprovider hebben die dit soort kritieke zaken ook kan regelen.

[Zwarte_os]

Ik zou persoonlijk dat liever op Europees niveau laten coordineren a la eduroam.

[happysan]

Zou mooi zijn als de landen samen komen om een mooi Europees volwaardig alternatief voor AWS of Azure te realiseren. Daar kan Nederland dan zijn kritieke infra op plaatsen, samen met de andere landen in Europa.

Dan hebben we het voordeel van een grootschalige infra verdeeld over het hele continent, zonder dat ieder land het wiel opnieuw moet uitvinden met z'n eigen spul.

[BCC]

Exoscale, OVHcloud, Scaleway - er is al best wat binnen de EU - https://european-alternat...naged-kubernetes-services

[GeroldM]

Er zijn veel landen in de EU en veel culturen. Wat een (heel) soepele werking van de EU als machtsblok in de weg zit.

Je hebt er dus wel gelijk in dat het op EU nivo geregeld dient te worden. Maar door de huidige situatie in de VS, heeft de EU niet zoveel keuze meer en zal men wel als 1 blok moeten gaan regeren.

Want de VS hebben (nog steeds) een (technisch) imposant leger, en Rusland heeft duidelijk aangetoond dat het er totaal geen probleem mee om net zoveel soldaten voor de machinegeweren van de tegenstander te plaatsen om deze zodanig te verhitten dat de loop kromtrekt (om daarna de positie aan te vallen).

De wereld veranderde flink op het moment dat de VS de symbiotische verbanden met Canada verbrak. Een relatie die zo'n 150 jaar heeft standgehouden en veel langer door had kunnen gaan als Trump/Musk niet de strapatsen uit hadden gehaald die ze hebben uitgehaald. Velen denken dat deze ellende na 4 jaar stopt, maar het beeld dat de (helft van de) VS heeft van de rest van de wereld is behoorlijk verziekt.

Dus als Trump na deze periode geen president meer is, zeg 'als' omdat ik verwacht dat hij zich als president voor het leven uit zal roepen. En waarvan ik hoop dat er nog weinig jaren voor Trump over zijn vanwege zijn ongezonde levensstijl. Maar dat zal weinig uitmaken op het wereldbeeld dat de VS op de rest van de wered projecteert.

Dus is het van belang dat de mate van de belangrijkheid van de VS word ingedamd. De eerste stap is het losweken van diensten en besturingssystemen uit de VS. Van de EU verwacht ik dat er zou genoeg kennis, kunde en macht moet zijn om dat relatief snel voor elkaar te krijgen.

Ook zou ik als EU zijnde een handreiking doen naar Canada en eventueel Mexico/Australie/nieuw-Zeeland. Dat zij op assistentie (militair/humanitair) van de EU kunnen rekenen als de VS meent zich te moeten roeren.

Putin lacht nu, omdat hij de VS zonder slag of stoot onder controle heeft gekregen. Maar hij is ook triester, omdat hij nu met de EU een machtige speler op het internationale speelveld heeft gekweekt. De EU is op dit moment nog te verdeeld en in ongeloof over hoe de VS zich van haar slechtste kant hebben laten zien. Maar dat kan dus snel veranderen. En de EU zit vast aan Rusland, wat zowel een groot voor- als nadeel is qua militaire acties.

[WhiteHatter]

Heel het internet is afhankelijk van buitenlandse entiteiten dat is nou juist het idee van het internet. Denk je nou echt dat er nog iets doordraait hier als ome Trump daar de kabels doorknipt. Dan kan je leuk al je data in Nederlandse datacenters hebben staan maar ligt alles alsnog plat. Nederlandse tech industrie ligt lichtjaren achter als het gaat om server hardware, firewalls, routers, switches... Waar denk jij waar al die hardware vandaan komt voor die Nederlandse datacenters, niet uit Nederland in ieder geval. Deze hele discussie is gewoon weer een voorbeeld dat mensen bovenin geen idee hebben hoe de wereld werkt. Ik hoor graag van 1 politicus hoe DNS werkt en wat het inhoud, dan praten we verder.

[wiseger]

Er is geen enkele garantie dat dat zo is. De Amerikaanse wet is heel duidelijk, overheidsdiensten kunnen gewoon de infrastructuur hacken de gegevens zichzelf toe-eigenen e.d. met hulp van de Cloud aanbieder. Zonder dat de Cloud aanbieder überhaupt de klant op de hoogte brengt.

Nu met president Trump worden mensen ineens wakker en schrikken ze dat president Trump ineens controle over grote delen van onze infrastructuur heeft.

Unaniem akkoord geeft wel aan dat de schrik er goed in zit.

[DennusB]

Daar heb je zelf ook een deel controle over, als jij eigen key-material gebruikt (bijv met een HSM) voor je encryptie, dan kunnen ze er echt niet bij.

[wiseger]

Volledig vertrouwen op encryptie is echt vragen om ellende. Ik ken het argument, dat is wat de Cloud aanbieders de klanten elke keer voorhouden.

Kritieke infra hoort gewoon in Nederland te staan, beheert door Nederlandse entiteiten.

[DennusB]

Ja maar geen vertrouwen hebben in encryptie welke zeer regelmatig door volledige audits moet voelt ook een beetje als aluhoedjes gedrag. Waar de infra ook staat, in-flight & at-rest encryptie moet je sowieso goed regelen.

[wiseger]

Neemt niet weg dat het slechts een enkele barrière is, eentje die in het verleden regelmatig niet waterdicht bleek te zijn.

Kritieke infra wil je gewoon binnen je eigen landsgrenzen en je eigen controle hebben.

Dat alu-hoedje argument gaat niet meer op. Men is in Europa wakker geworden. Zelfs bij militaire producten als straaljagers en raketten maakt men zich inmiddels ernstig zorgen of die geen kill-switch bevatten. Het ondenkbare, dat ze ingezet kunnen worden tegen de VS, is niet langer meer ondenkbaar.

Het gemak waarmee de VS ineens het Starlink internet in de Oekraïne uitzette, terwijl de Starlink rekening gewoon door Duitsland en Polen betaald werd, heeft men doen inzien dat de wereld echt veranderd is en vertrouwen op blauwe ogen niet langer kan.

[NLxAROSA]

"Vertrouwen komt te voet en gaat te paard".

Het heeft jaren gekost voordat Europese bedrijven en instanties de Amerikaanse (cloud) bedrijven vertrouwden en dat is nu in één keer de deur uit.

En reken maar dat big consultancy/system integrator klaarstaat om grootschalige migraties uit te helpen voeren.

We zien regeringen dit soort besluiten nemen, Airbus is een paar dagen terug een 'Buy European' campagne begonnen, en er gebeurt nog veel meer. De geldkraan gaat open voor Europese (defensie) industrie en tech.

Het is een doos van Pandora en hij is zojuist geopend.

[Seal64]

Nu alleen nog zorgen dat we dat in Europa ook als Europa oppakken, en niet als "ieder voor zich" wat de norm lijkt te zijn. Dan zit je allemaal met een klein stukje van een Europees leger, maar dat moet dan ook nog wel allemaal lekker samenwerken en compatibel zijn.

Wat dit soort dingen hebben de Amerikanen het dan toch handiger opgepakt, daar doet Washington dit soort zaken voor de hele club, en niet ieder voor zich.

[GeroldM]

Had ook al gehoord van een gerucht dat de VS van een kill-switch heeft geactiveerd in de F-16's die naar Oekraine zijn verplaatst. Er was daardoor ook een gerucht dat Canada de gehele order voor F-35's heeft geannuleerd. Want als er in die oude F-16's een verborgen/ongedocumenteerde kill-switch zit, welke de VS naar eigen goeddunken in en uit kan schakelen...dan zit er zeker 1 of meerdere in de F-35.

Dus kun je zelfs met ruim 50 jaar oud VS oorlogsmaterieel, wat gewoon bij hen is aangekocht en betaald, er niet op kunt vertrouwen dat de VS dit materieel niet op afstand onbruikbaar kan maken middels een kill-switch.

Mocht dit waar blijken te zijn, dan verspeelt de VS wel heel erg veel krediet, heel erg snel. Heb dit nog nergens kunnen verifieeren, dus is het niets meer dan een gerucht. Natuurlijk hoop ik dat het niet waar is, dat mzou duidelijk moeten zijn.

Echter zie ik de VS wel als geniepig genoeg om dit wel te doen. Oftwel hoe 33% van een bevolkingsgroep 100% van dezelfde bevolkingsgroep een gigantisch oor aannaait.

[Sheean]

Al is de encryptie en beveiliging op orde, wanneer de infrastructuur, de hardware en software in handen is van een partij met slechte bedoelingen valt er meer dan genoeg narigheid uit te halen. En al zou zelfs dan het nog te vertrouwen zijn, ze kunnen ook gewoon de stekker eruit trekken.

[WokBoy]

Er is altijd een moment dat data unencrypted in het geheugen leeft. Als dat in een VM is die wordt beheerd door een cloudprovider, dan kan diezelfde cloudprovider die data lezen, kopieren en aanpassen. Dat staat los van het feit dat deze provider - of de leverancier van het OS - het besturingssysteem kan aanpassen naar eigen wens, op zo'n manier dat jij als klant dat niet zult merken. Ik denk niet dat ze Jomanda's in dienst hebben die versleutelde data kan decrypten en wegstralen, dat niet.

[emeralda]

Encryptie kan gekraakt worden. Je weet nooit wat voor supercomputers/AI de toekomst brengt.

[TD-er]

Of door overheden afgedwongen super-injunctions voor backdoors.

Het is simpelweg naief te denken "het is encrypted, dus veilig".
Encryptie is niets meer dan een laagje in de totale beveiliging.

[Microwilly]

Encryptie is niets meer dan een laagje in de totale beveiliging.

Lol?? Het hele internet staat of valt met encryptie. Belastingdienst(DigiID) Banken ( o.a. internationaal betalingsverkeer ) 4/5G netwerken, Politie ( C2000 ), Defensie.

[WhiteHatter]

draaiend op Amerikaanse software, gebruikmakend van Amerikaans/Chinees/Japanse hardware.. nee goed verhaal.

[closefuture]

Het hele cloud encryptie verhaal is al uitgebreid beschreven (en onderuit gehaald) in artikelen zoals Servers in de EU, eigen (dubbele) sleutels: helpt het?.

[108rogar]

Is dat zo? Encryptie geldt meestal alleen voor data "at rest", dus in opslag. Als er mee gewerkt wordt, staat het onversleuteld in het geheugen van de cloud aanbieder.

[Microwilly]

Voor data opslag is cloud prima mogelijk met encryptie. Maar voor diensten die Sidn aanbied is cloud gevaarlijk! Omdat je niks kan versleutelen waar AWS of andere cloud providers niet bij kunnen ^^

[jpsch]

Geldt toch ook voor Nederland met de Sleepwet?

[wiseger]

Ik weet niet waar onze inlichtingendiensten de data bewaren die ze bij elkaar harken. Ik hoop dat er een groot data center ergens in Nederland staat die door de diensten zelf beheert wordt.

Lijkt me evident dat je niet wil dat dergelijke data in het buitenland opgeslagen worden met het argument, we versleutelen alles hoor.

[Ikzellef]

Precies dat.

[jaapzb]

De servers draaien in datacentra van amazon, worst case lopen ze gewoon naar die servers toe en trekken ze de stekker er uit

[cyclone]

As if jij als klant ooit een AWS Data center binnenkomt en al zou dat lukken hoe ga je dan bepalen welke doos / dozen je uit het rack moet trekken.
Sorry maar dit getuigd van weinig kennis inzake hoe een hedendaags cloud provider zijn compute / storage bouwt.

Jouw suggestie is botweg niet mogelijk, echt niet.

Even on topic.
Mooi dat het belang van een top domain duidelijk is binnen de gehele politiek, ik ben positief verrast.
Echter nu ze er iets van vinden zullen ze ook wat budget moeten toekennen aan SIDN om ze in staat te stellen zelf een degelijk infra op te tuigen en te beheren op Nederlands / Europees grondgebied.

Maar al met al positieve wending dit.

[Reactie gewijzigd door cyclone op 19 maart 2025 11:42]

[jaapzb]

De mensen van amazon komen hun eigen datacentrum niet in? We hebben het over de worst case scenario waar trump ons zo veel mogelijk schade wil berokkenen zonder dat hij daarvoor bommen op ons land gaat gooien, dan is ergens een datacentrum binnen lopen onder order van de president denk ik geen enkel probleem.

Als je gebruik maakt van EC2 instances, die draaien gewoon op apparatuur in een datacentrum.

Als je gebruik maakt van cloud services, dan hoeft het zo moeilijk allemaal ook helemaal niet, dan ondebreek je gewoon je service naar de desbetreffende klant door op een knopje in een management UI te klikken.

Mijn punt is dat amazon eindbaas is voor whatever je daar hebt draaien, als ze je niet meer moeten dan ben je zo je infra kwijt.

[Reactie gewijzigd door jaapzb op 19 maart 2025 11:49]

[Microwilly]

100%

[Cartman!]

Vervolgens kunnen ze hun bedrijf wel sluiten omdat niemand ze meer vertrouwd, dat doen ze echt niet.

[Martin_1966]

De Amerikaanse Big Tech bedrijven kruipen op het ogenblik voor Trump. Ik zou er niet van uitgaan dat deze bedrijven onze kritische internet infrastructuur beschermen tegen de zin van de Amerikaanse overheid in.

[watercoolertje]

As if jij als klant ooit een AWS Data center binnenkomt en al zou dat lukken hoe ga je dan bepalen welke doos / dozen je uit het rack moet trekken.
Sorry maar dit getuigd van weinig kennis inzake hoe een hedendaags cloud provider zijn compute / storage bouwt.

Jouw suggestie is botweg niet mogelijk, echt niet.

Het is zeker niet onmogelijk, geen idee hoe je daar bij komt, er zal wel wat nevenschade zijn (andere sites die toevallig op dezelfde instantie draaien gaan mee onderuit).

Maar de realiteit is dus NOG makkelijker, gewoon het deel wat SIDN huurt via software uitzetten Dus eigenlijk nog veel erger dan de mogelijkheid om het fysiek uit te zetten...

[Reactie gewijzigd door watercoolertje op 19 maart 2025 12:48]

[DennusB]

Exact, zeker met zaken als encryptie is het een stuk lastiger voor de leverancier om dingen "in te zien", maar de vraag is wel of het "onmogelijk" blijft, je weet niet wat voor achterdeurtjes ze moeten inbouwen.

[Microwilly]

Hoe wil je encryptie in zetten bij AWS. Op data die beschikbaar moet zijn voor klanten achter een portal. En dus niet door AWS ingezien mogen worden.. ^^

[DennusB]

Wat dacht je van KMS encryptie? Eventueel met een eigen HSM

[Reactie gewijzigd door DennusB op 19 maart 2025 13:43]

[Basszje]

Hoe je het went of keert, data die niet bij jou staat is 'niet van jou' als puntje bij paaltje komt. Een of andere labiele leider ( ahum ) kan bijvoorbeeld (in opdacht van een 'cyrillisch-sprekende vijand' ) gewoon zeggen dat alle Europese data verwijderd dient te worden.

De patriot act is vrij duidelijk dat hoe dan ook bedrijven die in VS zaken doen van alles moeten slikken of wegwezen en dat zal geen enkel amerikaans bedrijf doen natuurlijk. Dat is dus een blijvend risico. Ook als data, of enige bedrijfsactiviteit over de grenzen plaatsvindt.

[Alex3]

Cyrillisch is geen taal maar een schrift.

[Basszje]

не питання, був жарт

[flurb]

Het ging puur om de administratie..
De DNS infra zou gewoon in NL blijven staan.

Beetje storm in glas water, gegeven dat we landelijk de overheid gaan overzetten naar office365, zoals besloten vorig jaar. (Al lijkt het dat men nu wat beter overziet hoe niet verstandig dat beleid zou zijn)

[wildhagen]

Unaniem en de Tweede Kamer? Kan me de laatste keer dat dat gebeurd is niet herinneren

Dan heb je een wel heel kort geheugen, want twee weken geleden gebeurde dat ook al: https://www.nationaalarch...we-archiefwet-unaniem-aan

Maar wel een goed resultaat lijkt me verder. Dit moet inderdaad niet naar een partij in de VS. Zeker de laatste weken hebben we kunnen zien hoe onbetrouwbaar dat land geworden is. Zeker als je bedenkt fat de eigenaar van Amazon direct achter dat beleid staat, via zijn publieke steun aan de president.

Dat levert gewoon onnodige risicos op voor onze nationale TLD en dus infra, en dat moeten we imho niet willen.

Hopelijk doet de regering/het kabinet hier ook echr iets mee, en negeren ze dit niet omdat men het er niet mee eens is oid.

[Christoxz]

Unaniem en de Tweede Kamer? Kan me de laatste keer dat dat gebeurd is niet herinneren

Denk dat je het zelf niet mee krijgt. Alleen al in dit lijstje, zijn er 5 moties unaniem aangenomen en niet allemaal hebben te maken met de ICT.
https://debatdirect.tweed...mmingen-15-16/markeringen

[Scribe]

Was ook meer humoristisch bedoeld, maar interessant om te zien dat dat vaker gebeurt dan ik dacht
Dankjewel!

[Alfa1970]

Wat was de lijst van aanwezigen?
De opkomst van mensen die echt werken in de 2e kamer laat nogal eens te wensen over als je de media mag geloven.
En als 3 kwart niet aanwezig was dan lijkt het me goed mogelijk om iets "unaniem" door een stemming heen te laten komen.

Buiten dat, goed om te horen dat men daar voor sommige dingen soms wel het gezonde verstand laat prevaleren boven alle partij politieke nonsens.

[cat_byte]

Ik kan deze motie en de uitslag van de stemming alleen maar toejuichen. Wat ik zorgelijk vind, is dat het nu pas bij onze volksvertegenwoordigers doordringt. Al jarenlang waarschuwen allerhande experts voor:
- de toegenomen afhankelijkheid van buitenlandse (buiten de EU) partijen m.b.t. cloudopslag en SaaS e.d.
- de geopolitieke spanningen
- de mate waarin de VS lak hebben aan privacy/beschermen van burgerrechten
- de mate waarin social media ook politiek beïnvloedt (door valse informatie te verspreiden, fabeltjesfuik etc)

Maar het moest allemaal 'goedkoop', dus uitbesteden enz. Voor een commerciële onderneming kan ik daar.nog in meegaan. Maar alles wat de overheid en semi-overheid aangaat,zouden we toch in eigen beheer moeten willen houden.
Is het onnozelheid, is het 4 ijaar overleven naar de volgende verkiezingen en niet vooruit durven kijken want dat levert geen stemmen op?

En nog kijken we naar een overheid die vrolijk doorgaat met whatsapp reclame (buurtpreventie), X en meta nog volop gebruikt (en daarmee dus ook goedkeurt dat burgers met hun data indirect een anti-democratische oranje man steunen).

Ik vind het zorgelijk dat het zover heeft moeten komen tot er iets gebeurt. Neemt niet weg dat ik wel gelukkig ben dat men zich eindelijk bewust wordt van de positie waarin we ons hebben laten wurmen.

[swhnld]

Het is ook een kwestie van kennis en kunde, en schuiven met zakken met geld (markt kopen).

Bijna elk alternatief uit Europa wordt op een bepaald moment opgekocht. Misschien verliezen ze geld direct op die aankoop, maar ze stellen wel hun markt op de langere termijn veilig doordat er geen alternatief meer is.

En op de scholen leren de studenten ook de oplossingen van deze Amerikaanse bedrijven, want ook daar is geen lokaal alternatief.

[cat_byte]

Zeker waar dat het tegen het kapitaal van o.a. Google en Microsoft amper valt op te boksen. Qua opleidingen zijn zij ook idd degene die allerlei gratis en nagenoeg gratis tools, certificaten etc bieden. Wil je apps maken, dan gebruik je Firebase . Goedkope security certificaten: Microsoft to the rescue. Ze hebben het slim gedaan.

Dat tweedekamerleden daar jarenlang niet de risico's van hebben gezien, begrijp ik. Het aantal vraagstukken neemt toe, de tweede kamer blijft desondanks uit evenveel.zeteld bestaan en dit is een vakgebied apart. Maar de experts hebben van zich laten horen de afgelopen jaren. Ik blijf het schokkend vinden dat nu de wind echt draait, er ineens actie moet komen. Ik verwacht niet van kiezers dat ze dit meenemen in hun stem. Maar ik verwacht toch van volksvertegenwoordigers dat ze zich laten informeren door experts en vooruitkijken (vooruitkijken = regeren toch?).

[swhnld]

Er was waarschijnlijk ooit een tijd dat de volksvertegenwoordigers vooruit keken, maar tegenwoordig, met alle snelle communicatie van het internet, is dat nog maar amper te bemerken. Ze lijken ongeveer zo ver te kijken als de volgende post op een sociaal media platform, of krantenartikel de volgende dag.
Zelfs internationale afspraken binnen de EU in 2 jaar tijd vertalen naar wetgeving en die wet aannemen lukt de volksvertegenwoordiging niet, en dat terwijl ze de inhoud kunnen kopiëren en plakken uit de verdragen.

En er zullen vast wel vertegenwoordigers zijn die het goed willen doen. Maar zelfs in tijden van crisis zie je dat politieke partijen ervoor kiezen om machtspelletjes te spelen in plaats van de schouders er onder te stoppen en de boel op te lossen. Want daar gaat het ze meer om dan het daadwerkelijke uitvoeren. Wie heeft de macht en kan zijn/haar wil opleggen aan het volk.

[Olympus user]

Ik ben het met je eens. Maar wat de reden ook is, beter laat dan nooit.
Ben benieuwd wat dit kabinet zegt, waarschijnlijk iets van : beleid.

[cat_byte]

Een commissie die gaat onderzoeken kan natuurlijk ook. Maar belangrijker is dat er een duidelijke visie komt hoe wel het dan wel willen en daar als overheid ook naar handelen. En niet voor een jaar, maar wat langere termijn, zodat je gedegen oplossingen hebt.

[Olympus user]

Ik hoop het.
Hopelijk zijn we in Europa wakker geworden en slaan we onze eigen weg in.

[CAPSLOCK2000]

Is het onnozelheid, is het 4 ijaar overleven naar de volgende verkiezingen en niet vooruit durven kijken want dat levert geen stemmen op?

En nog kijken we naar een overheid die vrolijk doorgaat met whatsapp reclame (buurtpreventie), X en meta nog volop gebruikt (en daarmee dus ook goedkeurt dat burgers met hun data indirect een anti-democratische oranje man steunen).

Allemaal, uiteindelijk is de politiek een afstemming van de bevolking. Zolang de grote meerderheid blij is zal de politiek niks doen tenzij ze een probleem voor hun eigen plannen zien. Dat is geen kwade opzet maar pragmatisme.
Zolang het grootste deel van de bevolking gebruik maakt van Whatsapp, X, Meta, MS Office, AWS, etc... zal de politiek dat niet al te hard in de weg zitten. Ze doen het zelf ook en weten niet beter. Natuurlijk hebben ze wel eens gehoord dat het niet ok is, dus technisch gezien weten ze het wel, maar net als de meesten kunnen ze het niet echt goed plaatsen.

Ik denk dat 'Klimaat & Milieu' een vergelijkbaar ondewerp is dat iets verder is. Daar hebben we ook decennia lang eigenlijk niks aan gedaan ondanks dat we al lang door hadden dat er problemen waren. Veel mooie plannen maar weinig is uitgevoerd. Nu zijn we in de volgende fase aangekomen waarin zelfs de grootste tegenstanders er niet meer om hun kunnen. Onze huidige regering heeft klimaat bepaald niet als speerpunt maar heeft toch een minister voor Klimaat, het is nog wel de Vicepremier van de VVD.

Ik vind het zorgelijk dat het zover heeft moeten komen tot er iets gebeurt. Neemt niet weg dat ik wel gelukkig ben dat men zich eindelijk bewust wordt van de positie waarin we ons hebben laten wurmen.

Bewustzijn is een goede eerste stap, nu is het aan ons om de maatschappij duidelijk te maken wat ze wél moeten doen.

[vrije_vogel]

Als stichtingsbestuur lijkt het me lastig om een unanieme uitspraak van de volksvertegenwoordiging te weerstaan. Zelfs al heeft die op zichzelf nog geen rechtskracht. De wereld is in korte tijd ingrijpend veranderd.

De beweegredenen van SIDN komen niet zo sterk over. Het gaat om een tamelijk eenvoudige registratie. 6 miljoen domeinen is veel, maar de mutatiegraad is laag. De administratie daarvan kan niet heel ingewikkeld zijn en zal bijvoorbeeld ook geen grote piekmomenten kennen. Er is speelde wat over een samenwerking met Canada. Als er een land is dat op dit moment niet genegen is om zich afhankelijk te maken van de VS is het Canada. Daar moet ook uit te komen zijn.

[familyman]

Korte tijd veranderd.... helaas zijn onze politici tegenwoordig net zo kortzichtig als hun twitter-feed.

Er waren al signalen genoeg. We hebben het over kritieke infrastructuur (het duurde al lang genoeg voordat men dat door had).

Het is al heel lang een echt groot probleem. Tussen trump en ukraine wordt dat nu zelfs de tweede kamer duidelijk. Overdrijving maakt duidelijk, leerde mijn leraar me vroeger ooit.

Er is nog een reeks problemen nauwelijk effectief geadresseerd, maar iig begint dat nu wel te komen.

[R1]

had de verkeerde motie geopend, dus idd unaniem.
Wat mij betreft heerst er een verkeerd beeld en is dit vooral een angst reactie op wat er nu allemaal in de wereld gebeurt.
De meeste overheden draaien " soeverein" op een intel based Dell server met Vmware, obv MS windows of IBM redhat software, gekoppeld aan een cisco netwerk.
Daarnaast is het Overheid datacenter in Amsterdam gehuurd van, jawel, de Amerikanen !
linkje
Als Trump wilt vraagt hij Equinix even de kabel eruit te halen van die ODC kooi.
Of je krijgt geen Cisco/Dell/Microsoft/RedHat/IBM.... (security) updates meer.

Trump zal zo snel niet iets uitzetten. Op het moment dat hij dat tot een wapen maakt, gaan Amazon, Microsoft en Google failliet. Er zal dan wereldwijd een exodus volgen uit de honderden miljarden kostende cloud DCs/regios van de hyperscalers

EU moet zorgen voor een volwassen EU cloud provider. Maar ja, vetrouw je dan wel een franse cloud of duitse cloud, want niet door een NL bedrijf gemaakt? (Denk aan aanbesteding onderzeeërs). In het verleden zijn er oorlogen gevoerd met Fransen, Spanjaarden, Duitsers.
Als je alles in NL wilt doen heb je weer het risico dat een leverancier te klein is om zoiets te ontwikkelen, of zelfs failliet gaat.
Fijn dat Katman voorstelt om het vanuit de overheid te leveren maar ze zorgt niet voor budget en mensen. De overheid moet 20% gaan besparen op IT'ers. Veel doen dat door PaaS af te nemen in een Public Cloud zodat een deel van je beheerlast wegvalt en je met minder mensen toekunt. Pak je het slim aan dan kun je het ook zelfs goedkoper hosten in een public cloud (afh. van de use-case).
SIDN heeft dit ook als reden aangegeven: minder tijd kwijt aan beheer, meer tijd voor hun kerntaak: DNS resolving . link

't brengt ons nergens en ondertussen zal het alleen maar langer duren voordat men realiseert dat je niet meer alles zelf kunt bouwen en beheren doordat de westerse wereld vergrijst en de personeels tekorten blijvend zijn en groter worden.

Dus laten we snel een door de markt bekostigd volwaardige EU cloud bouwen (niet van de belastingcenten) en tot die tijd vooral onze overheid versnellen en innoveren met cloud producten. De IT markt is voorlopig gedomineerd door de USA, en niet alleen de Public cloud diensten maar ook Hardware en Software!

[Reactie gewijzigd door R1 op 19 maart 2025 16:44]

[Il 2]

Het gaat om motie 26643-1317, daar is wel unaniem voor gestemd door iedere partij.

[wooha]

Bedankt voor de link, maar ...

Daar staan allemaal groene vinkjes bij "de motie-Kathmann c.s. over het .nl-domein weer volledig in Nederland krijgen (26643, nr. 1317)".

Allerlei andere moties zijn niet unaniem aangenomen.

[stuiterveer]

Mooi dat het wordt tegengehouden. Wel vind ik het raar om in gevallen als dit te zien dat cloud-infra (hoezeer ik het woord "cloud" ook haat) eigenlijk geen degelijke alternatieven heeft van Nederlandse/Europese makelij. Ondertussen zetten we wel weet ik veel hoeveel nieuwe datacenters op in Nederland, maar dat versterkt alleen maar de marktpositie van diezelfde Amerikaanse partijen die we in het geval van SIDN zo verafschuwen (en terecht overigens, no way dat controle over zaken als dit buiten het betreffende land moeten worden beheerd). Waar is de Tweede Kamer in dat geval wanneer er weer zo'n duit geld wordt neergelegd voor een zoveelste datacenter? Worden onze belangen in dat geval ook behartigd? "We" hebben het zelf zover laten komen dat we opeens de SIDN op de rem moeten laten trappen...

[trab_78]

Twee belangrijke kanttekeningen daarbij zijn overigens wel dat de .nl-resolvers niet worden verplaatst en dat de AWS-servers in Europa staan.

Dat de servers in Europa staan maakt in dit geval niet heel veel uit. Zelfs als het over privacy gaat is het uiterst discutabel hoeveel het nu werkelijk uitmaakt dat de data op Europese servers van een Amerikaans bedrijf staat. Maar in het geval van SIDN zijn de zorgen niet zozeer over de privacy, maar over de beschikbaarheid. In principe kan de Amerikaanse overheid "zomaar" sancties opleggen aan een partij, waarbij het voor Amerikaanse bedrijven illegaal is om nog langer diensten te verlenen aan die partij.

Dat speelt momenteel bijvoorbeeld bij het Internationaal Strafhof (ICC). De Amerikaanse regering heeft hen sancties opgelegd n.a.v. het dagvaarden van Israëlische politici. Ze lopen nu het gevaar niet meer bij hun eigen data te kunnen, die in de cloud staat. Daarvoor maakt de fysieke lokatie van de server niet uit: het Amerikaanse bedrijf dat de service aanbiedt mag mogelijk geen zaken meer met ze doen en zou hun account dus kunnen blokkeren of zelfs verwijderen. Zoiets zou bij SIDN dus ook kunnen gebeuren in theorie.