SIDN wil domeinregistratiesysteem naar AWS verplaatsen

De Stichting Internet Domeinregistratie Nederland gaat zijn infrastructuur verplaatsen naar AWS. Dat doet de organisatie onder andere vanwege de kosten. Het gaat om het domeinregistratiesysteem, maar niet om de resolver. Verschillende instanties hebben kritiek.

SIDN schrijft in een blogpost dat het een groot deel van de interne infrastructuur niet meer in eigen beheer houdt, maar uitbesteedt aan Amazon Web Services. Het gaat dan vooral om het domeinregistratieplatform Fury. SIDN werkt sinds vorig jaar samen met zijn Canadese tegenhanger CIRA aan dat eigen nieuwe systeem, dat inmiddels ook bij andere tld-beheerders wordt gebruikt. SIDN wil het platform 'nog makkelijker toegankelijk maken' door het als dienst aan te bieden. Dat gebeurt door het niet meer in eigen beheer te houden, maar het in een publieke cloudomgeving te zetten. Dat wordt AWS, schrijft SIDN. Het gaat daarbij wel om Europese servers.

Volgens SIDN is die verhuizing vooral bedoeld vanwege de kosten. Onder andere de energiekosten, de kosten van nieuwe hardware en het vinden van personeel om de infrastructuur te beheren, is erg duur. Ook zegt SIDN dat het 'organisaties onnodig kwetsbaar maakt' als slechts een klein deel van het personeel weet hoe het beheer werkt.

SIDN host zijn infrastructuur nu nog in twee datacenters. In de komende jaren wordt 'de complete ict-omgeving' omgezet naar AWS. SIDN wil dat proces begin 2026 hebben afgerond.

Opvallend is dat SIDN bewust niet kiest voor een Europese cloudprovider omdat zo'n dienst er niet is. Er bestaat 'geen volwaardig Europees alternatief' voor AWS. "Zodra dat wel opduikt, willen we over kunnen stappen", schrijft de stichting. De Dutch Cloud Community, een koepel van Nederlandse hostingproviders, zegt in een reactie verbaasd te zijn om de beslissing. "Wat ons verbaasde, als brancheorganisatie van Nederlandse hosting- en cloudproviders, is hoe dit nieuws is gepresenteerd alsof het volstrekt normaal is dat een partij als SIDN, met haar roots in de Nederlandse infrastructuur, één van haar kerntaken en systemen niet bij een Nederlandse cloudprovider zou kunnen onderbrengen, als het besluit om het niet meer intern te willen draaien."

SIDN zegt in een reactie daarop dat het die afweging wel heeft gemaakt. "We hebben, met hulp van externe deskundigen, heel zorgvuldig gekeken naar alle mogelijke alternatieven, maar zijn helaas tot het besluit gekomen dat die er nog niet zijn", schrijft de organisatie. "Alhoewel we op vele manieren proberen bij te dragen aan de strategische digitale autonomie van ons land en van Europa, heeft de permanente beschikbaarheid van .nl en de bescherming van onze gegevens hier de doorslag gegeven."

Reacties (205)

[Kek]

De posts onder dat blog artikel op linkedin zijn niet mals. Ik heb al vele grotere namen binnen de hosting/DC wereld langs zien komen (CEOs CTOs), de klanten van SIDN dus, die vel tegen zijn.

En terecht. Dit project lijkt uit de mouw te zijn geschud door de nieuwe CTO van SIDN om zijn stempel te zetten. Alleen al de symbolische F. You door naar AWS te gaan, die niet eens servers in NL heeft is niet te bevatten.

[daredevil__2000]

En terecht. Dit project lijkt uit de mouw te zijn geschud door de nieuwe CTO van SIDN om zijn stempel te zetten. Alleen al de symbolische F. You door naar AWS te gaan, die niet eens servers in NL heeft is niet te bevatten.

Het bizarre is dat SIDN zichzelf ook lijkt tegen te spreken. Ze stellen in een los berichtje:

We kunnen jullie verzekeren dat we zeker niet over 1 nacht ijs zijn gegaan om tot dit ook voor ons lastige besluit te komen om onze systemen onder te brengen bij AWS. Goed om te beseffen dat het hier alleen gaat over ons registratiesysteem en niet over onze kerndienst resolving en onze daarbij behorende DNS-infrastructuur.

Terwijl de CTO Loek Bakker ook stelt:

SIDN’s nieuwe CTO Loek Bakker legt uit wat daarvoor de reden is. “We gaan de komende 2 jaar onze complete ICT-omgeving naar Amazon Web Services (AWS) overzetten.

Los daarvan had de Vereniging van Registars al ruim voor de publicatie vragen gesteld zoals zij zelf ook nogmaals aangeven op LinkedIn

Graag plaatsen wij hier een korte reactie:

Wij kunnen de vele verbaasde en boze reacties op deze post volledig begrijpen! Sinds wij enige tijd geleden op de hoogte zijn gesteld van het besluit van SIDN om gebruik te gaan maken van AWS zijn er vele kritische vragen gesteld door de VvR, zowel vanuit de TechCom (Technische Commissie) als vanuit het bestuur.

Wij kunnen jullie verzekeren dat alle reacties onder dit artikel wel op de een of andere manier in onze vraagstelling en kritiek richting SIDN zijn meegenomen. Wij zijn nog in afwachting van een inhoudlijke reactie/uitleg/toelichting daarop. Wij zijn dus ook verrast en op zijn zachtst gezegd ‘not amused’ met deze post.

Wij hebben direct contact met SIDN opgenomen en een spoedoverleg aangevraagd. Jullie reacties laten zien dat de kritiek en vragen van de VvR ruim gedeeld worden door onze achterban en ‘internet Nederland’ in de breedste zin van het woord.
Wij zullen contact zoeken en houden met enkele andere belangengroepen aangezien dit breder gaat dan alleen de registrars.

Het Bestuur van de VvR

Ook stelt SIDN:

"Tegelijkertijd maken we ons registratiesysteem wel onafhankelijk van specifieke cloudleveranciers en gebruiken we generieke opensourcetechnologie, zodat we zodra dat verantwoord mogelijk is, relatief eenvoudig alsnog naar een Nederlands of Europese cloudleverancier kunnen verhuizen."

Als ze generieke opensource technologie gebruiken waarom zouden Nederlandse en Europese aanbieders dan niet geschikt zijn? Dit proeft toch echt als dat ze iets gaan gebruiken wat alleen door AWS geleverd kan worden waardoor er direct sprake is van een Vendor Lock-in.

Als je de reacties op LinkedIn onder het bericht van SIDN leest dan krijg je ook de indruk dat de Nederlandse aanbieder totaal niet bevraagd zijn door SIDN over de mogelijkheden. Diverse CEO's en CTO's van verschillende Nederlandse aanbieders spreken hun verbazing uit over de gang naar AWS en verzoeken SIDN ook om contact op te nemen om te kijken naar de mogelijkheden om dit binnen de Nederlandse grezen gewoon te realiseren.

Ook bijzonder dat SIDN stelt dat het alleen gaat om hun registratiesysteem. Dat is toch juist het deel waar je de gegevens in verwerkt of zie ik dat nu verkeerd?

[Boudewijn26]

Waarschijnlijk bedoelen ze met generieke opensource technologie Kubernetes. Dan is het de vraag of je een managed Kubernetes cluster van een AWS, Google of Azure afneemt of puur de VMs pakt en er zelf een Kubernetes opgooit.

Dat laatste is makkelijker gezegd dan gedaan. Zo moet je dan zelf de connectie tussen je load balancer en Kubernetes leggen. Dan leg je dus alsnog cloud provider specifieke verbindingen.

Dus je hebt de keuze: ofwel je zit vast aan je cloud provider omdat zij je hele cluster managen of je zit vast aan je cloud provider omdat je met hun load balancer bent geïntegreerd.

[Brent]

Ook zegt SIDN dat het 'organisaties onnodig kwetsbaar maakt' als slechts een klein deel van het personeel weet hoe het beheer werkt.

Iedereen die weleens bij semi-overheid heeft gewerkt herkent dit soort sentiment, waarvan de ultieme conclusie is een totale uitbesteding van kennis en je dus organisaties zoals Rijkswaterstaat overhoud waar men de expertise niet meer heeft om expertise van contractors te beoordelen. Over jezelf kwetsbaar maken gesproken. Zelfs een toko als Surf runt niet (enkel) zijn eigen data center. Enerzijds is het het afdekken van risico: als er iets foutgaat is de org in the clear, juridisch gezien. En vanuit dat oogpunt is het misschien wel een rationele beslissing. Maar anderszijds is het een totale uitverkoop, en wordt SIDN niets meer dan een paar managers die alleen nog maar dure consultants kunnen inhuren ook voor de eenvoudige vragen. Het is een prisoners dilemma denk ik, waarbij de optimale keuze voor diensten individueel misschien wel zo is, maar voor ons burgers als geheel de rekening alleen maar groter wordt.

Er zijn pogingen geweest een Rijkscorps van softdevs aan te houden, en bij bijvoorbeeld dit soort klussen in te vliegen wanneer er hulp nodig is/iets fout gaat/iets nieuws opgetuigd moet worden. Maarja, dat is ideologisch gezien niet passend binnen het huidige marktfetisjisme, plus vergt, en dat is heel moeilijk voor bestuurders, ruimte voor technici om beslissingen te nemen. Bestuurders zijn er_enorm_ aan gehecht dat zelf te doen, en vrijwillig geen mm daarvan op te willen geven.

Bert Hubert is inmiddels prof op het onderwerp, wat mij betreft straks die minister van digitalisering en bouwt aan dat corps. Heel wat overheidsdiensten (welke niet, zou je haast zeggen) die daarvan kunnen profiteren, en peperdure commerciële oplossingen kunnen afstoten.

[Reactie gewijzigd door Brent op 22 juli 2024 15:17]

[willemb2]

Bert Hubert is inmiddels prof op het onderwerp, wat mij betreft straks die minister van digitalisering en bouwt aan dat corps.

Eens! Lees b.v. zijn recente stuk Taking the Airbus to the IKEA Cloud.

[WD-41]

Bedankt voor de tip, die kende ik nog niet!

[Drharlin]

Iedereen die weleens bij semi-overheid heeft gewerkt herkent dit soort sentiment, waarvan de ultieme conclusie is een totale uitbesteding van kennis en je dus organisaties zoals Rijkswaterstaat overhoud waar men de expertise niet meer heeft om expertise van contractors te beoordelen. Over jezelf kwetsbaar maken gesproken. Zelfs een toko als Surf runt niet zijn eigen data center.

Surf is een coöperatie eigendom van de leden (de universiteiten) veel van hun spullen staat ook bij de verschillende leden. Je kunt over surf veel zeggen maar ze zijn prima in staat om de expertise van hun contractors en eventuele onderaannemers te beoordelen.

[Brent]

Een stuk beter, zeker, maar vergeleken met vergelijkbare organisaties in het buitenland: nope Maar dat horen ze natuurlijk liever niet bij Surf Misschien moet ik het toespitsen: ik heb het over de (Europese) academische HPC wereld. Daar loopt Surf helaas niet bepaald voorop. Een concreet voorbeeld is onderzoek/dev naar tooling. Surf spitst zich helemaal toe op de embarrasingly parallel workload, zoals dat lekker schaalt bij commerciele partijen (ze huren ruimte commercieel in het naastgelegen gebouw voor compute). Toen ik vroeg wat ze doen met andere workload (network heavy, en natuurlijk het interessantst: een onvoorspelbare mix), leken ze geen flauw idee te hebben waar ik het over hadden. Misschien andere afdeling, zou kunnen. In elk geval, tenders voor zaken als EuroHPC, Surf interesseert het volgens mij niet eens.

[Drharlin]

ik heb het over de (Europese) academische HPC wereld. Daar loopt Surf helaas niet bepaald voorop.

HPC was Sara en valt 'net' onder de Surf paraplu, altijd een zelfstandige toko geweest. Die zijn nog volop bezig met integreren. Vroeger beheerde Sara ook het netwerk van Surfnet.

[Reactie gewijzigd door Drharlin op 22 juli 2024 15:17]

[Brent]

Volgens mij sprak ik mensen van dataverwerking oid. Idd niet per se HPC, maar wel gebruikers wanneer nodig ivm grote workloads (begreep ik). Is dat dan een afgezonderde afdeling van wat SARA was?

[Drharlin]

Volgens mij sprak ik mensen van dataverwerking oid. Idd niet per se HPC, maar wel gebruikers wanneer nodig ivm grote workloads (begreep ik). Is dat dan een afgezonderde afdeling van wat SARA was?

Zover ik weet viel dat onder SARA, ik heb zelf meer met de netwerktak te maken.

[SgtElPotato]

Zonder meer informatie te hebben over de achtergrond kunnen wij niet bepalen of een ander platform kostentechnisch beter was of überhaupt wel haalbaar.

Daarnaast geven ze zelf aan een exit-strategie te gaan bedenken waardoor een overstap naar een platform in de EU (liefst in NL) makkelijker zou moeten worden.

En daarnaast is het gewoon mogelijk om aparte voorwaardes te krijgen zodat de data alleen in NL of in de EU gehost gaat worden zonder dat er iets naar de USA gaat. Nou weet ik niet hoe het zit of dat dan ook echt een losse entiteit is waardoor de USA bijvoorbeeld geen data kan vorderen uit de EU.

[blinchik]

Wij hebben onlangs de hele berekening gedaan, AWS zou een factor 3 a 4 duurder zijn bij ons (als we de development servers bij AWS 's nachts zouden afzetten - terwijl die bij ons blijven aanstaan. Het is een vraag of dat technisch haalbaar zou zijn, vermits er 's nachts ook soms wel bij development processen draaien).

We spreken bij ons niet over een rewrite naar cloud programming, maar een lift en shift naar VM's bij Amazon.

Maar het zal veel afhangen van het aantal storage en resources die je hebt, voor hoeveel je de resources van je eigen cluster kan "opgebruiken" en hoe het zit met toekomstige groeicapaciteit. Daar hebben wij ook rekening mee gehouden, maar dat kan natuurlijk ook een reden zijn om voor Cloud te kiezen.

Nu goed, AWS voor SIDN lijkt me nu ook wel een van de pot gerukt alternatief, iets van nationaal belang in een externe, niet Europese cloud onderbrengen (en dan maakt het me eigenlijk niets uit of dit nu Amerikaans, Chinees, Aziatisch of whatever is).

[Rolfie]

Het hangt er natuurlijk allemaal vanaf, hoe je alles berekend.

Als je gaat nadenken over bijvoorbeeld bij Azure, over Availably zones en de diensten daarmee, als je datl zelf wilt gaan bouwen, dan heb je toch echt wel goede technische specialisten nodig op netwerk, storage en hypervisors, terwijl ik het in Azure zo in elkaar geklikt hebt.

Als je storage vol zit, moet je ook vaak grote investeringen doen, als je het zelf wilt hosten. In de cloud, heb ik zo een paar T voor een maand en kan het daarna weg gooien.

[Buitenaerts]

Klopt wij hebben een software bedrijf, waar we ongeveer 8k per maand aan cloud diensten betalen kan waarschijnlijk als je alles zelf doet goedkoper. Maar daar hebben wij helemaal geen zin in, platform kosten zitten gewoon in de kosten verwerkt voor de klant wat neer komt op een paar euro per maand. Verder zijn wij op moment bezig om een migratie voor te bereiden, hiervoor hebben we ons cpu quota verhoogd naar 200 om dit binnen een paar uur klaar te hebben. Kan gewoon, zonder dat je daar zelf allerlei moeilijke dingen voor moet gaan regelen.

[Rolfie]

Klopt. Cloud heeft als groot voordeel dat het heel snel schaalbaar is, en je gemakkelijk geavanceerde oplossingen kunt bouwen, zonder zelf complete infrastructuur te onderhouden.

Wil je een test je draaien, of meer CPU/Memory een oplossing is, dan is dit zeer gemakkelijk te doen en weer terug te schalen.

Tijd is ook geld hierin.

[AmateurVinoloog]

Het is niet alleen de kosten van ijzer/energie, maar ook het beheer wat je er nog bij krijgt. Een IT specialist om het ijzer te onderhouden kost je ook gemakkelijk 5000 euro p/m (kosten =/= salaris!). Zet dat af tegen het gemak waarmee je opschaalt in een cloudplatform en ik denk dat de keuze snel gemaakt is.Er zijn genoeg scenario's te bedenken waarin het onderhouden van ijzer goedkoper is om zelf te doen, maar ik kan er net zo veel bedenken waarin de TCO helemaal niet zo slecht uitvalt voor een cloudoplossing.

Anderzijds zou ik juist voor een SIDN verwachten dat ze dit beheer nu juist wel zelf doen. Het is nota bene hun kernactiviteit.

[Reactie gewijzigd door AmateurVinoloog op 22 juli 2024 15:17]

[blinchik]

Goed dat je het aanhaalt, dit heb ik al enkele keren *zelf* gezien bij klanten. Dat is nu ook vaak een van de misredeneringen, dat je in de cloud opeens geen management meer zou moeten doen. Alle principes van selfmanagement gelden ook in de cloud.

Ijzer beheren kost eigenlijk bijna geen moeite, het gaat niet meer kapot en upgrades kosten weinig tijd. Het echte management is wat moeilijk is, maar helaas denken veel mensen dat ze in de cloud de dure IT specialist kunnen missen want je moet toch maar een beetje klikken.

En dan gaat het pas loeihard mis: niet alleen zijn de kosten niet zo transparant (want je betaalt voor 100 verschillende services en het is niet meer zo zwart wit als een vm), en sales heeft al een financiele belofte gemaakt aan de klant. De dure IT specialist die de firewall beheerde hebben we niet meer nodig (want de cloud is uberhaupt veilig en alles gebeurt vanzelf). En het hele paswoord management zit in een publiek toegankelijke S3 bucket te wachten....

[Rolfie]

Goed dat je het aanhaalt, dit heb ik al enkele keren *zelf* gezien bij klanten. Dat is nu ook vaak een van de misredeneringen, dat je in de cloud opeens geen management meer zou moeten doen. Alle principes van selfmanagement gelden ook in de cloud.

Klopt, je moet nog steeds een stukje beheer en architectuur doen. Maar heel veel hoef je niet meer te doen. Hardware, Hypervisor, storage, networking is een stuk gemakkelijk geworden in de cloud.

Wel eens een dual datacenter concept gemaakt, icm virtualisatie, storage, network appliances?

Ijzer beheren kost eigenlijk bijna geen moeite, het gaat niet meer kapot en upgrades kosten weinig tijd.

Ijzer beheren, kost ook geld. Je moet het aanschaffen, wat meestal een lastige is. Standaard pizza doos is wel te doen, maar als je nieuwe storage moet aanschaffen, van een miljoen of meer, is dit toch echt een stuk ingewikkelder als je dit wilt en moet forecasten icm je lopende projecten. 1 standaard Pizza is te doen. 64CPU dozen met 1T aan geheugen worden toch wat lastiger. Core switches, Firewalls.....
Zeker als je de infrastructuur over meerdere datacenters gaat plaatsen, is dit gewoon om dit zelf te doen, complex en heb je hiervoor veel ijzer en kennis nodig. Iets wat cloud voor een groot gedeelte oplost.
maar het is ook zeker niet de magische oplossing voor alles.

Ik heb omgevingen mee gemaakt waarbij dit soort punten heel erg lastig zijn en je ook vaak als afnemer Nee kreeg te horen, omdat een nieuw project niet zijn forecasting had gedaan voor storage.

En dan gaat het pas loeihard mis

Je noemt nu voornamelijk punten, die niet specifiek met cloud te maken hebben cloud. Het zelfde krijgt je met een verkeerd geconfigureerde webserver.
Dit zijn bij mij geen argumenten, die je nu benoemd. Je hebt altijd kundig personeel nodig, bij cloud zijn dit alleen andere disciplines die je nodig hebt. En als je die hebt, kan/werkt cloud een stuk effecter voor je organisatie. Maar het lost niet magisch al je IT problemen in eens op.....


Het echte management is wat moeilijk is, maar helaas denken veel mensen dat ze in de cloud de dure IT specialist kunnen missen want je moet toch maar een beetje klikken.

[blinchik]

Wel eens een dual datacenter concept gemaakt, icm virtualisatie, storage, network appliances?

Ja.

Dit zijn bij mij geen argumenten, die je nu benoemd. Je hebt altijd kundig personeel nodig, bij cloud zijn dit alleen andere disciplines die je nodig hebt. En als je die hebt, kan/werkt cloud een stuk effecter voor je organisatie.

Je punt was dat je die "dure it specialist" om het ijzer te kunnen onderhouden, zou kunnen uitsparen. Dat sprak ik tegen, in de cloud heb je nog steeds dezelfde zorgen en moet heb je nog steeds even veel werk, en nu is dat geen argument meer?

[morphje]

64CPU dozen met 1T aan geheugen worden toch wat lastiger. Core switches, Firewalls.....

Valt best mee. Kostte me ongeveer twee maanden het management overtuigen van het plan en daarna waren de servers geleverd in mum van tijd. De storage nodes waren wat lastiger, maar dat was post corona tijd waarin supermicro nogal wat lever issues had. Het enige nadeel is dat ik het rack niet vol kan stoppen, want die 64 cpu bakken trekken te veel stroom.

Het beheer van die machines kost ons momenteel niks meer dan cloudinstances, maar laat ik zeggen 1 mandag per maand max. Het ophangen en inrichten was gewoon een van de vele projecten die we uitvoeren en past gewoon binnen onze strategie.

[Rolfie]

Het is ook allemaal te doen, maar in cloud werkt dit allemaal net even gemakkelijk.
Wat als je 64CPU node toch nu eens 128CPU nodig heeft wegens performance issues?
Je noemt ook een mooi probleem, stroom, warmte, rackspace. Ook altijd lastige om dit goed te beheren.

En dit kan je natuurlijk ook altijd allemaal goed zelf doen, maar het zijn vaak grote, dure, lastige en lang lopende discussies en geregel.
CAPEX is altijd een lastige zeker als je over grote investeringen gaat praten en OPEX is een stuk gemakkelijker.

Alles heeft voor en nadelen....

[morphje]

Het argument was dan ook gemak versus kosten. Creditcard trekken is altijd eenvoudiger, maar niet altijd de beste oplossing. Cloud is simpelweg significant duurder dan bare metal en besparingen in personeel worden vaak niet gerealiseerd. Er zijn ook zeer zeker goede argumenten voor (gedeeltelijke) cloud oplossingen, maar alles blind in de cloud gooien is simpelweg kortzichtig, dom en duur.

Maar het argument waar ik op reageerde was dat 64 cpu dozen moeilijk te krijgen zijn en dat dat best mee valt. 128cpu dozen zijn net zo eenvoudig te verkrijgen. Ja ze zijn duur, maar dat zijn 64 vCPU instances ook. Sterker nog, die dingen kosten 15k per maand. Mijn 64 cores doosjes kostte minder dan dat en ik schrijf ze over 3 jaar af in mijn voorstellen. colo en stroom kosten een paar honderd euro extra per maand en hoe het datacenter dat doet is hun zorg.

Is CAPEX moeilijk? Ligt eraan hoe je er tegenaan kijkt. Mijn voorstel liegt er niet om, de realiteit nog minder. Ja je moet terug naar de hollandse roots en jezelf lostrekken van de amerikaanse krediet cultuur en snelle winsten. Het verschil tussen short term profit en long term gain. Maar dat is waar de amerikaanse cultuur goed in is, verslaving en afhankelijkheid creeeren.

[Rolfie]

Ik zou ook zeker flexibiliteit hier aan toevoegen, iets wat in Cloud heel eenvoudig is.
128vs64CPU's kost bij veel bedrijven een paar weken doorloop tijd op processen, zoals finanticeel approval, levering, plaating, configuratie. In cloud heb ik dit binnen 5 minuten geupgrade, of kan direct een server er naast zetten. Capaciteit forecasting is niet nodig.

En indien gewent, is het ook zo weer terug draaien. Hoef ik bij onprem niet mee te komen.

Ik had ook altijd een discussie, als hardware oud/afgeschreven was, of uitbreiding nodig was van de Storage, in beide DC's.

Snelheid is enorm verhoogt, en ik zie voornamelijk een voordeel in capex/opex, zeker bij grote investeringen.

Maar alles heeft zo zijn voordelen en nadelen.

[blinchik]

En dan heeft men ook geen zin meer om te programmeren en dan laat je alles in India doen, waarschijnlijk ook goedkoper en meer relax.

Beetje het zelfde, het klinkt allemaal mooi, maar op termijn zie je toch veel bedrijven terugkomen van die ideeen.

[Rolfie]

Je moet resources gebruiken waar ze optimaal inzetbaar zijn.

[BugBoy]

Wij bouwen hier ook op oudere hardware omdat het "goedkoper" is dan bouwen in Azure, maar er is vooral gekeken naar directe kosten en de indirecte kosten zijn niet meegenomen. Zoals:

• In de cloud kunnen we veel meer parallel bouwen, waardoor wachttijden van onze CI/CD pipeline flink naar beneden gaan.
• Geen gedoe meer met Gitlab updates (soms kritiek), die snel moeten worden geupdate.
• Geen uitval doordat er weer eens ergens een disk is volgelopen (vooral firmware builds vragen best veel diskruimte en cache).

Zelf bouwservers 1-op-1 in AWS/Azure zetten zal inderdaad duurder zijn (lift and shift). Maar je CI/CD in GitHub plaatsen -zonder dedicated build servers- kan toch echt goedkoper zijn. Vooral als je niet bij elke regel een commit/push doet met een volledige CI build. Dan draaien je build agents maar beperkt en zeer parallel (indien mogelijk) en dat is echt wel een voordeel.

Bestaande CI/CD ombouwen ben ik ook geen voorstander van, tenzij je nog heel lang moet met een systeem. Die ombouw kost ook veel tijd en geld dat vaak beter elders ingezet kan worden. Voor nieuwbouw is het wel degelijk iets om te overwegen.

[stok]

Die verhaaltjes (oa. exit strategie) zijn gewoon manager speak en afleiding, zodat argumenten weerlegt zijn. En de mensen het daarover gaan hebben ipv de kern-issue.

[SgtElPotato]

Gebaseerd op wat, je mening, je onderbuik gevoel?

Daarnaast hebben ze wel servers in de EU (EU richtlijnen kunnen gevolgd worden). Zelfs overheden gebruiken AWS / Azure voor clouddiensten, hoe erg wil je het hebben, maar daar horen we ook niemand meer over. En wie weet hebben ze zulke plannen voor het schalen en uitbrengen van hun platform dat er geen andere cloud providers zijn die dat voor 'normale' prijzen kunnen aanbieden waardoor het rendabel blijft, maar dat is giswerk.

En volgens mij kun je nog steeds aparte voorwaardes krijgen waardoor je data en alles alleen in de EU / NL gehost gaat worden, maar misschien kunnen alleen overheden dat, dat weet ik niet zeker.

[hellum]

Die conclusie is makkelijk te trekken doordat er tegenstrijdigheden in de tekst staan. Ze willen namelijk niet vast aan AWS zitten, maar wel AWS specifieke technieken gebruiken.

[RobTweaks]

Dat je een exit-strategie hebt, betekent ook niet dat je in alle gevallen zonder enige consequentie voor de dienstverlening kunt overstappen. Zo tegenstrijdig vind ik deze passage dus niet.

[Reactie gewijzigd door RobTweaks op 22 juli 2024 15:17]

[hellum]

Misschien, maar door de manier waarop AWS werkt, is die exitstrategie dus gewoon gebakken lucht

[Djerro123]

Dat is te kort door de bocht. Een registratie systeem is wat, een frontend, api laag, database? Dit klinkt als een vrij normale LoB applicatie en dat stop je in een container, zet het op EKS of Fargate en tada je hebt een exit strategie.
“Oh maar we moeten nog wel een DirectConnect hebben naar ons DC, ivm legacy. Oh, we kunnen niet overstappen naar iets anders want die hebben geen DirectConnect-variant van zichzelf richting onze DCs? Oh Well dan blijven we maar zitten. Het zou toch al zuur zijn om al onze IaC (van AWS CDK) om te gaan schrijven.”

[hellum]

Hoe is dat te kort door de bocht? Er staat nergens beschreven wat ze willen gebruiken en hoe en hoe de exitstrategie gaat werken. Uitgaand van dit hele plan ga ik er gewoon vanuit dat hier ook niet meer de vijf minuten over nagedacht is.

[Djerro123]

De “op de manier zoals AWS werkt is de exit strategie gebakken lucht” is te kort door de bocht omdat je wel degelijk gewoon degelijke applicatuur op AWS kan draaien zonder grote lockin.

Ik zeg niet dat dit hier het geval is, maar dat bij voorbaat elke exit strategie (want je weet helemaal niet waar het hier over gaat, of heb je inside kennis?) gebakken lucht is omdat hoe aws werkt, dat is gewoon niet waar.

[hellum]

Nee, ik doe gewoon aan logisch redeneren (althans, dat probeer ik). Het SIDN kiest voor AWS want dat biedt *iets* dat geen enkele Europese partij biedt. Tegelijkertijd willen ze in de exit strategie vendor lock-in vermijden. Wat blijft er dan nog over dat AWS wel biedt en een Europese partij niet?

In mijn ogen is dus, of de reden om voor AWS te kiezen onzin, of de exitstrategie onzin. Maar logischerwijs gaan ze niet samen.

Edit: mijn gedachten gaan sneller dan mijn type skills

[Reactie gewijzigd door hellum op 22 juli 2024 15:17]

[Djerro123]

Oké fair punt, dank voor het uiteenzetten.

Enige wat ik kan bedenken is dat de exitstrategie vooral technisch benaderd wordt, terwijl de “iets” wat AWS heeft ook non-technisch kan zijn (kosten, aantrekkelijkheid voor personeel, aansluiting bij kennis van personeel, gratis vlucht en verblijf naar AWS Reinvent voor de nieuwe CTO, etc).

Maar als de “iets” technisch van aard is, dan spreekt dat elkaar idd tegen.

[hellum]

Dat het twee verschillende dingen zijn zou natuurlijk kunnen. Maar kosten / personeel / kennis hadden ze toch minimaal kunnen overleggen met hostingpartijen binnen NL / EU. Uit ervaring weet ik dat in overleg veel te regelen is. Daarvoor is niet eens een poging ondernomen.

[Djerro123]

Oh ik probeer zeker niet goed te praten dat ze naar AWS gaan, genoeg competente MSPs hier in NL die dit gewoon kunnen. Echt totale waanzin dat dit erdoorheen gedrukt wordt.

[latka]

Ja, zo geredeneerd is het een non-argument: er is altijd een exit-strategie mogelijk. Trek de stekker eruit en je bent exit van AWS. Dus nee, het snijdt geen enkel hout.

[RobTweaks]

Ik heb de uitwerking van de exit-strategie niet gelezen. Jij wel? Zo zonder de verdere context durf ik niet te zeggen of deze wel of niet 'hout snijdt'. Er is nog een heel grijs gebied tussen "alles draait door niemand die iets merkt" en "de stekker eruit is ook een exit".

Op het eerste oog vind ik deze overstap een zorgelijke ontwikkeling. Maar zo zwart-wit als "de exit-strategie is gebakken lucht" en "het snijdt geen enkel hout" zou ik niet zondermeer willen/kunnen/durven zeggen.

[BiLLY_daKid]

Ervan uitgaande dat SIDN tot de kerninfrastructuur behoord, een exit-strategy moet getest kunnen worden. Het is geen theoretisch idee wat je neerkalkt.

[Argantonis]

Tja het ligt er nogal aan welke technieken dat dan zijn. Wij draaien ook op AWS, maar met een beperkt aantal AWS-technieken. Als je jezelf zwaar afhankelijk maakt van DynamoDB is het weer wat anders dan dat je emailtjes verstuurt via de SES REST interface. Er zijn nogal wat gradaties in ‘technieken van AWS’ en hoeveel moeite/tijd het kost om dat te vervangen door iets anders.

[icecreamfarmer]

In principe is dat gewoon de ervaring in 99% van de gevallen.

[multimho]

Al kost het tien keer zoveel om het zelf te doen. Dat moet het punt niet zijn. En dat is exact de discussie. Sommige dingen zijn nu eenmaal van belangrijker dan geld. Lees macht.

Het gaat erom dat als Trump gek wordt en Amazon verbiedt, we hier in NL bij sidn wel nog 10 man hebben die een server kast in kunnen richten en dan maar zelf even .nl kunnen draaien.

Het is de kern taak van sidn die kennis en kunde op pijl te houden en die dus niet uit te besteden aan een derde.

[turbojet80s]

Je kunt het an sich wel uitbesteden aan derden, maar waarom dan niet een MSP in Nederland? Hoeft zeker niet meer dan AWS te kosten en is meestal volledig gemanaged tot aan applicatie niveau en met een 24/7 sla erop.

[Siaon]

Als je een kantoor hebt in de VS, dan val je sowieso onder de patriot-act.

[SgtElPotato]

Gezien overheden ook gebruik maken van AWS / Azure moeten we daar ook maar eens streng naar gaan kijken. Lijkt me iets erger dan SIDN.

[latka]

Niet allemaal. Werkte in het verleden bij een club die diensten in de financiele sector aanbood en iets bij AWS/Azure draaien mocht daar niet. Bij EU cloud was het geen probleem. Hangt een beetje van de kracht van je security officer af schat ik zo in.

[swhnld]

Er is geen exit strategie wanneer je de kennis binnenshuis niet meer hebt.
En juist zoiets vitaal voor de Nederlandse internet infrastructuur moet die kennis juist wel in eigen huis hebben.

Misschien grijpt het ministerie nog in met een aanwijzing voor vitale infrastructuur, dan krijgen ze zwaardere regelgeving om aan te voldoen.

[tremolo]

Een "exit-strategie" is niet voldoende. AWS heeft bijvoorbeeld ook hoge egress fees (data transfer fees) op het moment dat je wil overstappen naar een andere provider. Je komt er dus niet zomaar vanaf.

De trend is juist uit de cloud vertrekken vanwege de hoge kosten, daarom verbazingwekkend besluit.

[Bigs]

Die reacties komen wel allemaal mensen die in de Nederlandse cloud/datacenter industrie werken, en ik zie weinig argumenten waarom AWS niet de juiste keuze zou zijn.

Het is natuurlijk onzin om te roepen dat "er geen alternatieven in Europe beschikbaar zijn" maar an sich is de keuze voor AWS ongetwijfeld prima te onderbouwen.

[dmantione]

Ik zal het argument geven: .nl is Nederlandse internetinfrastructuur. Nederland is een land. Landen maken wetten. Wat binnen de landsgrenzen afspeelt, valt onder Nederlandse wetten. Verplaats je iets naar een ander land, dan zit daar een andere overheid die andere wetten maakt. Je hebt dan met de wetten van een ander land te maken.

Voor cruciale infrastructuur waarbij het land tot stilstand komt als het er niet is, is alles wat zich buiten de Nederlandse landgrenzen bevindt, totaal onacceptabel. En uiteraard is buitenlands eigendom hiervoor niet zo min acceptabel. En dus is AWS de verkeerde keus.

[Reactie gewijzigd door dmantione op 22 juli 2024 15:17]

[killah]

@dmantione Dat niet alleen. Momenteel is de VS een bevriende natie. Maar wat als dat zou veranderen. Wil je eigenlijk kritieke infra op dit soort omgevingen hebben. Er zijn in de EU en NL volgens mij genoeg bedrijven die het kunnen. Alleen niet zo sexy als AWS, Azure, etc. Ik kom zelfs keuzes tegen voor deze omgevingen puur omdat ze de papieren er voor hebben. Niet omdat er onderzoek naar gedaan is wat nu echt beter is.

[DeCo]

Het is alsof Frank Lammers bij AH de boodschappen gaat halen.
Bovendien rammelt de onderbouwing van SIDN van alle kanten. Het is nog niet prima onderbouwd.

[jurroen]

Kritieke infrastructuur, het feit dat ze hun bips hebben afgeveegd met de vragen van de VvR en dat ze een Amerikaanse aanbieder kiezen zonder enige vorm van onderbouwing waarom een Nederlandse aanbieder niet volstaat en een Europese ook niet.

Dat de "cloud/datacenter industrie" zo fel reageert is omdat die sector heel goed beseft wat de gevolgen zijn.

Die reactie komt echt niet van de hypothetische mogelijkheid dat een .nl domein inkoop van 3,76 euro naar 3,85 gaat.

[svennd]

Dat lijkt me idd wat er door de PR bs echt gebeurt. 5 maand in positie, er moesten wat gebeuren.

[Reactie gewijzigd door svennd op 22 juli 2024 15:17]

[Rax-IP]

Moeten ze zorgen dat ze voor dezelfde prijs een compleet alternatief hebben.

Net weer een keer met een de grootse Nederlandse cloud providers gebenchmarked en mijn management samenvatting was vrij simpel .

Onvoldoende op vrijwel ieder echt belangrijk vlak zolang je niet fulltime eigen beheerders in dienst hebt.

En zij zijn geen klant van de sidn dat zijn de mensen die een nl domein willen hebben.

De providers zijn slechts een tussen persoon om ervoor te zorgen dat ze een dienst aan hun eigen klant aan kunnen bieden.

[Cergorach]

You door naar AWS te gaan, die niet eens servers in NL heeft is niet te bevatten.

Dat is niet helemaal waar, zo te zien heeft AWS twee locaties in Amsterdam voor Edge, wat effectief Cloudfront caching servers zijn.

Daarnaast zijn ze nu wel bezig met daadwerkelijk een 'server' locatie in Amsterdam, SOON(tm). Wellicht dat het besluit van SIDN daar wat mee te maken heeft?

[latka]

Ik schat in dat de achtergrond van de CTO (Gartner, CapGemini en Nijenrode) er meer mee te maken heeft.

[Morkatog]

Dan hebben al die mensen het bericht niet gelezen. Dit is het gevolg van een samenwerking met CIRA die ook al Ierland en Nieuw-Zeeland bedient. Dat ze (alle 4 deze partijen) een dergelijke infrastructuur (dat Fury-systeem) niet willen hosten bij een Nederlandse provider of Europese provider snap ik goed; die hebben A) niet een dergelijk goede geografische spreiding van hun availability zones als AWS en bieden een assortiment aan diensten aan dat veel kleiner is (niet dat ze alles nodig gaan hebben, maar toch..).

Misschien moeten de grotere providers van Europa zich eens achter de oren krabben en gaan nadenken over hoe ze een volwaardig alternatief kunnen worden (het antwoord daarop heb ik eigenlijk hierboven al gegeven).

Zie je het al voor je? beste ICANN, wij hebben een heel vet DRS-systeem. Willen jullie het ook gebruiken? Oh ja, de infra staat wel ALLEEN in Nederland (of een andere kleine subset van Europese landen).
Dat gaat hem natuurlijk niet worden...

[killah]

OVH is wel een provider met redelijke spreiding. Is alleen wat hardcore. Niet zo geschikt voor de klik generatie.

[Morkatog]

Dat laatste is voor SIDN denk ik niet per se een issue. OVH was ook de enige waar ik later nog aan dacht als eventuele optie, maar feit blijft dat op dit moment AWS (of de andere grote spelers uit de VS) qua opties meer te bieden heeft. Of je het daadwerkelijk allemaal nodig hebt is een tweede..

[Odie]

Off-topic: Ik vind het altijd wel grappig als mensen in hun LinkedIn profiel over zichzelf praten in de derde persoonsvorm.

[avlt]

Dat is een opstapje naar majesteitelijk meervoud

[kuurtjes]

Hierdoor komt dus alle info van de .nl domeinen via de Cloud Act in de handen van de VS?

EDIT: Patriot act moest Cloud act zijn.

[Reactie gewijzigd door kuurtjes op 22 juli 2024 15:17]

[wmkuipers]

Ik vind de meeste reacties hier wel wat overdreven, AWS heeft daarvoor een oplossing waar zelfs de Nederlandse Overheid een samenwerkingsovereenkomst mee heeft. Een Europese soevereine cloud, die niet onder die acts valt.

https://press.aboutamazon...-european-sovereign-cloud

[mavink]

Die is er dus nog niet he...

[wmkuipers]

SIDN draait ook nog niet in AWS he

[multimho]

Kunnen ze helemaal niet beloven. Lees maar eens wat over internationale souvereiniteitsregels.

Amazon is Amerikaans. Punt.

Dus heeft Amerika rechts macht en tegenwoordig belangrijker, soft power. Kijk maar eens naar economische sancties.

Dus Amazon kan papiertjes maken wat ze willen, de Amerikaanse overheid ook, als puntje bij paaltje komt, dan zijn al die papiertjes onwettig. Kijk maar naar de rechtzaken van Max Schrems.

[kuurtjes]

Sorry maar ik weet niet of ik dat zomaar moet geloven. Elk land dat AWS verbied om data door te geven gaat immers in tegen de wetgeving van de VS. Uiteindelijk moet AWS dus kiezen of ze de wetgeving van de VS volgen of die van een ander land. En als ze in beide landen blijven zonder al teveel geluid te maken ga ik er van uit dat ze de data gewoon doorgeven.

[dmantione]

Wellicht niet onder Amerikaanse wetten, al zou ik daar achterdochtig zijn als hij in Amerikaanse eigendom is, maar als het in Duitsland gevestigd is, komt alle info van de .nl-domeinen in handen van Duitsland. Goede buur hoor, maar, dit soort infrastructuur hoor je nu eenmaal niet aan een goede buur toe te vertrouwen.

[closefuture]

De enige manier waarop Amazon een (min of meer) onafhankelijke "Amazon cloud" in Europa kan maken is als ze hun cloud software licenseren aan een partij als KPN.

Ze noemen het wel "independent" maar aan het eind van de dag valt het gewoon nog onder Amazon VS. En als de rechter in de VS iets zegt dan zal dat ook voor de "independent" Amazon cloud gelden.

[MrMarcie]

Maar het is wel goedkoper! Of dat een argument is

[david-v]

Bij een aanbesteding wel ja. Of koop jij al je producten made in Holland onafhankelijk van de prijs?

[MrMarcie]

Sommige dingen hou je in eigen hand ook al is d e prijs hoger. Want op de lange termijn zijn we nu potentieel veel duurder uit.

[david-v]

Sommige dingen hou je in eigen hand ook al is d e prijs hoger

Waarom? omdat je een voorbeeld functie hebt? dat kan, maar het is een blijft een stichting en geen overheidsorgaan voor zover ik weet. Bovendien staat de core van het systeem nog steeds in Nederland. Dit gaat om de systemen voor het registreren van een nieuw domein.

Want op de lange termijn zijn we nu potentieel veel duurder uit.

Koffiedik kijken kan ik ook. Op de lange termijn zijn we potentieel veel goedkoper uit.

Ik maak al jaren gebruik van de cloud en ik ken weinig diensten die (veel) duurder zijn geworden. Juist wel veel diensten die goedkoper zijn geworden.

[rajackar]

Het blijft me verbazen dat dit toch altijd zomaar geroepen wordt en dan ook snel een +2 krijgt.
Dit is namelijk helemaal niet hoe dit werkt.
De overheid in de VS kan helemaal niet zomaar data inzien vanuit de patriot act.
Het zou fijn zijn als deze fabel een keer zou verdwijnen.

Ik ben er overigens niet per se voorstander van om dit te doen.
Het lijkt me goed om voor het nl domein niet afhankelijk te zijn van een buitenlandse partij.

[Reactie gewijzigd door rajackar op 22 juli 2024 15:17]

[LinuxMan]

de CIA en NSA zijn overigens niet aan deze wetgeving gebonden, die hebben vanuit de grondwet al toestemming om in andere landen te spioneren, en die kunnen Amerikaanse bedrijven dwingen om daar aan mee te werken. Zo'n dwangbevel is verder Amerikaans staatsgeheim, dus een bedrijf mag dat nooit toegeven dat ze meewerken aan spionage door NSA of CIA.

[M3m3nt0m0r1]

Probeer de Cloud Act i.p.v. de Patriot Act.

[kuurtjes]

Heb het aangepast. Dat was inderdaad wat ik bedoelde.

[CriticalHit_NL]

Ja en dan zijn ze op een gegeven moment zo afhankelijk van AWS dat ze er nog moeilijk vanaf komen, laat staan als de kosten daar doodleuk ook gaan stijgen.

Mijn inziens geen goed plan.

Amazon heeft inmiddels wel bewezen graag de markt te verzieken door laag in te stappen met de prijzen en het aantrekkelijk proberen te maken om de rest uit de markt te prijzen en failliet te laten gaan, zodra er genoeg markt penetratie is gaan de prijzen omhoog want concurrentie is toch weg.

Ook een goed artikel om te lezen:
https://ilsr.org/ilsr-comment-letter-cloud-aws/

[Frame164]

Je wordt alleen maar afhankelijk van een HCP als je gebruikt maakt van hun softwarefunctionaliteit. Als je zelf 100% van de applicaties bouwt gebruik je slechts een minimaal deel van de aangeboden services, maar kan je heel makkelijk naar een andere HCP. Of weer terug op je eigen cloud zetten. Je moet gewoon niet in de val lopen van makkelijk te gebruiken modules die door AWS en anderen worden geleverd.

[SunnieNL]

Maar als je die modules van AWS niet gaat gebruiken, hoezo is er dan geen tegenhanger in de EU beschikbaar? Er zijn in de EU genoeg managed services te vinden die met alle liefde die applicatie gaan hosten en het beheer van de servers op zich nemen.

Daarnaast ga ik er niet van uit dat AWS het beheer en development op zich gaat nemen. Het artikel geeft als reden dat het niet handig is als maar een paar mensen weten hoe het systeem werkt. Dat verander je niet door de hosting naar AWS te verhuizen. Want dan heb je nog steeds beheerders nodig die weten hoe en AWS werkt en hoe het eigen ontwikkeld systeem werkt (en hoe dat eventeel integreerd in services van AWS).

Verhuizing naar AWS maakt het overigens ook nog eens onnodig lastig voor de SIDN om straks aan de richtlijnen van de NIS2 te voldoen.

[Reactie gewijzigd door SunnieNL op 22 juli 2024 15:17]

[Mellow Jack]

Maar dan heeft AWS geen meerwaarde tov Europese spelers. Tenminste, ik kan ze niet verzinnen

[HakanX]

Ze gaan wel specifieke functies gebruiken en dat hebben ze alsvolgt geformuleerd:

En we implementeren zo min mogelijk functies die specifiek zijn voor AWS

Beginnen met enkele functies, eenmaal op de glijbaan kun je alleen nog maar naar beneden.

[Reactie gewijzigd door HakanX op 22 juli 2024 15:17]

[martijnsch]

Ik wil het helemaal niet goed praten, maar meer voor de volledigheid, in het artikel van SIDN staat een paragraaf hierover:

Hoe gaan jullie vendor lock-in voorkomen?
“De grote vraag is natuurlijk: waarom brengen jullie jullie essentiële diensten naar de publieke cloud, op een moment dat het zo belangrijk is om onze Europese digitale autonomie te waarborgen? Het antwoord op die vraag is in het kort dat er nog geen volwaardig Europees alternatief bestaat. Zodra dat wel opduikt, willen we over kunnen stappen. Daarom is een exit-strategie essentieel. Die bestaat er in grote lijnen uit dat we ‘vendor-agnostische architectuurprincipes’ gaan hanteren bij de overstap naar de cloud: we maken zoveel mogelijk gebruik van open standaarden. En we implementeren zo min mogelijk functies die specifiek zijn voor AWS. Elke stap evalueren we. We doen de belofte aan onze stakeholders om die kennis te delen, ook de dingen waarvan we achteraf denken: dat hadden we anders moeten doen. Zo stellen we stap-voor-stap een handboek samen, waarin we alle do’s en dont’s beschrijven van vendor-agnostische cloud engineering. SIDN Labs-directeur Cristian Hesselman en ik komen binnenkort met een blog, waarin we dieper ingaan op deze beslissing.”

[Mellow Jack]

Ik ben benieuwd hoe ze cloud onafhankelijk gaan implementeren en dan uitkomen op iets wat alleen AWS (of Microsoft/Google) kan. Of zal het zo'n loze belofte worden dat ze wel een managed cluster afnemen maar geen platform specifieke functies implementeren.

[TechSupreme]

Wat ik hier lees is: "Echt waar, pinky swear, 1000% zeker we gaan het zo maken dat we altijd ergens anders naartoe kunnen. We gaan geen gebruik maken van alle redenen waarom je juist voor AWS zou kiezen, we gaan het zo generiek mogelijk houden dus we hadden eigenlijk kunnen kiezen voor elke andere generieke cloud provider, maar we kiezen voor AWS want... redenen".

Heb ik het zo een beetje goed samengevat?

Het zou me eigenlijk niks verbazen dat ze de hele ontwikkeling overlaten aan de Canadezen (misschien beter ook want na al die faalprojecten van het SIDN is er nu een kans dat er wel iets werkends wordt opgeleverd) en dat die gewoon AWS gebruiken omdat ze niet beter weten.

[glennoo]

De grote vraag is natuurlijk: waarom brengen jullie jullie essentiële diensten naar de publieke cloud, op een moment dat het zo belangrijk is om onze Europese digitale autonomie te waarborgen? Het antwoord op die vraag is in het kort dat er nog geen volwaardig Europees alternatief bestaat.

En die gaat er ook nooit komen. Tegen de tijd dat zoiets is opgebouwd ben je alweer zoveel jaar verder dat het achterhaalt ten opzichte van de amerikaanse partijen en dan wordt het alsnog niet "volwaardig" gezien. Dus bij deze, het .nl TLD is uit handen gegeven en we zijn voortaan afhankelijk van de amerikanen.

[david-v]

Hoewel ik de keuze niet wil goed praten...je bent al afhankelijk van de Amerikanen, al decennia lang. Onze belastingdienst draait op mainframes van een Amerikaanse partij, hele datacenters draaien op systemen en routers van Amerikaanse partijen. We hebben het hier over het "beheer" en "onderhoud" van de datacenter die dus uitgevoerd wordt door een bedrijf geregistreerd in Amerika en waar werknemers uit heel de wereld werkzaam zijn. Volgens mij is het zelfs zo dat deze datacenters door mensen die in de EU wonen en werken beheerd worden daar waar dat van toepassing is.

Maar eerlijk is eerlijk, als we een Europees alternatief willen dan zal deze nooit komen als een partij als SIDN kiest voor AWS omdat het Europees alternatief nog niet af is....en dat gaat zo natuurlijk ook nooit gebeuren.

Wat ik wel eens zou willen weten, hebben ze een aanbesteding de deur uit gedaan en naar meerdere partijen gekeken of hebben ze deze beslissing zelf genomen? En als er een aanbesteding is geweest, wat zou dan de conclusie zijn geweest waardoor ze toch voor AWS moesten kiezen?

[Casejunkie]

En als er een aanbesteding is geweest, wat zou dan de conclusie zijn geweest waardoor ze toch voor AWS moesten kiezen?

Geld? als het aan alle gestelde eisen verder voldoet.

[david-v]

Dat zou best kunnen. Meestal zijn er wel meer verschillen maar de prijs kan bij een aanbesteding behoorlijk wat "punten" opleveren. Al hoop ik dat het niet prominent een onderdeel was van de aanbesteding. In het verleden zijn er genoeg contracten binnengehaald op prijs om vervolgens de hoofdprijs te vragen bij aanpassingen of meerwerk. Als de klant eenmaal binnen is, kan je losgaan....

[Jermak]

Hoe zijn ze anders zo groot geworden.

Ook het hoosten van `vergelijkings sites` met Amazon als goedkoopste aanbieder

[Reactie gewijzigd door Jermak op 22 juli 2024 15:17]

[M3m3nt0m0r1]

https://www.security.nl/p...omgeving+SIDN+naar+Amazon

En daar zijn de Kamervragen. Welke ik voor de verandering zeer terecht vind.

[david-v]

bedankt!

wat mij betreft is dit de crux:

Hoe reageert u op de bewering van SIDN dat zij overstapt naar een Amerikaanse cloud omdat “er nog geen volwaardig Europees alternatief bestaat?", vragen de Kamerleden hierover. Die willen tevens weten welke maatregelen Nederland neemt om zo snel mogelijk te komen tot een betrouwbaar en publiek Europees cloudsysteem.

Dat....is de vraag!

[Polderviking]

Jawel, maar het is ook wel makkelijk.
Ik denk dat SIDN ook wel even mag doorkomen met exact waarom ze vinden dat er geen gelijkwaardig Europees alternatief bestaat.
Op welke manier schieten Europese partijen (OVH ofzo) exact tekort tegenover AWS.
Want als we daar vaag over blijven blijf je ook eeuwig gissen over wat er dan zogenaamd moet komen.

[Reactie gewijzigd door Polderviking op 22 juli 2024 15:17]

[jinvanthee]

Zou de Tweede Kamer dit kunnen tegenhouden dan?

[dmantione]

Heel simpel. Initiatiefwetje met bijvoorbeeld de volgende tekst:

"Aan de Telecomwet wordt het volgende artikel toegevoegd:

Alle infrastructuur met betrekking tot het .nl-domein dient zich op het grondgebied van het Koninkrijk der Nederlanden te bevinden en in Nederlands eigendom te zijn."

...kan met een gewone meerderheid worden aangenomen.

[Vinnie.1234]

Gewoon een core systeem van ons internet onderbrengen in een ander land lijkt mij op geen enkele manier een goed idee. Ik blijf vinden dat alle core systemen gewoon in Nederland gehost moeten worden. Je weet nooit wat de toekomst ons brengt. Zijn we over 20 jaar nog wel goede vrienden met Amerika of met Duitsland?

Het is logisch in een wereld economie dat dingen overal en nergens gebeuren, maar voor de core vind ik dit absoluut niet. Dat de website van Tweakers er uit ligt door bijvoorbeeld problemen met Amerika is erg, maar zou niet het hele land door plat liggen. Dat al onze .nl domeinen niet meer werken zou ik een veel groter probleem vinden (ja ik weet dat Tweakers.net is, gaat even om het idee)

Net als voor stroom, zorg, defensie etc. Je moet op basis alles zelf kunnen zonder hulp van andere landen. Dat je boven de basis samenwerkt met andere landen is top. Dus voor stroom moeten we zelf genoeg kunnen opwekken om normaal gesproken alles te kunnen! Dat we bij pieken wat uit het buitenland importeren is een minder groot probleem. Pieken zouden als dat moet voorkomen kunnen worden.

[david-v]

Net als voor stroom, zorg, defensie etc. Je moet op basis alles zelf kunnen zonder hulp van andere landen.

Je bent tegenwoordig voor alles afhankelijk van andere landen, want Nederland heeft nou eenmaal niet alle benodigde grondstoffen. Leuk dat we zelf stroom kunnen genereren, maar dat doen we wel met windmolens en zonnepanelen die gemaakt zijn van grondstoffen die niet in Nederland te vinden zijn. Hetzelfde met de hele infrastructuur die nodig is om die stroom te verdelen. Ook daar zijn we voor van alles en nog wat afhankelijk van andere landen. We hebben ook geen fabrieken in Nederland die hele tanks, artillerie en munitie kan produceren zonder grondstoffen van andere landen.

Nu kiest een stichting om niet de resolver, maar om de registratiesystemen van .nl domeinen te verplaatsen naar een datacenter van een Amerikaans bedrijf, en de wereld is te klein, terwijl banken, de overheid, het bedrijfsleven en particulieren niet anders doen. Iedereen staat te klappen als ING eindelijk Apple Pay ondersteunt (daar hoor je niemand roepen dat dat echt niet kan, want Amerikaans)

[D13DS3L]

Dan refereer ik je graag even naar de comments in dit artikel:
nieuws: ING Nederland: Google Pay is vanaf eind februari beschikbaar
Waar er wel degelijk erg veel commentaar is dat ing overstapt op Google Pay, in plaats van de app die ze al hebben. Over hoe het kut is dat ING onze data nu aanbesteed (waarschijnlijk alleen maar om te profiteren van korte termijn monopoly discounts)

De reden dat dit nooit voor Apple Pay is gebeurt is omdat apple nooit de nfc chip heeft opengesteld voor app-ontwikkelaars. Nu is dit vorige week eindelijk gedaan:
https://www.macrumors.com...-nfc-third-party-apps-eu/
En staan we inderdaad allemaal te klappen dat dit monopoly ook weer gebroken is.

Het gaat hier niet persé dat we afhankelijk zijn van andere landen, maar dat we afhankelijk zijn van labiele techbedrijven die het niet zo nauw nemen met onze privacy. Hun meer macht geven zorgt er alleen maar voor dat we nog afhankelijker worden.

[david-v]

Het gaat hier niet persé dat we afhankelijk zijn van andere landen, maar dat we afhankelijk zijn van labiele techbedrijven die het niet zo nauw nemen met onze privacy. Hun meer macht geven zorgt er alleen maar voor dat we nog afhankelijker worden.

Ik ben het met je eens hoor, voornamelijk om de producten die deze grote big techs als zoekmachines, social media, advertenties, chatapps enzovoort de wereld in slingeren.

Maar we hebben het hier letterlijk over datacenters waar het niet draait om advertenties, social media en het vergaren van data van klanten. De Azure, AWS en Google clouds van deze wereld staan in een totaal andere "zuil" of hoe je het ook noemt. Met het gebruik van Azure, AWS of Google cloud is het niet zo dat alle (meta)data van je klanten door deze bedrijven wordt verzameld ten einde geld te verdienen.

De enige vraag die wel speelt is of je deze mega bedrijven nog groter en machtiger wil laten worden omdat ze ook in de infrastructurele kant van het internet een flinke vinger in de pap hebben. En ja, daar ben ik wel gevoelig voor.

Persoonlijk denk ik dat al deze bedrijven uiteindelijk gesplitst zouden moeten worden. Puur om te voorkomen dat een bedrijf 50 of 100 miljard kan neerleggen om een ander mega bedrijf over te nemen en zo de markt volledig gaat domineren.

[D13DS3L]

Ik denk dat dan ook hier vooral de crux van het verhaal en de kritiek ligt. Het is namelijk niet dat AWS je data zou uitlezen (denk ik dan) maar ze zijn er wel verantwoordelijk voor. Een investering in AWS blijft inderdaad gewoon een investering in amazon en hun praktijken...

Persoonlijk denk ik dat al deze bedrijven uiteindelijk gesplitst zouden moeten worden. Puur om te voorkomen dat een bedrijf 50 of 100 miljard kan neerleggen om een ander mega bedrijf over te nemen en zo de markt volledig gaat domineren.

[rolf-smit]

Ja laten we met z'n alle de big tech nog meer gaan sponsoren. Iedereen naar Microsoft, Apple, Amazon of Google.

We moeten dit echt een halt toe roepen, zoveel verantwoordelijkheid bij dit soort bedrijven is echt absurd. We zijn te afhankelijk van dit soort reuzen.


En nu denk je misschien maar welk Europese alternatief is er dan? Ja, dat is precies het probleem als je het mij vraagt. Niemand krijgt door dit soort grootmachten nog iets van de grond en elk bedrijf kiest dan maar voor de big tech, dat is een cirkel waar we uit moeten.

[Reactie gewijzigd door rolf-smit op 22 juli 2024 15:17]

[Snow_King]

Precies. Laat SIDN nou hier ook zijn morele verplichtingen na moeten laten komen en dus NIET voor AWS te moeten kiezen.

Dit kan prima in NL draaien. Euro's investeren in onze kennis en kunde.

[My-life]

We hebben in de EU geen big tech omdat hier voornamelijk op economische groei wordt aangestuurd. Overheden, politie, enz. gebruiken Meta voor communicatie. In andere werelddelen zou dit ondenkbaar zijn.
Tijdens de pandemie beseften we ons dat volledig afhankelijk zijn een groot risico is, maar dat besef is inmiddels weer weggezakt. Tot dat de volgende crisis zich weer aandient.

[HooksForFeet]

Waar sturen ze in bijvoorbeeld de VS dan precies op aan, dat die industrieën daar wel hebben kunnen ontstaan?

[Anoniem: 454358]

risicokapitaal.
Als je daar een leuk idee hebt, kan het makkelijker zijn om bijvoorbeeld direct een miljoen of wat te krijgen bij durfkapitalisten.
In europa krijg je meestal bij wijze van spreken nog een 500 euro krediet,

[CrazyBernie]

Buiten het risico kapitaal is er ook nog steeds geen echte Europese markt voor digitale bedrijven.

Bijv de belasting wetgeving is compleet verschillend
Betaal systemen zijn per land anders
Taal barrière
Privacy wetgeving
Contract recht
Dan heb je ook nog met overheden te maken die erg nationalistisch zijn. (KPN mag bijvoorbeeld niet fuseren met een ander telecom bedrijf)

In de VS is dat echt anders .

[Anoniem: 454358]

Als dat waar zou zijn, dan zouden bedrijven als meta en aws in europa ook niks kunnen, en dat kunnen ze dus wel.

[CrazyBernie]

Maar meta aws en anderen zijn dus eerst super snel groot geworden in de eenvormige Amerikaanse markt en kunnen zich dan prima veroorloven om alle problem in kleinere gebieden te overwinnen.

Maar een Nederlandse speler moet dus zodra ie echt volume wilt bereiken meteen die complexiteit oplossen.

[Bor]

Overheden, politie, enz. gebruiken Meta voor communicatie.

Heb je hier voorbeelden van of bedoel je op bv het bereiken van Burgers etc waar Meta niet het officiële communicatiekanaal is maar vaak een van de meerdere?

[Raymond Deen]

Over het algemeen worden er veel zaken op X en op Facebook geplaatst door overheden in plaats van op hun eigen websites.
Dat komt natuurlijk door het véél grotere bereik van een boodschap die op zo'n platform geplaatst wordt tegenover een eigen website, maar is natuurlijk wel tekenend voor het landscahp aan Europese varianten van dit soort diensten (net als voor AWS overigens).

[Artz]

Sociale media hebben inderdaad veel bereik maar nog altjd dubbelt de informatie vanuit bv ministeries met de informatie op de website. Er zijn namelijk allerlei toegankelijkheidseisen waar de overheid aan moet voldoen die alleen op de eigen kanalen mogelijk is.

[Anoniem: 623295]

De (Belgische) overheid deelt geen smartphones uit aan politieagenten, inspecteurs, etc. dus die zitten bijna allemaal samen in groepen op WhatsApp en Messenger op hun privé toestel werkgerelateerde zaken met elkaar te delen.

[Reactie gewijzigd door Anoniem: 623295 op 22 juli 2024 15:17]

[bendeleider]

De laatste aflevering van De Technoloog gaat dieper op dit probleem in

[thePiett]

Wat zou er voor die applicaties zo veeleisend zijn dit niet kan worden ondergebracht bij een Nederlandse managed hostig provider?

[Haribo112]

Exact. TransIP bijvoorbeeld biedt gewoon OpenStack en Kubernetes platformen aan waar je prima een serieuze infra op kan hosten

[sdk1985]

Het lijkt erop dat SIDN een verdienmodel ziet in de vorm van het leveren van een platform voor TLD registratie aan alle TLD's die je kunt bedenken. Persoonlijk vind ik dit een vreemde en vooral onnodige stap. Het betreft hier een stichting in het leven geroepen om .nl aan de praat te houden. Voor die kerntaak komt er meer dan voldoende geld binnen. Een kerntaak die ze al jaren prima af gaat.

Ik krijg hier een beetje het Sanguin gevoel bij. Bloed in Nederland is veel duurder dan bijvoorbeeld in België. Dat is heel raar want Sanquin krijgt per jaar 304 miljoen binnen en geven vervolgens 108 miljoen uit aan personeel en 28 miljoen aan inkoop kosten. Netto blijft er 90 miljoen over en er zijn ook nog 48 miljoen aan 'overige lasten'. Sanquin gebruikt hun monopolie positie om onderzoek te doen naar onderzoek dat ze zelf belangrijk vinden. Zouden ze daar mee stoppen dan kan de prijs van bloed letterlijk halveren.

SIDN lijkt ook deze kant op te gaan, commercialiseren om zo geld uit te geven aan taken die ze zelf belangrijk vinden.

[CrazyBernie]

Volgens mij commercialiseren ze niet maar bieden ze deze dienst aan anderen zodat er schaal grote ontstaat en lagere kosten.