Privát vagy publikus felhő előnyösebb egy cégnek?

Vannak az életnek nagy kérdései, amelyekre nap mint nap keresik a választ. Ilyen lehet a tyúk és a tojás elsőbbségbeli problematikájának megfejtése, aminek szerencsére nulla százalék IT vonatkozása van, így erre tőlünk az ég világon senki nem vár megoldást. Viszont manapság ténylegesen napi szintű probléma az adatbiztonság, adattárolás, ha másért nem, hát a májusban beköszöntő GDPR korszak végett. S minthogy az internet korát éljük, napjainkban már jellemzően nem az íróasztal fiókjába suvasztott floppin tároljuk a fontos adatokat, hanem felhőben. De pontosan milyen felhőt válasszunk cégünk kritikus állományainak, adatbázisainak? Hol spórolhatunk és hol a határ, amikor már adatvesztést kockáztatunk? Erre keressük ma a választ. 

Publikus vagy privát felhő? Mi a különbség? 

Mielőtt belevágnánk, próbáljunk megválaszolni egy nagyon egyszerűnek látszó, de valójában korántsem könnyen megválaszolható kérdést. Mi a különbség a privát és a publikus felhő között? Publikus felhőt valószínűleg mindenki látott, rengeteg ilyen szolgáltatás található az interneten, átmeneti fájlmegosztóktól a fájlok folyamatos tárolására szolgáló megoldásokon át a komolyabb, akár irodai szolgáltatásokat is integráló szolgáltatásokig. Lényegük, hogy bárki, bármikor regisztrálhat (ingyen vagy pénzért), vagyis a szolgáltatás mögött infrastruktúra teljesen megosztott, nem sajátíthatjuk ki az adott szervert, hogy ott csak a mi cégünk felhasználói ténykedhessenek. A privát felhő ezzel szemben korlátozható, az adott infrastruktúra erőforrásait, szoftvereit kizárólag a mi cégünk lányai és fiai használhatják, teljesen függetlenül attól, hogy a privát felhő tényleg a cég egyik szobájában zümmög, vagy Amerika déli részén van rázárva a szerverszoba ajtaja. Ebből aztán rögvest következik a privát felhő két előnye: biztonságosabb, hiszen nem regisztrálhat rá akárki, ráadásul terhelni is csak a cég fogja a szerver erőforrásait. Emellett a privát felhő az elvárásainknak megfelelően skálázható a végtelenségig, szemben a publikus megoldás korlátozott skálázhatóságával. Az már egy másik kérdés, hogy a privát szerver hardvere is tényleg a mi tulajdonunk-e, vagy csak bérbe vettük. Tulajdonképpen mindkét eset előfordulhat, mert bár elsőre az tűnik logikusnak, hogy ami privát, az totálisan legyen a miénk, de az élet ennél sokszínűbb. A lényeg, hogy bármilyen megoldást is válasszunk, egy privát felhő infrastruktúráját csak a cég által kiválasztott felhasználók érhetik el.

Kinek, melyiket?

Miként általában egy szerver üzemeltetésének, úgy egy felhő szolgáltatás fenntartásának is vannak költségeit. Éppen ezért ha a céges felhőt teljesen a saját felügyeletünk alá akarjuk venni, saját szerverrel, saját szoftverekkel stb., akkor első körben azonnal át kell gondolnunk, hogy kompetencia és erőforrás tekintetében készen állunk-e erre a feladatra. A saját infrastruktúra ugyanis saját felügyeletet jelent, vagyis nekünk kell foglalkozni a biztonsági megoldásokkal, a fejlesztésekkel, frissítésekkel, verziókövetéssel, beszerzéssel, kompatibilitási kérdésekkel. Ehhez szakember és hely szükséges. A saját infrastruktúra biztonsági szempontból jól felügyelhető, viszont éppen ez a hátulütője is: nem mutogathatunk másra, ha hibázunk, a biztonság is teljesen a mi felelősségünk.  Ezzel szemben a publikus felhők használatánál nekünk csak a fizetéssel kell törődnünk, a konfigurálás egyszerű, a frissítések, biztonsági javítások, titkosítási megoldások, hardver cserék és egyéb rendszergazdai problémák pedig nem minket terhelnek, hanem a szolgáltatót.

De keverhetjük is a dolgokat! Privát felhőt ugyanis külső megoldások segítségével is kialakíthatunk, ami jelentősen csökkentheti az IT támogatási költségeket. Példaként ott a Microsoft Azure vagy az Amazon Virtual Private Cloud, amelyekkel létrehozható privát infrastruktúra is, amelyet szintén csak az autentikált felhasználók érhetnek el. De építhetünk ki önálló infrastruktúrát egy VMware vCloud Suite segítségével is, így biztosítva mondjuk egy globális cég esetén, hogy az adatközpontot bárhonnan elérjék a cég munkatársai. 

Példaként talán jó lehet még a levelezés kérdése is: ha egy Gmail vagy Microsoft O365 levelezésre fizetünk elő, akkor bár céges levelezésünk lesz, tulajdonképpen még mindig publikus felhőben dolgozunk. Ezzel szemben ha egy - akár Amazonos, akár Azure-os megoldásra épülő - virtuális gép alatt telepítünk saját levelezőszervert, akkor a levelezésünk privát felhőbe kerül. Utóbbinál viszont az üzemeltetésről, fejlesztésekről is nekünk kell gondoskodnunk.

Ha a Microsoft Azure esetében kvázi csak a hardvert vesszük igénybe, az még publikus felhőnek számítható, míg ha egy telepített virtuális gépen (például Windows Server) futtatjuk a domain controllert és így oldjuk meg a felhasználók autentikációját, akkor alapvetően privát felhőnk van. Mellesleg autentikálhatunk Microsoft Azure AD megoldással is, így a végén eljutva a hibrid felhős megoldáshoz. Itt fontos előre meghatározni, hogy melyek azok a szolgáltatások, adatok, amelyek kikerülhetnek a cég irodáján kívülre, s melyek azok, amelyeket fizikailag sem engednénk távol magunktól.

Közepes- és kis vállalkozások gondolkodhatnak még a Microsoft Dynamics NAV megoldásában is, amely rugalmas és bővíthető, ráadásul jól integrálható független szoftvergyártók megoldásaival is. De érdekes felhő szolgáltatást nyújt például a Kaspersky is, ahol a vírusvédelemhez és a többszintű védelemhez nem kell kialakítanunk egy bonyolult biztonsági központot és infrastruktúrát, hanem felhő alapon kapjuk a kényelmesen menedzselhető biztonsági megoldást a cég eszközeire.

Egyéb szempontok

A fentiekből talán kiderült, hogy a “melyiket válasszuk” kérdésre sajnos nem nagyon lehet mindenkire egyformán érvényes választ adni. Az alap tételek természetesen itt is azok, hogy CAPEX vagy OPEX költségekben gondolkodunk inkább, illetve milyen kompetencia, erőforrás áll a cég rendelkezésére. Sőt, fontos szempont az is, hogy mennyire hektikus az erőforrások felhasználása, hiszen egy általában alacsony terheltségű, néha viszont kiugróan magas nyúzásnak kitett rendszer esetében a ritkán előforduló nagy terhelésnek megfelelő hardverbe és szoftverbe beruházni nem feltétlenül megtérülő ötlet. Sokkal jobban megéri egy átmenetileg felskálázható megoldást alkalmazni a terheltebb időszakban.

Szempont lehet továbbá, hogy miként osztjuk el a befektetéseket. Fizetünk egyetlen szolgáltatónak, például a Microsoftnak, hogy minden Azure alapokon ketyegjen? Vagy inkább több szolgáltatóból válogatunk a különféle részfeladatokhoz? Érdekesség, hogy a Microsoft esetében, ha Azure-os környezetbe telepítünk valamilyen open source, vagy hivatalos terméktámogatás szempontjából gyengébb megoldást (pl. Debian Linux), akkor a Microsoft teljes terméktámogatást ad nekünk hozzá. Vagyis ebből a szempontból már jobban jártunk, mintha teljesen saját környezetben telepítettünk volna.

Egy Amazon vagy Azure alapokon nyugvó felhőszolgáltatás esetében adataink redundánsan tárolódnak, akár három példányban, így probléma esetén van honnan visszaszerezni a sérült adatok eredetijét. Ugyanezt megvalósítani házon belül igencsak költséges lenne.

Ha több felhőszolgáltatásból igyekszünk építkezni, akkor figyelembe kell venni azok minőségi különbségeit is. S ha már itt tartunk: egy adatközpont sebességénél erősen beleszámít annak földrajzi elhelyezkedése is, ráadásul ha sok kis állománnyal dolgozunk, akkor ezek le- és feltöltése szintén ronthatja a kiszolgálási sebességet. E szempontból egy alkalmazásszerver vagy adatbázis szerver esetében praktikus lehet a házon belül tartás, mert ha nagy az adatmozgás, a sebesség ingadozásán túl még az is előfordulhat, hogy a szolgáltató felárat két a letöltésekért.

Összetett kérdés tehát ez is, amelyre nincs igazán etalon, minden cég esetében egyedi a helyzet, s ennek megfelelően kell átgondolni - rövid- és hosszútávú terveket egyaránt figyelembe véve -, hogy milyen irányban fejlesztünk. A fenti szempontok viszont tökéletesek lehetnek kiindulási pontnak.