Šéf AWS: magnetické disky nezvládají moderní aplikace (diskuse)

[Harvie.CZ]

Spíš "moderní" vývojáři nezvládají psát aplikace pro průměrný HW

[Bubak]

Neni spravnejsi moderni "vyvojari"?

[mozog]

bohuzel +1

[kavol]

+1

smažu deset malých plaintextových mailů, a na minutu se mi rozsvítí disk a než zhasne, tak se mi nenačte mail z jiné složky ... tomu říkám pokrok :-/

[Lol Phirae]

Tos to KDE ještě neodinstaloval?

[kavol]

no, rád bych, ale kam jít?

- teď tu nový kolega zprovozňoval Thunderbird, a odradil mě ještě než to začal používat ... používat SMTP s TLS? - pche, zapomeň; zkoušíme všecko možné, žádnou kloudnou chybovou hlášku to nevysype, jen furt opakuje do zblbnutí, že to prostě nejde, žádná kombinace těch dvou a půl voleb nefunguje, až zkopírovat nastavení od jiného kolegy, a samozřejmě bez SSL/TLS ...

[TomasVondra]

No, a nebo prostě chyba nebyla v Thunderbirdu ... používám několik let k plné spokojenosti, a to i se SMTP a TLS.

[Luk]

Taky používám v Thunderbirdu SMTP s TLS, už hodně dlouho. Nikdy jsem s tím nezažil problémy (ty měl například mailový klient v Opeře).

[kavol]

No, a nebo prostě chyba nebyla v Thunderbirdu ...

to je možné - pak bych ovšem od něj čekal, že řekne, kde ta chyba je

například jestli mu selhal TLS handskahe a ve kterém kroku

nebo jestli je ten port vůbec dostupný

nebo jestli není překlep v názvu, jestli se resolvuje

atd.

[xkucf03]

+1, taky s tím nemám problém.

Jenže jsem si nastavoval ty účty už dávno – dneska už TB dost zapplovatěl a je tam ten průvodce a databáze služeb a jejich konfigurací. Což je na jednu stranu fajn, ale zase když člověk přesně ví, co chce, tak mu to hází klacky pod nohy.

[Luk]

Ten průvodce je to nejhorší, co v TB je. Sice už ho trochu opravili, ale stejně.

[SPM]

Spíš zhoršili. Opravili tam bug, kterej umožňoval toho dementního průvodce obejít a nastavit ty účty pozdě. Trvalo mi asi hodinu, než jsem zjistil, že to ruční zadání parametrů funguje ve chvíli, kdy se u všech konfigurovatelných parametrů nastaví hodnota ručně...

[dustin]

Ano ten wizard je opravdu humus...

[xkucf03]

A přitom by v tom průvodci stačila jednoduchá rozdvojka:

• jsem BFU a znám jen svoji e-mailovou adresu a heslo
• chci si nastavit všechno ručně

nebo ať je třeba i ten BFU režim výchozí, ale ať je tam tlačítko, kterým se dá hned skočit na ten plnohodnotný dialog a není nutné kontrolovat údaje proti databázi poskytovatelů, DNS a HTTP rozhraní.

[Lol Phirae]

To asi nechtěli, protože to má Outlook.

[Luk]

Teď už je to stejně jedno, protože Thunderbird to má spočítané

[little.owl]

Pokud tam nacpou nejakeho instantniho messengera, jdu od nej, otazka zni kam. Claws Mail - neni to z blata do louze? Ma s nim nekdo zkusenosti? Vracet se po 10 letech k mutt se mi moc nechce.

[xkucf03]

KMail.

[little.owl]

To bych musel nainstalovat pul KDE a to je pro me jako zastance Gnome 3 prakticky a spolecensky neprijatelne. Ale diky.

[Lol Phirae]

Prosímtě, to opravdu nedělej. Díky sračkonádi ani i7 s SSD není dostatečně rychlé na provoz tohoto výkřiku "pokroku".

[Luk]

Zajímavý je poštovní klient v Opeře (velmi rychlý, snadno ovladatelný), ale... Některé věci se mi tam prostě nelíbí. Například podivně nakládá s flagy zpráv, svévolně označuje zprávy za spam, naopak ty již označené ignoruje. Možná už je to opraveno, ale v jedenáctkových verzích to tak bylo.

[Lol Phirae]

Claws Mail - neni to z blata do louze? Ma s nim nekdo zkusenosti?

Ale jo, v rámci možností velmi slušné. (Enterprise funkce ve stylu Utlouku od toho samozřejmě nečekej.)

[Luk]

Bohužel, klient s funkčním rozsahem a BFUovitostí Outlooku a současně dodržující otevřené standardy a doporučení tady zatím není a asi hned tak nebude

[little.owl]

Enterprise funkce ve stylu Utlouku od toho samozřejmě nečekej.

To by bylo v pohode, noc takoveho nepotrebuji.

[David Jaša]

Používám poměrně spokojeně evolution.

[little.owl]

Mel jsem vzdy pocit, ze je to bloated, plus prefereji plain text format pro ulozeni mailu, a tam byl tusim take nejaky problem. Urcite se na Evolution kouknu, urcite udelali progress.

[Bubak]

To je divny, ja to s TLS (no, mozna SSL, musel bych mrknout na server, v TB mam nastaveno SSL/TLS) pouzivam. Ale takhle po ruce radu nemam... A mam porad TB 3.1 neco, nejak me serou ty jejich verzove zavody.

[nyan]

Hehe, thunderbird. Reknu mu at skontroluje novou postu, na vterinu zasviti v status baru prubeh, pak zhasne. Pak v pristich minutach se magicky zacnou objevovat nove maily

Dalsi variace na evolution (= overengineering), jenom vic bloated.

[Luk]

Pak v pristich minutach se magicky zacnou objevovat nove maily

Jo, takhle TB funguje

[MilanK]

To bude claws-mail.

Evolution také dlouho přemýšlí, ale během té doby alespoň lze číst/mazat jiné maily.

[little.owl]

Zalezi na aplikaci a co zpracovava za data. Kompilaci kernelu SSD urychli, tedy kde je chyba, ze je to na magnetickem disku pomale? gcc? kernel? make? Ne, bottleneck je prave rotacni disk.

[petr_p]

gcc -pipe. Nebo máš moc rychlý procesor, že disk nestíhá načítat zdrojáky.

[little.owl]

Build server s Intel Xeon E5-2670 a pouziti SSD je znat - 2-3x rychlejsi (nejedna se o kernel a gcc).

[Lol Phirae]

Kup si víc paměti a kompiluj v tmpfs.

[cezz]

Ramka je ta druha alternativa, ktoru v blogu spomina..

[little.owl]

U nas je snadnejsi koupit Intel PCIe SSD nez zmenit par radek na build serveru, ktery umi i podpisovat image.

[little.owl]

Projel jsem to znovu - kompilace je rychlejsi na SSD o cca 50%, zbytek zlepseni jde na vrub castecne operacim s gitem a hlavne automatickym testum, ktere nacitaji sekvence obrazku.

[xkucf03]

Tak si je sekvenčně natáhni do RAM a pak bleskově zkompiluj

[stativ]

To přirovnání tedy dává smysl…

[TomasVondra]

To přirovnání je blábol, ale vtipné je že ať ho v tom článku hledám jak hledám, tak on ho tam Vogels nikde neuvádí - to pouze autor zprávičky byl zřejmě kreativní a vkládá mu ho do úst. Ne že bych AWS nějak miloval, ale Vogels v tom článku konstatuje poměrně prosté skutečnosti:

• AWS uvádí novou instanci se 2 SSD disky
• SSD vám dají daleko vyšší IOPS než standardní disky (za stejnou cenu)
• standardní rotační disky se postupně dostávají do pozice páskových mechanik
• mnoho aplikací vykazuje naprosto náhodný přístup k datům (relační i nerelační databáze)

Je tam také pár tvrzení se kterými by se dalo polemizovat (např. že 15k disky dávají něco málo přes 100 IOPS - kvalitní dávají i přes 300), ale celkově těžko polemizovat.

To že se dneska aplikace prasí (viz. registr vozidel kde vývojáři po týdnu zoufalého provozu zjistili že relační databáze může mít také něco jako indexy) ještě neznamená že neexistují aplikace které prostě masivní náhodný přístup vyžadují, a v tom případě jsou rotační disky často brzda.

[little.owl]

Tohle bylo pojeti z technologickych zpravicek BBC, ktere jsem poslouchal v aute - OK, novinarska zkratka, ale v podstate se neodchylili od veci a proto jsem to take pouzil; staci se zamyslet v kontextu veci nad jeho nasledujicim tvrzenimi:

Magnetic disks are rapidly starting to exhibit tape-like properties and with modern workloads being increasingly random, they are becoming less and less suitable as a storage system.

One area where we have seen this particularly culminate is in modern NoSQL

A ci nazvem:

Expanding The Cloud – High Performance I/O Instances for Amazon EC2

[TomasVondra]

No, nevím - srovnání "vztah mezi diskem a cloudem je jako mezi magnetickým páskem a diskem v minulosti" prostě není novinářská zkratka ale nesmysl. To že to tak zprznil nějaký redaktor v rádiu (byť je to BBC) je smutné, ale co jiného od médií čekat ... V tom článku se to prostě nikde nepíše, a ani to z něj nejde vyvozovat.

Osobně nechápu (a může to být moje omezenost) jak z těch dvou vámi uvedených vět má plynout to srovnání (nebo jeho smysluplnost), ale pokud mi vysvětlíte jak jde srovnávat virtualizované prostředí (cloud) a úložné médium (disk), leda dobře. Jediné co z toho dedukuji já je že nové aplikace, provozované často v cloudu od Amazonu s využitím NoSQL databází, mají značné nároky na náhodné I/O které s tradičními disky nejde dost dobře naplňovat.

To samé ten titulek - to akorát říká že Amazon ve svém cloudu představuje novou instanci s velkým I/O výkonem.

[little.owl]

V kontextu historie a jeho vyjadreni jsem to chapal take jinak.

Byly tu derne pasky a pak super magneticky pasek, ktery byl velmi rychly. Jenze pak prisly magneticke rotacni disky a tenhle spickovy magneticky pasek uz nebyl najednou tak spickovy, a co hure, zacal vykazovat "tape-like properties", pomaly random access, prestoze nove modely byly lepsi rychlejsi nez cokoliv predtim. A ted jsme v podobne situaci - mame nove cool SSD - a mame rotacni magneticke disky vetsi a rychlejsi nez kdykoliv predtim, a presto nam u novych cloudovych aplikaci zacinaji opet najednou vykazovat ty stare osklive "tape-like properties".

Nasel jsem zdroj, ze ktereho BBC cerpala - obvykle takove veci prebiraji - neprekvapive - The Register zde a v takove spolecnosti dezinformatoru budu celkem rad.

[TomasVondra]

Tak zrovna The Register s titulkama často zachází IMHO naprosto bulvárním způsobem ... no nic.

[Käyttäjä 11133]

(kvalitní dávají i přes 300), ale celkově těžko polemizovat.

Citation needed...

[frEon]

tak pokud mas seek za 3 - 4 ms a sekunda ma 1000 ms, prostym vypoctem to +- tak vychazi. samozrejme necemu obcas pomuze cache v disku atd...

[TomasVondra]

Viz. např. http://www.tomshardware.com/reviews/sas-6gb-s-hdd,2402-11.html

Ale strašně záleží na definici IOPS (proto jsem psal že by se o tom dalo polemizovat). Pokud disk vezmete jenom jako rotující plotny, tak to samozřejmě umí jenom 15k otáček / 60 vteřin = 250 operací / vteřinu. Ale SAS disky (skutečné, ne takové ty "Franto vezmi SATA a přidělej k tomu SAS konektor") umí všelijak optimalizovat cestu hlaviček apod. IOMeter samozřejmě používá trochu jinou definici IOPS, ale je zajímavé vidět jaké rozdíly jsou i mezi stejně rychlými disky - nejrychlejší testovaný má přes 400, nejpomalejší cca 320. A ještě vtipnější je že v access time je pořadí opačné ...

[J]

Ad disky - pokud vim, teoreticky maximum 15k disku je +-200IOPS, pro zjistovani kolik jich bude treba se pouziva 180. Tech 100 da desktopovej disk.

Ad aplikace - disk je pokud me skleroza neklame .... ULOZISTE ... nikoli pracovni pamet. Koupit dneska server, s 512GB RAM lze vpodstate "za hubicku", takze celej registr muze bejt v ramce. Mam tu SQLko se 64GB RAM, databaze ma cca 150GB. Uspesnost cache je 99+% => na disky to prakticky nehrabe (pri cteni samo). Zapisy jsou pak co se vykonu tejce linearni => pocet IO me az tak moc nezajima (zapisuje se do transakcniho logu a do dat se to migruje postupne).

[TomasVondra]

Víceméně máte pravdu, ale v několika věcech bych polemizoval.

Samozřejmě pokud se vám aktivní část dat vejde do paměti, je to optimální. Ne vždy to ale jde zařídit a ne vždy je akceptovatelné že určité procento requestů bude trvat řádově déle (například pokud máte uzavřená nějaká SLA s třetími stranami). Především se to ale týká read-mostly zátěže, jakmile se začne zapisovat (náhodným stylem - kousek tady, kousek tam), tak je nakonec houby platné že se to vejde do paměti - aby to bylo ACID tak se to na disk musí zapsat, a to v okamžiku commitu. To je první místo kde hraje IOPS výkon roli, i když tady to ještě jde "utavit" řadičem s write cachí. Horší je to v okamžiku kdy se provádí checkpoint - tam už jaksi cache na řadiči nepomůže, protože ta má také jenom omezenou velikost. Ale je fakt že většina běžných aplikací je v drtivé většině o čtení.

Druhá věc je že nejde ani tak o výkon jako o poměr cena/výkon. Řekněme že firma skutečně má ~500 GB dataset, a rozhoduje se mezi nákupem RAM (+ odpovídající zajištění a trvalé uložiště) a SSD disky. Pokud SSD Intel 710 a (nebo i Intel 320) budeme považovat za spolehlivý hw, tak kapacitu 500 GB pokryje cca za 60kKč (resp. 25kKč v případě 320). Když se to srovná s cenou za stejnou kapacitu v RAM (řekněmě 400kKč), tak je rozdíl evidentní. Jasně, RAM bude většinou dávat lepší výkon (ale viz. odstavec výše), ale zase se to dá vypnout (i neočekávaně) a data se neztratí. Takže to mnohdy je rozumná alternativa. Otázka je jenom jestli ten výkon pro daný účel stačí nebo jestli je skutečně potřeba RAM a jestli se to vyplatí.

[microcz]

+1 díky za vysvětlení Tomáši ...taky jsem se divil.

Celé mi to připadalo, jako kdyby někdo začal místo nůžek a holícího strojku začal porovnávat nůžky a kadeřnictví a do toho se pustil dav s učenou diskuzí na téma "moderní" kadeřníci

[frr]

Ten hlod s indexama v registru vozidel mě dostal na kolena. Asi nejlepší offtopic komentář co jsem kdy četl.

[Bubak]

No jo, kdyz se prasi, tak samozrejme hw nestiha...

[microcz]

+1

[xkucf03]

V serverovně se nemá co prášit. A psaní bez diakritiky je mor.

[Bubak]

No jo, pravdu díš

[martin]

Tomu nerozumím "přirovnává současný vztah mezi diskem a cloudem" - to se jako v cloudu disky nepoužívají?

To mi připomíná ten díl BOFH, kdy přesvědčil šéfa, že je potřeba koupit několik kilometrů kabelů, aby v nich obíhala data

[cezz]

Kukni si ten clanok. Rec je o klasickych magnetickych diskoch.

[Ladicek]

Rád bych všechny, kdo se tady vychloubají řečmi o moderních vývojářích, upozornil, že v tom článku se mluví zejména o databázích a o tom, že databáze jsou úzkým hrdlem při škálování monstr aplikací, které na AWS běží. To je fakt něco trochu jiného, než o čem mluvíte.

[JoHnY2]

Souhlas, bohuzel se to pak prekrouti v blabol pro manazery typu: "Kdyz nemate v Cloudu NoSQL na SSDckach, tak vam zastarava IT a nejdete s dobou."

Nestihani monstr aplikaci muselo bejt jasny predem ne? Vsichni s extremnima workloadama byli donuceny utyct z ACID SQL databazi na NoSQL systemy, ktery maj jen eventual consistency . Tim se vyresil problem bottlenecku v SW a logicky vybublal v HW, kde jsou HDD jednoznacne nejslabsi clanek. Priznam se, ze jsem jeste nemel moznost si sahnout na system, kterej by vyslovene nebylo rozumne mozny provozovat bez SSD. Na vetsine veci ktery jsem videl dodneska stacej rychly HDD a maximalne by bylo prima je podporit necim jako ZFS L2ARC cache na SSDckach. Sun s tim predbeh dobu vazne o dost.

[Käyttäjä 11133]

Sun s tim predbeh dobu vazne o dost.

Technologie ne nepodobná ZFS L2ARC stála za výpadkem registru motorových vozidel v jedné nejmenované zemi na severu evropy.. :)

[melkors]

Zeby?

Povidejte, prehanejte!

Take by me zajimalo, co se tam presne stalo ...

[myšák]

Ve zkratce řečeno by se na to hodil známý citát: "Jeden zařval vypni to, druhý zařval nejde to"

[xkucf03]

Falešný Schwarzenbeg na Twitteru:

Byl jsem se podívat v krizovém štábu na dopravě. Všichni tam sedí před jedním monitorem a občas někdo vykřikne: "Teď! Teď! Teď to pojede!"

[kavol]

Rád bych všechny, kdo se tady vychloubají řečmi o moderních vývojářích, upozornil, že v tom článku se mluví zejména o databázích a o tom, že databáze jsou úzkým hrdlem při škálování monstr aplikací, které na AWS běží. To je fakt něco trochu jiného, než o čem mluvíte.

mno, goto #6 ... nad čím asi Akonadi běží?

co se týče "monstr aplikací", Akonadi mi dostatečně "monstr" přijde, ba víc "monstr" než třeba ukládání dat z LHC, ale to je čistě o odlišném chápání toho slova

[JoHnY2]

Pokud jde o Akonadi, tak me osobne uplne stacilo, kdyz jsem si precet na blogu vyvojare nekdy v dobe KDE 4.6, ze udelal takovy lehkou optimalizaci ... a vetsina query se zrychlila 10x nebo nejak podobne brutalne. Docela me to pobavilo, protoze za fakt, ze podobnou optimalizaci nikdo nezkousel provist nekdy od verze v KDE 4.1 by si vyvojari zaslouzili jednu do zubu.

[Ladicek]

Můžeš pustit Akonadi na AWS s SSD diskama, ne? Srsly, ten článek fakt mluví úplně o něčem jiném. Souhlasím, že v případě Akondi není na vině ani disk, ani databáze, dokonce ani zlý cloud

[kavol]

Srsly, ten článek fakt mluví úplně o něčem jiném.

a o čem "úplně jiném"?

a mimochodem, co myslíš, oproti těm od sračkonadi jak moc "jiní" moderní vývojáři vyvíjejí cloudoviny?

a jak si vykládáš větu ... if the database can be configured such that it no longer is a bottleneck, applications can become much simple, and thus more reliable and scalable?

[Ladicek]

a mimochodem, co myslíš, oproti těm od sračkonadi jak moc "jiní" moderní vývojáři vyvíjejí cloudoviny?

IMHO o dost jiní, aspoň soudě podle pár přednášek, co jsem viděl. Ono pronajmout si od Amazonu takovouhle monstr-instanci není vůbec levné (víc než 3000 dolarů za hodinu), takže si to sotva lajzne někdo, kdo má rezervy ve výkonu někde v softwaru.

[Ladicek]

víc než 3000 dolarů za hodinu

OK, to je nepřesné, víc než 3k to je za on demand instanci, rezervovaná instance může být i pětkrát levnější (s nějakou fixní cenou předem). Což teda pořád není žádná sláva

[TomasVondra]

3000 dolarů za hodinu? To se vzalo kde? Ta High I/O instance stojí 3 - 4 dolary / hodinu.

[kavol]

IMHO o dost jiní, aspoň soudě podle pár přednášek, co jsem viděl.

nevim, co jsi viděl za přednášky, ale od teorie k praxi je dlouhá cesta

Ono pronajmout si od Amazonu takovouhle monstr-instanci není vůbec levné (víc než 3000 dolarů za hodinu), takže si to sotva lajzne někdo, kdo má rezervy ve výkonu někde v softwaru.

v takovém světě bych chtěl žít ... bohužel hnedle v této diskusi máš protipříklad, nefunkčnost registru vozidel taky není levná záležitost, a zjevně si to někdo lajznul

[daneel]

Mno jo, ale registr, to je stat. A stat/my blbci zjevne v relativnim klidu sneseme v zasade vsechno... ... Tak proc by si to nelajsnul...

[xkucf03]

NoSQL aplikace přece mají skvěle škálovat a být vůbec úžasné, nebo ne?

[Ladicek]

Můžeš jít do Amazonu a říct jim, že Dynamo byl blbý nápad.

[xkucf03]

Tak znova: pokud by to škálovalo dobře, tak by stačilo dokoupit další HW a poskládat ho vedle sebe a nebylo by potřeba kupovat úplně jiný druh hardwaru s jinými parametry. Ono koupit rychlejší disky a procesory a pak se chlubit, jak ten systém běhá rychleji není žádná velká věda.

Nové HW technologie jsou určitě fajn, o tom žádná, ale prostě mi přišlo trochu úsměvné dávat do souvislosti NoSQL a pomalé rotační disky (resp. nutnost SSD), když jednou ze slibovaných vlastností NoSQL byla škálovatelnost a mělo být možné zvednout výkon tím, že udělám cluster z více serverů složených ze současného HW.

[TomasVondra]

Ale však vy můžete škálovat tím že budete přidávat další a další stroje, v tom vám nikdo nebrání. A nebo prostě můžete nahradit kus hw kvůli jehož limitům jste museli škálovat v takové míře, no a pak nebudete muset používat tak velký cluster. To je celé.

Část NoSQL databází byla navržena právě proto aby takové škálování bylo na commodity hw jednoduše možné (ne že by to s relačními DB nebylo vůbec možné - viz. např. sharding), no a teď se prostě do "commodity hw" oblasti dostávají SSD. A je pravda že NoSQL se často používají na aplikacích s velkým aktivním datasetem a náhodným přístupem (např. data mnoha uživatelů, kteří k nim náhodně přistupují), takže ta souvislost tam do jisté míry je. I když samozřejmě z rotačních disků mohou výrazně těžit i tradiční relační DB apod.

[Filip Jirsák]

Řekl bych, že je to trochu jinak. Na začátku používání rotačních disků to myslím bylo tak, že všechna data byla na pásce, a rotační disk fungoval spíš jako rychlá cache pro rychlý přístup k nejčastěji používaným datům. Dnes je to podobné s rotačními disky a SSD - na rotačním disku jsou všechna data, ale ta nejčastěji používaná se vytáhnou do cache na SSD. S tím souvisí i ta škálovatelnost -- v případě klasické aplikace budu mít všechna data na rotačním disku s pomalým přístupem a právě používaná data se vytáhnou do rychlé RAM, plus zbytek volné RAM se používá jako cache. Jenže když mám výpočetních uzlů tisíce, už se vyplatí na cache nepoužívat drahou RAM, ale třeba právě SSD disky. Takže se SSD dostaly přesně do dřívější role rotačních disků -- je to cache, která je mezi RAM a trvalým úložištěm, je výrazně rychlejší, než trvalé úložiště, ale za stejnou cenu má podstatně větší kapacitu, než RAM.

[xkucf03]

Tohle je všechno pravda, nejsme ve sporu… jen tam prostě nevidím tu souvislost s NoSQL (naopak v souvislosti s NoSQL bych čekal spíš něco ve stylu: s NoSQL si nemusíte kupovat drahé SSD disky a stačí postavit víc levných serverů/disků vedle sebe a bude to krásně škálovat)

[Filip Jirsák]

S NoSQL zvládne stejnou zátěž odbavit menší počet serverů, když využijete cache postavenou na SSD discích. Cache není řešení pro všechny případy, ale zrovna v případě mnoha NoSQL řešení se dá použít docela dobře bez nějakých zásahů do aplikace.

[xkucf03]

A u SQL databází nebo jiných aplikací se snad nedá použít?

Vždyť tohle je stejně věc, o kterou by se měl starat OS a databáze/aplikace by měla maximálně jen říct: tahle data chci mít rychle přístupná a tahle můžou být na pomalejším disku.

[Filip Jirsák]

Samozřejmě, že dá, ale nikoli bez přepsání aplikace. A Amazon těžko bude přepisovat aplikace svých zákazníků.

Aplikace o tom nic neví, která data mají být rychle přístupná – zvlášť v cloudu.

[R]

To uz mohol porovnat disk napriklad s bananom... Ale to by nebola dobra reklama.

[xkucf03]

IMHO je Amazon a trochu dál než Banán.

[Heron]

[xkucf03]

hmm, a přitom většina aplikací dělá kokotiny a navíc je to nesmyslně centralizované – místo aby si X skupin lidí nainstalovalo distribuovanou aplikaci na X menších nezávislých serverů…

[TomasVondra]

Firma může buď provozovat 20 serverů s rotačními disky aby dosáhla požadovaného výkonu, nebo může použít 2 servery s SSD disky. Server stojí netriviální peníze, maintenance stojí netriviální peníze. Hádejte co si firma vybere?