Több tucat cég internetes szolgáltatása szünetelt idén tavasszal, amikor az Amazon Web Services felhőalapú számítógépes platformja leállt. Olyan népszerű „áldozatok” is voltak, mint az egyebek mellett a barátaink megtalálását segítő, helymeghatározáson alapuló Foursquare mobilalkalmazás, a New York Times különböző projektjeiről tájékoztató oldal és a Washington Post által kiadott Foreign Policy.

Ezek mind az Amazon szerverein futottak, tehát azok lerobbanásával kényszerűen beszüntették a működést. A csütörtök hajnalban történt gikszer után csak a következő hét elejére állt helyre teljesen a megszokott rend. Az eset nem volt egyedi, az év folyamán több hasonló leállás is akadt.


Mi mit tud? ■ A történtek után igazolva látták magukat a felhőalapú szolgáltatások (cloud computing) bírálói, mondván, most bebizonyosodott, hogy az ilyesmi nem biztonságos, ezért kritikus üzleti alkalmazásokhoz nem szabad használni. Cloud computing esetén ugyanis a felhasználó csak szolgáltatást vásárol, az ezt lehetővé tévő hardver és szoftver nincs nála. Így nem tőle függ a biztonságos működtetés.

Ugyanakkor éppen ez teszi költségtakarékossá ezt a megoldást: az IT szolgáltató hatékonyabb, hiszen a sok ügyfél miatt méretgazdaságosan tud működni, s mivel erre szakosodott, a folyamatai is optimalizáltak. További előny, hogy a felhasználónál nincs szükség nagy beruházásra, nem kell megvenni a szervert, a hálózati eszközök egy részét és a szoftvereket. Fizetni csak a szolgáltatásért kell, azért is felhasználás-arányosan. A cégeket tehát a jobb ár/érték arány mégiscsak a cloud felé nyomja.

Erre a dilemmára az IT ipar válasza az úgynevezett private cloud (magánfelhő), amikor a rendszert maga a felhasználó hozza létre. Az ettől való megkülönböztetés érdekében a klasszikus cloud megoldás a public cloud (nyilvános felhő) megnevezést kapta. A private cloud révén valóban csökkenthetőek a kockázatok, feltéve, hogy jól csinálják. A birtoklás ugyanis nem egyenlő a biztonsággal, utóbbit csak a hozzáértés tudja garantálni. Fontos, hogy kialakítsák a megfelelő, biztonságot garantáló folyamatokat, tevékenységeket, továbbá a munkatársak (nem csak az IT szakemberek) betartsák a biztonsági előírásokat.

Ugyanakkor a private cloud nem hoz sok olyan üzleti előnyt, amellyel a public cloud jellegéből adódóan rendelkezik. A magánfelhő kihasználásán ugyan sokat lehet javítani, de a jelentős egyszeri beruházást nem lehet megúszni. A szolgáltatás rugalmas bővítésének és szűkítésének lehetősége is korlátozottabb. A private cloud gyökerei inkább a virtualizációhoz köthetők, ami mára elfogadott vállalati gyakorlattá vált.


Variációk egy témára ■ A biztonság és az olcsóság együttes figyelembe vételével lehet eldönteni, hogy mikor mit választunk. Üzletileg kritikus alkalmazásoknál a private cloud a megoldás, más esetekben spórolhatunk a public cloud segítségével. Ezeket azonban érdemes lehet kombinálni. Így jöhet létre a hibrid felhő (hybrid cloud), amikor például az adatréteget a biztonság érdekében private, az alkalmazásréteget pedig spórolás céljából public cloudba tesszük. De úgy is válogathatunk, hogy a kritikus üzleti alkalmazások private, a kevésbé kritikusak public cloudban fussanak.

A döntést azonban nem célszerű elhamarkodni. Mivel mind a megtakarítások, mind a kockázatok az egész szervezetet érintik, stratégiai szinten kell foglalkozni a kérdéssel. Más megoldások lehetnek előnyösek az ágazattól, a vállalati mérettől, az IT menedzsment érettségétől, sőt alkalmazástípustól függően is.


Ha megalapozottan akarunk határozni arról, hogy kell-e egyáltalán tennünk valamit, s ha igen, akkor mely területeken tegyük le a voksunkat a virtualizáció, a nyilvános, a magán, netán a hibrid felhő vagy valami más mellett, akkor átfogó döntés-előkészítő elemzés szükséges. A dolog stratégiai jelentősége, újdonsága és a technológiai komplexitás miatt az IT vezetők akkor alhatnak nyugodtan, ha független minőségbiztosítót is segítségül hívnak.

Kell tudni tárgyalni ■ A számítási felhő igénybevétele átalakítja az informatikai részlegeket is. Ilyenkor a vállalaton belül már nem az IT végzi a szolgáltatásokat, de felel a működésükért, a szolgáltató kezeléséért. Ez annyit jelent, hogy más kompetenciákra lesz szükség.

Példának okáért nem kell majd házon belül szervert üzemeltetni, viszont össze kell foglalni az igényeket, meg kell mondani, hogy mi az a szolgáltatási szint, amire a vállalatnak szüksége van (mert ha többet kérünk, az drágább is lesz), s tudni kell tárgyalni, majd jó megállapodást kötni a szállítókkal.