Nokia 630 ZDARMA pro nové majitele MSDN

Potřebujete plně automatické škálování v cloudu?

  • Comments 6

Budu upřímný a přiznám, že k obsahu tohoto postu mě přivedla hodně živá diskuse s kolegy v hospodě Seattlu (pokud někdy navštívíte toto nádherné město na severozápadě USA a budete si chtít dát lokální pivo, určitě navštivte Rock Bottom) :-)

Jednou z charakteristik cloudu, Windows Azure nevyjímaje, je elastické chování. To v podstatě znamená, že výkon, který z cloudu získáme je vždy přizpůsoben potřebám, které naše aplikace má. Jde o nádhernou myšlenku a technicky realizovatelnou. Je zde však ono časté ALE – výkon není zadarmo. Čím více odebíráme, tím více platíme. Proto v mnoha případech řadu forem cloud computingu také nazýváme Utility Computing.

Jaké tedy máme teoreticky možnosti v přidělování výkonu?

Plně manuální. U této formy je výkon cloudu kdykoli k dispozici, ale přidělování výkonu je plně na vlastníkovi aplikace. Prostřednictvím administrativních nástrojů přidává nebo ubírá dedikovanou kapacitu cloudu.

Aplikačně automatizované. V tomto případě si aplikace sama, podle definovaných algoritmů a parametrů, žádá o potřebné cloud zdroje. Příklad jak takovou funkčnost zajistit najdete v mém postu Jak jezdit ve Windows Azure cloudu s optimální spotřebou.

Cloud automatizované. Tato forma, v případě Windows Azure zatím hypotetická, funguje tak, že samotný „mozek cloudu“ analyzuje vytížení aplikace a automaticky přiděluje odpovídající výkon.

Vraťme se nyní tématu postu – potřebují zákazníci opravdu třetí formu škálování – cloud automatizovanou? Osobně si myslím, že ne. Jak dobře poznamenal můj kolega Michael Juřek – je to jako by jste si objednali malíře pokojů a řekli – je mi jedno kolik to bude stát, jen ať je to dobře vymalované. Jaký je váš názor?

Díky,

  Dalibor

  • Suhlasim, ze "nekonecne" plne automatizovany cloud je nezmysel. Zmysel to ale uz ma, pokial stanovime hranice - horny a dolny limit - skalovatelnosti, co vlastne robi i amazon. V pripade malire by to teda znelo - vymaluj mi pokoj za 100 Kc a kdyz to bude dobre, tak ti zaplatim klidne i 200 Kc. To ale WA zatial neponuka....

  • Suhalsim s povedanym, ze by asi niekto prilis nesuhlasil, ak "bolo jedno kolko to bude stat". Na druhej strane, napr. minule sa ma niekto spytal, ked som sa mu snazil vysvetlit ako funguje Windows Azure, ci sa da nastavit nieco take, ze ked ma na Windows Azure Web Aplikaciu, tak by chcel niekde nastavit, ze cas odozvy stranky ma byt stale pod 0.5sekundy, a nech Windows Azure (tu asi myslel ten "mozek cloudu"...) alokuje automaticky dalsie zdroje ak je aktualne velka zataz a potom nech si automaticky odpoji ak je zataz mensia.

    Pricom by - ako pisal Stefan vyssie - chcel len definovat horny limit (nekonecno co sa tyka penazi, nie je prijemna predstava ani ked je teoreticka) na zdroje, nad ktory by sa neslo , ani pri nesplneni pozadovanych veci (odozvy do 0..5sek). No a chcel by byt informovany ked mu Azure "samo" prida zdroje - aby teoreticky mohol toto "elasticke spravanie"  vypnut, ked by sa mu uz nepacilo...

    Ja som mu odpovedal, ze pridavat zdroje sa na Windows Azure musi rucne, o AzureScale priklade som nevedel. dik za to.

    Teda taky scenar aky-taky zmysel aj urcitu pritazlivost pre zakaznikov moze mat. Snad by sa to dalo aj realizovat (napr. metrika kolko trva vygenerovanie vysledneho HTML kodu web stranky na strane servra sa snad nejak merat da).

    Teda v podstate by islo skor o aplikacne automatizovane pridelovanie zdrojov, no zakaznik nechce pisat aplikacnu logiku ako to dosiahnut, skor by chcel len deklativne definovat co chce dosiahnut a do ako daleko je ochotny ist pri pridelovani zdrojov (horny limit).

    -- s.

  • Z pohledu návrháře business aplikací na webové platformě si toto dovedu představit jako úžásnou vlastnost pro "zalepení" jedné vývojové fáze, kterou je optimalizace. Pokud se zakázka nestíhá nebo má být hotová v extremním čase, pak tím získáme drahocený čas a aplikaci můžeme spustit dříve i přes její vyšší nároky na prostředky, cloud to za nás vyřeší, uživatel rozdíl nepozná a dev team může stále v tichosti optimalizovat za běhu. I když to bude dražší, stále si myslím, že to je lepší cesta než dodat aplikaci pozdě, což se sebou nese další náklady (pokuty, penále, snížení zisku zákazníka po dobu prodlevy atp.), které zajisté překročí náklady na vyšší výkon cloudu.

    V průběhu optimalizace se pak nároky na výkon logicky snižuji, a s každým releasem jsou nároky na výkon cloudu nižší => náklady na provoz klesají.

    Dovedu si představit, že díky této vlastnosti mohu v extermním případě ušetřit až 30 procent nákladů, zejména pokud je vývoj ve skluzu...

  • Ad Adam Koudela: Ked uz hovorime o byznyse ;) tak by som dodal, ze cloud prostredie ma dalsiu zaujimavu vlastnost, ktoru nemaju klasicke aplikacie (alebo aspon nie v takej miere)...

    Predstavte si, ze prevadzkujete napr. na Windows Azure aplikaciu a platite cloud sposobom za pouzitie zdrojov. Tu ma optimalizacia priamy financny efekt - ked zoptimalizujete pristup k zdrojom - povedzme menej hitov do DB - tak priamo menej platite. A to tiez otvara nove moznosti byznysu - napr. co sa tyka multitenant aplikacii.

    Povedzme nasadite web aplikaciu, na ktorej (nad jednou codebase a jednou db) budete prevadzkovat sluzby pre viacerych klientov, ktory platia nejaky pausal za pouzitie. Cim optimalnejsi je vas kod - tym menej vy interne platite Microsoftu (a tym faktom vasa marza na veci, vas zisk rastie), tym viac zakaznikov mozete na danej aplikacii prevadzkovat.

    Mozno opat prichadzaju casy, ked sa bude hladiet na efektivnost kodu ako za "good old times", ked bola pamat obmedzena a procesory pomale... ;)

    -- s.

  • Ad SlavoF: Určitě s tím souhlasím, má to mnoho výhod a obě dvě zmiňované zde dokážou uspořit značné náklady, ale je nutné počítat zejména s tím, že ne každý scénář může být výhodný a to i přes maximální optimalizaci kódu. My třeba stavíme ERP aplikace na webové platformě, kde se cloud vyplatí jen do určitého počtu uživatelů (zatím cloud však nevyužíváme), neboť po překočení "bodu zvratu" bude investice do vlastní "per CPU license" pro zákazníka výhodnější a hostingové řešení (což v podstatě cloud je) bude ve výsledku dražší.

    Jelikož nejsem developer, tak mě "čistota kódu" a jeho efektivita až tak nepálí, i když samozřejmě zbytečně pomalou aplikaci nepřipouštím - prostě to udržet v rozumných mezích. A je to dávno právě těmi "výkonnými procesry a big RAM", což jsou vesměs zanedbatelné náklady oproti obrovským nákladům na vývoj, resp. na optimalizaci, která může být klidně 100x dražší než několikanásobně nad-dimezovaný server, který výkonostní rozdíl daný méně optimalním kódem hravě odstraní (a teď se tady nebavíme o optimalizaci JavaScriptu na klientovi, to už tak lehce vykompenzovat nejde :-))

    Každopádně Cloud automatizované řešení uvítám a možná to bude jeden z argumentů, proč na Cloud co nejdříve přejít a ušetřit tak u malých a středně velkých projektů nemalé náklady a zvýšit tak konkurenceschopnost v daném odvětví, neboť bude možné aplikace uvézt do ostrého provozu ještě v extrémějších lhůtách než nyní.

    A bude pak jen na developerech, jak rychle kód optimalizují a vyrovnají náklady na stanovenou úroveň.

  • To SlavoF: Asi se dá souhlasit s tím, že by existovaly parametry, podle nichž by se autoškálování provádělo. Otázkou jen zůstává, které by to měly být. Čas renderování stránky je určitě dobrý kandidát, ale dovedu si představit docela reálně situci, kdy vykreslení konkrétní stránky bude pomalé ne z důvodu přetížené Web role, ale třeba databáze, externí webové služby, jejíž data používám, apod. Pak by muselo docházet k docela složité analýze renderování stránky, aby se např. nestalo, že se zcela zbytečně přidává plyn na nevhodném místě.

    Proto si myslím, že zatím Azure takový mechanismu nemá. Ze stejného důvodu také vidím jako lepší řešení tu druhou variantu, kterou jsem popsal - aplikačně řízené. V tomto případě totiž bude škálování daleko snadněší, protože jako autor aplikace rozumím kontextu.

    Závěrem mne napadá ještě jedna úvaha. Možná slyším trávu růst, ale už vidím, kolik lidí si stěžuje, že přidáváme zbytečně moc výkonu, aby jsme více vydělali. :-). To bych fakt nechtěl.

    - Dalibor

Page 1 of 1 (6 items)
Leave a Comment
  • Please add 6 and 4 and type the answer here:
  • Post