Cikkem első részében azt próbáltam megvilágítani, miért kelthette a felhőszolgáltatás azt a reményt, hogy megoldást ad a szállítóhoz kötöttség (vendor lock-in) problémájára. Végül azzal a konklúzióval zártam gondolatmenetemet, hogy bizonyos esetekben továbbra is fennáll ez a veszély.
Ráadásul a felhőbe költözésnek platform és szoftver szintű szolgáltatásoknál olyan költségei is lehetnek, amikkel esetleg az igénybe vevője már csak akkor szembesül, amikor a váltást meglépi.
Az alábbiakban azt vizsgálom meg, hogy miként lehet elérni, hogy felhőfüggetlen szolgáltatáshoz juthassunk.
Nem jó, ha utólag vagyunk okosak
Mint az IT-ben olyan sok esetben, itt is a legfontosabb a megelőzés. Mint Miles Ward, a Google Cloud Platform globális vezetője írta egy internetes közleményében, nem lehetetlen olyan felhőmegoldás-független informatikai rendszert kialakítani, ami őrzi a felhőszolgáltatások rugalmasságát, skálázhatóságát, és nem szorítja be az ügyfelet egy szolgáltatóhoz.
Ezt kijelenteni persze könnyű. De milyen lépéseket kell követnünk ahhoz, hogy ez meg is valósuljon?
Először is aktív ellenállást kell tanúsítani a gyártói elköteleződéssel szemben. Minden hosszú távú szerződés veszélyes lehet, és az előre fizetett tételek is erősen torzíthatják a döntéshozatalt.
A technikai csapdahelyzetek
De ez még nem ad megoldást a technikai elköteleződés elkerülésére. Az nagyon nehézkes lehet, hiszen sok szolgáltató szabadalmaztatott API-kkal zárja le az értékesebb szolgáltatásait, és az alkalmazásokat valójában ezek köré tervezi.
Ezek a „ragadós szolgáltatások” jelentős ösztönzőként hatnak, hogy a fejlesztők, rendszerintegrátorok a „rövidebb utat” válasszák, azaz némi könnyebbségért cserébe inkább bevállaljanak – az ügyfelek nevében – egy kis függőséget. Ezzel azonban egy olyan technikai jellegű adósságot vesznek a nyakukba, ami akkor lesz különösen szembetűnő, amikor valami sokkal erősebb, jobb, szebb megoldás érkezik.
Több társaság megpróbált segíteni a felhasználóknak kikerülni ebből a csapdából. Olyan absztrakt réteget hoztak létre a zárt API-ra, amivel a felhasználó képessé vált egy eszközt több felhőszolgáltatáson is használni. Ez elvben nagyon szép, de a megvalósítás már igencsak törékenynek bizonyult, ugyanis kompromisszumra kényszerítette a felhasználót, mert mindig a leggyengébb megoldás adta a funkcionális maximumot. És hát természetesen a felhőszolgáltatók sem örültek neki, mivel megtörhette a felhasználóik röghöz kötését.
Szerencsére van lehetőség ezen csapdák elkerülésére. Ki lehet alakítani olyan skálázható, költséghatékony architektúrát, amelyben nem kell elfogadni sem a gyártói kényszerkötődést, sem a legkisebb közös technikai funkcionalitás elvét. Egy ilyen megoldásnál mindaddig használhatók maradhatnak a zárt, tulajdonosi termékek, amíg azok rendelkeznek a nyílt API-k kezelésének lehetőségével.
Senki nem állítja, hogy ez egy egyszerű és gyors munka. Sokkal inkább egy nagyon összetett, komoly szaktudást, felkészültséget igénylő feladat. De az erre fordított erőforrások – leginkább pénz és idő – a rendszer üzemben tartása során megtérülnek. És minél több rendszert ültetünk át erre az architekturális felépítményre, annál kisebb lesz a költsége mind a kialakításnak, mind a fenntartásnak.
Nem spórolható meg a kockázatelemzés
Annak eldöntésére, hogy egy zárt világú felhőszolgáltatót választunk, vagy egy olyat, ami előkészíti gyárilag azt is, hogy alkalomadtán el tudjunk költözni, már egy kockázatelemzés része kell legyen, amit a beszerzésnél be kell(ene) építeni az értékelési szempontrendszerbe.
A döntési helyzet felhőszinten nagyon hasonló, mint a helyi rendszereknél, amikor azt vizsgáljuk, hogy a fizetős és zárt vagy a nyílt és ingyenes rendszereket válasszuk-e?. A felhőnél valamivel még könnyebb is a dolgunk, hiszen nem merül fel például olyan probléma, hogy honnan szerzünk olyan megfelelően kiképzett szakembereket, akik nem rettennek meg némi kódelemzéstől, és akár újra is tudják fordítani a teljes rendszert. A felhőnél ugyanis ez is a szolgáltatás része lehet.
A Google például – több más felhőszolgáltatóval együtt – felismerte, hogy nem rossz, ha például Cloud Platform esetében nagyobb hatalmat adnak a felhasználó kezébe. Természetesen tisztában vannak azzal, hogy ez a megközelítés egyben megadja a felhasználónak a szabad mozgás lehetőségét, de bíznak abban, hogy az általuk létrehozott nagy teljesítményű, stabil és költséghatékony megvalósítás, valamint az alacsonyabb kockázat és a kisebb kitettség sok vállalat számára vonzó lesz.
Tehát van megoldás?
Összegzésképpen elmondható, hogy a korábbi, helyi IT problémái a külső felhőszolgáltatók megjelenésével részben eltűntek, ám lettek helyettük újak. Azok a stratégiák, amelyek segítettek elkerülni a gyártói kényszerkötődést, itt már részben hasznavehetetlenek, így helyettük újakat kell kidolgozni.
A felhőszolgáltatótól való függetlenség megőrzésére most két fő irányt látok megvalósíthatónak.
1. Használjunk hibrid felhőt! Ebben az esetben ugyanis mindig megvan az a lehetőségünk, hogy erőforrásainkat „visszahúzzuk” a vállalaton belülre, majd újra kiterjesszük, de már más irányba.
2. Használjunk nyílt, ingyenes és interoperábilis rendszereket, API-kat! Ebben az esetben azt nyerjük, hogy minden elem szabadon futtatható lesz akár több felhőszolgáltatónál is.
a melléklet támogatója az EURO ONE
Projektek O-gyűrűje. Mit tanulhat egy projektvezető a Challenger tragédiájából?