Názory k článku
AWS hlásí výpadek v jednom z datacenter, řada služeb je nedostupná

Kéž by se z toho lidé a firmy poučili a hostovali své aplikace buď na vlastní infrastruktuře nebo alespoň na evropské či české. Momentálně totiž cpou peníze megakorporaci, pro kterou je většina jejích zákazníků naprosto bezvýznamných, takže na ně nikdo nebere žádné ohledy, a když se něco stane, tak jsou naprosto bezmocní.

Cloud neexistuje – jen počítače cizích lidí.

To je to, oni to maji jen v EU ;-) dokonce rikas, kde to mas, ale CIA chce smirovat a tak vse fyzluji z USA - data asi nereplikuji ale US servery sahaji na EU data ... jak jinak si vysvtlit, ze jeden region v USA ovlivnuje DC v EU a ne treba v Cine ;-) - protoze Cinsky cloud nesmi sahat do USA - proto je Cinsky AWS i Azure zcela jiny produkt, zvlastni autentifikace nekompatibili se zbytkem sveta, ale muzete si to do Ciny replikovat

Za vsim hledej penize.

Když jsem si porovnával cloud a hostování na vlastní infrastruktuře, tak pro většinu scénářů vyšel cloud x-násobně dražší.

A zapocital si cenu lidi co se o to staraji? Ja jsem zaryty odpurce cmoudu, a pokud me vlastni hosting stoji v ramci teamu max par jednotek clovekohodin tydne tak je to mega levnejsi nez cokoliv co se da koupit. I bych rekl ze bezpecnejsi a spolehlivejsi.

V okamziku kdy na to myusis mit dedikovnaeho clvoeka, nedejbzoe team, coz od jiste velikosti je afaik nezbytne, tak se ty krivky protnou a je po srande. Kvalita pak zalezi na tom tvem teamu, ktery muz ebyt lepsi, a nebo horsi nez to co dostanes v amazonim prumeru....

Není to spíš tak, že od jisté velikosti je, co se týče nároků na práci těch lidi, úplně jedno, jestli ten provisioning to vytočí v lokálním DC nebo úplně někde jinde?

Takže kromě člobrdy, co jednou za 5 let vymění HW popř udělá nějaké RMA (ten je navíc, vs člověka, co má na starosti cloudy, optimalizace mezi nimi etc.) můžeme z obou stran nerovnice ty lidi zase odečíst, ne?

20. 10. 2025, 15:21 editováno autorem komentáře

A to si jako myslis, ze na cloud nepotrebujes mit lidi ;-) a ted se podrz, pokud mas linuy, jsou ti lidi drazsi, pokud mas windows, tak clovek na cloud je drazsi nez win admin ;-)

Cloud se sam nespravuje, nepotrebujes jen lidi na HW - a velka firma je stejne ma, nebot jsou lokalni a stredni hold necha tyhle veci delat i drazsi lidi, neb je to parkrat za mesic, nekdy za rok.

Treba mi si vse instalujem sami, ale v ramci DC mame v cene facility - takze treba vymenu naseho kabelu udelaji sami, prace na HW dela vendor i bez nas.

Ja to reknu takhle, pro jeden projekt potrebovali nutne NetApp Metro cluster - dokud tam meli 400GB tak se vyplatilo to pronajmout - IO se nepocitalo, v momente kdy to narostlo na 200TB tak jsme nakupem vlastniho reseni setrili 30k euro / mesic - za 4 mesice se nam zaplatil vlastni full flash - tedy inline deduplikace i komprese a misto rozsireni se zjistilo, ze se tam vejde pres 300TB.

V jine firme jsme meli vlastni podzemni DC a pronajimali jsme si 2 mistnosti v jinem DC - zvazovali, zda by nevyslo levnejsi mit DR site v cloudu - a nevyslo ;-) a pokud by se tam nedej boze neco spustilo, tak by byla veskera uspora fuc ;-)

Kdyz spictali 600TB PureStore - tedy full flash, co delal miliony IOPS s latenci pod 0.5ms - a ten job tam jel kazdy den skoro cely a 1x mesice se zastavil a tyden to delo dalsi job - tak jen ta masina by nas stala vice nez cele DC i s lidmi ...

Tak především záleží, co je to za cloud. Když si pronajímám VM, tak mám náklady na lidi skoro stejné, odpadnou jen starosti se železem, jinak se řeší přesně to stejné. Pokud si pronajímám přímo službu, tak mám sice menší náklady na lidi, ale zase platím za tu sluźbu samotnou ještě více než v případě IaaS.

"A zapocital si cenu lidi"

To je neuveritelny zvast. Vzdy. Jako admin se o HW staram asi tak promile svyho casu. O SW se nekdo starat stejne musi ze?

Třeba Basecamp migroval z cloudu - viz https://basecamp.com/cloud-exit - a ušetřil prý hodně peněz

Ani se nedivím - trochu výkonnější železo je v cloudu extrémně drahé. Cloud byl zajímavý pro firmy, které hodně rostly nebo jejich zátěž kolísala. Dneska mají cloud i zdejší velké korporace - jestli jsem to pochopil - jeden z důvodů je, že bezpečnost a dostupnost mohou předat někomu dostatečně velkému a nemusí se o ně starat. Reputační riziko nese někdo jiný, a to je pro ně důležité. Ve smyslu letitého tvrzení, že nikdy nikoho nevyhodili, když koupil Oracle, DB2, SAP, ...

Když se podíváte na ceny databázových serverů, které mají mít trochu slušnější výkon (větší než minimální), tak je to hodně drahé. Slušné fyzické železo (s řádově lepšími parametry) by se vám zaplatilo během roku.

Presne tak a to i s platy EU lidi ze zapadu, ktere tak jako tak musis mit taky, nebot ani cloud se nespravuje sam, usetris jen na facility - btw instalace jsme delali mi az prepojovani kabliku atd. delala facility

Jediny scenar kdy vyjde AWS velmi levne je, kdyz jsi mala firma a 1x mesicne potrebuje nabusenou masinu treba za 1 mega - pak ji vytvoris, narves data, nechat si na tech 200cpu a 4TB RAM spocitat, vyplivnes vysledek a zkartujes masinu - abys neplatil za rezervaci - prersenji ani masinu nechces, chces AWS API aplikaci, tedy bez OS - cili efektivne linux jen o tom nevis a data v S3

Jinak platis za odeslana data, kdybys chtel nahodou odejit a treba AZURE pak dela zajimave veci, ze ty data nejdou stahnout zpet ;-) ... a v cloudu platis za vsechno, za rezervaci HW co nic nedela (CPU, RAM, disky i prazdne misto), za kazdou IO na CPU i disku - kdyz mas SSD, neplatis za I/O disku, ale platis vic za data i za rezervaci prazdneho mista, platis za odeslana data.

"pro většinu scénářů vyšel cloud x-násobně dražší."

To neprekvapive plati zcela vseobecne, ze pronajem cehokoli je dlouhodobe vyrazne drazsi. Kdyz si chces vyvrtat jednu diru, pak si asi nebudes kupovat vrtaci kladivo, ale pucis si ho ... pokud vrtas kazdej den ... tak te typicky to pucovani zruinuje asi tak za tyden.

Když to budou hostovat na své infrastruktuře, budou ty výpadky častější. Úplně stejně, jako se tohle stalo v regionu US-east-1, se tohle může stát v nějakém evropském regionu. Jako se ostatně před dvěma týdny stalo Microsoftu, tam byl myslím naopak postižen jenom evropský region.

Ano, možná budou jednotlivé výpadky častější, ale zas to pokaždé nesestřelí velkou část služeb najednou.

To ano, ale z hlediska provozovatele služby je lepší mít služby levnější a s menším počtem výpadků. Dokonce je i lepší, když vypadne spousta dalších služeb – za prvé je to menší reputační problém (uživatelé vidí, že toho vypadlo spousta a že to tedy asi není chyba dané služby), za druhé pak zákazníci nemůžou utíkat ke konkurenci, protože ta také nefunguje.

> Když to budou hostovat na své infrastruktuře, budou ty výpadky častější.

Nevím proč? Na druhé straně s tím mohou něco dělat, zatímco u AWS mohou jen čekat, zda to začne fungovat. Nebo mohou naplánovat změny na čas, kdy výpadek nevadí.

Protože tam nebudou fungovat úspory z rozsahu, takže za stejné peníze budou mít horší služby od dodavatelů, méně a méně zkušených odborníků.

Amazon ten problém samozřejmě řeší, a nemyslím si, že kdyby to někdo provozoval na vlastní infrastruktuře, vyřeší to rychleji. Takže to „mohou něco dělat“ je dost pochybná výhoda, nanejvýš jde o ten pocit, že „se něco děje“.

Ona je taky dost nedoporučená strategie viset na jedné lokalitě. us-east je cenově nejdostupnější takže asi i nejzatíženější lokalita.
Je docela s podivem, že výpadek DynamoDB má tak extrémní dopad. U S3 bych to čekal.
Pokud si to někdo bude hostovat sám, bude ho to stát pro něj myslím dost neuvěřitelné peníze (pokud by se pokusil nasimulovat podobné podmínky - což ani nezkusí - myslím, že většina ani nechápe co to je).
Proto téměř neexistují evropští poskytovatelé - dokážou stěží oživit OpenStack.

To mne nejvíc překvapilo, že i velké a známé firmy poskytující služby celosvětově to odstřelilo – myslel jsem si, že používají více regionů. Ony to ale často přenášejí na koncové uživatele – poskytují jim služby ve stejných regionech, jako AWS nebo Azure a tudíž je nechají, ať si případně regiony řeší sami.

On je ten výpadek zjevně větší, než jen DynamoDB – možná AWS interně používá DynamoDB pro další služby. Každopádně už samotný Amazon potvrdil, že to má dopad i na EC2, a dopady to má i na Lambda služby.

Ale to byl přesně ten problém, nefungovala replikace mezi regiony i když i zákazníci měli zapnutou, takže…

Problem s DynamoDB... za kterym stoji problemy s DNS :-) Ale to uz nezni tak "vznesene", aneb preci DNS je jednoduchy, na tom se nemuze nic pokazit... :D

Je to tym, ze us-east-1 bol dlho predvoleny a boli tam centralizovane sluzby AWS ako IAM, SSO alebo aj nejake ulozisko S3 metadat. Preto support zvykol spominat, ze vypadok us-east-1 je "koniec sveta" a nepojde nic. A rovnako tvrdenie ako "ked si ulozim subor do S3, tak uz bude ten subor dostupny cez S3" platilo iba pre us-east-1; inde mohol fungovat caching a az po nespecifikovanej dobe to malo zacat fungovat.

To sa teda postupne opravuje, ale zakaznici sa stale spoliehaju na us-east-1.

Je to nedoporucene, ale je to tak.

Mohlo a nemohlo ;-) - vypadky se moc nedeji, od toho je cluster - a pokud neco zmrvis, rychle to opravis - a necekas az to zjisti nejaka firma i kdyz je profi a ma to - ale nikdy nevis, zda ti nelze, do AWS se na svoje servery nepodivas ;-)

Treba mi delali ten cloud jeste drive, nez to bylo cool ;-) a ve smlouve bylo, ze zakaznik ma pravo to videt, ma pravo zadarmo na nahodnou obnovu dat i masiny v ramci testu atd.

Podelat se muze cokoliv, ale zalezi jak moc setris, kdyz mas redundanci, tak jsi v klidu a ver ze Azure i AWS setri fest ;-) a na vsem

Viz casablanca, ti tvrdili lidem ze se nic nedeje, kdyz se po netu povalovaly fotky jak jim tece voda do racku.

A to nejsou zdaleka jediny ... kdy ze to byla ta "zaplava" na morave? Jeden ze zakazniku ma nekde v ostrave web ... a ackoli nebyl zaplavenej, tak byl off ... to jsou henti profesionalove ...

"ver ze Azure i AWS setri fest "

Predevsim vubec netusis co jak kde vlastne bezi a jak to je (nebo spis neni) zajisteny.

" budou ty výpadky častější"

Tohle umi mr JIrsak zcela jiste dolozit, nelepe nejakou verejne auditovanmou statistikou ze?

Je to totiz nehorazny blabol. U vetsiny svych zakazniku umim v pripade libovolnyho vypadku rozjet nahradni reseni v radu maximalne nizkych desitek minut, a to v situacich, kdy neco totalne failne. V tom uplne nejmensim meritku to umi kazda uklizecka, staci zapnout to rezervni pc.

No a teraz tu o Snehurce.

Toto, co pises je blbost. Mozno to vies tak rychlo zobehat za urcitych okolnoti ale urcite nie v pripade akehokolvek vypadku.
Urcite niesi dostupny 356/24, ak by si nahodou aj bol, tak vsetko, co k tomu potrebujes nemusi byt vtedy dostupne. To rezervne PC nemusi ist zapnut/nemusi fungovat a dalsie scenare, kde sa to nepodari rozbehat v kratkom case tebe alebo tej uklizecke.
Je to len iluzia. Na vsetky scenare nemozes byt pripraveny.

Predpokladam, ze to tvoje riesenie/produkt nieje nijak komplexne. S komplexitou narasta riziko a mozne problemy.

Akorát předvádíte, že vůbec netušíte, o čem je vlastně řeč. A jenom to potvrzuje příklad, kdy se tváříte, že reprezentativním vzorkem je jedno PC, ke kterému se dostane uklízečka.

Chtěl bych vidět, jak to náhradní řešení rozjíždíte v řádu nízkých desítek minut třeba v situaci, kdy vám budou servery v datovém centru plavat. Pochybuju, že máte pro většinu svých zákazníků hot standby v jiné lokalitě.

Ostatně ona je dostatečně vypovídající i ta první osoba „já umím“. HA řešení závislé na jednom člověku?

Jinak samozřejmě můžete technicky nic nebrání tomu provozovat si sám stejně spolehlivé prostředí, jako nabízejí cloudy. Nebo i spolehlivější. Akorát to bude ve většině případů podstatně dražší.

Tohle porovnání je trochu zavádějící.
Ve vlastním datacentru obvykle provozujete/řešíte servery, zatímco v cloudu to budou mnohem spíše kontejnery. V in-house datacentru platíte za kapacitu, v cloudu obvykle mnohem spíš za spotřebované zdroje.

On se nechá vybudovat i in-house cloud - a tak při správném škálování bude provoz levnější, než v pronajatém cloudu. Ale vybudování (datacenter pro cloud) bude určitě dražší, než pronájem, kde se o investici dělí více zákazníků...

Mno, pokud ti vypadne možnost dělat změny do DNS nebo ztratíš možnost dělat na S3 nové namespace či nezprovozníš IAM v novém regionu, těžko něco rozjedeš. Tady pomohl jen mít hot backup. Podpora multi-cloud řešení je drahá a velmi náročná na údržbu.

Provozovat HA na vlastni infrastrukture je pro spoustu firem nedosazitelne. I velke korporace ktere maji vlastni datacentra a dokonce vlastni ASko s tim maji velke problemy.

20. 10. 2025, 14:05 editováno autorem komentáře

Pri spravne architekture nepotrebujete explicitni HA, protoze je to implicitni dusledek potreby mit skalovatelne reseni. Snad si nemyslite ze nejaka sluzba bezi na jednom / skrze jedno zarizeni.

Neexistuje architektura, kde je to "zadarmo".
Mas typicky 1 entry point do app a ked nechces byt iba v 1 krajine, tak uz su tam aj podstatne latencie a nie je sranda mat ani DB transakciu. Mozno ked mas Spanner, tak to neriesis - ale inde je to dost o navrhu.

Skalovat vykon v jednom DC je odlisna uloha nez skalovat pres nekolik DC.

Vyhoda cloudu je ze je vsechno self-service.
V cloudu muzete obejit vsechny korporatni procesy kteryma si sami sobe komplikujete zivot. V cloudu spustite terraform a za par minut mate infrastrukturu v jednom DC, ten samy .tf vam vytvori identickou konfigurace v jinem DC.
Pokud pouzivate ITIL tak vam ten samy process muze trvat nekolik tydnu nez vsechno vytorite pomoci ticketu zadanych nekolika ruznym tymum. A nakonec ani nemate jistotu ze obe DC jsou nakonfigorovana identicky.

Tady je par duvodu proc HA nefunguje v korporatu na on-premise
- nikdo vam to nedovoli otestovat HA failover nez to pujde do produkce, protoze je to "nebezpecne"
- nekoho napadlo filtrovat vsechny IMCP packety vsechny ICMP host unreachable(i nikdo nevi proc)
- na zmenu DNS je potrebujete ticket, automatizece DNS se neplanuje
- dodavatel dodal aplikaci s archaickymi JDBC drivery, ktere nepodporuji switchover

No je uz takovy folklor, radoby-bezpecaci bezhlave radi filtruji vsecko i kdyz nevedi proc vlastne - a ICMP signalizace je toho nejcastejsi obeti. Typicky vas ten samy bezpecak bude nuti heslo obmesic, protoze je to prece "bezpecny"

A co mi brání k on-premu přistupovat jako ke cloudu?
Stejně už máš ty korporátní Terraformy, které pak používáš, a bez toho tě nepustí ani do cloudu. Pokud už ta znalost je, tak je jedno, jestli je to z pohledu vývojáře cloud nebo on-prem.

PS.: Zažil jsem i reálné trhací testy na produkci, kde se testovalo správné fungování HA. A byly pravidelné. Myslím, že je to jen o tom, co kdo chce mít na triku, když dojde na lámání chleba.

Jaky problem ?
Docker je HA uz z principu.
SAN - mam 2x fabric a multipath
Netapp MC - mam syncronni repliku do 2 lokalit
Oracle RAC - to same
Vmware - tam snad ani neni treba nic rikat i pidi lokace maji 3 servery uz jen kvuli upgrade
LAN - zase sestackujes switche, udelas LACP a 1 kabel das do jednoho, druhy do druheho

Pokud chces aplikaci v clusteru mas stale moznosti, od RHEL peacemakru, pres jine reseni - dnes to uz ale nahrazuje casto docker, vmware atd.

Vim ze jedna firma mela hodne Oracle RAC a casto i primo na serverech - kdyz jim odesel kriticky clovek tak zacali zvazovat, ze ustri na licencih, koupi si single a nechaji to vmware, ze by RAC nechali jen na 2 instacich - tedy 4 servery + testovaci servery - kazdy upgrade se delal nejdrive na testu i vyvoj se tam nejdrive daval, oni jeste meli dev ktery jako ze musel bezet a test, ktery se mohl cely znicit

Nedosažitelné je to tak leda v něčí hlavě. Jediný problém v on-premise je údržba. Musí se updatovat SW, FW, občas nahradit kritické prvky. To bývá problém protože někdo může mít špičku v grafu a může mu jebnout.

Jenže jakmile máte něco víc, než jen webový ksicht (HW řekněme 2-3 chassis a víc), tak už v cloudu platíte násobně víc, než za HW i s výplatami adminů.

Ked chcete mat rovnaku spolahlivost a rychlost, tak vas vyjde cloud s vyjednanou cenou menej. Samozrejme je otazka, ci to treba a hlavne nie vsetky data chcu ludia cpat do cloudu.

A to je ta iluze o které jsem psal. Rychlost je nesmysl. Naopak, jak chcete výkon, tak se v cloudu nedoplatíte. A co se spolehlivosti týče 99.99999% problémů jsou aplikační problémy. To jste na tom stejně.

"Ked chcete mat rovnaku spolahlivost "

Vazne? Kterej provozovatel libovolnyho cmoudu mi bude garantovat uhradu zpusobenych skod tim, ze to nepojede? Kdyz mam svoje, muzu s tim neco delat ze?

Provozovat HA si zvladne kazdej konickar doma/s podobne postizenym kamosem. HA klidne muze vypadat a velice casto i vypada tak, ze na regalu je nahradni PC, ktery se capne a vymeni, coz je akce tak na 2-3 minuty. Takze ... kdo mi bude garantovat vyreseni vypadku do 5ti minut? Pochlub se.

Já mám ještě lepší nápad, vykašlat se na model služeb, co potřebuje server. Já nevím, proč prostě? Však můžeme běhat na decentralizovaní síti nebo servelss.

Třeba pro chat existuje Jami, SimpleX... dneska jsem zjistil, že Signal používá AWS, takže v mojich očích klesly na úroven odpadu jako WhatsApp nebo Messenger.

Jedna věc jsou kecálci a podobné věci které by mohli běžet decentralizovaně... Druhá ostatní appky -- předpokládám že asi nechcete mít databázi s historií Vašeho účtu distribuovanou po náhodných nodech po světě... případně se kouknout jen na půlku filmu na Netflixu protože se zrovna odpojil nějaký node který má druhou. A to nemluvě o lékařských záznamech (ano v aws jsou i některé nemocnice) ;-)

20. 10. 2025, 19:06 editováno autorem komentáře

Ono by v podstatě mělo platit kritérium: co potřebuješ nejvíc, měj nejblíž. Firma (nemocnice...) by prostě neměla být závislá na tom, jestli funguje jeden (jediný) externí dodavatel.
Jenže pak se udělá výběrové řízení, a vybere se řešení od té firmy, která to slíbí podle zadání za nejnižší cenu. S výsledkem, že je to buď na podstřelené interní infrastruktuře nebo v tom nejlevnějším cloudu.

No torrent v pohodě funguje, většinu filmů stejně seženu víc tam než centrálně na serveru, protože buď nemá licenci, případně v daném regionu není, takže aha, hledám VPNku... navíc, nic ti nebrání si jako firma hostit vlastní nodes a lidi ti mohou hostit další nodes...

Tak o torrentu se nebudeme bavit, sdílet autorsky chráněná díla není zrovna úplně v pohodě. Osobně by mě zajímalo (kdyby se přešlo na "legální" torrenty), kdo těm lidem co sdílí bude platit za konektivitu a data (space) která poskytli? Dejme tomu onen Netflix, platíte autory, kameramany ... a z druhé strany IT, konektivitu, space na úložišti atd. Krom toho by to úplně nefungovalo, protože osobně např. Netflix používám na televizi. Momentálně tam mám volno tak 1GB navíc bych asi nechtěl aby mi televize odesílala kvanta dat do internetu.
Ve finále to AWSko má taky nody takže když spadne jeden server, tahá data z jiného. Myslím si že legální torrenty by opravdu nebyly řešení (stačí se podívat kolik lidí brbralo na windows update delivery optimalization, osobně nevidím důvod proč by společnost které platím peníze měla ještě využívat zdarma můj uplink)

"případně se kouknout jen na půlku filmu na Netflixu protože se zrovna odpojil nějaký node"

Ty asi moc nevis o tom jak fungujou distribuovany systemy ze? Vis, rika se temu matematika, v tomhle pripade pravdepodobnost. A libovolny obsah je v takovy siti zmutiplikovan prave tak, aby pravdepodobnost, ze nebude dostupny byla miziva.

Slovo "mizivá" bych nahratil "škoda vzniklá možnou nedostupností byla nižší, než náklady na další zvýšení dostupnosti", což v naprosté většině případů má do epsilonu opravdu daleko ;-).

Matematika mě zajímá dlouho, a slova jako "mizivá" tam opravdu nepatří (přestože používá exaktně definované termíny jako "continuous almost everywhere").

Vlastní infrastruktura je často interně příšerně drahá: aby se omezilo plýtvání zdroji, účtuje si firma za servery nesmyslné částky (z kapsy do kapsy, takže reálně to nebolí), což naopak vede k tomu, že se často zvolí levnější externí řešení (které se už ovšem platit musí).
Jakmile je jednou část infrastruktury hostovaná venku, nastává problém, že sice může být celé řešení HA, ale nakonec k němu vede (obrazně!) jen jeden kabel, takže nemusí být dostupné (a napojené na ostatní části).
Kupříkladu po převodu e-mailů z (interního) Exchange/Outlook serveru na O365 se typicky zhorší rychlost doručování a přibyde reportovaných výpadků, protože na interním serveru bylo nastavení podle potřeb firmy, zatímco externí řešení využívá nastavení podle šablon; a menší problémy se daří doma řešit rychleji, než stihne Microsoft reagovat na zadání ticketu, případně rychleji, než někdo ten ticket vůbec zadá (vyřešeno na první zavolání).

(Stručné shrnutí analýzy převodu služeb z interních serverů do cloudu: Bude to umět půlku věcí, stát dvojnásobek - ale konkurence to už má dávno!)

No, to je napad za vsechny prachy a nevim jestli jste si toho vedom. Ale mit vlastni data centrum stoji hodne penez, ok asi mene nez si ho hostovat. Jenze v cem je problem? Lidi, za prve v cr nemame dostatek odbor iku, kteri to.u rozumi a tudiz jsou schopni to delat na urovni 'AWS' a za dalsi, pikud by tady uz takovych odborniku bylo, tak by je nikdo nezaplatil. Je potreba mit treba 2 - 3 a kazdy za 200 cisteho a k nim dalsich treba 6 lidi za mi imalne 80 cisteho. To jste kolem 1.5M v hrubem jen za lidi. Jakmile date min penez, lidi nevydrzi, budou se to it, kvalita bude kolisat. Jakmile bude mene lidi, za nete ty stavajici zdimat, zakazovat dovolene a dlouhodobe se to neudrzi, bud budou chtit vice penez a nebo opet odejdou.

Takze jednodussi je zaplatit mega mesicne AWS a at si lidi a tyhle starosti resi ona, navic vam to jde z jineho baliku penez, ktery obvykle je stedrejsi, nez ten na vyplaty delniku.

Jeden pripad za vsechny, nejmenovana K banka nechala odejit ajtaky, protoze dat jim 80tis hrubeho jim prislo moc, dopadlo to tak, ze jim bankovnctvi neustale padalo, do toho si vymysleli migraci na novou verzi, ktera totalne nefungovala... Hlavne ze maj novacky za 60 taliru a platej externi firmu na odborniky.

Pokud to je ta banka, co myslím, tak jim to reálně a stoprocentně stále nefunguje. ;-D

Tohle je problém všech non-IT firem: celá IT infrastruktura, od hardware po lidi, jsou jen náklady. Pak máte na jedné straně pracovníky (telefonní/on-line) podpory klientů, skladníky, a různé odborné kancelářské síly, které pracují za minimální mzdu, a vedle toho přeplacené ajťáky s platem 80 tisíc hrubého, kteří neustále zcela neloajálně pokukují po lépe placené práci jinde.
Je jasné, že když (tak či onak) o IT infrastruktuře rozhodují obchodníci a manageři, mají priority nastavené na koruny a radši objednají řešení od externí firmy, která jim slíbí 90 % toho, o čem si myslí, že to potřebují.

Sezen mi skladnika, co bude delat za minimalku(zvladne aspon do 3 pocitat a pozna modrou od cerveny), pocitam ze ti spousta firem urve ruce a za kazdyho ti nejmin 5 tech minimalek vyplatej jako premii. To co vidim kolem sebe, tak nejobycejnejsi skladnik pod 50k je problem.

Tohle je zcela pitome nasazeni cloudu.. neznamenal cloud nahodou jednou to, ze neexistoval SPOF ? Tj. o zadny cloud nejde, ale o primitivni cohosting / cohousing.

Architekt reseni by mel po takovem incidentu padaka. Na strane AWS i velikeho zakaznika.

neznamenal cloud nahodou jednou to, ze neexistoval SPOF
Ne.

Architekt reseni by mel po takovem incidentu padaka. Na strane AWS i velikeho zakaznika.
Tak určitě. A že takovou službu tedy nenabídnete sám, když to podle vašich komentářů evidentně umíte lépe?

K tomu, abych poznal zkažené maso fakt nemusím být řezník.

To není vůbec tak jednoduché. Většina lidí by označila surströmming za zkažené maso, ale přitom je hlavní problém v tom, že ho vůbec neumí správně otevřít a zpracovat. (Nápověda: otevřít pod vodou a propláchnout. Rozhodně se k tomu nechovat jako ke krabičce sardinek v kečupu.) :-)

Kdo řekl, že se veškeré zkažené maso nedá jíst? :-D
Nemluvě tedy o tom, že ještě před sto padesáti lety by vám lidé řekli, že ryba není maso.

Jenže pokud tvrdíte, že to maso je zkažené, a ukazujete při tom na řepu, asi vás řezníci nebudou brát vážně.

> Tak určitě. A že takovou službu tedy nenabídnete sám, když to podle vašich komentářů evidentně umíte lépe?

Problem je aj v motivaciach. Vela ludi to vie navrhnut lepsie, ale ked niekto z biznisu vidi, ze to bude stat niekedy aj dvojnasobok, tak to nechce.

Nikdo není neomylný. Prostě se našlo další SPOF, fixne se to, SPOF se odstraní a jede se dál...

"fixne se to, SPOF se odstraní "

Nikoli

"a jede se dál"

Ano ...

Cet si nekdy neujakou cmoudovou smlouvu? On ti nekdo neco (naprosto cokoli) garantuje? Maximalne se vyda nejaky prohlaseni na tema ze se takovy omyl deje jednou za 10 let ... a za par tejdnu to bude znova dokola.

Jasne ze je, proto taky nabizi rozprostreni na 2 DC ;-) - ale jak znamo, svetlo je pomale a tak to nesmi byt dale nez 100km idelane mene - no a je to drazsi.

Jina vec je, ze je to rozprostreno na kupu HW, tazke aspon HW muze odejit a sluzba pojede, nebo se spusti na jinem.

Ale cele je to o tom, ze nkomu, kdo vam neukaze jak to vypada proste verite

Problém spočíva v tom, že toto nebolo zlyhanie hardvéru v jednej zóne (AZ), ale zlyhanie nízkoúrovňovej služby na úrovni celého regiónu US-EAST-1.
Príčina: AWS hlási problém s DNS rozlíšením pre kľúčovú databázu DynamoDB v celom US-EAST-1. DNS je ako telefónny zoznam internetu – ak sa adresa nepreloží, služby sa nemôžu navzájom nájsť, aj keď sú v rôznych, inak funkčných AZs.
Kaskádový Efekt (SPoF): DynamoDB je základ, na ktorom beží obrovské množstvo iných služieb AWS (napr. IAM pre overovanie, CloudTrail). Zlyhanie DNS na regionálnej úrovni v jednom kritickom bode okamžite spustilo kaskádu zlyhaní naprieč celým regiónom.
Globálna Závislosť: US-EAST-1 je historicky prvý a "domovský" región. Riadiace roviny (control planes) pre niektoré globálne služby AWS sú stále naň naviazané, a preto výpadok pocítili aj klienti mimo USA.
Záverečné ponaučenie (najmä pre firmy): Redundancia v rámci jedného regiónu (cez AZs) je dobrá, ale nechráni pred zlyhaním celej riadiacej roviny regiónu. Skutočná odolnosť vyžaduje architektúru naprieč viacerými geografickými regiónmi.

Ano, kvůli DNS jim selhala služba DynamoDB, kvůli tomu byl pak problém mimo jiné s vytvářením EC2 instancí, a kvůli problémům v interní EC2 síti mají teď problémy se síťovou konektivitou. Což zase ovlivňuje mimo jiné i DynamoDB.

Jsem zvědav na post mortem, jestli ho vydají, protože tentokrát to nevypadá na úplné selhání jedné služby, ale spíš že se to kaskádově přelévá z jedné služby na jinou, podle toho, jak jsou na sobě služby závislé.

A bude z toho pokuta pro ně? Nebo jak je známo tak korporátu se nic nestane, protože ugh ugh mně neznámej autismus v špatném slova smyslu, ale kdyby to byla malá firma, tak ji dáme takovou pokutu, že může okamžitě zavřít?

Kde je Evropská unie a všechny úřady? Nikde, ale budeme jebat Apple za USB-C... achjo...

Ten váš komentář vyznívá, že ta malá firma, která dostala takovou pokutu, že může okamžitě zavřít, je Apple.

Jenže všichni víme, že Apple tak nějak nikdy na toto nezavře. :)

Jak vis ze za to nedostanou pokutu?

Oni dostanou pokutu za to, že centralizují internet, a tento výpadek je toho jasný symptom? Rozhodně nedostanou takovou pokutu, aby je to jakkoliv poškodilo.

Tak ono kdyz si ruzne komponenty nedokazaly resolvnout co potrebovaly... tak to ten dominovy efekt zpusobi vcelku rychle. Ono mit zadratovane adresy v aplikacich je takove... ponekud provozne neprakticke, takze samozrejme DNS se intenzivne pouziva.

Ovšem nikdo nikde netvrdil, že AWS mělo obecně problém s DNS. Podle zveřejněných informací byl problém pouze s překladem jmen pro Dynamo DB API. Problém s DNS byl plně vyřešen po půl jedné našeho času, ale pokračují problémy s dalšími službami.

No tak jasne, pokud vlivem chyby v DNS selhaly nejake automaticke deploymenty, ktere se tam za ty tri hodiny nepochybne nahromadily, tak to pak logicky ucpalo trubky :-) To uz je spis jen dusledek. Aneb tezko rict, kolik tech EC2 "jen" spachalo sebevrazdu... protoze kill/redeploy je velmi caste reseni v pripade problemu. Coz je samozrejme na jednu stranu krasny sluha... co ale nekdy muze byt zly pan.

Vidis ... a pritom to ma zcela primitivni reseni. Pouzivat vice (ruznych) dns serveru ze? To treba takhle pred par lety soudruzi v MS patchli widle ... a DNSka prestala prakticky fungovat. Ja si to precet az na webu ... protoze ve vsech infrastrukturach mam i tuxi dns. Teprve pak sem se sel podivat ... a ono to fakt failovalo, ale ty tuxi stroje prekladaly.

Zazracna technologie za miliardy dolaru.

Jak přesně pomůže více různých DNS serverů v situaci, kdy máte v zóně chybný DNS záznam?

Tváříte se jak mistr světa, všichni okolo to dělají blbě, přitom ale ani nechápete, v čem byl problém…

ano, tady více DNS nepomohl, protože jsi nemohl udělat úpravu toho jednoho, u kterého spadl management a měl staré záznamy. I s tímhle se lze vypořádat, ale musíš s tím počítat...

Když jsem si říkal, že cca 80 % provozu internetu jede skrz US a AWS, tak jsem si říkal, že mi hrabe. Bohužel jsem měl asi pravdu.

Nicméně, pokud si jakoukoliv službu budu kupovat, tak se jich prvně na supportu zeptám jestli někde používají AWS. Pokud ano, budu požadovat slevu jako penalizaci pro ně, že přispívají k problému jménem centralizuejem internet a odevdat ho korporacím a ne všem, tak jak byl internet navržen.

Já nevím, proč nemůžeme používat P2P a serverless věci? A než mi někdo napíše, že to nejde, tak asi neumí IT nebo vůbec nechápe sítě.

Například, když chci někomu poslat fotku, či zprávu, proč mu nejde přímo a potřebuji to poslat na nějaký server a ten mu to pak přepošle? Však logičtější je to poslat přímo jemu. Taky si s kamošem nepovídám přes neznámého random člověka, který ještě neříká, co chce říci a jen se ohání black box smlouvu a věřím mu jen na základě toho, jak mi od druhé strany chodí zprávy?

Už má každý dostupnou IPv6 konektivitu?

1. Protože se kvůli dlouho odkládanému zavedení IPv6 a podceňování bezpečnosti staví sítě tak, že se očekává, že jsou v nich jen klienti ,kteří se připojují k serverům někde v internetu. 2. Protože když někomu chcete poslat fotku nebo zprávu, vy jí chcete odeslat hned, ale on si jí chce stáhnout později a do zařízení, které si sám určí. 3. Protože ta komunikace přes server se dá dobře zpeněžit, zatímco předplatné za aplikaci pro P2P posílání zpráv nebo fotek se nikomu nebude chtít platit.

Nejsou to neřešitelné problémy a doufám, že se je postupně vyřešit podaří, ale rychlé to nebude.

1. Výborně, tak to musíme začít dělat co nejdřív, aby ten problém byl viděl a řešil se.
2. A proč je nutné ji odeslat hned? Jami to řeší tak, že leží u tebe, kde stejně ležet bude, protože ji z té galerie nesmažeš za 5 minut... a až se zařízení na druhé straně připojí ... no tak se pošle? No a nebo to jde řešit jako SimpleX chat. Dočasně se uloží na relay a už se druhá strana objeví, tak si fotku vyzvedne.
3. Ano, to je pravda, takže pak se musíme smířit s nasranými zákazníky, s tím, že jsou věci na hovno, furt to nejede... a že všichni chtějí volit socialisty, protože haha trh selhal, protože to na trhu v 90 % dělají všichni stejně na ho...

A proč je nutné ji odeslat hned?
Protože teď jsem na připojení, odkud to chci odeslat. Až bude na vhodném připojení ten, komu chci fotku poslat, nebudu možná já vůbec na internetu, nebo bude někde v lese na pomalém připojení a nebudu zvědavý na to, aby se přes to posílaly velké fotky.

Tak to samozřejmě řeší varianta s hejnem relayů (Takto funguje SimpleX chat), no a když jsi v lese, tak se ti velká fotka neodešle ani v lese, nehledě na to, jestli používáš P2P, relayed nebo centralized službu.

Je jedno, kde ta fotka leží, stejně si ji musíš ty stáhnout, a když to je u tebe pomalé, no tak to prostě nebude, a i na tom hloupém Facebook Messengeru bude šedý obdélníček, co bude způsobovat vytížení tvého připojení, že neprocpeš ani tu jednu zprávu od sebe.

Serverless neznamena, ze neexistuje server. Znamena to, ze nemas VM o ktoru sa musis starat. Stale ale niekde na serveri tvoje "funkcie" bezat musia, len tentokrat podvozok nie je nejaky OS alebo container runtime, o ktory sa staras, ale sada kvazi-standardizovanych kniznic, ktore poskytuju poskytuju runtime pre tvoje funkcie.

Stale je to pocitac niekoho ineho. Akurat uz nie s tak low level pristupom. Tebe odpadne cast starosti o system, prevadzkovatel vie lepsie vytazit a vybalansovat svoj hardware.

A pak to cele vybouchne, protoze jedna z afektovanych veci byl i dockerhub :-) Pokus o deploy v nekterych chvilich byl tak trosku sebevrazedna mise. Error, runtime fuc.

Pokud píši serverless, tak tím myslím i nějakou VMku, na které všechno běží...

Server je cizí počítač připojený do internetu a je jedno, jestli to je počítač, kde běží na železe OS nebo VMka nebo docker.

Ono to v praxi má určité problémy. Např. já teď sbírám od sportovního oddílu fotky z akcí a budu z nich dělat prezentaci. Řekl jsem si, že místo Google alba to zkusím sbírat na svůj domácí NAS a využil na to určenou funkcionalitu Synology.

Jenže co čert nechtěl, pár dnů na to, co jsem rozeslal link hromadě lidí, jsem potřeboval něco na tom NASu překopat a posledních pár dnů mám mnoha hodinové výpadky (je to jen domácí NAS, nemám to řešení HA). A ty lidi, co mi fotky posílají, se mouhou setkávat s tím, že zrovna v okamžiku, kdy oni na to mají čas, ta služba zrovna není dostupná.

Takže přímá komunikace vypadá možná na první pohled jednoduše, ale v praxi naráží na dost komplikací, které pro změnu u komunikace přes prostředníka odpadají.

Špatně škálované řešení. ;-)
Proto mám doma ty NASy dva, abych v případě výpadku mohl okamžitě nahodit neplnohodnotnou zálohu, která tyhle kritické operace dočasně přebere.

Kazdy voli reseni umerne rizikum a potrebam. Aneb nekdo po vyhodnoceni rizik muze dojit k nazoru, ze zivit doma dva NAS je nadbytecny a neekonomicky luxus.

Já mám ten jeden standardně vypnutý, na pokusy, tedy testovací prostředí s (mnohem) menšími disky. Ale v případě potřeby naň přepnout je otázka chvíle - než nastartuje.

No konkretne v pripade Synology Photos, dana funkcionalita vyziadania foto nefungovala ani ked som prekopavat nic nepotreboval. Od dotycnych som dostal pekne vynadane.

AWS (US-EAST-1) DynamoDB Outage report explained in plain English.

1. A race condition in DynamoDB’s DNS automation deleted its main endpoint record.

2. This happened when 2 DNS systems updated Route 53 at the same time and removed all IPs.

3. DynamoDB went offline, and services that depend on it like EC2, Lambda, Redshift, and IAM stopped working.

4. EC2 could not launch new instances because it uses DynamoDB to track server state.

5. Network and Load Balancer systems failed next, causing connection errors across AWS.

6. Engineers fixed the DNS issue, full recovery took about 15 hours.

If you are a DevOps or Cloud Engineer, this is a great use case to understand.

A small DNS automation glitch can bring half the internet down.