Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' 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

AWS-storing treft diensten als Alexa, Slack en BitBucket - update

Amazon Web Services heeft vrijdagavond te maken met een storing, die gevolgen heeft voor verschillende andere dienstverleners. Zo is Amazons eigen Alexa-dienst niet beschikbaar en ondervinden bijvoorbeeld Slack en BitBucket problemen.

Op zijn AWS-statuspagina meldt Amazon dat de problemen in Noord-Amerika spelen en te maken hebben met zijn Direct Connect-dienst. Daarmee is het voor bedrijven mogelijk om een verbinding op te zetten tussen een eigen datacenter en de AWS-servers. Het bedrijf meldt dat het aan een oplossing werkt en dat sommige verbindingen inactief zijn.

The Verge schrijft dat door de problemen de Alexa-spraakassistent niet meer functioneert op verschillende apparaten. Na het stellen van een vraag geeft de assistent aan dat er geen verbinding mogelijk is. Ook andere diensten lijken problemen te hebben. Atlassian-dienst BitBucket meldt dat de problemen inmiddels weer verminderen en dat deze het gevolg waren van problemen met AWS.

Communicatiedienst Slack schrijft op zijn statuspagina dat er meldingen zijn dat zijn dienst onbereikbaar is. Dit wijt het bedrijf aan problemen met 'een upstreamprovider'. GitHub ondervond vrijdag eveneens problemen, maar is inmiddels weer hersteld.

Update, 20:44: Kort na publicatie van dit bericht meldde Slack geen problemen meer te ondervinden.

Door Sander van Voorst

Nieuwsredacteur

02-03-2018 • 20:34

107 Linkedin Google+

Submitter: Xisuthros333

Reacties (107)

Wijzig sortering
Een storing bij publieke cloud diensten als AWS of Azure is zo zeldzaam dat het nieuws is. Dat is een testament van betrouwbaarheid van deze platformen. Hoeveel moet je zelf regelen om op dat beschikbaarheidsniveau te opereren? En je weet dat de best en brightest - die je zelf nooit kunt betalen - daar zitten, hard te werken volgens geoefende procedures om de boel weer aan de praat te krijgen.

Maar dat is ook alle zekerheid die je hebt. Je bent als publieke cloud klant een nummer. Uiteindelijk ben je puntje-bij-paaltje nog altijd zelf verantwoordelijk. Of het nu gaat om je bedrijf of je eigen huis (de kachel werkt niet want internet is stuk).

En die soms extreme afhankelijkheid zet me soms wel aan het denken.
En je vergeet dat een cloudprivider niet per definitie goedkoper is.

Je kan het vergelijken met Lego. Als je een vierkante bak wil bouwen kan dat prima met Duplo waar maar 10 verschillende blokken van bestaan. Wil je een bak maken van technisch Lego dan kan dat ook alleen is technisch Lego veel duurder en zal het resultaat verfijnder zijn.

Met Duplo zijn de mogelijkheden beperkt met technisch Lego eindeloos. Maar wat als je alleen maar een bakje nodig hebt?
Deze vergelijking gaat echt mank. Draai je linux dan draai je linux als VPS.

En zoals hieronder, eigen hosting is vaak goedkoper en biedt meer flexibilliteit in je setup.
Wanneer het alleen om hosting gaat heb je gelijk. Maar wanneer automatische schaalbaarheid gaat spelen, kun je met VPS hosting niet meer af.
Tuurlijk wel, je eigen VPS platform. We hebben het hier over selfhosted he, AWS, dat zijn VPS-en in de "cloud" .
AWS EC2 zijn "VPS-en in de cloud". En load balancers. en System Config Management.
Daarnaast heb je:
-S3
-Workspaces
-Route53
-EFS
-SES
-SQS
-SNS
-RDS
-DMS
-...

En die services werken allemaal zo goed als naadloos met elkaar samen.
edit @hieronderzo : Dat AWS wel wat meer is dan enkel wat vmmetjes

[Reactie gewijzigd door Tokkes op 4 maart 2018 01:34]

Ja dus, wat veranderd dat aan mijn statement ? Al hun services zijn dat ook.
Ik zie niet in hoe je een flexibele scalability gaat halen met eigen VPS platforms op een kosten-effectieve manier op die wijze. Alleen dat is interessant in de cloud. De rest is beter af met een VPS op wat voor wijze dan ook.
En jij weet niet wat een cloud dienst is...
een "eigen" cloud - is die dan ook compliant met alle standaarden als ISO27001 en anderen? Is jouw datacenter zodanig fysiek beveiligd dat zelfs engineers slechts tijdelijk toegang hebben tot de servers? Kan jij ook in seconden je infrastructuur migreren naar pakweg singapore? Wat is jouw RPO/RTO als je aan disaster recovery moet doen als je fysieke bak het laat afweten? Hoeveel kost het je om infra op te zetten in een nieuwe regio/availability zone, in tijd en geld? Die tijd om op 'server niveau' (bedoel je hypervisor niveau?) onderhoud te gaan plegen en dat te configeren en instellen is ook 'geld' - want iemand moet daar tijd in steken en da's ook niet gratis. Tijd en geld die je niet in andere dingen kan steken.
Alles wat je vraagt kan mijn omgeving en is zo beveiligd.

Ja geloof het of niet, ik ga me er niet druk om maken. Ik zie aleen veel bedrijven die de knowledge gewoon niet hebben en het dan maar gooien op een tijds/geld kwestie, en de uitvoerende werknemers des te meer omdat ze de kansen niet krijgen of het zelf gewoon niet kunnen. Jammer.
Die kennis heb jij duidelijk niet. Ten eerste is cloud niet per definitie FOSS. Sterker nog: vaker niet dan wel.

Verder heb ik het niet over serverniveau. Jij beperkt je tot VPS, niet ik. Redeneren met de stok gaat je goed af.

Voor een schaalbare dienst waarbij de effective usage onbekend is of fluctueert, ben je altijd beter af met een cloudoplossing. Daar waar het gebruik altijd constant is, is een VPS veel kosteneffectiever.

Dat dat er bij jou niet in gaat, heeft alles te maken met je kennisgebrek op dit vakgebied. Dan kun je anderen belachelijk proberen te maken, maar je erkent dan wel je domheid.
Je roept allemaal tegenstrijdige zaken, cloud "just someone else his computer" en hoe of wat je daarop doet is dan ook wat de service bepaald en welke software je er voor gebuikt is aan de aanbieder. Ik beperk me tot niets, dat is juist mijn kracht.

Het probleem van de cloudresellers is dat ze zelf gewoon de adem niet hebben om het zelf goed te doen en door mee te liften op iemand anders zijn dienst hun klant nog afhankelijker willen maken door er zelf aan te verdienen.

Het is exact hetzelfde als de webhostingbedrijven van 15 jaar geleden met een resellerpakket of een dedicated server met Direcamin erop.

En tja... soms wil je verder geen kennis nemen van bedrijven die de boel gewoon belazeren, ga er maar eens met ICTrecht over praten, die kunnen je er wel een beeld over geven inmiddels.
Misschien moet je naast je kennis ook je begrijpend lezen een keer oppoetsen. Ik roep nergens dat cloud "just someone else his computer" is. Sterker nog: cloud is geen VM die ergens anders draait, dat is VPS! Jij komt ineens met loze kreten zoals FOSS om de hoek. Klok en klepel. Dat je je tot niks beperkt, heb ik al gemerkt in je argumentatie :+

Je haalt er ineens resellers bij, geen idee waar het vandaan komt, maar mijn reactie erop: resellers verkopen altijd iets wat ze niet zelf gemaakt hebben. Dat zit in de naam. Ze halen geld uit de marge en evt. support naderhand (of bijkomende dienstverlening).

Ook trek je hosting bedrijven erbij met dedicated servers: ja dat is belazeren, ontken ik niet, maar het onderwerp werd ook niet eerder aangesneden...

Ik deel je mening 100% dat er zo verschrikkelijk veel toko's de boel belazeren, maar dat is buiten IT land niet anders! En als je het toppunt van belazeren wilt weten en toch nog keihard wil lachen na onze nutteloze discussie, zoek dan vooral de filmpjes even op van Rianne van Rijbroek. Dan kun je pas echt lachen. Maar die doos wordt wel gevraagd en geeft een (nutteloos) boek uit.
En zoals hieronder, eigen hosting is vaak goedkoper en biedt meer flexibilliteit in je setup.
Dit hoor ik wel meer maar bij veel vergelijkingen worden er verborgen kosten aan de eigen hosting kant en waarde aan de cloud kant vergeten.
Noem ze eens op dan ? Ik ben echt goedkoper uit hoor met veel VM's.
Je betaalt dan ook niet enkel voor 'de server'.

Je betaalt daar ook nog voor je data redundantie, verbindingen zijn redundant, het schalen, de interconnectiviteit tussen verschillende regios, ...

Als de cloud echt zo oninteressant was, dan haalde mijn werkgever geen miljoenen per kwartaal binnen om die dingen te resellen.
Wat denk je dat ik met zoveel servers niet alles HA en over meerdere DC's draai ? Het is echt peanuts qua kosten hoor. Dat jullie eventueel in commerciele datacenters zitten die hoge prijzen handteren is gewoon je markt niet goed kennen.

Success met resellen, er is dan ook vast VEEL "kennis" aanwezig. Er is veel te veel van hetzelfde in die markt dus ik denk dat je wat overdrijft ;)

[Reactie gewijzigd door Tivoler op 3 maart 2018 15:11]

nee, wij zitten *volledig* in de (public) cloud ;) We hebben zelf geen fysieke servers staan in geen enkel datacentre, geen enkel kantoor.
Wij doen aan enablement en managed operations, evenals het resellen van AWS en GCP en Azure diensten.

Genoeg bedrijven die het op een of andere manier toch financieel aantrekkelijker vinden om tussen de 5k en 150k/maand uit te geven aan cloud services dan het fysiek zelf te draaien.

en het is niet alleen start-ups. Audi's on Demand applicatie draait volledig in AWS. De weer-app van The Met Office idem. Economist, Belron/Carglass. Netflix heeft infra in AWS. Apple gebruikt de public cloud ook.

De public cloud geeft ons en de klanten flexibiliteit die je niet hebt bij fysieke hardware. Retail stores schalen hun webwinkel infrastructuur even 4 tot zelfs 10 voudig voor dagen als black Friday / Boxing Day/ ..... Doe je dat ook met je HA opstelling over meerdere DC's? Want dat betekent dan dat je heel wat extra resources hebt die hard gezegd 48 weken in het jaar niets aan het opleveren zijn. En het is niet dat de afschrijving van die hardware/resources even stopt gedurende die downtime. Daarbij heb je ook firewalls en routers en dhcp/dns servers te onderhouden en in te stellen, support op betalen, ... . Dat zit allemaal al in je AWS prijs bij.

Als je de cloud ziet als "enkel" een virtueel datacentre waar je wat VM's neerplempt, dan is de cloud inderdaad misschien niet echt iets voor jou. De public cloudservices van AWS, Azure en Google zijn wel wat meer dan 'gewoon' wat VM'tjes draaien. Uiteraard start bijna elke migratie naar de cloud met een lift-and-shift van bestaande infrastructuur, maar daarna dien je al je services en applicaties 'cloud-aware' te maken.

acloud.guru is een volledig serverless website. Er zit wat static website en mediafiles in S3, AngularJS roept Lambdafuncties aan, authenticatie met 0Auth, wat DynamoDB en klaar.
Na een aantal jaar is A Cloud Guru nog maar pas uit free tier op AWS en uitgerekend kost het hen eurocentjes als jij een volledige online course doorkijkt. Dat is inc. storage, lambda time, bandbreedte, ...

Moet jij eens proberen een website met een paar duizenden members die videos streamen voor een paar cent per dag online te houden met je fysieke hardware. En daarnaast automatisch schaalt.

[Reactie gewijzigd door Tokkes op 4 maart 2018 01:50]

"Zoiets doe ik vriend..."
Hoe?
Als dat zo het geval was hadden jullie de infrastructuur zelf wel opgebouwd, kijk naar het Dropbox voorbeeld.

Geen bedrijf die op dergelijke basis reselling wil doen of je wil gewoon afhankelijk zijn.
Ja Tivoler, kijk hoe groot AWS en GCE en Azure zijn... je kan toch niet ontkennen dat het populaire oplossingen zijn?

Je zal vast gelijk hebben aangaande je eigen situatie, maar hier ben je appels met peren aan het vergelijken. Het probleem dat jij dus oplost is niet hetzelfde als de wens die een Cloud provider klant heeft. Die ken jij blijkbaar nog niet..
Nee ik ontken het ook niet, ik vind het juist heel zorgelijk!

Het probleem is dat de (re)sellers appels met peren vergelijken en de ontwetende klant hier vaak niet heel veel beter van wordt @ the end.

Als mensen mij naar de "cloud" vragen voor hun applicatie raad ik ze het zeker af, reden voldoende gegeven.
Als mensen mij naar de "cloud" vragen voor hun applicatie raad ik ze het zeker af, reden voldoende gegeven.
Die mensen zijn er genoeg, en dat antwoord ik ook regelmatig.
Maar ... "zeker afraden" ? Nee dan wil je dus niet weten wat het echte probleem is. Wat duidelijk is te lezen uit je reacties. De abstractie die cloud oplossingen bieden aan organisaties is niet aan jou besteed, want
de implementatie en beheer doe je liever zelf. Niets mis mee! Doe ik vaak ook graag zelf als het kan. Maar dat is niet noodzakelijk de meest verstandige stap voor een organisatie.
Als de de plussen en minnen goed kunt verduidelijken kan het vaak juist wel de verstandige stap zijn.

Het "probleem" is dat "de Cloud" als "oplossing" wordt gezien voor ieder "probleem" dat er eigenlijk niet is en niet gaat komen. Het is meer een "common feeling" voor velen, "wij" zijn in de "Cloud".
Het "probleem" is dat "de Cloud" als "oplossing" wordt gezien voor ieder "probleem" dat er eigenlijk niet is en niet gaat komen. Het is meer een "common feeling" voor velen, "wij" zijn in de "Cloud".
Klopt. Maar het is dus ook een gewilde oplossing voor echte problemen.

Als jij services op servers in datacenter infrastructuur beheert voor anderen zodat die jouw kennis/ervaring niet zelf moeten inlijven, dan zou je "platform" een cloud kunnen noemen. Marketing helaas, maar wel duidelijk voor wie niet wil weten hoe ingewikkeld het is.
Als je start met nul betalende klaten is cloud uiteraard goedkoper.
Draai je één server, dan heb je gelijk. Draai je er 1000 24x7 dan hebben we een ander verhaal. Betaal eens 10 man personeel in drie shiften de klok rond enkel voor permanente ondersteuning, én hun opleidingen én hun vakantiedagen, .... We spreken over minimaal factor 3 (Gartner)
Hoezo ? Alles is automated, I draai alles alone, for years en heb backup die op de hoogte is.
Wat is er dan precies flexibeler? Op AWS heb je diensten die toegespitst zijn op 1 ding net 99,99% uptime garantie zoals bijvoorbeeld S3, een wereldwijd CDN als CloudFront, serverless architecture met Lambda en dan zijn er nog tientallen diensten. Heb je iets heel specifieke nodig kun je gewoon EC2 instance spawnen met eigen software en anders ECS gebruiken met containers.

Je bent of werkzaam voor de concurrent van AWS of een miljardenbedrijf en anders zou ik denken dat je enorm naïef ent at je denkt dit zelf te kunnen evenaren.
Dropbox heeft bijvoorbeeld 75 miljoen kunnen besparen door eigen infra te gebruiken. Alleen Europese klanten worden nog door AWS S3 bedient: https://www.geekwire.com/...ding-tech-infrastructure/
Maar zo'n besparing kan pas als je groot genoeg bent. Voordat je zoveel betalende klanten hebt is iets als aws goedkoper.
Het hangt ook van de complexiteit van je infrastructuur en stacks af. Ik kan me voorstellen dat een eigen datacenter runnen makkelijker is voor een storage provider dan voor een enterprise verzekeraar.
Voor infrastructuur is voor mij de vuistregel dat je cloud als 'reservebank' moet behandelen.
- Wat je 24x7 nodig hebt zelf bouwen. Eventueel beheer ervan uitbesteden als je de kennis niet hebt.
- Alles wat je tijdelijk nodig hebt (alles boven je baseline) betrek je uit de cloud.
Hybride cloud dus..

Voor SaaS is het even anders. Het valt niet mee om het gemak van O365 kosten-effectief in het klein na te bouwen.
Wat is de schaal, welke groei verwacht je, verwacht je ook krimping? werk je met pieken en dalen?

Je 24/7 zelf bouwen vind ik persoonlijk nog kwalijker in je voorbeeld, wat is je uptime SLA? Niet iedereen kan dit zelf bouwen, nog minder kunnen dit zelf onderhouden. Waarom zou je HW kopen als je het beheer uitbesteed? Wie wil jouw bouwsels zomaar in beheer nemen? Bij mij mag je je alvast aan een stevige due diligence verwachten met een 24/7 wens, want dan moet ik een 24/7 team achter de hand houden, hier hangt een kostenplaatje aan....

Oh BTW: hybride 24/7 is altijd duurst want je gaat veel uitgeven aan een zeer dure basis infra on prem, en daarboven nog cloud leggen zorgt er voor dat je je absis infra niet maximaal benut.

In wat ik zie in mijn dagelijkse job is on prem enkel goedkoper als je een grote schaal hebt, of niet de SLA's die cloud kan bieden nodig hebt. toch ga ik dit nooit als vuistregel nemen, want again, it all depends..
Ik vergelijk het altijd met een auto kopen en een auto huren..
Heb je een stable workload dan is private cloud goedkoper, maar fluctueert je workload en kunnen je applicaties dynamisch scalen dan kan public cloud weer een stuk voordeliger zijn.
Zelf doe ik pre-sales voor hybride cloud, welke je in theorie best of both worlds kan geven..
Ikzelf verwacht eigenlijk dat er niet zo heel veel knappe koppen rondlopen. Dagelijks serverbeheer in grote serverparken is niet bepaald uitdagend.

Het ontwerpen van software om dat zo efficient mogelijk te doen, dat is wel interessant, maar daarna, wil je dat zo'n park met zo min mogelijk personeel van het laagst mogelijke nivo de dagelijkse rompslomp uitvoeren.

Kosten van hardware en stroomvoorziening zijn al hoog genoeg, dan wil je maar 1 of 2 slimmerikken in dienst hebben om de basis bij te houden en assistentie te verlenen aan een programmeer-toko om functionaliteiten uit te breiden. Doe je dat allemaal zelf, dan lijkt het mij veel te lang te duren voordat je uberhaupt winst draait.
Cloudproviders hebben in iedere vorm teveel macht t.o.v. klant.

Dat is niet goed.
Nuja, je kunt vaak relatief eenvoudig wisselen van clouddienst, of zelf een server hosten.
In dat opzicht ben je zelf vrij en staat de cloudprovider machteloos?
Voor iaas geldt dat inderdaad voor 90%. Amazon host inmiddels zelfs vmware infra zodat je bijna helemaal makkelijk kan migreren of verhuizen later naar een andere Cloud provider. Hoe hoger je in de Cloud stack komt (paas, saas ed) hoe groter het risico op vendor lockin. Bv serverless computing waarbij code draait bij de Cloud provider dan kan deze code behoorlijk cloudspecifiek worden.
serverless computing? wat is dat nou weer voor term? cloud provider heeft ook servers staan...
Een mooi startpunt om je in de cloud te verdiepen op een regenachtige of besneeuwde zaterdag http://www.thecloudtutorial.com
Serverless computing betekent dat je niet betaalt voor een vps of een container in de cloud, maar dat je software een methode aanroept die tijdelijk in de cloud wordt uitgevoerd, waarna het geheel weer down gaat. Zo betaal je letterlijk voor wat je gebruikt. Het nadeel is wel dat, als je dezelfde methode op een moment meerdere keren aanroept, je dus niet een keer betaalt maar het aantal keren dat je de methode hebt aangeroepen. Dat is het verdienmodel, heb ik begrepen.

Info: https://martinfowler.com/articles/serverless.html
Serverless computing betekent zonder dat je een vm draait. Azure webapps bijvoorbeeld, Of Azure functions.
Azure webapps bijvoorbeeld, Of Azure functions.
Dus gewoon een webhosting pakket. Wat draait op servers.

[Reactie gewijzigd door The Zep Man op 3 maart 2018 09:19]

Dat is gewoon cloud aka client server.
Serverless is zonder servers te beheren. Dus allemaal managed services., maar geen VM's/servers te configureren/beheren/onderhouden.
Check dan OpenFaaS die je in een willekeurig gehoste Kubernetes cluster kunt draaien.

Sowieso als je kubernetes gebruikt heb je meer flexibiliteit waar je je oplossing gaat hosten.
Dat geldt vooral voor AWS en dan met name de oudere services zoals SQS, Dynamo. Als je kijkt naar bijvoorbeeld Google Dataflow, dan praat je gewoon tegen Apache Beam APIs.
De laatste 4 jaar halen wij op al onze diensten een hogere uptime dan alle grote cloudproviders (AWS/Azure/etc.). Alles draait redundant op 2 plekken, verder helemaal geen spannende dingen. We hebben in het afgelopen halfjaar met O365 al meer downtime gehad dan in 10 jaar tijd on-premise Exchange. Cloud ...
En hoeveel kost het om een hogere on-prem availability te realiseren?
In vergelijking met alles in de cloud hosten ongeveer 4 x zo goedkoop.
Maar je redundante infra kost je amper iets als die niet hoeft te draaien in de cloud? Daarentegen heb je de aanschaf en afschrijving van fysieke hardware... die laatste stopt niet.

En gebruik je dan de cloud wel naar haar volle potentieel?
Als het niet hoeft te draaien ben je in principe niet hot standby redundant zoals we dat nu wel zijn. Je moet wel appels met appels vergelijken. Als er nu 1 DC klatsboem down gaat zijn we, afhankelijk van welke dienst en hoe HA die moet zijn, binnen enkele seconden tot enkele minuten weer online. Aanschaf en afschrijving van fysieke hardware is echt nihil vergeleken met de maandelijkse cloudkosten.

Voor onze bedrijfstak is de cloud echt gewoon niet geschikt, als je tenminste niet veel meer geld wilt gaan uitgeven.
Waarom waren jullie in staat om deze hoge beschikbaarheid te bereiken?
Redundantie op server en storagegebied, virtualisatie gebruiken en slimme dingen doen zoals geen duur pakket gebruiken om failovers te doen maar zelf scripten.
Jij hebt 10 jaar onprem exchange met virtualisatie en SAN.

Dan heb je enorm dure mailboxen.
Je moet echt ophouden met dingen baseren op een verouderd profiel ;)
Grappig dat is waar ik ook in geloof en al deels heb bewezen. Het probleem is dat ‘zelf-bouw’ vaak verkeerd wordt gepakt: ongestructureerd zonder afspraken en processen, zonder een goed plan, ontwerp. En dan hopen mensen dat je in de publieke cloud al die problemen niet meer hebt. Terwijl juist met publieke cloud je dat helemaal ook moet ‘ownen’.
Sterker nog, dan is je ontwerp en beheer daarvan nog veel belangrijker. Elke beslissing die je in de cloud neemt kost geld om te veranderen terwijl on premise er vaak nog wel iets te regelen valt (hooguit wat overuurtjes)
dus jij haal 5 x 9 inc patchen van software en hardware.

Daar geloof ik niks van. Als ik naar alle klanten kijk waar ik ben geweest afgelopen Jaren komt er bijna niemand boven de 3x 9 effectief ongelogen.
Dat heb ik niet gezegd. Als ik kijk naar downtime van alles wat wij in de cloud hebben draaien, hebben wij het afgelopen jaar 2 dagen ongeplande downtime gehad. Onze eigen diensten hadden een ongeplande downtime van hooguit enkele uren gecombineerd. Dat hoef je niet te geloven, maar toch Is het zo.
Lol zegt de man met zijn Eigen website down op een VPS hoster :)
Die website is al jaren bewust down en draait ook niet bij een vps. Volgende keer beter je best doen.
Je argumenteert iets dat niet gezegd wordt. De discussie gaat over afhankelijkheid en uptime, niet over stoer doen. Je wilt gewoon hoge uptime en hij geeft aan dat het niet uiterst ingewikkeld hoeft te zijn om lokaal (met externe redundancies) een minstens even goede uptime te halen als de bekende cloud diensten. Zegt zelfs dat het niet zo spannend is..
Juist, dank je.
let wel kleine storingen die alleen 1 tot een paar kleine afnemers treft zullen hier niet als nieuwsberricht verschijnen. daarnaast heb je als het buiten de deur staat altijd nog te maken met tussenpartijen zoals isp's welke ook verstoringen kunnen hebben. neemt natuurlijk niet weg dat dit soort aws platformen mooie oplossingen zijn die nog een lange toekomst zullen hebben.
Een storing bij publieke cloud diensten als AWS of Azure is zo zeldzaam dat het nieuws is. Dat is een testament van betrouwbaarheid van deze platformen. Hoeveel moet je zelf regelen om op dat beschikbaarheidsniveau te opereren?
Ik zie dat toch anders. In mijn ogen zijn zelfs AWS en Azure niet in staat om hun platform echt betrouwbaar te maken. Ondanks alle investeringen blijft het af en toe mis gaan. Daarbij moeten we wel ook onderscheid maken tussen het platform en de VM's en applicaties die er op leven. Want
Uiteindelijk ben je puntje-bij-paaltje nog altijd zelf verantwoordelijk.
Spijker op de kop. Het platform als geheel is behoorlijk betrouwbaar, maar dat geldt niet voor de individuele VM's die er op draaien. Als gebruiker wordt je zelf geacht om je applicaties zo te bouwen dat het uitvallen van een enkele VM geen gevolgen heeft.
Dat is niet zo heel anders dan wanneer je een dedicated server huurt in drie, onafhankelijke, traditionele datacenters.

Applicaties bouwen die echt high-available zijn is enorm moeilijk. Dit voorval laat zien dat zelfs reuzen als Alexa, Slack en BitBucket het niet lukt. Als kleine afnemer zal het je waarschijnlijk dus ook niet lukken.

Ik zeg niet dat er geen rol is voor de cloud, maar het is ook geen tovermiddel.
Helemaal met je eens!
Cloud vereist ook veel kennis en expertise om hogel beschikbaarheird en goede rto/rpo te realiseren.

Saas da’s vaak wat makkelijker maar ook daarimheen zit nog zoveel governance als je het goed en veilig wilt doen.
Stel dat je als bedrijf zijnde draait op AWS, en er is een storing bij AWS, is het dan mogelijk om het verkeer om te leiden naar een backup (Azure of local hosting)? Dat AWS storing heeft, lees je niet vaak. Zoals ik het in een andere post heb gezet, als zij in hun SLA zetten wat hun downtimes eventueel kunnen zijn (verwachte en onverwachte downtimes), dan is er toch niks aan de hand?

Als er iets down is, is het wel vervelend, maar nu er steeds meer mensen toegang krijgen tot het internet, kunnen de services niet altijd up blijven. Niet alleen de onderhoud speelt een rol, ook de hoeveelheid pageviews en de stroming van het verkeer speelt een rol. Vooral nu er dus ook DDOS'sen zijn met een grootte van 1.3Tbit/s. Dat is iets meer dan 1.5GB per seconde!

Voordeel van de cloud computing vind ik wel dat je vrijwel alles virtueel hebt (vaker snapshots) en dat je dus ook minder mensen nodig hebt die op het systeem gaan letten, want als het eenmaal uit ligt, is het boven je macht :P
Dit is waarom Amazon Availabillity zones heeft en zelfs meerdere regios.
Als jouw applicatie/bedrijf dermate kritische dingen uitvoerd kun je met gemak zorgen voor geografische redundantie.
En moet je eens kijken wat dat kost... kan je beter een eigen dual datacenter gebruiken bij een isp / telco. Is leuk die availability zones maar als je je failover site (AZ) actief wil maken en er zijn geen resources? Zonder reserved resources, die veel kosten, heb je geen garantie dat die availability zone al je services kan booten bij een failure van je main AZ.

[Reactie gewijzigd door InsanelyHack op 3 maart 2018 01:40]

Inderdaad en als er al overgeschakeld kan worden, dan is er een grotere kans op latency problemen. En dat soort problemen maakt je dag echt miserabel...kan je er bijna net zo goed helemaal uitliggen.

Veel technologien van de cloud zijn inderdaad erg interessant voor bedrijven, maar SLA's met de Cloud provider betekenen weinig als je daardoor je software niet op tijd af kunt leveren bij je klant. Die gaat misschien een keer mee in dat hele verhaal, maar of ze dat een tweede keer doen...

Een hybride vorm waar je een deel zelf host en de minst kritieke zaken uitbesteed aan een cloud provider lijkt mij voor de meeste bedrijven de meest gunstige oplossing als zij de kosten, baten en risico's tegenover elkaar zetten.

Zelf ben ik werkzaam in een omgeving waar het absoluut "verboten!" is om data buiten de EU te behandelen. De meeste bedrijven in deze branch zien zelfs graag dat hun data de NL landsgrenzen niet overgaat, omdat geen enkele Cloud provider garandeert dat hun data de EU/NL nooit zal verlaten of word ingezien door partijen buiten de EU/NL. Toko's als Microsoft Azure beloven dat niet te doen, maar beloven is geen garantie.
Stel dat je als bedrijf zijnde draait op AWS, en er is een storing bij AWS, is het dan mogelijk om het verkeer om te leiden naar een backup (Azure of local hosting)?
Dat kan, maar is redelijk onbetaalbaar. Daarnaast moet je dan op applicatieniveau gaan zorgen dat de boel redundant kan draaien (active/passive of hot standby). Er zitten nogal wat haken en ogen aan dus nemen de meeste bedrijven het voor lief dat de boel er een aantal uur per jaar uitligt.
Voordeel van de cloud computing vind ik wel dat je vrijwel alles virtueel hebt (vaker snapshots) en dat je dus ook minder mensen nodig hebt die op het systeem gaan letten, want als het eenmaal uit ligt, is het boven je macht :P
Dat slaat nergens op :)
[...]

Dat kan, maar is redelijk onbetaalbaar. Daarnaast moet je dan op applicatieniveau gaan zorgen dat de boel redundant kan draaien (active/passive of hot standby). Er zitten nogal wat haken en ogen aan dus nemen de meeste bedrijven het voor lief dat de boel er een aantal uur per jaar uitligt.


[...]

Dat slaat nergens op :)
Ik kan je beantwoorden met je eigen quote ;)

Als het onbetaalbaar is doe je iets verkeerd want het is echt niet duurder dan in prem met alles wat er bij komt kijken.

Dat gezegd te hebben is cloud niet altijd het antwoord, maar er zijn voldoende voorbeelden waar het elkaar kan complimenteren en je bijvoorbeeld hybrid draait.
Failover van AWS naar Azure en andersom is ook prima mogelijk en als je het goed inricht is zone rudundant ook meer dan prima.
Aangezien ik net een business case heb geschreven hierover kan ik melden dat voor ons geval de cloud ongeveer 4 x zo duur was, zelfs "met alles erbij".

Als jij een SQL cluster hebt draaien in Azure en er gebeurt iets met dat datacenter zul je toch je omgeving moeten vertellen dat je SCCM omgeving nu naar een andere SQL server moet wijzen. Of hot standby draaien met realtime sync (voor zover mogelijk). Kosten stijgen daarmee ook weer.

Grote voordeel van cloud is flexibiliteit. Morgen kun je er 500 servers bij hebben als je app ineens app van de dag is in de App Store, of als je elke maand de 20e enorm veel nummers moet crunchen. Vior dat soort dingen krijg je de business case qua zelf doen inderdaad nooit rond. Voor al het andere, I beg to differ.
Het schijnt nu al opgelost te zijn... om ~20:37 (NL) staat op de Slack status pagina.

Overigens wel strak van Slack dat hun updates altijd om xx:x7 waren, op één na!

[Reactie gewijzigd door D0phoofd op 2 maart 2018 20:43]

We're afraid we spoke too soon regarding connectivity issues due to an issue with an upstream provider. Some users are unable to connect and we're monitoring with the provider. Our apologies for the disruption, we'll continue to update here.

11:48 AM PST・See in your timezone
En toch weer niet.
Overigens wel strak van Slack dat hun updates altijd om xx:x7 waren, op één na!
Toen ik op de ESD bij KPN werkte en er hoge prio tickets binnenkwamen waren we verantwoordelijk voor het rapporteren van de status elk uur. Dit lijkt hier ook gewoon het geval te zijn. Niks spannends dus.
Wat ik mij nu afvraag is of het ook impact op hun winkel gehad heeft (de supermarkt). Dat moet toch haast wel want ik geloof dat het allemaal cloud processing is. Wat zou daar het fallback scenario zijn aangezien je niet zo maar naar buiten kunt lopen.
Dat een klein deel van Amazon haar diensten problemen heeft, betekend niet dat de supermarkt er ook last van heeft gehad.

Het gedeelte dat storingen heeft is slechts beperkt, het is niet dat de hele amazon cloud plat ligt ;)

Zo te zien op de status pagina, gaat het alleen maar om:
AWS Internet Connectivity (N. Virginia)
AWS Direct Connect (N. Virginia)

[Reactie gewijzigd door mmjjb op 3 maart 2018 02:33]

Eind van de ochtend en vanavond had ik last van toen ik een coursera course deed. Lag dus niet aan mijn eigen verbinding.
Grote instellingen draaien mission critical systemen nog niet op IAAS, omdat men daar nog wat huiverig voor is. Dit is koren op de ouderwetse-cultuur-molen om on-prem te blijven met de backbone, i.p.v. vooruit te kijken en naar een hybrid model te werken. Hoeveel jaar zal het nog duren voordat de grote verzekeraars, banken, ziekenhuizen (laat staan de overheid) echt hybrid infra draaien? Ik schat in minstens 15 jaar, als de langlopende contracten met huidige infraboeren 2 x zijn verlengd en men daar geen vruchten van heeft geplukt. Tegelijkertijd lanceert iedereen en zijn moeder een start-up om een stukje v/d taart te vreten, op een gegeven moment zit daar een succesmodel tussen dat aan de poten begint te zagen.. dan is 15 jaar echt te lang.
Hoeveel jaar zal het nog duren voordat de grote verzekeraars, banken, ziekenhuizen (laat staan de overheid) echt hybrid infra draaien?
Gebeurt al jaren... of dacht je serieus dat (online) bankieren zonder Akamai DDoS & CDNs, actuariaten zonder large scale Hadoop en datalakes, of lokale overheden zonder iets als O365 Exchange Online werken?
Gek genoeg zorgt die hele beweging van on-premise naar IaaS/PaaS vendors als AWS, Azure, BlueMix er juist voor dat er weer veel meer in-house wordt gedaan in plaats van dikke service contracten met full stack dienstverleners.
Ook bij de grote financiële instellingen gebeurd dat al lang al kan ik je vertellen.
Daar is echt geen 15 jaar voor nodig 8)7
Communicatiedienst Slack schrijft op zijn statuspagina dat er meldingen zijn dat zijn dienst onbereikbaar is.
Lekker rustig doorgewerkt vandaag! Bedankt! :>
Slashdot is al een paar dagen offline, heeft dat er ook mee te maken?
Ook een beetje aan het afkicken??
;-)
Gister 2 uur last gehad dat alexa niet wou luisteren, meer niet.
Wijze les: Multi-AZ is goed, multi-region is beter.
Dat ligt er maar weer aan. Als jouw clients allemaal in de buurt van één region zitten dan is de latency naar een Multi AZ in diezelfde region optimaler dan wanneer jouw clients bij een failover worden geredirect naar een andere region (bv van Euro -> North America). Ieder voordeel heeft zijn nadeel. (Johan Cruijff ✝)

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True