Amazon Web Services kampt met storing

Amazon Web Services kampt momenteel met een storing. Deze storing heeft onder andere invloed op diensten van Amazon zelf, maar ook diensten als Adobe Spark, Roku en Flickr zijn hierdoor deels offline.

De eerste melding op Amazons statuspagina werd rond woensdagavond 19:00 uur Nederlandse tijd geplaatst. "Kinesis kampt momenteel met een verhoogd foutenpercentage in ons US-East-1-gebied, wat ook enkele andere AWS-diensten beïnvloedt", zo wordt vermeld op het Amazon Service Health-dashboard. Het bedrijf meldt daarbij ook dat de storing invloed heeft op 'de mogelijkheid om updates te plaatsen' op dit dashboard. Wel heeft het bedrijf naar eigen zeggen de oorzaak inmiddels gevonden, en wordt momenteel doorgewerkt aan een oplossing.

De storing zorgt onder andere voor problemen bij diensten van Amazon zelf, waaronder Amazon Workspaces, IoT Services en Marketplace. Op DownDetector worden daarnaast problemen met diensten als Alexa gemeld. Ook bedrijven melden op Twitter dat hun diensten momenteel offline zijn, waaronder Adobe Spark. De streamingapparaten van Roku kampen hierdoor ook met een storing, evenals fotowebsite Flickr en podcastdienst Anchor van Spotify.

Dit is niet de eerste keer dat een AWS-storing verschillende internetdiensten treft. In 2018 zorgde een dergelijke storing ervoor dat diensten als Slack tijdelijk onbereikbaar waren. Een jaar eerder ondervonden onder andere Imgur, Medium, Trello en Quora problemen vanwege een AWS-storing.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (105)

Storingen horen erbij maar ik snap niet waarom de aws statuspage nog steeds afhankelijk is van (kennelijk heel wat) aws diensten. Het is niet de eerste keer dat ze door een storing hun statuspage niet konden bijwerken, en toen hadden ze beterschap beloofd. Hoe moeilijk is het voor zo’n club om een pagina bij een concurrent te hosten waar allicht handmatige updates/berichten altijd nog tot de mogelijkheid behoren?

Als klein bedrijfje (Transloadit) hosten wij alles op aws, maar onze statuspage is t/m de domeinnaam registratie en dns aan toe op gcp gehost, zodat je daar nooit gerommel mee kan krijgen (beiden tegelijk down is een veel kleinere kans / force majeur).

[Reactie gewijzigd door kevinvz op 26 november 2020 21:04]

Om de status pagina aan te passen moet er goedkeuring zijn ( het is 1 politiek spel bij Amazon).

We hired an engineer out of Amazon AWS at a previous company.
Whenever one of our cloud services went down, he would go to great lengths to not update our status dashboard. When we finally forced him to update the status page, he would only change it to yellow and write vague updates about how service might be degraded for some customers. He flat out refused to ever admit that the cloud services were down.

After some digging, he told us that admitting your services were down was considered a death sentence for your job at his previous team at Amazon. He was so scarred from the experience that he refused to ever take responsibility for outages. Ultimately, we had to put someone else in charge of updating the status page because he just couldn't be trusted.

https://news.ycombinator.com/item?id=25209773

Wat opvalt, is dat nu plotseling hoeveel van je data naar Amerika reist en er afhankelijk van is voor te functioneren.

Zoals merkte ik op dat als je op de deurbel duwde tijdens de storing, dat er geen enkele chime afging...geen wifi of geen internet of geen amerika == geen services

Onbegrijpelijk dat ze in europa geen servers hebben, nu begrijp ik waarom het vaak 3 seconden duurt voor mijn deurbel chime afgaat...1.5 seconden naar ginder reizen en 1.5 second terug ...

Ik had hetzelfde voor met onze connected kattenluik van surepet , die werkte ook niet meer. Dat is nochtans een UK bedrijf, maar die blijkbaar zijn infrastructuur in USA draait...

En een maand geleden was er een IP conflict probleem in USA bij cloudflare, vreemd genoeg lag de hele wereld plat hierdoor...dat noem ik ook niet echt redundant. Ook daar waren we dus afhankelijk van een probleem in USA.

[Reactie gewijzigd door sebastienbo op 26 november 2020 23:54]

Onbegrijpelijk dat ze in europa geen servers hebben, nu begrijp ik waarom het vaak 3 seconden duurt voor mijn deurbel chime afgaat...1.5 seconden naar ginder reizen en 1.5 second terug ...

Ik had hetzelfde voor met onze connected kattenluik van surepet , die werkte ook niet meer. Dat is nochtans een UK bedrijf, maar die blijkbaar zijn infrastructuur in USA draait...

Ik vind het eerder onbegrijpelijk dat mensen vrijwillig producten kopen die voor 100% afhankelijk zijn van internet en 1 bedrijf. Mijn inziens kunnen cloud diensten een aanvulling zijn voor een product, maar een afhankelijkheid blijf ik ver van weg. Je hoort zeer regelmatig dat een bedrijf of dienst uit de lucht gaat, zit je daar met je dure product....

Waar men het host is ook discutabel, zeker als het binnen diensten als AWS of Azure is. Vaak wordt er gestart met een EU hosting en gaandeweg de tijd wordt dit vanuit bijvoorbeeld kostenoogpunt overgezet naar de USA of andere goedkope plekken, de gebruiker heeft er toch geen weet van over het algemeen.

Zeker off-topic, maar ik ben niet zo bekend met "slimme" deurbellen, omdat ik nooit in mijn leven eentje zal kopen. Bestaan er echt deurbellen die voor het "afspelen van de deurbel" afhankelijk van het internet / clouddiensten zijn? Ik dacht dat zoiets alleen nodig was om op afstand mee met de camera te kunnen kijken. Welke deurbel is dat als ik vragen mag?

Ja en er moet echt niet veel mis zijn, als je eigen internet down is, of je wifi access point, dan komt er geen deurbel binnen. Er zijn nu wel deurbellen die kleine apparaatjes meegeven die je naar je oude gong kan laten gaan.

Ik vraag me alleen af of een partij als amazon wel de ruimte heeft contractueel gezien om een statuspagina bij een andere partij onder te brengen. En als ze dat zouden doen. Hoe groot is de kans dan dat dit down gaat door een storing bij die andere partij?

Zo had ik hier dus bijvoorbeeld geen hinder van de storing, want geen us services, maar bijvoorbeeld wel doordat een derde partij zijn spul niet op orde had en een bad gateway afgaf bij. Terwijl ik daar ook niet de US versie zouden afnemen.

En in jullie geval. Hoe garandeer je dat een storing bij GCP geen issues geeft?

Het gaat er minder om dat de statuspagina altijd up is, en meer dat hij niet tegelijk met je platform down gaat. Als onze statuspage down is terwijl ons platform prima draait, zullen weinig mensen daar moeite mee hebben. Als ons platform down gaat en de statuspage up is, vinden mensen het fijn snelle status updates te krijgen over wanneer het platform weer online is. Als ze beiden down gaan of niet goed functioneren, dan is er stront aan de knikker. Dit is bij aws nu twee keer gebeurd omdat ze hun eigen technologie/netwerk/datacenters gebruiken voor de statuspage.

De kans dat gcp en aws tegelijk een probleem hebben is gewoon velen malen kleiner. En als dat gebeurt, kun je spreken van een force majeure waar je klanten dan ook wel weer begrip voor kunnen opbrengen. Je hebt er immers alles aan gedaan wat je redelijkerwijs mag verwachten on het risico van dubbel down te vermeiden.

En wat zou contractueel het bezwaar zijn? Status updates kun je zien als publieke informatie (iedereen kan dit inzien) dus waarom niet onafhankelijk hosten. Misschien niet meteen bij de grootste concurrent, maar waarom niet gewoon bij m’n oude werkgever en hoofdsponsor van Tweakers bijvoorbeeld

[Reactie gewijzigd door kevinvz op 26 november 2020 07:54]

Tja, is het dan ook niet handiger sommige klanten op gcp te zetten, met hun statuspage op aws? Dan voorkom je dat elke klant hinder ondervindt bij een aws storing.

Zeker, en daar heb ik gister nog naar gekeken, maar dat is ook veeeeeeel duurder : ) (steeds je infra spiegelen, steeds weer net andere constraints tegenkomen of features die niet 100% overlappen, om te zwijgen over gewoon dubbele fees die je betaalt)

Een statuspage bij een andere host is een kleine ingreep. kosten/baten

[Reactie gewijzigd door kevinvz op 26 november 2020 20:52]

Dan kun je de klant toch zelf laten bepalen? Tenminste, wij adviseren de klant waarmee wij de beste ervaringen hebben, maar laten de keuze wel bij de klant liggen.

Hangt van je platform af denk ik, maar mooi als dat bij jullie makkelijk kan, dat wel. Ben ik wel een beetje jaloers op

En wat zou contractueel het bezwaar zijn? Status updates kun je zien als publieke informatie (iedereen kan dit inzien) dus waarom niet onafhankelijk hosten

Denk dat ze juist contractueel zich hebben verplicht om in geval van storingen informatie te delen via een van te voren afgesproken kanaal.

En wat zou het de klant uitmaken waar Amazon dat host? Zolang ze maar de (publieke) informatie over de storing maar kunnen vinden zodat ze weten wat er aan de hand is, dan kunnen ze daar vervolgens zelf ook naar handelen qua informatie intern / extern.

Ik snap dat het er niet zozeer om gaat dat die status pag up en running moet zijn, maar meer om het algehele design waarmee je dus ook rekening moet houden met waar derde partijen hun dingen hebben staan. Als je voor statuspages bijvoorbeeld gebruik maakt van Ping services en die houden er bijvoorbeeld even mee op wat doet dit dan met je SLA? Sommigen gebruiken dergelijke tooling namelijk om uptime te kunnen meten. Het is dus wel degelijk belangrijk dat een dienst waar je je metrics mee verzameld dat daar failsafes voor ingebouwd zijn om mee te crossreferencen als jet ware.

Je kan wel zeggen " zodat je daar nooit gerommel mee kan krijgen.", maar dat is echt hel kort door de bocht.

En wat zou contractueel het bezwaar zijn? Status updates kun je zien als publieke informatie (iedereen kan dit inzien) dus waarom niet onafhankelijk hosten. Misschien niet meteen bij de grootste concurrent, maar waarom niet gewoon bij m’n oude werkgever en hoofdsponsor van Tweakers bijvoorbeeld

niet contractueel richting klanten, maar juist richting hostende partijen. Ik weet niet of een google/azure/alibaba daar wel op zitten te wachten bijvoorbeeld. Misschien heft amazon zelf wel contracten met betrekking tot GDPR of privacy shield dat het niet eens mag. I dunno, Dergelijke dingen zijn best ingewikkeld.

De kans dat gcp en aws tegelijk een probleem hebben is gewoon velen malen kleiner. En als dat gebeurt, kun je spreken van een force majeure waar je klanten dan ook wel weer begrip voor kunnen opbrengen. Je hebt er immers alles aan gedaan wat je redelijkerwijs mag verwachten on het risico van dubbel down te vermeiden.

Precies, dus kun je dan niet beter multitenant distribution/loadbalancing hebben? Dus dat je beide diensten gebruikt?

AWS kan prima de statuspagina updaten, het is overigens ook redundant gehost. Voor zover ik me kan heugen is met de afgelopen jaren 1 maal de statuspagina ook volledig naar de gallemiezen gegaan (met de huge s3 outage).
En ook binnen 1 partij is redundancy makkelijk te bereiken. Zeker als je meerdere datacentra hebt, meerdere domains, meerdere backbones en een plethora aan private lines.

Het is simpelweg dat veel AWS services een SLA hebben. En als je flinke Enterprise Customer bent heb je recht op schadevergoeding of compensatie onder bepaalde omstandigheden, als die SLA geschonden wordt. Dus dat dashboard op rood mikken, daar moet heel wat voor gebeuren bij AWS.

Weet je dat Re:Invent ook al jaren gestreamed werd door andere domains dan die van AWS zelf? Als er dan teveel traffic was was je niet zelf de schuld. Ik ben echt benieuwd hoe dat dit jaar gaat nu alles digital zal zijn.

Check anders https://stop.lying.cloud/ uit, daar heb je meer aan (beetje druk en ver dus wat geduld hebben). Dit ligt niet aan incapabele engineers of brakke architectuur, maar aan management en politics en image.

[Reactie gewijzigd door HgnX op 26 november 2020 17:25]

En ook binnen 1 partij is redundancy makkelijk te bereiken. Zeker als je meerdere datacentra hebt, meerdere domains, meerdere backbones en een plethora aan private lines.

Dat heeft AWS allemaal, en meer, en toch gaat eens in de zoveel jaar half us-east-1 plat. Soms deploy je een bug, een driver issue in EBS, een router/dns/lb misconfiguratie, een packet storm in je datacenter. En dan blijkt ineens dat redundant uitgevoerde systemen toch meer gemeen hebben dan je dacht. Daarom is een statuspage off-site hosten gewoon een best practice, waar AWS dus niet aan voldoet.

Wat betreft politiek kun je gelijk hebben, misschien kost het ze teveel een SLAs. Anderzijds, AWS zegt altijd "customer obsession" te hebben en dit zou daar haaks op staan--en ze op de langere termijn meer PR schade kunnen berokkenen dan dat ze snel wat centen op SLAs besparen. Zeker gezien AWS nog al winstgevend is en echt wel wat kan missen om de lange termijn relaties gezond te houden.

De verklaring van @NicoJuicy vind ik dan aannemelijker, dat poppetjes binnen AWS bang zijn ontslagen te worden als hun verantwoordelijkheid "officieel down" was, en dat die praktijk wordt verdoezeld met "het lukte niet te updaten".

https://stop.lying.cloud/

Dit is heel nice, thanks

[Reactie gewijzigd door kevinvz op 26 november 2020 20:34]

Jullie status pagina ziet er goed uit! Mag ik vragen hoe jullie die health checks doen?

Dank! Intern is er veel kritiek op de looks en we gaan binnenkort wel een redesign doen haha

De statuspage is een Nodejs app die zelf geautomatiseerde checks uitvoert en dan groen of rood kleurt. Daarnaast pollt hij ons Twitter account voor relevante berichten.

Dit is inhouse spul maar er is bijvoorbeeld ook een dienst als statuspage.io waar je dit soort functionaliteit kunt uitbesteden. GitHub, Travis, Vercel, en vele andere grote clubs maken daar gebruik van.

Ik kan je vertellen uit eigen ervaring dat AWS er op staat dat zelfs technologie van hun onderaannemers op AWS draait. Wat echt SUPER irritant is als je dat niet al hebt - want overstappen is niet zomaar een optie.

"Hoe moeilijk is het voor zo’n club om een pagina bij een concurrent te hosten waar allicht handmatige updates/berichten altijd nog tot de mogelijkheid behoren?" - Als er een manager is die het idee afschiet - heel moeilijk.

Nou, het is vrij simpel. Veel AWS services hebben een SLA. En als je flinke Enterprise Customer bent heb je recht op schadevergoeding of compensatie onder bepaalde omstandigheden, als die SLA geschonden wordt. Dus dat dashboard op rood mikken, daar moet heel wat voor gebeuren bij AWS.

Ring had eerder op de avond ook last van een storing. Ring is van Amazon en zal we op AWS draaien (aanname). Ik zie een link?

Ring had hier ook wat problemen, deurbel ging niet af en beweging is niet opgeslagen toen de pakketbezorger langs kwam. Dit was rond 19u.

Waarom kopen mensen een huishoudelijk apparaat dat niet werkt als de internetverbinding weg is? Ik snap er echt helemaal niks van.

Precies. Ik heb een Siemens oven die ik op afstand via een app kan voorverwarmen e.d. Maar hij doet het toch echt nog met gewone knoppen als de verbinding weg valt. Dat is voor mij een voorwaarde.

Voor mij is het zelfs een voorwaarde dat het apparaat überhaupt niet via internet bediend 'moet' worden. Als ik in m'n lokale netwerk zit, wil ik niet afhankelijk zijn van een één of andere cloud-dienst om de app te gebruiken. Dat raakt in mijn beleving echt kant nog wal.

Blij dat ik de ouderwetse bel er bedraad aan heb hangen. Dan zie je ze niet, maar hoor je ze wel (met geluk).

Ik heb een ring met een chime. De app was down maar de chime ging gelukkig wel af.
Wil toch wel een andere deurbel binnenkort...

Door deze zeldzame storing? Of andere redenen?
Bedoel, heb hem nu net een maandje of 2 hangen, maar ik ben super blij met de ring.

Nee, niet door deze storing. Zie mijn reactie hieronder.
Ik ben op zich blij met de werking. Al mag de video en 2-weg audio verbinding wat sneller opgezet worden.
Verder laat ik Ring via mn Homey snapshots versturen, maar die zijn vaak leeg.
De nieuwe snapshots in notificaties van de Ring app zijn wel weer perfect.

Mag ik vragen waarom? Ik was van plan er 1 te installeren namelijk.

Ik zoek een deurbel met lokale opslag (en met accu).
Best tevreden met de kwaliteit van de beelden en app van Ring. De nieuwe persoonsdetectie en zone instelling werkt goed voor mij (straat niet ver van mijn voordeur)
Ondanks goede wifi en snel internet is de pakketbezorger wel vaak al weg voordat je tegen m kunt praten.
Maar de bekende privacy bezwaren en de abonnementskosten zorgen dus vooral dat ik in de markt ben voor een alternatief.
Tips en ervaringen welkom!

Lokale opslag doet eufy. Verder geen ervaring mee.

Mijn ring is gelukkig wel snel,
Er accu. (3+) Of mijn bezorgers zijn allemaal langzamer. Kost inderdaad wel heel even, dat geef ik toe, maar dat kost naar de deur lopen normaal ook.

Onze standaard deurbelgong gaat ook gewoon af als er op de Ring gedrukt wordt, hoor. Dat heeft niks te maken met slim versus dom.

Maar ook ik wil weg van de Ring. Ik wil van de Amazon-cloud af.

En waarom van de Amazon cloud? Of van cloud in het algemeen?
En dat wordt nogal lastig, zo niet onmogelijk, aangezien steeds meer de cloud in gaat.

Tuurlijk, je kunt zelf van alles maken aan IoT oplossingen, maar vaak krijg je het niet zo mooi als wat je koopt. Een belknop afvangen en een relais over laten gaan lukt prima, melding naar telefoon ook. Dan nog je intercom functie opzetten, beweging detecteren en dan alleen personen... Dan hebben we het nog maar over de deurbel, dan moet je je klimaatbeheersing en verlichting nog, om over een spraak assistent nog maar te zwijgen.

En dat allemaal omdat er gister 1 hikje was?

Oow, en vergeet je streaming diensten niet op te zeggen, draaien ook in de cloud

Enerzijds van de Amazon-cloud door hoe Jeff Bezos zichzelf steeds maar blijft verrijken, en anderszijds van cloud in het algemeen omdat shit gewoon moet blijven werken als je verbinding eruit ligt.

Ik heb alle camera's in huis via devices UniFi Protect van Ubiquiti lopen, en dat is dus lokale opslag. Voorheen had je echter de cloud alsnog nodig voor de mobiele apps, omdat die een per se een handshake wilden doen tussen jouw lokale(!) opslag en je device. Sinds kort kan UniFi Protect gelukkig ook puur lokaal blijven werken, dus als je internetverbinding eruit ligt kun je nog steeds bij je beelden. Ubiquiti heeft ook een deurbel die, zoals ik begrijp, in februari in Europa beschikbaar wordt. Zaken als klimaatbeheersing, bewegingsdetectie (binnen en buiten), verlichting etc. zijn hier al volledig geïmplementeerd en geautomatiseerd met een cloud-onafhankelijke oplossing, namelijk met IP Symcon.

Streamingdiensten ga ik niet opzeggen omdat ze niet werken als je verbinding eruit ligt. Dat is namelijk inherent aan streamingdiensten.

[Reactie gewijzigd door gday op 26 november 2020 09:46]

Nou ben ik niet bekend met Ring. Maar je bent dus met Ring afhankelijk van een werkende wifi verbinding (of is ie bekabeld?), een internetverbinding en een Amerikaanse cloud-oplossing om je deurbel te kunnen horen? Dus even los van alle 'slimme dingen' die een Ring heeft. Dus er komt dan gewoon überhaupt geen geluid uit dat ding als één van de drie uitvalt?

Ring draait absoluut op aws. Net als Alexa. Maar die hebben het hier de hele tijd goed gedaan.

Nu bellen ze hier niet de hele avond aan, dus mogelijk in ring wel een hik. Alexa gebruiken we vrij intensief, die heeft het prima gedaan. Maar is ook net hoe je je ontwerp maakt, dat zal Amazon zelf wel op orde hebben denk ik 😉

postnl er misschien ook last van? De site en app hebben moeite met weergeven van profiel, bestellingen en ook tracking.

Yup
https://aws.amazon.com/so...tudies/postnl-case-study/
https://dutchitchannel.nl...es-naar-public-cloud.html

Dat PostNL diensten in AWS heeft draaien betekent niet dat ze problemen hebben door deze storing. Nogal misleidend.

Stukje uit het artikel

Commerciële kanalen zoals het consumentenplatform van PostNL (de app), PostWeb, retailondersteuning enzovoort maken gebruik van Amazon’s IaaS-diensten, zoals Amazon EC2

App heeft problemen en AWS heeft storing. Nee inderdaad dat wil niets zeggen maar het is wel erg toevallig.

Dat zal waarschijnlijk toeval zijn. De storing bij AWS was beperkt tot de us-east-1 region, PostNL heeft (vrijwel?) alles in de EU draaien.

Dat klopt niet, onder andere eu-west-1 heeft elke nieuwe service direct beschikbaar.

US-EAST-1 is inderdaad de goedkoopste regio, maar het verschil met b.v. Ierland is niet heel groot en zoals Jay-v ook al aangeeft krijgt Ierland 90% van de nieuwe diensten ook direct.

Overigens adviseren medewerkers van AWS eigenlijk altijd om us-east-1 niet als primaire regio te gebruiken als je failover naar een andere regio in je dienst wilt inbouwen. De reden daarvoor is heel simpel: us-east-1 is vele malen groter dan andere regio's. Dus als die plat gaat en iedereen ineens in b.v. us-east-2 extra machines wil starten gaan die heel snel op zijn. Andersom, van kleinere regio's naar us-east-1, is veel makkelijker op te vangen. Of je moet met AZ-gebonden reserved instances gaan werken, dat wil je echt niet.

PostNL heeft het al dagen zwaar. En echt heel goed werkt het al jaren niet 🙈 en wat zouden die in us-East moeten draaien?

Niets. PostNL bedient hoofdzakelijk de Nederlandse en Belgische markt, dus die zitten gewoon in Ierland of Frankfurt waarschijnlijk.

Ik denk dat die het eerder zwaar hebben door de pre-kerstactiviteiten. Het wordt dit jaar extreem druk qua post- en pakketbezorging. Daar valt bijna niet tegen op te schalen.

Bijzonder dat we in Europa ‘last’ hebben van een storing in de us-east regio! Want als je een goed design hebt, dan kunnen diensten in meerdere regio’s draaien en komt een klant uit Europa onder normale omstandigheden niet in is-east uit! De standaard is dat je us-west, us-east en eu-west combineert tot 1 geheel om zo storing op te vangen.

Ligt er ook wel weer aan wie/waar je klanten/bezoekers zijn he... Als dat primair uit de EU komt, is 't logischer multi-region HA diensten uit te smeren over de verschillende eu-west/central/east regions. En dat dan ook nog rekening houdend met AWS producten (WorkMail bijv) die niet in alle regions te krijgen zijn en/of over meerdere regio's uit te spreiden zijn.
Beetje kort door de bocht dus...

De merken die er last van hebben opereren op internationale schaal... doe je alleen Europa kan je design anders zijn. Maar die hebben dan ook nu geen last van de storing in us-east-1 😉

Toch wel. Quay had bijvoorbeeld ook een storing vanavond in eu.

Je kunt best door cascading en loadbalancing naar andere AZ’s issue krijgen doordat je scaling niet te ver mag doorschalen bijvoorbeeld. Als je daar ineens ook us load krijgt kan het zijn dat je overbelasting krijgt by design.

Ja, alles kan stuk, limieten zijn goed, maar met monitoring zou je dat (tijdig) moeten opmerken. Als je oorzaak een defect elders is, pas je de limiet aan. Maar een goed en fail-proof design blijft lastig. Maar het kan zeker!

Bedoel, Netflix draait er ook, gebruikt ongeveer alle diensten, maar hun design is dat er een hele AZ weg moet kunnen vallen. 😉 hikt zelden, totale stop kan ik me niet herinneren.

https://about.netflix.com...-great-viewing-experience
De providers lijken dus netflix wel te helpen. Dat scheelt dus al heel veel voor Netflix. Amazon heeft die luxe niet. Netflix levert maar 1 dienst en Amazon meerdere tegelijk aan meerdere bedrijven. Ook scheelt het dat Netflix natuurlijk minder data verwerkt. Die zijn eigenlijk alleen druk met uploaden. Dat maakt de storing kans natuurlijk ook wel iets kleiner en een storing makkelijker te verhelpen. Ook de data die Netflix verwerkt is "minder belangrijk". Mocht Netflix bijvoorbeeld de "mijn lijst" van vandaag kwijt raken en die van gisteren terug zetten denk ik dat weinig mensen dit zien als storing. Die zullen dan meet denken van "ik dacht dat ik die film(s) er al uitgehaald/erin gezet had maar blijkbaar toch niet".

Ik bedoel meer: Netflix draait op Amazon.
Is 1 van hun grootste klanten, natuurlijk met lokale caching bij de grotere providers.
Maar aanmelden en opstarten van je stream, dat wordt dus in AWS geregeld. Dat lukte volgens mij gister avond prima!

Aahhh sorry verkeerd begrepen. Ik dacht even dat je bedoelde dat netflix het zo goed had geregeld dat ze nooit storing hadden. Blijkbaar moet ik niet meer reageren voordat ik ga slapen

Sterker zelfs veel klanten willen hun data niet eens in de US vanwege alle extra regels omtrent data opslag

Quay.io had er last van wat gebruikt wordt voor het builden en deployen van containers

Dat komt doordat een aantal diensten binnen AWS zelf nog steeds afhankelijk zijn van de hoofdregio van AWS us-east-1, ook al maak jij als klant gebruik van dienst in een andere regio.

Nabu Casa home Assistant is ook affected.

Kreeg de hele avond al te horen van Google Home dat ie geen connectie met die service kon opzetten.

[Reactie gewijzigd door DutchHammer op 25 november 2020 21:18]

Ook Meetup is nog steeds down.
Was dus erg rustig op onze meetup van vanavond, omdat de Zoom link helaas alleen op de Meetup pagina stond.
Leermomentje voor volgende keer.

@AverageNL Ik weet dat het niet persé heel boeiend is, maar Flickr is al een aantal jaar niet meer van Yahoo.

Ik zie het inderdaad. Ik heb het aangepast, thanks

Teamviewer loopt er ook deels over denk ik nieuw apparaat krijg je normaal een mail om te bevestigen dat het OK is. Mail is na 15 minuten nog niet binnen.

Ik merkte dit vanmiddag al rond 16:00 uur op AWS us-east-1. EventBridge rules werden niet meer getriggerd.
Twee uur mijn eigen logica lopen debuggen totdat AWS een storing meldt 😞

Move to the cloud they said, it will be fun they said...

Want on-prem gaat er natuurlijk nooit iets stuk of mis...

Natuurlijk kan daar ook iets stuk of mis gaan. Maar nu heeft 1 bedrijf storing maar wel veel bedrijven er last van.

Hiermee wil ik trouwens niet zeggen dat de cloud slecht is. Ja ze hebben wel eens problemen maar als die paar keer die in de artikel de enigste keren dat er noemenswaardige storingen geweest zijn zou ik er geen probleem van maken. Deze enkele keren problemen wegen niet op tegen de voordelen voor de meeste bedrijven.

daarom is multicloud de oplossing als je dit soort scenarios wil voorkomen.. als je behalve op AWS ook op Azure and GPC draait dan ben je veel meer redundant..
Kost natuurlijk wel een hoop meer..

Je zou maar een Roomba binnen hebben gehad maar hem niet kunnen instellen omdat de app van iRobot eruit lig door AWS

Dan wacht je even? Of je zet hem neer, drukt op de knop en hij gaat zijn gang 👍