Een groot aantal gebruikers van het Azure-cloudplatform ondervond ernstige problemen als gevolg van een wereldwijde storing bij Microsoft. Sommige diensten ondervonden rond negen uur ‘s avonds nog steeds hinder.
Een verkeerde configuratie-wijziging bij de Azure Front Door-dienst veroorzaakte de problemen. Microsoft schakelde daarop terug naar een eerdere configuratie die wel goed werkte. Maar het duurde enkele uren voordat het Content Delivery Network zich grotendeels had hersteld. Clouddiensten zoals Microsoft 365 en Outlook werkten een deel van de namiddag en vroege avond gebrekkig.
Onder meer de kaartautomaten van NS en de NS-reisplanner vielen langere tijd uit. AlleStoringen.nl registreerde even voor vijf uur 1.111 meldingen van storingen. De web-ticketshop van de voetbalclub Heracles kon geen orders meer verwerken. Ook in de VS werden veel storingen gemeld. Bij Alaska Airlines vielen hele systemen uit waaronder check-in diensten. Starbucks en Costco behoorden eveneens tot de slachtoffers.
De impact van de storing was in de eerste uren vrij groot, want sommige gebruikers kregen geen toegang tot Office 365/Microsoft 365, Copilot, Minecraft en X-Box Live. Zo meldt persbureau AP. Microsoft bevestigde de problemen met Microsoft365 en Azure op zijn service-statusoverzicht. De storingen werden toegeschreven aan moeilijkheden met de naamomzetting (dns).
Gaat het een trend worden ?
Hyperscaler weer onderuit vanwege “verkeerde configratie”.
Zeg ik ook altijd als er wat misgaat met iets technisch dat ik beheer.
De klant begrijpt dan meteen dat er niet doorgevraagd dient te worden.
Dan verzin ik met iets met een ha failover quorum split brain corosync verhaal.
Dat wil niemand horen.
Wel dat ik het ga oplossen met een eerdere configuratie die wel goed werkte.
en dat ze weer rustig kunnen slapen.
Foutje bedankt en de hyperscalers en zenuwachtig worden..
Want wat nu ?
Hopen dat de klant in paniek vraagt om een cloudagnostic oplossing.
Dat betekent leuk werk en per definitie multicloud in testfase,
want hoe weet je anders dan iets overal werkt.
Na veel geld lever je dan compleet met afsluitend feestje het project af.
Mailtje wordt in bedrijf rondgestuurd met het succesverhaal.
Daarna deur dicht doen en weten dat ze toch wel bij MS blijven.
Zo agnostic is het immers allemaal niet.
Maar dat staat wel weer mooi op mijn cv.
Volgende keer vast iets met AI.
Ook leuk.
Misschien moet je je CV aanpassen, Dino. Want als je een storing die kritieke diensten raakt wegzet als een technisch probleem dan mis je de essentie. Dit is geen incident maar de kanarie in de koolmijn. Wie dat niet ziet, doet aan symptoombestrijding.
We bouwen een digitale economie op een infrastructuur die we niet zelf beheersen. Toegang is alles. En als die toegang afhankelijk is van een ‘kill switch’ buiten onze jurisdictie dan is de vraag niet of het misgaat, maar wanneer en hoe hard.
NIS2 probeert grip te krijgen op precies dit soort risico’s. Want het echte probleem zit niet bij Microsoft maar in de bestuurskamers waar besloten wordt om kritieke processen op luchtkastelen te bouwen. Dat is geen vooruitgang maar bestuurlijke nalatigheid.
Gelukkig was het een intern probleem, en geen cyberaanval, benadrukt Microsoft. Het incident op 29 oktober wordt nu algemeen afgedaan als ‘a reminder of the critical role DNS plays in modern cloud computing’. Blijkbaar is een routeringsprobleem naar een interne Microsoft DNS server in 1 Azure regio in Amerika voldoende om hier in Nederland niet meer bij je bank te kunnen inloggen. En beetje vervelend ook want net op een lastig moment, zo vlak voor einde maand en kwartaal i.v.m. verslaglegging en belastingaangiftes.
Ik vrees inderdaad dat men in de bestuurskamers hiermee niet verder komt dan zich te laten wijsmaken dat de schaalvoordelen van hyperscalers blijven opwegen tegen dit soort ‘incidenten’ en een hybride cloud oplossing samen met agentic AI wel gaat zorgen dat dit niet meer tot grote problemen zal leiden de volgende keer. Ook al werd 1 dag eerder een storing bij Amazon ‘impacted multiple AWS offerings reliant on Elastic Container Service (ECS), highlighting ongoing vulnerabilities in the cloud giant’s densely interconnected infrastructure’.
Fred, je eerste zin gaat om het downlevelen van probleem waardoor het in de bestuurskamer afgedaan wordt als een technisch probleem. Woorden als routering, DNS en Azure regio gaan oor in, oor uit omdat ze geen directe koppeling maken met bestuurlijke risico’s en verantwoordelijkheid. Daardoor wordt een systeemstoring al snel afgedaan als een IT-probleem terwijl het een symptoom is van een falende digitale governance.
Want de papieren compliance van NIS2 leidt er straks toe dat we volgens het bestuur maar taart moeten gaan eten als er geen brood meer is. Dat is een cryptische metafoor die historische context nodig heeft om te begrijpen dat er een bestuurlijke disconnectie is om de ernst van een systeemfalen te begrijpen vanuit het perspectief van de burger.
Want in plaats van de killswitch van een DNS-storing kon de reiziger geen kaartje kopen, de patiënt geen zorg aanvragen, de burger geen belasting betalen. De toon maakt tenslotte de muziek want de bestuurders trainen in digitale geletterdheid gaat niet om HOE iets werkt maar WAT het betekent als het faalt. Want zolang het werkt is niemand erin geïnteresseerd.
Misschien kan Henri een leergang ‘Digitale consequentiekunde voor bestuurders’ opzetten want de huidige NIS2 trainingen blijven binnen het kader van compliance en risicomanagement. Compliance vieren terwijl de burger geen toegang heeft tot publieke diensten gaat om mijn cryptische metafoor welke de maatschappelijke KPI in de SLA boven de juridische en financiële KPI zet.
Ik ga alleen over mijn CV 🙂
Hoe iets weggezet wordt, bepaal ik niet.
Das meer iets van computable en exposure kopen.
symptoombestrijding is verder een verdienmodel.
net zoals The Fujitsu Hybrid Cloud Starter Kit for VMware 😛
“Critical role DNS” was overigens ook al bekend.
Namelijk rond 1983 toen DNS bedacht werd.
Grip proberen te krijgen op “precies dit soort risico’s”.
Zo ken ik er nog meer. Wie houdt zich nou bezig met afhankelijkheid DNS van routering ?
Krijgen we straks een NIS2 kieswijzer mbt cloudoplossingen ?
Dat je je eisen invult en dat dan blijkt dat je eigenlijk beter zat bij een coalitie met GCP.
Terwijl Henri een gamyfied digitale consequentiekunde voor bestuurders traning opzet
kan onze huisfilosoof mooi de parallellen tussen luchtkastelen en stacked virtualization beschouwen.
Vergeet dan ook niet die tussen serverless computing and overloos hallucineren.
Helpt ook allemaal niet, maar staat wel prima op CV.
Misschien is niet de gebiedende wijs in adviezen maar dat zegt nog niks over de kwaliteit van het advies. Het laat de keus vrij om iets te doen of na te laten. Net als ‘Digitale consequentiekunde voor bestuurders’ want ik laat de keus aan Henri. Want de bestuurders van vandaag die kunnen sturen op structuur, teamcultuur en een relationele veerkracht zijn de leiders van morgen.
Dat is niet mijn idee maar een visie van Mintzberg want cursus consequentiekunde in 1983 ging om de militaire condities van ons leger. Elk nadeel heb z’n voordeel als je ondanks een gebrek aan wapens, tijd en middelen een strategisch voordeel weet te behalen. Plan B van A-team staat symbool voor improvisatievermogen wat volgens mij de essentie van veerkracht is.
Dat uitbesteding van de infrastructuur leidt tot verdwijnen van het tactisch beheer en verlies van de cruciale domeinkennis is bekend. Technische affiniteit is alleen waardevol met doelgerichtheid op de business want redundantie voorkomt uitval maar niet afhankelijkheid. En volgens mij is deze constatering van toepassing op Amazon en Microsoft.
De consequentie van een kwaliteitsaspect zoals Fit for Reliability is dat je in 7 jaar niks kunt verkopen als er geen uitbreidingen nodig zijn. Daarom is iedereen blij dat Broadcom de eerdere voorwaarden heeft gewijzigd zodat er aandacht is voor plan B met bijvoorbeeld Hybrid Cloud Starter Kit for Proxmox.
Je hebt nog een paar persberichten gemist Dino:
https://itdaily.be/nieuws/datacenter/proxmox-fujitsu-fsas-technologies/
Een prodcut jatten, onnodig verbinden met hardware en zo meteen vendor lockin inbouwen. Claimen dat een deel functionaliteit ontbreekt en daar natuurlijk vaag
over blijven.
Vendor locked Proxmox met een SLA dus..
Straks integratie met andere Fujitsu producten of partners, zodat ze functioneel ook locked zijn. Daarna alleen nog beheerders aannemen die ervaren zijn met Fsas proxmox.
Dan noem je het enterprise.
Schoolvoorbeeld van Henris leergang.
bla bla improvisatievermogen en essentie van veerkracht.
Schaamteloos 😛
Da’s jouw mening Dino, de business wil ’turnkey’ oplossingen omdat:
“…uitbesteding van de infrastructuur leidt tot verdwijnen van het tactisch beheer en verlies van de cruciale domeinkennis…”
Een stukje consequentiekunde van zelf doen of laten doen want er is geen afhankelijkheid met de hardware maar een koppelverkoop van garantievoorwaarden aangaande continuïteit. Voor niets gaat de zon op als ik kijk naar de kosten van 7 maal 24 uur ondersteuning op hardware en software. Want met redundantie koop je alleen de tijd die tussen een event en een incident zit.
“E.T. phone home” van een SLA gaat om het licht aanhouden ook al is deze uit bij de light-off datacentra. Het is dus meer een keus van technische uitbesteding van de infrastructuur of je servers zelf blijven knuffelen als ik kijk naar de problematiek waar MKB onder zucht nu Broadcom zich richt op de enterprise klanten.
Vaag ben jij Dino want eerlijk over een gemis aan functionaliteit gaat om het gebrek aan hardware integraties zoals VMware, Microsoft en Nutanix hebben. De business vraag is of die functionaliteit ook nodig is want juist het MKB ervaart deze vaak als een overkill. Als je geen geavanceerde netwerkvirtualisatie, compliance-audits of multi-site disaster recovery nodig hebt waarom er dan wel voor betalen?
VMware onder Broadcom is als een luxe cruiseschip welke je moet huren om een sloot over te steken. Proxmox daarentegen is een roeiboot met buitenboordmotor, je kunt kiezen tussen de mankracht voor voortbeweging of het gebruik van de motor.
de schaamte voorbij doorbomen over turnkey oplossingen vlak na
het pleidooi voor improvisatievermogen, zucht.
wonderlijk hoe je hardwareintegratie bij functionaliteit onderbrengt.
Maar dat bedoel ik ook met die vaagheid: het bluffen en verwarring zaaien om daarna met onbeschoft hoge rekeningen te kunnen komen en er prat op gaan dat er nog duurdere oplossingen zijn dan die van jullie.
ProxmoxVE draait op Debian dat juist bekend staat om de combinatie van stabiliteit en multiplatform compatibiliteit. Dus om het op eigen hardware te laten draaien is totaal overbodig.
De analogie tussen buitenboordmotor en roeien is ook onzinnig, omdat een motor snelheid suggereert terwijl het resultaat een unskilled ticketlogging servicedesk is met escalatie naar overbelaste outsourced engineers die je niet verstaat.
Terugkomend op het topic weinig antwoorden voor de klant betreffende hosting.
To cloud or not to cloud en waarom waarvoor nou betalen, want als die alleen maar turnkey oplossingen wil blijftie wel bij Azure 🙂
“Dus om het op eigen hardware te laten draaien is totaal overbodig.”
Cloud-evangelisme zonder context is als een minister van wonen die brochures uitdeelt over luchtkastelen aan mensen die al jaren in een wachtlijst bivakkeren.
Zet maar niet in je CV dat je verstand hebt van boekhouden Dino want de boekhoudkundige lineaire afschrijving over 5 jaar betekent niet dat een server dan ook technisch afgeschreven is. Deze twee jaar langer gebruiken is een besparing van 28% op de TCO met een stukje consequentiekunde voor de break & fix garanties. We hebben het niet alleen over vaste kosten maar ook voorspelbare kosten.
Dat is heel anders in de cloud waar je iedere maand granulair afgerekend wordt op het gebruik van: vCPU, RAM, opslag, IOPS, snapshot, request, egress en licenties met elk zijn eigen tarief en tiering. Ga gerust verder met jezelf belachelijk maken Dino want realiteit van eigen hardware in de edge is mijn dagelijkse praktijk waar OT en cloud samenkomen in een probleem met de data.
Grappige van de wet van Moore is dat de fysieke server footprint wel kleiner is geworden maar virtualisatie heeft de infrastructuur niet laten verdwijnen, hoogstens een klein beetje laten verdampen hoewel ik dat niet kan zeggen van de data welke pas verdwijnt als je de schijven poetst. Wat wel aan het verdwijnen is, is het tactisch beheer en verlies van cruciale domeinkennis.
Zeg maar het nuchtere IT advies over lifecycles en risico’s door technische veroudering wat het operationeel houden onbeschoft duur maakt. Ik zaai geen verwarring en ik bluf niet als ik twee weken later een engineer moet sturen met een kofferbak vol infrastructuur vanuit mijn testomgeving want ik kan de configuratiefouten niet voorspellen maar tot op zekere hoogte wel de slijtage.
Of de lege tank waardoor het fijn is dat je nog de riemen hebt om mee te roeien want de metafoor gaat niet alleen om de keus van de buitenboord motor. Ik stapel altijd meerdere lagen op elkaar want het gaat meestal niet om een ‘greenfield’ door boekhoudkundige afschrijvingen in de infrastructuur.