Vlákno názorů k článku Cloud je někdy také předražená hračka od Michal Illich - Možná nebylo z článku zřejmé to nejdůležitější. Zkusím...

Možná nebylo z článku zřejmé to nejdůležitější. Zkusím článek tedy shrnout do třech vět:
1. Hrubé náklady na výpočetní výkon jsou v případě Amazon EC2 násobně vyšší než u zakoupeného hardware.
2. Amazon poskytuje ale i jiné výhody, zejména z oblasti škálovatelnosti.
3. Zda výhody převýší nevýhody je na individuální zvážení u každého projektu (ale u Wikidi rozhodně nepřevážily).

Michale promiňte, ale s tím srovnáním jste úplně mimo:

1) U vlastního hardware nezapočítáváte náklady na servis (když vám v pátek večer jeden z disků vypadne, co budete dělat?)

2) U Amazonu lze použít škálování a vaše servery nemusí běžet pořad. U nás běží přes noc 2x HighCPU EC2, ve špičce přes den se automaticky naškáluje až na 8x. Stejně tak přes noc a víkend jednoduše vypínáme celý "beta" cloud.

3) Vaše řešení není zdaleka tak spolehlivé jako AWS. Už jen proto, že můžete (v EU) využít 3 na sobě nezávislých zón (=serveroven) a fungovat tak i při totálním konektivity/na­pájení jedné z nich. Toto navíc jen minimálně navyšuje cenu. Stejně tak u AWS můžeme odstřelit libovolnou instanci a do pár minut za ni automaticky nastartuje náhrada.

4) Nevím kde jste vzal, kolik je 1 CU. Dokumentováná hodnota je 1Ghz Opteron/Xeon.

5) I kdybych uznal, že váš server = 15x HighCPU na AWS, bude mít zcela jistě úplně jiná slabá místa - například konektivitu, propustnost sběrnic, přístup na disk.

6) Využívat storage na instanci je u AWS bad practice. Předpokládám, že to používáte pro databázi - tu lze na AWS primitivně dedikovat na RDS, včetně řešení update, záloh, snapshotů a škálování. Nebo použít NOSQL SimpleDB. V každém případě vám data nezasekávají disk a nebrzdí aplikační instance, což (zdálky tipuji) bude hlavní problém vašeho řešení.

7) Z obchodního hlediska je AWS variabilní náklad a jako takový je závislý na vašem trafficu. Takže zatímco vy v případě neúspěchu odepíšete 150kKč (zbytek je zbytková cena HW), jiný neúspěšný startup odepíše po 6 měsících částku cca 10-20 tisíc, protože si pravděpodobně vystačil celou dobu s 1-2 instancemi. A to nemluvě o hodnotě, kterou 250k investice pro startup představuje a náklady ušlé příležitosti, když je práskne za zbytečný hardware.

8) Srovnávat "neomezenou" konektivitu z ČR a konktivitu z AWS je mírně řečeno "omezené".

1) Viz výhody na konci článku, kde píšu, že vám cloud ušetří náklady na správu hardware. Osobně bych to odhadoval tak na 10-15% nákladů na administraci.

2) Ano, rychlé škálování nahoru/dolů v článku uvádím jako výhodu. Ale při reserved instancích zase vypnutím na půl dne tolik neušetříte.

3) Ano, snažší distribuování napříč datacentry uvádím jako jednu z výhod cloudu.

4) Ze stránek Amazonu u přehledu instancí.

5) Pokud vím, tak hardware je to minimálně stejně dobrý jaký používá Amazon.

6) Souhlasím. Ale v praxi to znamená další náklady navíc u cloudového řešení.

7) Ano, pro několikaměsíční projekty se může cloud vyplatit. Ostatně to uvádím jako jednu z výhod.

8) S konektivitou u Ignumu jsme nezaznamenali žádný problém. Díky za optání.

Přijde mi, že jste v polovině svých "argumentů" pouze přeformuloval to, co uvádím i já v článku v sekci výhody. Jen mi z toho není jasné, proč dovozujete že jsem mimo já :)

To uz tu par lidi zminovalo.

Na druhou stranu je treba rict, ze CloudFront uplne v pohode dokaze mit jako zdroj dat server na ceskem hostingu a ty latecne omezit.

Pak je otazkou, kde ma CloudFront nainstalovane edge servery. Pro webove stranky je to mozna jedno (asi staci stejny kontinent), ale pro nejaka vetsi data to uplne legrace neni.

Rozhodne posilani videa z Irska do Dubaje nebo do Zahrebu neni uplne dobry napad.

Pokud bychom měli pocit, že to ze států jede pomalu, tak předsuneme dvě small instance, na kterých poběží nginx (máme už odzkoušené, že to budeme umět).
Hlavní výpočetní výkon si ale necháme na svém železe.

Berte to jako příklad toho, jak si myslím, že se dá cloud využít rozumně.

No v Cechach to neni ;-) Kdyz traceroutuju z cech, tak dostanu napr.

9 server-216-137-61-26.fra2.cloudfron­t.net (216.137.61.26) 8.524 ms 8.484 ms 8.501 ms

nebo

9 server-216-137-61-49.fra2.cloudfron­t.net (216.137.61.49) 17.165 ms 16.838 ms 18.657 ms

na cemz je krasne videt, jak dva ruzni provideri muzou mit na zahranicni konektivite odlisne odezvy.

O videoprenosech vubec nemluvim, tam je to jeste o jitteru a dalsich tezko ovlivnitelnych parametrech. Slo me hlavne o rozdil mezi tim, jestli cekam na html stranku dlouho a potom dlouho na kazdy dalsi (staticky) objekt na ni a nebo jestli dostanu ty objekty o neco rychleji pres nejakou CDN roztahanou do vetsiho mnozstvi vyznamnejsich peeringovych center.

No na jitter se muze taky dostat rada, nicmene clovek musi myslet na kapacitu. Jeste porad existuje netrivialni rozdil mezi dostupnou/zapla­cenou kapacitou ceskych (chorvatskych, dubajskych) ISP do Frankfurtu a do lokalniho propojovaciho centra.

Prece jen. Internet neni jen web.

Zajímavý nápad. Máte odzkoušené, že to bude fungovat? Sám to nedokážu odhadnout, ale tipuji možné problémy:

1) nevyřešíte geografickou vzdálenost

2) vnášíte možná zbytečně další bod do trasy - takže zatímco ISP návštěvníka z USA může mít výbornou linku někam na Evropy, zbytečně se komunikace natáhne přes nějaké datacentrum třeba na opačné straně USA.

3) Reverzní proxy umístěná mimo vnitřní síť na které máte aplikační servery vám tam asi vnese dalších pár miliskund režie (routování) oproti RP přímo v datacentru Ignum

4) Pokud budete chtít obsah poskytovat na stejné doméně, budete asi dost komplikovaně řešit logiku na úrovni DNS

V našem případě jsme se smířili s tím, že replikovat infrastrukturu do dalších datacentrech mimo EU-WEST-1 by bylo neúnosně drahé (ani ne tak náklady na AWS ale hlavně na správu a vývoj systému replikace dat). Částečně to řešíme posíláním veškerého statického obsahu přes CloudFront.

Děkuji. Můj - ne úplně související - článek k AWS je zde: http://www.lupa.cz/clanky/kdyz-praskne-mrak-je-po-cloudu/

Co se týká RDS, tak to řešení má své výhody a nevýhody, to je na delší debatu podle konkrétního způsobu nasazení. My je využíváme především protože se o ně nemusíme starat + máme out of the box monitoring/aler­ting, řešení záloh, možnost replikace a škálování. Mají ale i své nevýhody - například nedostanete SSH na server ani administrátora do MySQL, což by se často hodilo.

SAmozřejmě nic vám nebrání nainstalovat DB server na libovolnou (i micro) EC2 instanci, nebo dokonce na tu stejnou, kde běží aplikace. Z mých zkušeností je ale zásadní právě to oddělení na samostatný stroj, protože pak se aplikace a DB nepere o disk / cache / paměť

Děkuji za vysvětlení. Vy ty výhody sice uvádíte, ale nezahrnujete do výpočtu. Chápu důvody - nelze to dost dobře přesně vyčíslit, ale na druhou stranu to je přesně to, co dělá AWS lákavým řešením a zásadně to zkresluje objektivitu toho článku.