Verschillende websites en online diensten getroffen door Google Cloud-storing

Sinds dinsdagavond hebben veel websites en verschillende online diensten last van een storing bij Google Cloud. Onder andere Spotify, Discord en Marktplaats ondervinden problemen als gevolg van de storing.

Op allestoringen.nl komen sinds ongeveer 18.30 uur meldingen binnen van problemen met verschillende diensten en sites. Het probleem lijkt te liggen bij Google. Op de statuspagina van Google Cloud is te lezen dat er een storing is, waardoor websites een 404-melding geven.

Naast diensten als Spotify en Discord zijn ook sites als Martkplaats.nl niet of slecht bereikbaar. Verder melden spelers van Rocket League, Pokémon Go en Apex Legends problemen met de servers van de games.

Google meldt dat er wordt gezocht naar een oplossing.

Reacties (71)

Gevoelsmatig is 'het internet' (wat dat ook precies moge zijn) de laatste tijd wel vaak 'kapot'. Heb de afgelopen maand vaak meerdere storingen per dag in belangrijke diensten meegemaakt. Dat vind ik zorgelijk. Het internet is te afhankelijk geworden van enkele grote spelers, lijkt me.

Klopt helemaal. Ik krijg het gevoel dat bedrijven en mensen een storing van een grote speler wel accepteren en van een kleine niet.

nee dat zie je verkeerd. kleine partijen vallen niet op als er storing is, grote wel omdat dat invloed heeft op heel veel mensen en diensten dan.

Wat hij bedoelt denk ik is dat je als klant van een kleinere partij veel sneller hoog in de boom kan vliegen. Storingen bij een kleinere partij vallen ook op bij klanten, al komt niet alles in de media.

Alles is afgedekt met SLA's, voor grote en kleine klanten. Als de beloofde uptime niet geleverd kan worden dan gaat dat de providers geld kosten. Dus reken er maar op dat het ook voor hun loont om de diensten in de lucht te houden. Geld is immers hun grootste drijfveer.

Alles is zo afgedekt met SLA's dat je doorgaans al blij mag zijn dat je niet hoeft te betalen voor de duur van de storing, en dan vaak nog met de voorwaarde dat de storing lang heeft geduurd. Een nachtje downtime levert echt niets op.

Een SLA op "gratis" diensten is moeilijk te enforcen. Eerder imagoschade en indirecte financiele schade..

Mijn punt is niet dat het geld oplevert voor de klant, maar dat het de provider geld kost door gederfde inkomsten.

Heb ik inderdaad ook al meerdere meegemaakt op enkele werkplaatsen waar ik kom.

Atlassian Jira on-premise, mislukte upgrade, we hadden ongeveer een half uurtje downtime. Gezeur en vergadering, want verloren tijd, hoe kon dit gebeuren, etc. Migratie naar de cloud, enkele dagen later meer dan een halve dag downtime. Ahja, maar dat draait niet bij ons, dan kunnen we uiteraard alleen maar wachten. Geen verder gezeur. Zelfde met Exchange en Office 365 voorgehad, en met nog een paar andere productjes.

Dan denk je toch echt... Uh?!

Gelukkig ben ik niet de enige.

Zo heb ik dagen moeten debuggen omdat AWS elke dag tussen 09:30 en 10:00 packet loss had op VPN tunnels. De andere partij die in AWS kon niks zien en had het ook hoog in z'n bol, AWS heeft zulke problemen nooit terwijl het tweede DC altijd prima werkte met de zelfde setup

Op zich niet erg dat grote speler de infrastructuur van het internet of onze digitale wereld verzorgen. Maar we moeten waken dat de partijen die dat doen, intenties hebben die niet haaks op die van ons als consumenten staan.

Nu valt dit hier denk ik wel redelijk mee, maar denk aan een Facebook/Meta, die social media (Facebook/Instagram) en Whatsapp bezitten, maar alles van ons wil weten. Een Google die via Stadia invloed op het gamelandschap gaat uitoefenen, wat zonder Google al onder vuur ligt door lootboxes/pay2win constructies, releases van een niet af product, en niet nakomen van beloftes.

Maar ook een Google die verzuimt Android een fatsoenlijk updatebeleid te geven (Jolla lukt het ook met Sailfish), maar wel ondertussen een Google Play Services voorschotelt en een Apple die probeert een monopoliepositie te creëren wat reparaties betreft.

Je ziet dat die partijen steeds vaker negatief in het nieuws komen en de gebruikerservaring negatief beïnvloeden. De afgelopen jaren is er in de politiek weinig gebeurt om dat (structureel) aan te pakken. Privacy blijft een ding, overheid is daar gebaat bij vanwege de veiligheidsdiensten die minder moeite hoeven doen. Andere misstanden worden maar mondjesmaat aangepakt, zoals bijvoorbeeld belastingontwijking [small](ja, dat is legaal, maar niet eerlijk)]/small].

Ik denk dat we zelf veel kritischer moeten zijn met de partijen waar we producten/diensten van willen gebruiken.

Het is een klassieke inschattingsfout denk ik. We maken een inschatting op basis van wat we zien (gratis systeem, makkelijke interface, 'iedereen' gebruikt het) en niet op basis van potentiële risico's (word ik niet te afhankelijk van één partij, wat zijn de belangen van deze partij). Met andere woorden; we denken te weinig in het grotere plaatje. Helaas voor ons westerlingen doet onze regering dat óók te weinig. Die denken enkel aan de komende 4 jaar. Wat dat betreft gaat het wellicht beter in totalitaire staten (denk aan the great wall in China) met hun controle op 'het internet', waarbij ik overigens niet zeg dat ik hun systeem nu iets vind om direct na te streven Maar dat ze meer controle kunnen uitoefenen is in ieder geval niet altijd slecht.

Let maar op binnenkort valt al het internet uit overal en zitten we terug in de middeleeuwen.

Yep, solarflare, gashik, eoa ongeziene bug in eoa element, een e-bomb, spontane lanceringen van whatever, noord korea, het kan allemaal. Vraag is wat de kans daarop is, hoeveel zorgen je nuttig daarom kunt maken (of overlaten aan de experts) en wat de afterlife is. Als ooit een kernbom wordt gebruikt ga ik in ieder geval midden in de zon staan....
Carpe diem
Hodeo mihi, cras tibi

Hahahaha

Developer hier, dit is nou het resultaat van "maar de cloud is de toekomst".. Ikzelf werk met regelmaat in de cloud. Het werkt super nice en het maakt mijn leven een heel stuk makkelijker. Maar toch diep van binnen houdt ik er niet zo van om de draadjes uit handen te geven. Door je product bij google cloud of diensten zoals AWS neer te planten loop je inderdaad het risico dat je afhankelijk wordt van je code provider / host.

Ik ben bedrijven tegen gekomen welke niet eens konden werken aan hun code omdat een van de vele services binnen google cloud niet beschikbaar was. Dit resulteerde in een niet werkende test omgeving..

Naar mijn mening is de cloud geen oplossing voor alle problemen. Het is zeker nice maar in de tussentijd heb je alleen maar "ghost" dependencies welke aanwezig moeten zijn in de cloud om je volledige applicatie te laten draaien. Zelf een Redis servertje opzetten omdat je applicatie dat nodig heeft? Sure! Of al die moeite besparen en met een click op de knop een server aanslingeren binnen google cloud? Voor een product owner is de keuze snel gemaakt denk ik. Een knopje aanklikken is goedkoper dan zelf je devs werk uren te verbruiken.

Dit is een groeiend probleem en zal wel veel erger worden. De meeste apps welke geschreven zijn met Chromium in het achterhoofd werken vrijwel zeker volledig in de cloud. En het lijkt er op dat dit de standaard gaat worden. Alles wordt tegenwoordig een applicatie wat een webbrowser voor zichzelf host. Zie bijvoorbeeld BlazorHybrid apps gebasseerd op webassembly. In .NET 6 wordt dit allemaal "standardized".

Volgens mij zat het probleem in Networking waardoor o.a alle Google Loadbalancers een 404 gaven. Achterliggende diensten leek niets mis mee te zijn.

Er zijn te veel websites en diensten die afhankelijk zijn vaan een handvol cloudleveranciers. Gevolgen zijn steeds vaker voelbaar.

alles voor het grote geld.

Welnee, stabiliteit en beveiliging zouden voor mij belangrijkere redenen zijn om naar de cloud te migreren. Geld niet. Ga maar ff over naar Azure AD en Office 365, met alles wat daarbij hoort, voor een onderneming met 400-500 man. Dan is on premise echt goedkoper.

Denk het niet als je de TCO berekent.
Voor 500man spreken we toch rap over 4 of meer (afhankelijk van je DAG) Exchange Servers.
Dan de Exchange User cals, de Office licenties met SA (als je zou vergelijken met 365 Bus. Standard of 365 E3 natuurlijk).
De hardware waarop op dat moet draaien, met shared storage en redundant uitgevoerde componenten.
Dan de support contracten op de hardware, mission critical 4hrs response of 4hrs call to repair.
De hypervisors, de back-up infrastructuur, de storage voor de back-ups.
Er komt heel wat bij kijken.

Dat klopt precies wat je zegt, op papier. Alleen wordt er in de praktijk vaak met oudere hardware en/of software gewerkt, wordt er beknibbelt op service contracts, backup frequenties afgeschaald en wordt er niet (voldoende) in de infra geïnvesteerd. En als je je IT op zo'n manier aanfietst dan is die RCO opeens een stuk lager. En ik zie dat wel op veel plekken gebeuren. Maar ik beredeneer het misschien wel te veel vanuit mijn eigen ervaringen.

Wij gebruiken steeds nieuwe servers met support contracten van 5 jaar, nieuw materiaal een van de grote voordelen vind ik net de mooie backup retentie die we er naast kunnen zetten (archivering draait wel in de cloud).

4h call to repair vind ik idioot, het is peperduur, je koopt gewoon beter iets meer hardware zodat je mooi redundant bent en neemt next day support.

Een dochterbedrijf van ons heeft nu een deeltje naar Amazon verhuisd. Ik zie dat ze al meer dan 3x zo duur zitten nu. Geen schatting, gewoon cijfers uit de boekhouding.

Waarom denk je dat beveiliging opeens zoveel beter is in de cloud?

- Patches worden automatisch ook gewoon on-premise uitgevoerd, daar is eigenlijk geen echt verschil.
- Velen denken dat in de cloud alles automatisch gebeurt, maar je security instellingen, 2fa, geoblocking etc, moet je zowel on-premise als in de cloud uitvoeren (en meestal komt een breach door slechte security instellingen), dus daar is ook al geen echt verschil
- Beetje flauw, maar je attack vector in de cloud is waarschijnlijk veel groter (iedereen gebruikt Office365) terwijl je als klein bedrijf al specifiek gericht zou moeten aangevallen of gescand worden op een bepaald IP.
- On-premise ben je veel minder afhankelijk van internet & ddos aanvallen dan wanneer je in de cloud zou werken

Uiteraard zijn er ook voordelen, HA zal wel wat beter geregeld zijn (niet on site, maar mirroring naar meerdere locaties). Maar zomaar beveiliging als "beter" beschouwen in de cloud is wel wat kort door de bocht.

Patches worden automatisch ook gewoon on-premise uitgevoerd,

Dat is een grapje zeker? Windows updates worden op servers meestal niet automatisch uitgevoerd. En voor Exchange moet je sowieso manueel de laatste CU installeren, anders krijg je geeneens de recente updates.

Vorige week nog bij een nieuwe klant een Exchange server moeten virusvrij maken en updaten naar recente CU en patch level.

[Reactie gewijzigd door GoBieN-Be op 17 november 2021 19:53]

Ik geef toe dat ik 99% met Linux op servers (of eerder vm's) werk en daar worden *security patches* wel automatisch uitgerold.

Maar met Windows zie ik toch ook steeds automatisch security patches verschijnen. Exchange ken ik niet echt. Ik ben zeker geen Microsoft-fan, maar kan me echt niet indenken dat er geen automatisch patch management voor Exchange bestaat. Heb even een security patch voor Exchange opgezocht en:

This update is available through Windows Update. When you turn on automatic updating, this update will be downloaded and installed automatically. For more information about how to turn on automatic updating, see Windows Update: FAQ.

Bron

In de bron die je linkt staat iets meer naar onder op welke Exchange en CU versie de updates van toepassing zijn. Overigens hebben ze die specifieke update nog redelijk breed vrijgegeven. Recente security updates zijn strikter met de vereiste versies.

Duidelijker in een recente blogpost.

These updates are available for the following specific builds of Exchange Server:
Exchange Server 2013 CU23 (Exchange 2013 customers might also need to /prepareschema. Please see this post.)
Exchange Server 2016 CU21 and CU22
Exchange Server 2019 CU10 and CU11

En die CU's moet je manueel installeren, en jammer genoeg duurt dat zo'n 90min.

Overigens moet je op de meeste Linux distro's ook nog steeds een reboot uitvoeren als je een nieuwe kernel installeert. Ik vermoed dat bij Linux productie servers dit ook niet zomaar willekeurig gebeurd.

Er zijn perfect scenario's waar je op Windows server de Windows updates automatisch laat uitvoeren, maar meestal zijn dat geen kritieke systemen zoals databaseservers, domaincontrollers of Exchange servers. Maar grotere bedrijven zullen de updates misschien eerst in hun testomgeving willen uitrollen.

[Reactie gewijzigd door GoBieN-Be op 18 november 2021 19:48]

Interessant. Toch vind ik het vreemd dat Windows, wat toch als enterprise wordt beschouwd, op sommige zaken want mij betreft toch wat achterloopt.

Onder Linux kan je exact schedulen wanneer er services mogen herstart worden. En je kan ook perfect instellen dat services enkel automatisch mogen geïnstalleerd worden voor security updates, en niet voor "gewone" updates. Als je echt kritische servers hebt met een load balancer ervoor, kan je zelfs je servers sequentieel laten patchen en eerst met een hook controleren of de service wel goed draait voor je de volgende automatisch laat patchen :-) Ooit mee gespeeld, maar voor ons wat overkill, 's nachts mogen services bij ons wel een minuutje down gaan.

Een echte volledige reboot hoef je echt niet zo vaak te doen onder Linux. Dat moet enkel voor de kernel en voor kritische servers kan je Livepatch gebruiken, zodat je kernel patches zelfs online kan uitvoeren, je de laatste kernel online hebt draaien zonder dat je moet rebooten.

Ik begrijp inderdaad ook niet waarom bij Windows alles zo tergend lang moet duren, een update van een pakket dat 90 minuten duurt bij Linux heb ik nog nooit gezien (tenzij een volledige distro update, maar dat moet uiteraard wel manueel). Een pakket installeren is een kwestie van alles uitpakken, en in het slechtste geval duurt een restart van een service enkele minuten (bv. database met 128gb ram bij ons).

Maar die cloud leveranciers leren van iedere outage waardoor het uiteindelijk steeds betrouwbaarder wordt. Het totaal aantal storingen als we veel kleine spelers hebben zal veel groter zijn maar minder zichtbaar. En rol applicaties als Spotify maar eens uit via een verzameling kleine providers.

Maakt het iets uit?

Stel dat elke provider elk jaar 1 dag downtime heeft dan maakt het toch niets uit of diensten zijn ondergebracht bij 1 grote cloudprovider of bij 10 kleinere providers? In alle gevallen heb je een dag downtime.

Je zou juist verwachten dat een grote cloud provider meer middelen heeft om te investeren in kennis om dit soort dingen te voorkomen, en dat grote providers hierdoor betrouwbaarder zijn.

Deden de games van Niantec het daarom zo slecht 🙈

Yep, Niantic draait volledig op GCP. Destijds gigantische hulp gehad van Google met het efficiënt schalen van Pokemon Go.

Niet gek natuurlijk, Niantic is ontstaan als een startup binnen Google. Het is in 2015 los gekoppeld van Google en een eigen entiteit geworden.

Merkte het net ook toen ik een paar changes van onze API pushte naar Github. Auto distribution naar onze Staging instance op Google cloud werkte ook niet meer en de API was op staging ook niet te bereiken. Maar onze production instance had nergens problemen mee en die werkte wel gewoon.

Lijkt gewoon een selectief probleem te zijn die sommige instances en services betreft. Gelukkig niet heel Google cloud platform zelf.

Lijkt iets met de Google Load Balancers geweest te zijn (wat de incident page eigenlijk ook al zegt). Alles wat bij onze klanten achter GCP Cloud Load Balancing hangt werkte niet tussen 18:45-19:07.
Duurde helaas wel tot 19:10 voordat er een probleem vermeld werd op de status page. In 1e instantie ga je dan toch zoeken of je het zelf nog kan fixen. Maar 2 grote webshops down op vrijwel hetzelfde moment kon geen toeval zijn:)

[Reactie gewijzigd door sverzijl op 16 november 2021 20:02]

Ja ik heb dus ook 2 x mn push revert omdat ik dacht dat ik het kapot gemaakt had haha. Was ook helemaal in paniek dat ik het weer kapot had gemaakt

[Reactie gewijzigd door Snowfall op 16 november 2021 20:21]

Dit is zo herkenbaar
En niet alleen door google, maar ook andere api's haperen vaak als je wat belangrijkst pusht.
Laatst alles op staging getest, werkte perfect. Toen naar production servers en daar allemaal errors. Bleek het ook weer aan een externe api te liggen. Zweet staat je dan overal! Maar dan toch een opluchting dat je er zelf niks aan kon doen.

Oh lol, dat verklaard waarom spotify niet ging Achja 5*9's zeker ?

Het lijkt nu weer te werken. Veel luisterplezier!

Ik dacht dat ik het probleem had veroorzaakt, had net gezocht op "master boot record" namelijk.

ANSI.SYS is een fijne track

Tja dan moeten je maar niet in Google Cloud zitten het is immers een redelijk kleine speler op de cloud markt. Op prijs zijn ze lager maar qua functies en stabiliteit lopen ze toch achter.

AWS of Azure zijn verder en beter ontwikkeld maar wel iets duurder.

[Reactie gewijzigd door HKLM_ op 16 november 2021 19:47]

GCP loopt naar mijn bescheiden mening mijlenver voor op Azure en AWS qua functies. Qua stabiliteit vergelijkbaar. Uit eigen ervaring kan ik vertellen dat heel veel GCP wel werkt tijdens deze storing.

GCP voor op azure, oké. Maar op aws? 😂😂

Uh ja. GCP heeft een samenhangende console, volwassen functies, een duidelijke visie op tools in plaats van een allegaartje, prima community., goede developer tools, duidelijke API's. Goede out-of-the-box networking defaults.

AWS is een rommelzootje van willekeurige tools, wisselende user interfaces, te pas en te onpas wordt er een "nieuwe UI" van een deel naar je toegegooid.

GCP Cloud Functions staat met nek en schouders boven lambda's uit. Met name configuratie in AWS is een ramp terwijl dat bij GCP Functions out of the box prima werkt. Maar ook deployen gaat erg traag, monitoring en monitoring van lambda's is een ramp.

Redshift is op zich een leuke database maar vergt veel configuratie en eigen beheer. BigQuery werkt voor elke situatie die ik tegen gekomen ben snel beaalbaar. De Web UI van Redshift is al helemaal een ramp, BigQuery heeft een top-editor die je ook direct laat zien hoe zwaar je query nou eigenlijk is en wat het kan gaan kosten.

Dataflow is een perfecte data-verwerkingsoplossing met een solide basis, en heel snel op te zetten. AWS Glue is een ge-emmer met een uiterst brakke webinterface die om de haverklap stuk gaat, totaal afwijkende processen voor het aanmaken en het bewerken van elementen, zeer karige editor (en och ja, laten we daar ook maar 2 keuze's aanbieden om het overzichtelijk te houden), extreem brakke debugging. Daar is natuurlijk EMR maar dat is weer managed en vergt veel meer administrative overhead.

Moet ik doorgaan?

Azure heeft in ieder geval een stuk beter samenhangende web UI, en Databricks maakt het voor dataverwerking nog best goed bruikbaar. Maar bij Azure is voor bijzonder veel van de tools meerdere keuzes of modi. ADLS en Event Hubs, om even twee irritante te noemen. De API-support is de helft van de tijd experimenteel of incompleet.

Elke keer weer dat ik voor een klant met AWS moet werken is het afzien. Azure is nog wel werkbaar, maar doe mij maar GCP.

Ik vrees toch dat je niet recent met aws gewerkt hebt

Ik denk dat jij niet recent met AWS gewerkt hebt via de UI.

Maar zonder grappen: UX van de console van GCP is worlds apart van AWS. Networking ook. Subnets per regio ipv routed traffic via VPC tussen alle regio's.

En vergeet het gratis verkeerd binnen regio's niet..

Ui en cloud gaan mijn inziens niet samen. Je scrip alles met tools van de cloud provider zelf of met een neutrale tool als Terraform, Chef of Asible.
Een UI is te gevoelig voor fouten en niet schaalbaar.

Natuurlijk doe je niet aan pets. Dat is logisch.

En ja ik doe terraform. En tochik doe ik soms UI. Vooral op momenten waar je aan het diagnosticeren bent als je on call bent is de UI nou eenmaal nodig.

Daar maakt het ook uit hoeveel verbazing de diensten veroorzaken. Doet het onverwachte dingen? Dan is de ui harder nodig.

Daar scoort aws ook niet goed, wbt de caveats en het documenteren ervan.

Helaas wel…

Dat is maar net vanuit welk perspectief je naar de diensten kijkt. In de meeste analyses komen AWS en Azure boven Google in de lijsten kwa features en maturity. Maar nogmaals, het is afhankelijk van wat je wil doen op het cloudplatform.

Dat zal best, ik zal niet ontkennen dat ik biased ben richting GCP als GCP Certified Data Engineer. Azure heb ik een jaar intensief gebruikt, AWS een halfjaar maar geen certificering. Puur op basis van mijn eigen ervaring werk ik echt veel liever met GCP. Analyses heb ik weinig mee want uiteindelijk bepaald te klant toch wel platform ze gebruiken. In schaarse gevallen wordt mijn advies daarin gevraagd.

De klanten kiezen massaal voor AWS, ze hebben bijna 33% marktaandeel(boven de 40% als je naar top 10k sites kijkt) en dat stijgt al jaren. Google zit misschien tussen de 8 en de 10%. Zelf ben ik meer van AWS, GCP is een ontzettend leuke en inderdaad makkelijker om mee te werken, maar uiteindelijk is de VEEL completere set diensten van AWS toch doorslaggevend. En ja klanten stemmen met hun centen en dan wint AWS.

Dat vraag ik me af. Ik heb in ieder geval bij toepassing Azure gezien dat de keuze voor Microsoft gemaakt was op de golfbaan tussen het management. Vrijwel het voltallige ICT-team daar sprak voorkeur uit voor AWS. Overigens hoofdzakelijk door gebrek aan ervaring met GCP. Dat laatste werkt nou eenmaal ook tegen - als je klein marktaandeel hebt zijn er minder developers met ervaring die de keuze ervoor kunnen beïnvloeden.

Lang niet elke keuze wordt gemaakt op basis van kwaliteit van de dienstverlening of dienstenarsenaal. Heel veel gaat om geld, lobby'en, marketing en voorkeuren vanuit management.

Zeker! Daarom zie ik in ook veel Azure klanten, MS deed de support voor on prem al en neemt die klant dan ook mee in de cloud, puur politiek en centen idd. Wereldwijd is AWS toch echt de grootste en staat bij Gartner ook als beste aangeschreven en dat helpt wel als je een businesscase moet maken. Niks mis met GCP maar het is een beetje kip ei verhaal zoals je zelf al aangeeft.

Bij ons werkt Google Home ook niet goed meer. Verbinding met Hue is weg.

En ook wederom dat Google Fonts wat niet werkt en aangezien veel sites het gebruiken zijn veel sites nog bokke traag ook. Lekker weer

Net had DigitalOcean ook al een hickup (Gateway timeout van Cloudflare)?

Externe fonts maken de boel sowieso trager, lijkt mij... (Ik wil dat alles snel werkt.) In mijn browser heb ik dat uitgeschakelt (met een regedit o.i.d.; dat weet ik niet meer precies). Op enkele sites zie je dan blokjes met 0011000101, o.i.d. I.p.v. symbolen.

Gaat goed vandaag, eerst Online offline (what's in the name...) en nu Google. Opvallend dat dit de 2e grote storing bij Google is, in een week tijd.