Názory k článku
Cloud hosting aneb hosting v oblacích

Pouzivame, spokojnost... vdaka za dobre odvedenu robotu

Musíte rozlišovat. U Amazonu EC2 (termínem je tato služba označována jako IaaS) toto nafukování děláte "ručně" přes API Amazonu. Tedy dáte příkaz, aby se spustil nový server a aby se na něj nahrála správný ISO image operačního systému. A většinou také nahrajete data z S3. Celá procedura trvá asi 5 minut.

Každopádně, jelikož Amazon vám umožní nahrát vlastní ISO image operačního systému, tak nechává na vás jak si zkonfigurujete rozdělení zátěže. Je to do určité míry podobné jako když si zřídíte server hosting. Tam také musíte nakonfigurovat Apache,MySQL a bůh ví co ještě. Výhoda Amazonu je ovšem ta, že přidání nového počítače je otázka 5 minut a stejně tak jeho odebrání.

To co píšete, je možné nastavit. Existuje již hromada skriptů, které se u Amazonu o toto starají. Například RightScale je přímo služba pro automatické rozdělování zátěže nad Amazon EC2.

U Google App Engine (což je typický zástupce PaaS) se o toto nemusíte starat. Škáluje sám, podle zátěže. Na druhou stranu některá omezení jsou dosti drastická a doporučil bych ho opravdu pouze v případě, že programujete novou aplikaci. Asi bych se nepouštěl do dobrodružství přepisování stávající aplikace.

Poslední připomínka - snad kromě Amazonu EC2 budete mít vždy servery umístěné v americe. Takže pokud je vaše aplikace určena pro čechy, může se vám stát, že veškerá výhoda cloud computingu vyhučí na datové zácpě na trase Austin-Praha.

Vyborny clanek, diky.

Je videt ze v tom mate opravdu prehled a umite psat srozumitelne - nechtelo by se vam napsat clanecek i o open source projektech z tehle oblasti, napriklad o resenich pro firmy ktere si chteji vybudovat a snadno spravovat vlastni hybridni cloud, namixovat si vlastni servery a treba sluzby Amazonu, jak by to mel umoznovat treba AbiCloud?

Docela mě udivuje, jak stejné GUI mají CloudFront od Amazonu a nedávno redesignované Mosso, viz. sceenshot adminu.

S tvrzením, že se cloud hosting nehodí pro běžný eshop nebo blog nesouhlasím.

Každý, kdo něco takového provozuje, si začne všímat problémů s dostupností. A pokud si zaplatí nějakou monitorovací službu tak zjistí, že většina hostingů má krátké či delší výpadky. A pokud má jo smůlu, tak zažije i nějaký pořádný výpadek. Třeba na celý den. A pokud má hodně velkou smůlu, tak i výpadek spojený se ztrátou dat.

A pak je na místě se ptát, jestli není lepší nějaký cloud hosting, kde jsou data online redundantně uložena. Vzpamatování se z fatálního výpadku (porucha serveru se skripty) je otázkou několika minut. Jaké jsou ztráty vašeho eshopu za hodinu výpadku?

Cloud hosting bych tedy doporučil všem, kteří chtějí zažít vysokou dostupnost svého řešení. A takových lidí přibývá. Je smutné, že zavedení hosteři tento trend ignorují, jak je patrné například z aktuálního rozhovoru s ředitelem společnosti Ignum.

Naprosto souhlasím. A ještě dodávám že spousta e-shopů se potýká s velmi proměnlivým zájmem zákazníků – špičky např. před Vánoci – a možnost platit jen za spotřebované serverové hodiny je tak velkou výhodou.

Dalo by sa to pouzit aj na vypocty, ktore su narocne na velkost RAM?

Napriklad spajanie velkej panoramatickej fotky. Potrebujem tak 10 GB RAM.
OS linux iba jadro a Hugin a Enblend si dodam sam.

Prenos dat bude asi pomalsi ako samotne spajanie panoramy

Na EC2 je niekolko volitelnych typov instancii (tiez aj rozne spoplatnenych). Vid. http://aws.amazon.com/ec2/instance-types/

Napr. pre vas (tato je aj relativne draha...):

Extra Large Instance

15 GB memory
8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
1,690 GB instance storage (4×420 GB plus 10 GB root partition)
64-bit platform
I/O Performance: High
Price: $0.80 per instance hour

Dobrý den
na začátku článku je napsáno: "Představte si obrovský celosvětový e-shop. Takový e-shop potřebuje obrovskou a kvalitní počítačovou infrastrukturu, dimenzovanou na sezónní nápory koupěchtivých. Takže provozovatelé pořídí gargantuovský cluster, který ustojí desetinásobek předvánoční nákupní špičky. Problém je ale ten, že po zbytek roku většina tohoto obřího výkonu zahálí, chytá lelky a z nudy píše emo básně (tzv. Marvinův syndrom) - čili jen zbůhdarma spotřebovává proud. Logické rozhodnutí je nenechat ležet výkon ladem, ale provozovat na něm virtuální servery a pronajímat je zákazníkům."

A k tomu mám otázku - co se stane o Vanocích, až bude provozovatel e-shopu potřebovat ten výkon, na který je to dimenzováno?
Zdá se mi, že se poskytovatel takové služby dostane do stejných problémů jako každý jiný, kdo poskytuje služby na nějaké infrastruktuře. Buď kapacitu chce garantovat a potom ji musí vyhradit, nebo je to služba best effort.
Jak toto řeší Amazon? Nedostane se zákazník s e-shopem na jejich infrastruktuře do problémů v době, kdy Amazon bude potřebovat kapacitu a zákazník taky?

Dobrá otázka. Podobná padla na konferenci WebExpo v říjnu. Odpověď Amazonu je taková, že oni samozřejmě sledují nárůst alokované kapacity a nechtějí svým zákazníkům ustřihnout jejich weby (i když taková možnost v jejich SLA existuje), takže průběžně navyšují kapacitu. A jelikož oni těch serverů mají fakt mnoho, tak i když nějaký web začne exponenciálně růst, tak u nich se to projeví jako lineární přírůstek. A díky tomu mohou efektivně plánovat nákup další kapacity. Tedy nebojte se, ani vánoce vás neodpojí.

Raz sa im to uz cele zrubalo... (teda raz co ja viem)... ale inak zatial sa drzia naozaj statocne, nemozem sa stazovat...

No myslim, ze to je stejne jako treba ve financnictvi s rozkladanim rizika. Nemuzou garantovat 10 nasobnou rezervu vsem, ale v praxi ji dodaji kdyz ji budou potrebovat jednotlivci. Pak to je jen o rozlozeni mezi ruzne typy sluzeb. Kdyz budou 90% zateze delat eshopy, tak bych se vanoc docela bal :-)

Na druhou stranu, u opravdu velkeho hostingu uz to muze vypadat tak, ze pokryva znacnou cast populace a bude stavet na tom, ze lidi nemuzou delat vic veci zaroven. Takze kdyz vzroste zatez treba u zpravodajskych webu kvuli nejake udalosti, tak zas klesne jinde. O vanocich budou zas vsichni nakupovat a ostatni weby se budou flakat. Docela by bylo zajimave zjistit, jestli uz se takove chovani nekde neprojevuje.

Dobry den,
taktez me tato otazka napadla, ale myslim si, ze kdyz uz se nejaka firma rozhodne nabizet ostatnim takove sluzby, tak to dostatecne naddimenzuji aby to produkcni systemy neomezilo a jeste sypalo peniz;)

Pokud to je ale dimenzované na služby pro zakazniky, tak se ztrácí výhoda toho, že mám dočasně volnou svoji kapacitu a je tu stejné jako standardní hosting. Rozdíl je v technologii a ne v tom, že prodávám dočasně "nadbytečnou kapacitu"

Moc pekny clanek! Obzvlast se mi libilo srovnani a predstaveni poskytovatelu cloud hostingu. Uvidime jak se to bude vyvijet dobudoucna a zda-li zacnou poskytovatele hostingu migrovat hromadne na virtualni reseni a nabizet klientum produkty "site na miru" (ne uplne na miru samozrejme, ale podobne jako to ma Amazon)

Já jsem to naopak pochopil tak, že na S3 jsou hlavně data. Přesněji zvlášť data a zvlášť obrazy serverů. Pokud ale S3 umí jen uložit a načíst soubor, tak asi musím mít na svém serveru nainstalovaný i databázový server (MSSQL, Oracle, Firebird...) a sám se musím postarat o zálohování do S3. Z toho mi plyne, že buď budu do S3 ukládat aktualizovaný obraz celého serveru včetně aktuální databáze, a nebo budu využívat zálohovací mechanismy použité databáze a jen vytvořené zálohy databázového serveru ukládat do S3. Úplně jasné mi to tedy není.

Je možné využít Amazon Elastic Block Store, která funguje jako perzistetní úložiště.

Dajú sa v takomto prípade nejako ochrániť dáta tak, aby ich nevidel poskytovateľ služby? Celkom by ma to zaujímalo.

Má tu někdo zkušenosti s náročným výpočtem. Budu v nejbližší době potřebovat hodně velký výpočetní výkon. Potřebuji minimální diskový prostor (odhadem 30–50 MB), zato CPU čím víc, tím líp (přizpůsobím aplikaci). Jedná se o vlastní hybrid neuronové sítě, expertního systému a něco na způsob genetického algoritmu. Naprogramováno v C#, s příchodem Visual Studia 2010 bude odladěno na X vláken, takže třeba 30 CPU klidně vytížím na max. Odhadovaný čas běhu 1–2 dny. Pak 0. Nejedná se o veřejně přístupný web či službu. Potřebuji výsledek (každý víkend), který se pak využije jinde.

Díky všem za jakýkoliv postřeh.