Cloud computing - budoucnost nebo chiméra?

15.7.2010 10:44 | Přečteno: 1978×

V posledních letech technika cválá stále kupředu a člověk ji nemůže ignorovat, pokud nechce zůstávat pozadu. Jedním z fenoménů dnešní doby je stále populárnější pojem "cloud computing". Jaká je skutečná budoucnost tohoto trendu a jaké to bude mít důsledky pro firmy, uživatele, ale také pro vývojáře a "ajťáky" vůbec? Bude to znamenat jejich hromadnou rekvalifikaci? To jsou otázky, které si člověk, zajímající se o IT občas položí.

Problematiku je přitom třeba vidět v širších souvislostech. Například dříve si každý průměrný automechanik-amatér byl schopen opravit spoustu závad na autě, dnes však musí do servisu, vybaveného diagnostickým zařízením ..Trend je zadávat služby třetím stranám, doba "kutilů" je již definitivně za námi ..

A nyní se dostáváme k problematice cloud computingu. Firma má možnost zadat péči i svá data i síť někomu vzdálenému, který se bude starat i o chod serveru, zálohování dat apod. Firma ušetří za běžnou údržbu, ale bude platit pravidelný poplatek někomu dalšímu. Lidé, kteří cloud computing propagují říkají, kolik se ušetří peněz, času a nervů, když třeba lokální server selže. Poskytovatel cloudu zajistí obnovu serveru sám.

Je to právě tahle cesta, kterou se bude ubírat logistika menších i větších firem? Odzvonilo lokálním firemním serverům? Ano, řada otázek je na místě: Jak jsou data uložená třeba na druhém konci světa bezpečná? Nemůže je poskytovatel zneužít, případně nedojde k prolomení ochrany? Nebudou vzdálené servery třeba v málo bezpečných teritoriích?

V neposlední řadě je tu také spolehlivost připojení. Ta stále stoupá, dnes je situace jiná, než třeba před 5 lety. Ale budou data dostupná třeba právě v okamžiku, kdy dojde ke klíčovému jednání se zákazníkem? Ano - zálohování dat. Ale to samo o sobě není triviální záležitost a někdo se mu musí věnovat.

Některé přední IT firmy dávají cloudu zelenou. V první řadě Microsoft. Bude to další krok ke změně světa ve stylu "Big Brother"? Firemní data hromadně v cizích rukou, trochu mě z toho mrazí, domýšlím-li si různé katastrofické scénáře, počínaje ještě větším zneužíváním cílených reklam. Ale já jsem ze starého světa - uznávám to. Rád bych znal názory mladších a v IT branži kompetentnějších osob v této záležitosti.

       

Komentáře

[tom]

IMO zamenujete could computing a to kdo sluzbu provozuje. Firma sama o sobe muze mit interni cloud (tedy presneji receno v budoucnu by mohla mit, zejmena pokud je velka), ktery spravuje sama.

I kdyz je to buzzword tak je to spis technicky termin - urcite paradigma. Ze je neco cloud neznamena, ze to musi byt za morem u nejakeho poskytovatele.

[Dalibor Smolík]

Já jsem si toho vědom. Cloud je široký pojem. Spíš než o detaily mi šlo o princip - zda mít data pod relativní kontrolou ve firmě a mít člověka, který se o vše stará nebo to přenechat někomu zvenčí. To, že jsou data za mořem - je trochu extrém pro znázornění příkladu, ale bude i tohle běžná věc.

[tom]

Rozumim. Proti prikladu nic nenamitam. Jestlize jde v otazce zejmena o kontrolu, pak myslim ze se to bude ridit zejmena velikosti firmy. Ruzne mensi firmy a startupy urcite s radosti takovou nabidku vyuziji. Naopak vetsi a velke (banky, nadnarodni koncerny) budou prave kvuli otazce kontroly spise konzervativni a bud si cloud zorganizuji sami nebo toho cloud specialistu pozvou aby jim to postavil a pripadne sparavoval u nich.

[Dalibor Smolík]

Ano, tenhle scénář je pravděpodobný. Ale to si budou muset cloudingové firmy uvědomit, kdo bude jejich klientem - jinými slovy absence velkých firem může znatelně snižovat výši jejich plánovaných (resp. předpokládaných) zisků.
Na druhé straně spektra - u malých firem - se podstatně omezí počet zakázek pro menší administrátorské subjekty případně sníží se příležitosti pro studenty, mající trvalou brigádu u firem ve formě spravování serveru, nastavování aplikací apod. .

[melkors]

Obavam se, ze se aplikace samy nenastavi Ba dokonce ani nenapisi ... alespon do doby, kdy budou k dispozici skutecne AI, coz hned tak nebude.

[Käyttäjä 11133]

Většina bank a nadnárodních společností už dávno data u jiných organizací má. Většina z nich využivá outsourcované IT (ok, český trh je celkem vyjímkou), jediný rozdíl mezi současnýma nabídkama těch service providerů je ten, že například využívají separátní bare-metal hardware, dedikované sítě,... namísto toho, aby používali virtualizovanou síť pro všechny zákazníky. Ale například primární storage se centralizuje a sdíli, stejně jako backup infrastruktura. Proč asi? Servery jsou levné, síť je levná, ale dobré diskové pole ať už HDS, nebo HP, nebo NetApp stojí mnohem větší hromadu peněz, stejně jako kvalitní pásková backup infrastruktura (kolik myslíš, že stojí taková knihovna StorageTek SL8500), proto i velcí service providery mají tyto prvky sdílené pro všechny zákazníky. Maximálně mají oddělení na úrovni vertikálních trhů - zvláštní infrastruktura pro banky (protože mainframy. Tivoli Storage Manager,..) a ten zbytek.

[brutalniBommel]

pane kolego, vsimnete si prosim, ze pan Smolik hovori prave o malych firmach, ty nemaji urcite TB dat.

[pavlix]

Pane kolego, všimněte si prosím komentáře na který Marek odpovídal.

[CEST]

Taky o cloudech premyslime. Potrebujeme testovaci stroje pro supportaky, ktere bezi X dni a pak se muzou zrusit a misto nich vytvorit nove. To neni sice specificky cloud ve smyslu "bezi X virt.serveru, prijde napor, tak se nastartuje dalsich Y virt.serveru, aby se zatez rozlozila a az prejde napor, zase se pocet snizi", ale i tak je podobna myslenka "mame Z HW serveru a na nich potrebuji uzivatele startovat virtualni stroje - co delat s nevyuzitymi stroji?"

Pres noc pak kompilujeme zdrojaky, pres den jenom obcas, takze kompilovaci virt stroje taky pres den moc nebezi - prejdeme taky na nas system postavenej na OpenNebula s vlastnim rozhranim.

Kolega uz trosku zkousel Eucalyptus, ale to je opravdu jen na rozlozeni zateze-jeden typu server se spusti na vice hostech a zvladne tak obslouzit vic klientu. Jenze my potrebujeme podle pozadavku startovat ruzne VM.

Do cizich rukou sverujeme jenom public data (aktualizace a patche), ale privatni (subversion zdrojaky) bychom asi na cizi servery nedali. Takze resime sami vysokou dostupnost.

Osobne si myslim, pokud se s cloudama zacne opravdu hodne pracovat a firmy budou chtit udrzet svoje data u sebe, tak spis zacne pribyvat externi sprava cloudu. Proste externi odbornici prijdou do firmy, rozchodi cloud a budou to pouze spravovat. Pak by mohla firma treba i svuj nevyuzity cloud pronajimat pro externi zakazniky. Ale tam je pak zase otazka, kdo by daval svoje data cizi firme. Cili cloud u ciziho subjektu si budou zrizovat pouze firmy s public daty nebo jenom na zkousku. Citliva data zustanou ve firme.

Ale uvidime, jak to bude.

[brutalniBommel]

...To neni sice specificky cloud ve smyslu "bezi X virt.serveru, prijde napor, tak se nastartuje dalsich Y virt.serveru, aby se zatez rozlozila a az prejde napor, zase se pocet snizi", ale i tak je podobna myslenka ...

ne,ne, prave tak se dnes propaguje myslenka cloudu. To, ze bezi mimo firmu nejaka aplikace je stary kafe. U nas vykladali:

Amazon ma po svete rozesetou radu servroven, kde si uzivatel prave predplati moznost provozu virt. stroju. Pri nedostatku kapacity mu Amazon ty jeho virt. stroje nastartuje. Pro nas je to urcita sance, protoze nase aplikace jsou na servrech v internetu je jedno, kde ten server je. Amazon je urcite lepe napojen nez 08/15 provider z horni-dolni.

Co se vypadku tyce, je lokalni server samozrejme lepsi. Nase zkusenosti:

- lokalni aplikace - replikovane servry v miste - 2 x 4 hodiny vypadek za 8 let

- nyni 2 roky SAP vzdalene , 4 hodiny vypadek za 1 rok.

O data strach nemam, Amazonu posleme virt. image , s tou si nemohou nic pocit, problem by byla data, ale ty davame do proprieterni databaze, kterou dnes stejne nikdo nedokaze precist. (at zije aplikacni server)

[Käyttäjä 11133]

No řekněme, že je cloud, interní cloud a enterprise cloud. To co provozuje T-Systems je docela dobrý příklad cloudu se kterým nebude mít problém ani nikdo kdo má mnoho citlivých dat. Pochybuju, že by se v dohledné době střední společnosti ubíraly cestou cloudu, z prostého důvodu, příliš si cení svých dat na to aby je strčily do běžných internetových cloudů typu Amazon,... ale zase nejsou dost bohaté na to, aby si pořídili vlastní interní cloud, nebo si pronajali enterprise cloud od velkého service providera kterému se dá co se ochrany dat týče věřit.

Střední společnost si koupí nějaký low-end storage, pár serverů, hodí si na to vmware a bude tomu říkat interní cloud. :) Celé jim to bude spravovat šmudla bez potřebného vzdělání a backup a disaster recovery strategie nebudou. Tohle je současná situace v ČR.

Cloud není jen o snížení těch nákladů, ikdyž je pravda, že sdílet primary infrastrukturu je finančně výhodné. Hlavní benefit za cloudem ve velkých společnostech je business agility, jak dlouho si myslíš, že trvá deploynout nový server ve společnosti s 20 000 zaměstnanci? I virtualizovaný server se do produkce dává třeba 2 měsíce, s cloud infrastrukturou se dá tohle snížit třeba na 2 dny, nebo i na pár hodin.

Stal se ti problém se SAPem a potřebuješ udělat klon systému pro investigaci a začít disaster recovery pro obnovení businessu? V "legacy" modelech je to něco co uděláš jen těžko, v "cloud" modelu je to poměrně triviální, hotové během pár hodin.

Jak dlouho se dělá QA systém na SAPu v legacy modelech? Pár týdnů, (3 dny vezme jen obnova dat a pre a post stepy applikačních specialistů, bez deploymentu primární infrastruktury - storage, server, síť), v cloud modelu máš primární infrastrukturu deploynutou během pár minut, a klon databáze děláš jako FlexClone (nebo obdobu na jiných diskových polích) taky během pár minut. Pak už zbývá jen čas aplikačních specialistů.

[Dalibor Smolík]

virtualizovaný server se do produkce dává třeba 2 měsíce, s cloud infrastrukturou se dá tohle snížit třeba na 2 dny, nebo i na pár hodin.
Tohle je mi jasné a je to hlavní argument zastánců tohoto trendu. V takovém případě jsou finanční a časové úspory nesmírně významné. Čas ukáže, zda nebudou tyto nesporné výhody vykoupené velkou závislostí subjektů na cloudingových firmách, což by mohlo v budoucnu (při hromadném přechodu na tyto služby) vést ke vzniku nevyvážených a nevýhodných obchodních (či dokonce politických) vztahů. Samozřejmě, takové vztahy již dnes existují (kdo má ropu, je král), tady by došlo k jejich prohloubení i v jiných oblastech.

[Dalibor Smolík]

Jen aby nedošlo k mylné interpretaci - nejsem odpůrce cloudingu, jen pokládám k zamyšlení otázky, které považuji za důležité pro vedlejší efekty tohoto trendu.

[Käyttäjä 11133]

Spíš se mi zdá, že vycházíš z toho, že si společnosti řeší své IT interně, což ale ve světě velkých společností není zdaleka pravda. Dle mých odhadů je to tak, že malé společnosti mají svůj vlastní HW a outsourcovaný management, střední společnosti mají vlastní hardware i management a velké společnosti mají outsourcovanou infrastrukturu i management.

[Käyttäjä 11133]

Velké společnosti jsou už dávno u velkých service providerů typu Accenture, T-Systems, IBM,... pro ně se nic moc nezmění, to tihle service provideři si jen zoptimalizují své interní procesy.

Nadnárodní společnost nepůjde do credit-card cloudu, ale nemá problém s tím aby jejich infrastruktura byla součástí interního cloudu service providera. A závislost... zákazníci dokážou na konci kontraktu dělat půl roku dlouhou tranzici kvůli slevě ve výši 10%, takže tohle pro ně problém není... :) Ani s klaudem, ani bez něj. (Jako by tranzice nic nestála :D - po nákladech na tranzici je úspora třeba jen 3% za celou dobu trvání konraktu (3-5 let).)

[pasmen]

Nevím o jakém problému se SAP systémem tu mluvíš. Jestli o HW nebo aplikačním problému. Pokud o HW, obnova škáluje pouze s velikostí databáze. Sám jsem toto zkoušel a pro naší malinkou 200Gb databázi to trvalo cca 6 hodin komplet (instalace OS, instance, ...). Pokud aplikační problém, proboha, jak se ti to mohlo stát, nepoužíváte QA? A jak se dělá QA systém? Hmm, jak by se asi dělal, udeláš dump z produktivního systému, instalace s importem a pak už jen pár crcek typu TMS apod. Jakých pár týdnů Nám pár týdnů (asi pět, hrubého času) trval upgradem z R/3 4.7x200 na ERP 6.0 EHP4 včetně UC migrace. A to jsem to dělal poprvé. A to jak asi uznáš je trochu jiná liga než prachmizerné vytvoření QA

[Käyttäjä 11133]

Slyšel si někdy, že databáze může mít i 8TB například a pak obnova z pásek na vytvoření QA systému trvá 4 dny?

Pokud o HW, obnova škáluje pouze s velikostí databáze.

No jo, pouze...

Pokud aplikační problém, proboha, jak se ti to mohlo stát, nepoužíváte QA?

Samozřejmě, že zákazníci mají QA systém, ale to neznamená, že ten kdo ty systémy spravuje nemůže uděla chybu, nebo že se něco při testování nepodaří odhalit.

A jak se dělá QA systém? Hmm, jak by se asi dělal, udeláš dump z produktivního systému, instalace s importem

Aha, jak dlouho chceš exportovat tu 8TB velkou databázi? A jaký to bude mít performace impact na výkon? U velkých systémů by si udělal klasický bare metal disaster recovery, udělal post stepy na tom systému a pak připojil do sítě.

To že ty děláš ve společnosti kde jsou 4 IT specialisti a databáze má 200GB je sice pěkné, ale zkus začít přemýšlet ve větších měřítcích, databáze co se sizují po TB, prostředí, kde se dodržuje ITIL. Zkus si taky představit situaci, že se nejedná o přeplácnutí starého QA systému, ale že zákazník chce klon svého rok starého produkčního SAPu. Takže musíš deploynout nový server, udělat storage provisioning, network konfiguraci, OS deployment a pak restore s post stepy.

[pasmen]

Výmluvy... Ale jinak si trefil přesně počet IT specialistů u nás, máš bod! Ale zase mínus bod za zmrdšťinu (deploynout, bare metal disaster recovery, ...) to je jako číst sci-fi

[Käyttäjä 11133]

A co teprve business agility, to je zmrdština Nejsou to výmluvy, spíš nedostatek zkušeností s vělkým nasazením na tvé straně.

Já narozdíl od tebe už nějakého toho zákazníka s 8TB databází potkal, spolu s disaster recovery a věř mi, není to pěkný pohled na top management nadnárodní společnosti, když se dozví, že budou bez BIčka 5 dní zrovna když je čas reportingu. A to ještě nebylo ani pořádné DR, protože hardware i OS přežily v pohodě, jen databáze umřela.

[pasmen]

Já bych neřekl, že mám nedostatek zkušeností s velkým nasazením. S velkým nasazením nemám žádné zkušenosti Mám jistou představu, jak to asi funguje v takové opravdu velké společnosti. Zrovna pracuji na projektu, ve kterém konzultanti dodavatele nasazují řešení v opravdu velkých společnostech typu České pošty apod. Rozdíly mezi velkou a malou společností by se tak daly shrnout do velikosti dat a mírou užívání zmrdšťiny

[frEon]

Ale zase mínus bod za zmrdšťinu pridavam se. Me zase pobavil performance impact na vykon

[cthulhu]

8TB z pásek 4 dny? teda nevim co tam v tom helsinki používáte vy, ale..zastaralá LTO3 mechanika dává běžně 80-140MB/s (záleží na kompresi atd.) klony dneska umí kdejakej midrange, kdo na to nemá, holt ať si to "bastlí" na ZFS. prý kde se dodržuje ITIL..to jsem se fakt zasmál (jsem ichtyl-certified). ITIL je sada velice obecných doporučení, která se zhusta aplikují tak, aby prostě jen byla, ne aby něčemu pomohla. Ne vážně, zkus ty věci někdy zažít, ne si o nich jenom přečíst. Ještě nám něco pověz o six sigmě jak je to skvělý prosím, to tu dnes ještě v těch eskapádách buzz word nezaznělo. Za jak dlouho je server nasazen do prostředí, není fce vyjádřená počtem zaměstnanců, spíš platí - čím víc jsi zaoutsourcován, tím víc čekáš.

[Käyttäjä 11133]

8TB z pásek 4 dny? teda nevim co tam v tom helsinki používáte vy, ale..zastaralá LTO3 mechanika dává běžně 80-140MB/s (záleží na kompresi atd.)

To sice jo, ale jen pokud je po FCčku připojená přímo k tomu serveru a ne přes sdílený backup ethernet po kterém teče hromada dalšího trafficu. A taky bych nezapomínal na to, že je potřeba ještě přehrát archivní logy, což si taky vezme nějaký ten čas.

klony dneska umí kdejakej midrange

Jak přesně chceš klonovat systém, který si zazálohoval na pásky a na poli ho už nemáš?

ITIL je sada velice obecných doporučení, která se zhusta aplikují tak, aby prostě jen byla, ne aby něčemu pomohla.

ITIL je sada doporučení, které se implementují u service providerů aby měli alespoň nějaké procesy na které se zákazník může spolehnout a ne aby každý dělal co se mu zlíbí, nebo třeba taky nic.

A můžeš mi říct, kde přesně jsem řekl, že ITIL je něco skvělého a úžasného? Já totiž ITIL (respektive ITSM nějaké procesy) považuju za sice nutné, ale velké zlo bez kterých se velké společnosti neobejdou.

Za jak dlouho je server nasazen do prostředí, není fce vyjádřená počtem zaměstnanců, spíš platí - čím víc jsi zaoutsourcován, tím víc čekáš.

Čím více má firma zaměstnanců tím více má zpravidla restriktivnější pravidla a procesy, které se při takovém nasazování musí dodržet - tedy více administrativy kolem, proto to trvá déle.

[pasmen]

To sice jo, ale jen pokud je po FCčku připojená přímo k tomu serveru a ne přes sdílený backup ethernet po kterém teče hromada dalšího trafficu.

To je ovšem amaterismus nejhrubšího zrna Vše záleží na tom, jak moc si dat (a rychlosti případné následné obnovy) ceníš. Každý si snad spočte, že pokud mají data nějakou cenu, vezmu raději zálohu a letím s ní na druhý konec světa tryskáčem, kde provedu rychlou obnovu, než abych to cpal přes sdílený ethernet...

Čím více má firma zaměstnanců tím více má zpravidla restriktivnější pravidla a procesy, které se při takovém nasazování musí dodržet - tedy více administrativy kolem, proto to trvá déle.

Právě z toho důvodu, že jsou pravidla restriktivnější a procesy jednotné, přesně popsané a v principu jednoduché, trvá jejich nasazení kratší dobu. Nevím kde jsi vyčetl, že to trvá déle...

[Käyttäjä 11133]

Právě z toho důvodu, že jsou pravidla restriktivnější a procesy jednotné, přesně popsané a v principu jednoduché, trvá jejich nasazení kratší dobu. Nevím kde jsi vyčetl, že to trvá déle...

V praxi, protože ne každý požadavek zákazníka bude v service description partiřné služby. :)

To je ovšem amaterismus nejhrubšího zrna Vše záleží na tom, jak moc si dat (a rychlosti případné následné obnovy) ceníš. Každý si snad spočte, že pokud mají data nějakou cenu, vezmu raději zálohu a letím s ní na druhý konec světa tryskáčem, kde provedu rychlou obnovu, než abych to cpal přes sdílený ethernet...

Všechno je to o penězích, zkus si spočítat kolik by tě stála dedikovaná LTO4 mechanika pro každý server v datacentru kde máš 10 000 serverů :) A taky nevím kde si vzal to, že ta serverovna je na druhém konci světa. A je to sdílený backup ethernet (tedy ethernet dedikovaný pro zálohování, ale sdílený mezi všemy servery co se zálohují) a i po něm to jede 60MB/s, zkus si spočítat cenový rozdíl mesi SANem a tím Ethernetem a možná zjistíš, že těch 20MB/s rozdíl ti za to ve většině případů nestojí.

Jistě, pokud máš pár serverů a jeden SAN, tak není problém do toho SANu do jiné zóny připojit ještě tu jednu páskovou knihovnu a zálohovat přímo po SANu.

A BTW hodně štěstí s nakládáním StorageTek Enterprise páskových knihoven do tryskáče a s následnou instalací v cílovém datacentru. :) Nebo si fakt myslíš, že si prostě z té knihovny ty pásky vytáhneš, pošleš a tam je do nějaké jiné knihovny strčíš? Hodně štěstí s podporou od vendorů...

[pasmen]

Sorry, odmítám se bavit v tomhle tvém zmrdojazyku, protože mu nerozumím Takže závěr je, že jsi mě asi přebil argumenty, minimálně cizími slovy!

[Käyttäjä 11133]

V posledním příspěvku jedno slovíčko Enterprise, jinak všechno technické pojmy... No nevím, kde je ten zmrdojazyk. :)

[podlesh]

To nic. Někteří lidé si prostě nedovedou představit, že se anglicismy používají i z jiného důvodu než aby člověk byl "cool a in".

[deda.jabko]

problem je, ze stopka mluvi zmrdstinou schvalne... vendor, benefit, business, ...

a obcas z toho lezou perly jako vyse zmineny ,,performace impact na výkon'' nebo ,,service description partiřné služby''

[default]

Já bych to neviděl jako záměr. Já třeba neznám překlad devadesáti procent odborných termínů do češtiny. A nemyslím si, že je to důvod, abych své znalosti nepředával dál.

Každý, kdo se v dané oblasti pohybuje, ty termíny již zná, nebo se s nimi v nejbližší budoucnosti setká. Kdo je nezná, patrně nemá o danou problematiku zájem — tudíž nechápu, proč přispívá do diskuze, o jejíž téma zjevně nemá zájem.

[Heron]

Je to záměr. On se k tomu hrdě hlásí.

[default]

Aha. To jsem nevěděl. Tak to se omlouvám.

[Käyttäjä 11133]

Co je záměr? Já neznám správné překlady těch termínů. :) Pravda, záměr může být to, že je ani vědět nechci, ale to je jiná story.

[Chytrex]

Pravda, záměr může být to, že je ani vědět nechci, ale to je jiná story.

Pokud je tam kde pracuješ korporátní jazyk angličtina, je pochopitelné, že český termín je pro Tebe zbytečně zabraná kapacita v paměti..:)

[podlesh]

Je to záměr. On se k tomu hrdě hlásí.

Mohu požádat o link? Ať jsem v obraze...

[Heron]

Link nemám, bavíme se s Markem na jabberu .

[podlesh]

Aha, neperzistentní kanál, to je nefér

[podlesh]

No neříkám že se mi takové prznění jazyka líbí, ale osobně se řídím jednou zásadou: každému dám šanci ukázat, zda se chce domluvit (a pak chápu že mu to třeba moc nejde, koneckonců opak by byl docela pokrytecký) nebo zda si jen mele svou (a pak patří do kategorie které někdo říká "zmrd").

Zatím mi to připadá, že se Stopka snaží, takže u mě má kladné body.

[pasmen]

Ale já přece neříkám, že je to zmrd Ani si to nemyslím. Ale používat za každou cenu super bomba extra cool anglické výrazy tam, kde je mnohem vhodnější český ekvivalent, to je zkrátka zmrdojazyk Je mi jedno proč je tak někdo používá, proti, že si připadá hustej, nebo proto, že zkrátka byl moc dlouho mezi skutečnými zmrdy a tak nějak se mu to vžilo. To je fuk. Ale ta mluva je vtipná. Btw nedomnívám se, že citace slovníku cizích slov přispívá k domluvě.

[podlesh]

Koukám nápověda nepomohla, takže trknutí - co když člověk prostě češtinu normálně nepoužívá? Třeba když je v Helsinkách...

[pasmen]

Buď se tedy bavme anglicky, s čímž bych problém neměl, nebo mluvme česky, a používejme pouze zažité technické výrazy. Zbytek je zmrdšťina

[Lord Vetinari]

Nevies doporucit nejaku veselu paku? Rad by som zahral nejakeho leteckeho napodobovatela, a myslim ze klavesnica sa nehodi.

[Lord Vetinari]

Problem skor je ze Stopka hovori ako to je. A taktiez problem je ze ista cast nedokaze pochopit ze IT infrastruktura s 1000 strojov funguje trochu inak. Treba zazit ten rozdiel... zmeni to pohlad na svet.

[Dalibor Smolík]

Přestože nejsem z branže IT, dovedu si takovou infrastrukturu docela dobře představit. Jde o velký subjekt, který má dostatek sil i prostředků kombinovat cloud computing s vlastní správou (zálohování citlivých dat ve firmě, účinné šifrování dat, které jsou venku atd.), takže tam problém není. Ale z vlastní praxe vidím, jak to chodí v menších firmách a tam jsou rádi, že jim někdo umí nastavit poštovního klienta . O nějakém šifrování nemůže být ani řeči, ale přesto by se data hodila konkurenci .. Viděl jsem i nezašifrovanou wifinu. Kdo se v IT pohybuje, vidí kolem sebe trochu jinou úroveň. Ale stačí se motat třeba kolem drobných výrobců hraček, zemědělského družstva, středně velké truhlárny apod...

[Lord Vetinari]

Nuz velke objekty ktore nerobia v IT obycajne (imo 98% pripadov) zaplatia service providera.Jemu akurat povedia ze co chcu Hranica medzi outsourcingom a cloudom je nejasna: obcas hardware vlastni service provider, obcas jeho zakaznik a casto je vlastnictvo hardweru tazko definovatelne (rozne druhy leasingu ... ) - rovnako sa aj lisi co este je pod spravou offshoringu.

Inak viem ako to chodi v malej firme, dakedy davno som v jednej takej robil. Je to ine, a aj ked niekedy mam pocit ze lepsie asi sa uz nevratim.

[Chytrex]

Sdílím tvůj názor.. a myslím že dokonce i vím přesně o čem Marek píše.. Pokud to není náhoda tak člověk se stejným jménem maká ve stejné firmě:) Mimochodem je to nejmenovaná finsko/švédská firma:D

[Lord Vetinari]

Taktiez viem velmi presne o com Marek pise

[frEon]

jo, to mi pripomina, jak kamarad vypravel, ze letel 3x do madarska pro pasku ze zalohama a pokazdy kdyz se vratil, paska byla necitelna. pri treti ceste se musel hadat na letisti, ze paska do rentgenu opravdu nesmi

[Michal Vyskočil]

Hlavní benefit za cloudem ve velkých společnostech je business agility, jak dlouho si myslíš, že trvá deploynout nový server ve společnosti s 20 000 zaměstnanci? I virtualizovaný server se do produkce dává třeba 2 měsíce, s cloud infrastrukturou se dá tohle snížit třeba na 2 dny, nebo i na pár hodin.

Co se dá reálně stihnout je jedna věc, dohodnuté SLA věc druhá .

[TM]

Pane Smolík, vůbec se neomlouvejte za to, že jste ze starého světa a hrdě se k tomu hlašte.
Technicky vzato je cloud computing OK, pokud jej budeme brát jako technologii, kterou si nasadí firma ve své vlastní režii. Bohužel v podobě, jak je zákazníkům dnes vnucován je to IMHO největší katastrofa v dějinách IT a počátek cesty společnosti do otroctví.
Svěřovat cizímu megaprovozovateli důležitá firemní data, být závislý na připojení do Internetu, nemít pořádnou kontrolu nad aplikacemi, které s těmi daty pracují - to může udělat jen blázen. A raději ani nebudu rozvádět kam to dospěje v případě obyčejných domácích uživatelů, kteří jdou dnes radostně "jako ovce na porážku". Teď radostně hýkají, že soukromí nepotřebují, jednou jim - těm chytřejším - zmrzne úsměv.

[brutalniBommel]

ja to tak nevidim. My to dnes uz delame bezne, mame 4 GB image, ktery v sobe spravuje i data a to vse bezi u nejakeho providera. Ten zajistuje jenom backup, coz u virtualnich servru je hracka. Data jsou takhle napadnutelna zrovna tak, jako kdyz mate server u sebe. (je otevreno jen par portu>1024 a ssh). Ty 4 GB jsou po malou firmu(do 10 zamestnancu uplne vpohode, navic navysit to na 8, 16 je uplna malickost.

Co se dostupnosti tyce, tak zrovna v nedeli vypadla v oblasti Rudne smerem na Karlstejn elektrika na 2 hodiny, mobilni internet fungoval dal. Dneska jsou vypadku proudu a internetu v CZ srovnatelne.

Jina vec je spoluprace takove aplikace s mailama a file-servrem. To bych delel lokalne, protoze na takovem fileservru maji i takove male firmy podstatne vice dat (i kdyz je to z 90% srot) nez co muze nejaky image stravit.

[j AM]

A teď si představte, jaká hrůza, většina firem je na externím dodavateli závislá už teď! Místo aby měli svoje vlastní elektrárny tak jsou připojeni přes externího dodavatele a často nemají žádné záložní zdroje! Hrůza!

[Dalibor Smolík]

To ale není totéž. Samozřejmě si dneska doma chleba nepečeme (ale už jsou i domácí pekárny) a elektřinu si nevyrábíme. Firemní data jsou trochu jiného charakteru než samotná elektřina. Jsou snadno zneužitelná (zejména konkurencí) a mají být pod zvláštní ochranou.

[j AM]

Ale "ztráta napájení" může být stejně likvidační jako ztráta dat takže závislost tam je taky. Pokud jsou data nějakým způsobem šifrovaná je skoro jedno kde jsou.

Ono vždy záleží na situaci, ale obecně bych se toho tolik nebál.

[Dalibor Smolík]

Stále mám na zřeteli menší firmy. Pokud je ve firmě někdo, kdo zajistí šifrování dat, pak ani žádný cloud nepotřebuje. Zvládne to vlastními silami.

[pavlix]

Pokud jsou data nějakým způsobem šifrovaná je skoro jedno kde jsou.

Pokud to nebylo myšleno jako vtip, tak doporučuju se trochu víc zamyslet. Prvně ta věta tak příšerně zjednodušuje, že je už od začátku jasné, že je to kec. Druhá věc je, že ta data jsou aktivně používána, tudíž v rozšifrované podobě.

[Dalibor Smolík]

Ano, přesně tohle jsem měl na mysli. Možná jsem jen nedůvěřivý a čas ukáže, že cloud je správná cesta (případně ztráta soukromí bude běžným standardem ) - ale napadlo mě to a tak jsem se zeptal.

[Heron]

Nelze jinak než: +1

[msk]

... Bohužel v podobě, jak je zákazníkům dnes vnucován je to IMHO největší katastrofa v dějinách IT a počátek cesty společnosti do otroctví.

Napriek mojmu zvysenemu prahu paranoie a nutnej davke opatrnosti som sa rozhodol presunut 3 mnou spravovane firmy pod google apps. Zatial (!) som na ziaden problem nenarazil a neregistrujem ziaden naznak toho, ze by nejake interne informacie boli zneuzite. Je pravda, ze cas ukaze, firmy mozu lahko podlahnut politickym tlakom a data vydat, ale to mi pride pravdepodobnejsii nasrany zamestnanec, ktory vytrubi tajne veci svetu. A to je potom jedno, kde tie data lezia.

... být závislý na připojení do Internetu

Hm? Kolko % ceskych firiem by lahlo popolom, alebo sa otriaslo v zakladoch, keby im vypadla konektivita dajme tomu na rok? Odhadujem dobrych 20-40%.

... nemít pořádnou kontrolu nad aplikacemi, které s těmi daty pracují

Pocitace zamestnancov velkeho mnozstva firiem ( chce sa mi povedat vacsiny ) su plne aplikacii, ktore nie su pod kontrolou a nikto poriadne nevie, co v skutocnosti robia ( preslaveny skype, rozne picovinky a hry, samotny windows ako taky, virusy, alebo akykolvek closedsource software nepochadzajuci od dobre znameho dodavatela ).

[Dalibor Smolík]

Kolko % ceskych firiem by lahlo popolom, alebo sa otriaslo v zakladoch, keby im vypadla konektivita dajme tomu na rok?
Stačí třeba na dvě hodiny, je-li to třeba před rozhodujícím jednáním s hlavním zákazníkem

[Dan Ohnesorg]

A co kdyz cestou na to jednani nabourate? Kdyz zacne ve firme horet? Kdyz je sekretarka poleje kafem.....

Nikdy neni mozne osefovat vsechny situace a nema smysl jednu aktivitu mit jistenou na 99.999%

[Dalibor Smolík]

Tohle je jasné. Taková věc se totiž i v obchodním světě toleruje - stát se to může každému. Zákazník v takovém případě ke konkurenci obvykle nechodí, je tu určitá solidarita. Ale netoleruje se nepřipravenost k obchodnímu jednání z jiných důvodů, než z klasických "viz major". Taková firma se okamžitě vyhodnotí jako nekompetentní a odchod zákazníků začíná. Tohle mi můžeš věřit, vyzkoušeno z 30 leté praxe v zahraničním obchodu.

[Adolf Hitlerstein]

Ja by som do cloudu svoje data nedal...

[frEon]

presne, pak se ochladi, zacne prset a skonci v nejakem mori. to tak