2008-08-07

Cloud Computing

Megvan az új Buzzwörd amit a különböző típusú és beosztású managgerek és sáleszesek feljegyezhetnek a noteszükbe a prezentációkon puffogtatható kifejezések közé. Igaz hogy nem történt semmi a világban, marad a kliens-szerver architektúra jó eséllyel cluster-ezett szerverekkel és lazán egymáshoz kapcsolódó szolgáltatásokkal, ennek ellenére némelyek ezt világratörő innovációnak élik meg az MS-től kezdve a G-ig.

A Wikipedia szerint - nagyon nagy vonalakban- onnan jön a kifejezés, hogy a meetingeken az internetet felhőnek szokták ábrázolni. Update: sg.hu-s cikk, idézet belőle: "A számítási felhők hívei szerint a jövő útja központi szervereken futtatni a szoftvereket, és az elérésükért pénzt szedni a felhasználóktól." Jó nem?

A Web 2.0 kifejezés elterjedésénél még éreztem valami paradigmaváltást, hogy a request-reply formok helyére bejönnek a rich client alkalmazások. Mások teljesen a szociális oldaláról közelítették meg a kérdést, tehát hogy a közösség építi a fellelhető tudásbázist, de végülis a lényeg, hogy ha nem is hirtelen, de végbement valami ami az internet felhasználásának az elveit változtatta meg. Mások szerint persze ez is marhaság.

Ezzel az új kifejezéssel kapcsolatban éppen az zavar, hogy nincs szó semmilyen paradigmaváltásról, csak kitaláltak egy szinonímát egy régóta meglévő általános dologra.

Ráadásul a Cloud Computing -ról én az elosztott számítási rendszerekre asszociáltam eddig, mint pl. amelyek a személyi számítógépek üresjáratát kihasználva földönkívüli rádióadásokat keresnek, DNS-t kutatnak, kódokat törnek vagy ütköző részecskéket elemeznek. Ide sorolnám még a p2p fájlmegosztókat is tágabb értelemben. Ezeknél az architektúráknál a kliens aktívan részt vesz a rendszer működésében.

Mint a Wikipedia szócikkből kiderül, ez valójában Grid Computing. A grid-ről viszont inkább egy statikusan összeállított viszonylag homogén és szabályos szuperszámítógépre asszociáltam eddig, a felhő pedig egy olyan rendszer volt nálam, amibe szabadon becsatlakozhatnak különféle munkaállomások, tehát topológiai kérdés.

A Cloud Computing architektúrájában a kliens valójában nem része a felhőnek ami a szolgáltatásokat biztosítja, ad abszurdum nem osztja ki a rendszer a gépemre a feladatot, hogy XYZ emailjait tárolja el.

Boncolgathatnánk még a kérdést, hogy miért Computing, de végülis az emailek vagy dokumentumok tárolása és szinkronizálása is valamilyen szinten "computing", akárcsak a legbonyolultabb matematikai problémák megoldása.

Tehát:

  • internet, kliens-szerver architektúra (régi, elavult)
  • cloud computing (modern, trendi)
De a kettő ugyanaz.

Update 2009.01.21: Harangoztak a merevlemeznek, cikk az It-Café-n. A Google-nek, a Microsoft-nak és még másoknak is van tervezett megoldásuk személyes fájlok központi helyen való tárolására. Megemlítik a cikkben a problémákat is. Két dolog nekem is eszembe jutott: mit szólnának a kedves szolgáltatók, ha valaki kapásból csinálna egy lokálisan futtatható titkosító eszközt és így a központi tárhelyre csak értelmetlen bithalmazok kerülnének fel, amit nem lehet vizsgálgatni, indexelgetni, mazsolázgatni? Másrészről környezetvédelmi aggályaim is vannak, mert a saját gépemet lekapcsolom amikor nem használom, egy központi szerver viszont folyamatosan pörög, nem is beszélve a hálózati struktúráról és annak a terheléséről amíg az adatok átérnek a felhőből az aktuális eszközömre. Akkor inkább legyen olyan szolgáltatás amivel be tudom kapcsolni és vezérelni, adatokat lekérni az otthon hagyott eszközeimről. Ja és köszi a szamitasifelho.lap.hu-nak hogy belinkeltek!

2008-08-01

Mercurialozom

Ideje volt már feltennem a sajátgépemre egy elosztott verziókezelő rendszert. Miért is? Saját használatra Windows-on nem akartam CVS-t vagy SVN-t izzítani, viszont a fejlesztőkörnyezet history szolgáltatása elég Mórickás, ráadásul lehet hogy más is be fog csatlakozni a fejlesztésbe. E írás alapján a Mercurial mellett döntöttem. Dióhéjban: git-re nincs Windows támogatás, Bazaar nem rossz, de a Mercurial mégiscsak ismertebb.

Írás még róluk a Javaworld-ön. Összegyűjtve dolgok még a JHacks-en.

1 perc múlva már ott figyelt az installált Mercurial 1.0.1 verzió a Windows-os gépemen.

A 3.3-as Eclipse-hez pedig lehúztam egy plugint.
E levél szerint Zingo Andersen fejlesztgeti pár éve szabadidejében.
Először nem működött valami jól, mert nem tudtam visszanézni a régi verziókat, de végül uninstall után a béta update site-ről szedtem le a legfrissebbet, ami már jól működik. Az ikonok dekorálását explicit be kell kapcsolni a preferences label decorations-nél. Itt van a plugin fejlesztői oldala, itt van a béta update site URL-je is.

http://home.zingo.org/trac/mercurialeclipse

Megvan az SVN-ből vagy CVS-ből megszokott kellemes funkcionalitás. History, diff, annotation. Ezeket használom én, amikor verziókontrollozok. Persze a commit, update és társain kívül.

De van másik plugin is: Merclipse.
Ezt is kipróbáltam, de 5 perc után leszedtem, mert elsőre nem állt kézre a funkcionalitás. (Valami vagy nem működött, vagy nem találtam meg és nem volt jól ledokumentálva hogy hol keressem.)

Team - Share Project-tel lehet varázsolni hamar a meglévő projektből Mercurial repositoryt. Aztán még add-olgatni kell a fájlokat és kommit-olni. Anélkül hogy ismerném a belső működését kijelenthetem, hogy a verziózott fájlok a projektben a .hg könyvtárban kerülnek eltárolásra. Nem szemeteli össze az összes könyvtárat mint az SVN vagy CVS, csak a gyökeret.

Hogy hogyan kell több gépet együttműködésre bírni azzal egyelőre nem foglalkoztam.

A következőn gondolkodtam el: mivel nincs központi repó és minden fejlesztő gépén fenn van a teljes anyag, elvileg nehezebben vesznek el az adatok. Viszont ha tönkremegy valaki vinyója és senki más nem szedte le az aktuális változtatásait az gáz. (Tapasztalt DVCS júzerek cáfoljanak meg ha nincs igazam.) Szóval elosztott rendszer ide vagy oda, mégiscsak jó ha rávésődnek az adatok egy-két masszív központi vasra is. Nyilván meg lehet oldani valahogy.

Mivel egyelőre saját célra használom egyedül, kiélvezhetem a commit comment-ek és a branch-ek előnyeit, de gondoskodnom kell róla, hogy néha kiírjam a repót CD-re vagy valami hasonlóra.

A Selenic-es Wiki-ben volt egy link egy nagyon jó ingyenes elektronikus könyvre, de már nem él: http://hgbook.red-bean.com/hgbook.pdf

(Zárójelben megemlítem hogy most háromféle verziókezelő plugin működik aktívan az Eclipse-emben gond nélkül. Ebből a Mercurial és a CVS egy workspace-en belül van, de úgy emlékszem az egyéb kombinációk is jól működtek eddig.)

Különben pedig valóban. Amíg intraneten SVN-ezik az ember addig mindegy, mert jönnek az adatok mint az olajozott villám, de ahogy pl. mostanában rákapcsolódtam egy távoli Google-s SVN trunk-re https-sel kicsit kényelmetlen lett hirtelen a sebesség, vagyis annak a hiánya. Intraneten néha passzióból history-t nézek vagy compare to-zok. Távoli trunk-on már jobban meg kell gondolni van-e fél percem és sávszélességem ilyen műveletekre. Szóval ja: hasznos lehet az elosztott verziókezelő néhanapján.