Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Storing bij cdn-dienst Fastly zorgt voor veel onbereikbare websites - update

Veel internetdiensten zijn dinsdag sinds rond het middaguur niet bereikbaar, waarschijnlijk vanwege een storing bij cdn-provider Fastly. Dit bedrijf zegt op een storingspagina mogelijke problemen met de cdn-diensten te onderzoeken.

Fastly schreef op 11.58 uur Nederlandse tijd een 'potentiële performance-impact bij onze cdn-diensten' te onderzoeken. Sites en andere internetdiensten gebruiken zulke cdn's of content delivery networks, om datacentra dichterbij eindgebruikers te kunnen plaatsen. Fastly is qua dienst vergelijkbaar met Cloudflare, maar richt zich meer op snelheid dan op beveiliging. De dienst is de afgelopen jaren snel populairder geworden. Honderden websites en diensten gebruiken Fastly inmiddels om inhoud van webpagina's sneller uit te kunnen serveren.

Veel sites en diensten zijn sinds het middaguur moeilijk tot niet bereikbaar, waarschijnlijk vanwege de Fastly-storing. Volgens Downdetector gaat het om sites en diensten als Reddit, Twitch, Amazon, CNN, PayPal, Twitter en Stackoverflow. Met name servers in Europa en Azië lijken storingen te ervaren.

Update, 12:47 uur: Fastly zegt op zijn storingspagina het probleem te hebben geïdentificeerd en dat een oplossing nu wordt geïmplementeerd.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Hayte Hugo

Nieuwsredacteur

08-06-2021 • 12:29

161 Linkedin

Submitter: RobinFM

Reacties (161)

Wijzig sortering
Stackoverflow is down, dus dan maar pauze. Maar reddit is ook down...

Hopen dat ze snel weer online zijn
Maar als Stack Overflow down is, hoe willen ze dit probleem dan ooit op gaan lossen??
Tutorials op youTube van Meesters uit Indie die de les geven met trance muziek in de achtergrond en notepad als krijtbord.
Met de verplichte Hypercam 2 natuurlijk ;)

Seriously though, ik werk bij een grote organisatie en normaal komt het oplossen van problemen wel neer op slim Googlen - dus ook Stackoverflow :D
Op de uni's en hbo moeten ze dit als een voorbeeld geven over hoe recursion werkt.

Je googlet je probleem, je krijgt SO als eerste resultaat en vervolgens is het gesloten met een duplicaat. Je klickt op de duplicaat vraag en daarin heb je een antwoord: "Google it". Je googlet het en op magische wijze krijg je een post op r/programmerhumor als tweede resultaat (om de loop te breken). Vervolgens klik je erop. Zie je een link naar een oplossing vanuit SO. Je klikt erop en dan kom je op de eerste resultaat.

Definitie: Recursion / Infinite Loop.

TL;DR: Een circle heeft geen einde. als je googlet, komt je weer bij dezelfde vraag als beste result tegen die je vroeg om het te gaan googlen.
Heb je hier een link voor?
Hello Again! And Welcome to this quick tutorial, you see problem right here, you do this and that. And then your done! :Y)


Dont forget to subscribe, and hit the like button, and the notification bell. And dont forget to phone your family and make them patreons, check out this patreon list with patreons. And yeah also check out my channel, and all my other videos they are great!!
This video is sponsored by...
(Ik begin met) ... brilliant.org
Les van de legende: Nagoor Baboo (ICON OF JAVA)
http://www.durgasoft.com/
Dan maar even een update (release) ophalen bij GitHub om de tijd nuttig te besteden...

... Ook down. :'(

[Reactie gewijzigd door The Zep Man op 8 juni 2021 12:47]

Ja daar liep ik ook tegenaan.

Dan maar meeting
maar hoe gaan ze fastly terug up krijgen, als stackoverflow down is?
catch-22 }>
En Twitter is ook al stuk, dus niemand kan het normaal aan iemand anders vertellen
Zoekopdracht: youtube how to resolve cdn down...
Ik hoor gelijk een specifiek accent
hello, i Am Raj. i Am here toDay to Talk to You about depunDency InjecTion.
Oh, I see you no have platinum support contract. I cannot help you, sahib! Do you wish to get a platinum support contract?
reddit doet het prima bij mij.
Reddit werkt prima bij mij, ook toen je jouw reactie een halfuur geleden plaatste.

[Reactie gewijzigd door TheVivaldi op 8 juni 2021 12:58]

Mooie single point of failure hebben we dan weer als 1 dienstverlener een hele lading mega platforms plat kan leggen.
Na 15+ van desktop en embedded software development (en een beetje web) ben ik nu iets meer dan een jaar fulltime aan het webdevelopen (voornamelijk frontend en webgl, beetje backend), en ik vind het opvallend hoe anders de development-mentaliteit is tussen die twee werelden. Bij desktop/embedded development wil je zo veel mogelijk onder je eigen controle houden en op je eigen machine doen, en bij web lijkt het wel een YOLO van zo veel mogelijk externe services en libraries aan elkaar knopen.

Soms voel ik me een beetje een dinosaurus omdat ik die "oude" mentaliteit van controle houden maar moeilijk los kan laten. Maar als ik berichten als dit lees dan vind ik het weer onverstandig om je core business afhankelijk te maken van tig externe partijen/factoren.
Maar dat is goedkoper, want extern inkopen betekent lagere kosten en meer flexibiliteit voor de organisatie. Niks zelf hebben, alles extern draaien. Het mantra van alle financiele mannetjes de afgelopen decennia.

Eigenlijk ben ik wel blij dat er steeds vaker dit soort grote verstoringen zijn. Misschien dat ze hoger in de boom eens wakker worden dat het wel fijn is om zelf dingen te hosten en experts in huis te hebben.

[Reactie gewijzigd door DropjesLover op 8 juni 2021 15:21]

Juist omdat een externe provider de hosting over 10 jaar genomen goedkoper, sneller en stabieler doet gebruik je juist die. Waarom zou je als webdevelopment álles in huis halen? Dat is echt niet beter.
Dat is vooral de Javascript wereld. Een miljoen packages bundelen om het geheel een beetje werkbaar te maken, die je dan moet managen met package managers die ook wel wat te wensen over laten.
Pffff ja, Ik werk sinds kort met VueJS en ik mag een stuk of 200 packages naar binnen halen om mijn barebones app überhaupt aan te praat te krijgen (Een kleine dramatisering maar wel waar)
Je ziet dit conflict ook behoorlijk bij Linux package managers en build-systemen. Alle Linux build systemen werken air-gapped: Geen internet, geen losse bronnen. Op deze manier kan een build eenvoudig gereproduceerd worden en kun je eenvoudig alle bronnen controlen. Dit is echter niet ideaal met bijvoorbeeld PIP, welke vaak een textbestand gebruikt om bronnen te downloaden wanneer deze nodig zijn. Dit kan echter al veel later in het build-proces zijn, en dan loopt alles in het honderd.

Je ziet dan ook dat voor dit soort systemen, er extra scripts nodig zijn om de bestandslijst van bijvoorbeeld PIP te generen. Veel meer onhandig werk, maar gelukkig kan er op deze manier wel een reproducible build worden gemaakt.

Voorbeeld uit eigen collectie:
https://github.com/flathub/org.gnome.Lollypop

[Reactie gewijzigd door Eonfge op 8 juni 2021 15:07]

Als je denkt dat dat de enige SPF is dan heb ik slecht nieuws voor je. Als AMS-IX down gaat heb je bijvoorbeeld vrijwel helemaal geen internet meer, en ook dat gebeurt sporadisch wel eens. En iemand anders noemt hieronder al Cloudflare, wat de afgelopen jaren ook aardig wat downtime heeft veroorzaakt.

En wat te denken van Amazon? Amazon verzorgt intussen dermate veel clouddiensten dat er een hele boel sites plat gaan als Amazon problemen heeft. En hetzelfde geldt voor Azure en andere gelijkende diensten.

Ik denk dat het vrijwel onmogelijk is om dit soort dingen te voorkomen. Met de manier waarop het internet inherent gewoon werkt is het praktisch onmogelijk om een site te runnen die niet érgens op de lijn een SPF heeft die de site down kan krijgen. En dat SPF wordt dan gedeeld door alle sites die diezelfde dienst gebruiken...
Gelukkig is de AMS-ix opgebouwt uit 14 locaties. Maar inderdaad, heeeeel heeeel soms werkt het niet helemaal.

Elke toko kan problemen hebben en alles kan plat uiteindelijk.

Soms moet je het gewoon uitzitten :P
Ja precies, dat was mijn punt. Alles kan in theorie (en heel soms in de praktijk) down. Een SPF is soms onvermijdelijk, al kun je natuurlijk wel risico's beperken.
Je kunt het beste er voor zorgen dat er minimaal nog 1 extra SPF aanwezig is. Dan los je je SPF op.
Nee, dan heb je twee onafhankelijke single points of failure. :P
AWS/Azure/GPC hosted sites is alleen een issue als er een vendor wide probleem is anders is het een kwestie van een redundant systeem opbouwen in meerdere regios/availability zones met loadbalancers ervoor..
Over het algemeen zijn de global services van deze providers al default redundant uitgevoerd..
Maar er is vaak toch nog wel ergens een single point of failure (zoals Google laatst had met de security)
AWS/Azure/GPC hosted sites is alleen een issue als er een vendor wide probleem is
Nou, precies dat dus. En dat is nu met Fastly dus waarschijnlijk ook het geval.
Ik denk het ook ja..
Maar dat is nou juist het probleem: die bedrijven die jij noemt, bestaan niet uit één server of één locatie. Fastly zit ook over de hele wereld; dat is juist hun ding: de content dichter bij de gebruiker zetten. Ik vraag mij dan af (uit nieuwsgierigheid) wat er dan stuk is dat de hele boel plat is. Ze hebben een aantal datacenters, maar blijkbaar zit er ergens in de overkoepelende infra iets dat de hele boel plat kan leggen. Op zich interessant om dat te horen, al was het alleen maar om van te leren.
Misschien is het een kwestie van iets dat ze net tè goedkoop hebben uitgevoerd. "Want dat gaat toch nooit fout?" (famous last words)
Hebben we eerder ook al gezien toen Cloudflare ergens een slechte deployment had gedaan. Aan de ene kant heel jammer en schrikwekkend dat één partij zoveel invloed heeft op het internet, aan de andere kant is het natuurlijk ook gewoon een kwestie van "de grootste zijn de beste". Probeer maar eens als kleine speler een kosteneffectief globaal CDN netwerk op te zetten. Dus dan kom je al snel bij grotere spelers terecht die de kost kunnen spreiden over heel veel verschillende websites.
Klopt, maar het is vaak een kosten-baten analyse.. als je je CDN bij meerdere vendors doet verdubbelt je kosten ook (of nog meer).. en aangezien de providers vaak een SLA bieden met veel negens is vaak de keuze dat dat OK genoeg is..

Wat me wel opvalt is dat dit soort issues telkens vaker op vendor nivo zijn.. Dus ook al heb je wel je infrastructuur redundant ontworpen, als er in de vendor zelf single points of failure zijn dan gaat het alsnog mis.. en heel publiek want alle klanten hebben er last van..
Dat is een afweging die je maakt in een risicoanalyse. Hoe veel mag het kosten om een korte outage te vermijden die heel sporadisch voor kan komen. En mocht je het superredundant willen maken, dan introduceer je weer andere problemen. Het kan te complex worden.
Fijn, een hoop grote websites afhankelijk van dezelfde provider ...
Dat valt me ook al op de laatste paar jaar. Ik gebruik een add-on NoScript waarbij ik om veiligheidsredenen alleen scripting toesta voor domeinen die ik zelf whitelist. Maar het aantal 3rd party domeinen die websites aanroepen en vaak ook nodig hebben is enorm toegenomen. De tijd dat alles op de eigen server/domeinnaam draaide met misschien nog een 3rd party counter is wel over.
Hoe meer mensen 3rd party javascript blokkeren, hoe eerder sites daar vanaf stappen.
Lekker decentraal inderdaad.. Hopelijk wordt er een les uit getrokken.
Welke les? Fastly ging down en dan is je website even plat. Dat is een geaccepteerd risico en een keuze die gemaakt wordt in plaats van extra geld uitgeven om meerdere CDNs toe te passen alleen maar om dat ene moment van downtime potentieel te ontwijken. De wereld draaide gewoon door, niets aan de hand.
De wereld draait niet 'gewoon door' als betaalplatformen als PayPal eruit liggen, dat heeft redelijke gevolgen. Tuurlijk, het is geen niveautje 'Evergreen', maar zeker beter om dit in het vervolg te voorkomen.
Als jij verantwoordelijk zou zijn voor een website, hoeveel geld heb je dan over voor meer redundantie? Onder aan de streep moet je uiteraard nog wel geld overhouden.

Maar ik denk dat je nog niet zo oud bent. Anders had je ook geweten dat de beschikbaarheid van IT nog nooit zo goed is geweest als tegenwoordig. Nu valt het op als IT een keer is uitgevallen. Er zijn tijden geweest dat je er gewoon van uit ging dat services af en toe niet beschikbaar waren.
Als we het hebben over partijen als PayPal zou ik daar best wel wat voor over hebben ja.
Dat de Zeeman er ff uit ligt ja prima, maar vindt ik toch heel wat anders dan een van de grootste betaalplatformen op de wereld.
twitch is ook down. hoe krijg ik nu mijn hottub fix. :(
en de twitter emoji's werken niet meer. hoe dat zit.. geen idee..
Meeste standaard emoji's zitten allemaal op een open source database waar alle services ze vandaan vissen.

Gelukkig zijn de Tweakers emoticons uit het jaar 2002 veilig! :+
Nou, noem de open source database maar gewoon 'Unicode'

En ook halen services/diensten halen deze niet direct van de unicode, maar je OS implementeert deze emoji's zelf.
Deze worden dus niet zelf gehost, deze emoji bijvoorbeeld -> 🌀 heeft Tweakers geen invloed op.

Op twee verschillende OSsen kan de zelfde emoji er dus anders uit zien. Een makkelijk voorbeeld is iOS & Android. Beide volgen de Unicode standaard, maar hebben beide hun eigen uiterlijk maar dezelfde betekenis.
Deze site heeft een mooi overzicht hoe emoticons per platform kunnen verschillen. https://emojipedia.org/teddy-bear/
Oh, zou dat de reden zijn!? Had het gezien (met soms grappige resultaten door de alt-tekst) maar de link niet gelegd.
Geen Stackoverflow en geen Github. Fijn als je programmeur bent, zijn voor velen toch veelbezochte websites denk ik

[Edit]

Zoals een echte niet programmeur betaamt: de als variabele in mijn uitspraak hoeft niet per se waar te zijn in deze context

[Reactie gewijzigd door amx op 8 juni 2021 12:44]

Een keertje zelf een probleem oplossen kan geen kwaad hoor.
Gaat een beetje lastig als je source zelf ook Github staat en je geen PR's kunt maken/reviewen :'(
Pull requests. Blijft een rare benaming. Vind de MR's van GitLab toch logischer klinken.
Er is een andere hub die het nog wel doet. :+
Daar kun je je wel mee vermaken tot StackOverflow en Github weer online zijn.
If (programmer) {
everything = fine
} else {
panic = true
}
Undefined variable 'programmer' on line #1.
Hmm net nog met paypal betaald en dat leek gewoon te werken. Ook de bevestigings mail van Paypal ontvangen... maar mail zal wel een andere route hebben dan de website misschien
Mail gaat intern en dan rechtstreeks terug. Is uitgaand verkeer dus gaat niet over CDN.
Mails gaan niet via een CDN 😊
Daarom altijd multi-CDN deployments gebruiken, heb je zat failovers, plus meer kosten efficient. :)
Leg eens uit hoe dat meer kosten efficient is?
Meerdere providers/failovers is hogere kosten lijkt me..
Hangt beetje af welke regio’s je moet serveren. Er zijn CDN’s die in LATAM goedkoper zijn, andere weer in EMEA en de andere weer in de US. Met de juiste DNS routing zorg je ervoor dat de gebruikers de goedkoopste/snelste optie geserveerd krijgen.

Plus als bonus dat bij een flinke failure zoals dit bij Fastly alles gewoon blijft functioneren.
mmm het doel van een CDN is juist dat je dicht bij de gebruiker host om zo lagere latency en hogere througput te krijgen..
Als je in LATAM je CDN gaat hosten voor EMEA gebruikers dat sla je de plank volgens mij mis..
Dan heb je mijn vorige reactie niet goed gelezen maat. ;)
Dan snap ik niet hoe jij bij kosten besparingen komt.. :p

Stel je hebt je gebruikers in EMEA.
Ga je met 1 CDN dan heb je kosten X, ga je met 2 CDNs dan heb je kosten X+Y.. of als je het splits waarschijnlijk iets van 0.75X+0.75Y..
Kosten van andere regios zijn irrelevant..
Maar hij heeft het dan ook over international deployments. Niet al je eieren in 1 bucket hebben zeg maar.

dus je hebt in LATAM een andere (goedkopere) CDN dan voor EMEA. Met de juiste DNS routering kun je echter wel fallbacken naar LATAM als je EMEA provider het niet doet.
Bij 'multi-CDN deployments' interpreteer ik dat als meerdere CDN providers.. niet meerdere regios.. aangezien IMHO regio's juist inherent zijn voor een CDN..

Buiten dat als het een probleem is bij de vendor dat over alle regios gaat dan heb je nog steeds een probleem.. en daar lijkt het er hier op..

kijk maar eens hoe AWS een CDN service beschrijft: https://aws.amazon.com/cloudfront/
"Global Scaled Network for Fast Content Delivery
Amazon CloudFront is massively scaled and globally distributed. The CloudFront network has 225+ points of presence (PoPs) that are interconnected via the AWS backbone delivering ultra-low latency performance and high availability to your end users. The AWS backbone is a private network built on a global, fully redundant, parallel 100 GbE metro fiber network linked via trans-oceanic cables across the Atlantic, Pacific, and Indian Oceans, as well as, the Mediterranean, Red Sea, and South China Seas. Amazon CloudFront automatically maps network conditions and intelligently routes your user’s traffic to the most performant AWS edge location to serve up cached or dynamic content. CloudFront comes default with a multi-tiered caching architecture that offers you improved cache width and origin protection."


En fastly: https://status.fastly.com/incidents/vpk0ssybt3bj
"Fastly’s network has built-in redundancies and automatic failover routing to ensure optimal performance and uptime."

[Reactie gewijzigd door ToolkiT op 8 juni 2021 13:44]

Ja I know, Daarom begrijp ik het ook niet zo goed. Een beetje CDN heeft dit gewoon intern al op eenzelfde manier opgelost, maar ik snap zijn redenering verder wel.

Het kost alleen meer om met meerdere providers in zee te gaan, want interne administratie kost ook een hoop stiekem.

Met 1 provider kun je vaak betere afspraken maken en kun je met een beetje mazzel nog wat korting regelen (en heb je beter inzicht in SLA afspraken wereldwijd).
Multi-Cloud is zeker een verbetering qua redundancy.. maar wel tegen een prijs.. zowel qua complexiteit als kosten.. maar je haalt wel een single point of failure weg..
Meerdere providers klinkt als een leuke technische optie, maar is een operationeel en commercieel drama. Als er iets fout gaat weet je zeker dat men naar elkaar gaat wijzen. Beter "one neck to grab".
Maar als je in LATAM een CDN hebt en in EMEA, en de CDN van EMEA ligt eruit dan hebben je gebruikers vanuit EMEA dus nog steeds een werkende website. Weliswaar via LATAM en dus trager, maar het werkt wel.
Maar niet als het een vendor-wide probleem is (zoals het nu lijkt te zijn), want dan werkt LATAM niet..
Dus dan ga je naar meer vendors kijken als oplossing, maar dan gaan de kosten meestal juist omhoog..
precies. Zelfs als je het verkeer round-robin over twee providers gooit is het nog steeds meer dan de som van twee keer de helft.
Yep. FT, NYT etc. Ogenschijnlijk willekeurige connectieproblemen met diverse soorten meldingen.
Independent, guardian
Guardian laat weten op hun site dat er een grote outage is. Zo groot dat ze gewoon kunnen berichten over de outage. Oftewel: het is al weer opgelost voordat het een groot probleem kon worden. Zonder CDN providers als Fastly zouden we veel vaker problemen hebben.
GitHub website geeft ook 503 (Fastly) als je iets raw wil bekijken..
Niet alleen als je iets raw wilt bekijken.
De homepage en sites als ng-bootstrap.github.io lijken ook down te zijn of half te werken.


Om te kunnen reageren moet je ingelogd zijn


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True