Felhőről felhőre

Pár napja jelent meg több portálon a hír, hogy a Microsoft és az Oracle összekötik felhős infrastuktúráikat egymással azért, hogy az ügyfelek élvezhessék az alacsony késleltetés, nagy sávszélesség előnyeit, olyan esetekben amikor egyik szolgáltatás a Microsoft-nál a másik pedig az Oracle-nél van.

Úgy öt éve várom már azt a pillanatot, hogy valami hasonló történjen, de remélem itt nem áll meg újabb évekre az összeborulások sorozata. Szerintem csak tévképzet az, amit fentebb írtam, ennek elsősorban a szolgáltatók örülnek és élvezik előnyeit – a fenti kettő. Aki alacsony késleltetést szeretne az elsősorban a data gravity-vel kellene számoljon. Tehát attól, hogy összekötik magukat egymással, még nem lehet olyan dolgokat csinálni hogy East US régióban lévő middleware szolgáltatás, egy másik földrészen az OCI – Oracle Cloud Infrastructure – egy régiójában használ egy Oracle adatbázist.

Mikor ügyfelek felhős stratégiájába van szerencsém beleolvasni vagy tanácsot kérnek, azt szoktam mondani, hogy minden technológiának és szoftvernek, a saját gyártójának felhőjében – ha létezik – van a legjobb helye. Így természetesen, ha HyperV-n akarok IaaS-t használni, akkor jó eséllyel az Azure lesz az én terepem, ha natív VMware-t – akkor pedig az érdeklődés hiányában megszüntetett VMware Air, helyett pl AWS-ben és most már Azure-ban, ha Oracle-t, akkor az Oracle-nél.

Ami érdekesebb, hogy egészen egyszerűen az IT rendszerek 95%-a nincs készen a felhőbe történő migrációra. Vagy azon okból kifolyóan, hogy túl régi és hozzá van kötve valamilyen régi operációs rendszerhez, amit nem képes egy IaaS szolgáltatás nyújtani, vagy azért mert olyan komplex és többszintű, hogy az fentebb említett “data gravity” fogalmát csak extrém költségek mellett lehet tartani. Egészen sokszor az történik meg, hogy teljes virtuális gépek költöztetése a felhőbe mégsem hozza el azt a TCO-t, amivel az ügyfél számolt. Több oka lehet, de jelentős tényező az adatforgalom után fizetendő díj, mégpedik a felhőből vagy on premises vagy publikus internet irányba történő forgalmazás után.

Szintén borsosan mérik az árát a nem natív “igények” kielégítésére adott szolgáltatásoknak. Pár hete volt egy olyan hír is, hogy a VMware végre natívan fut az Azure-ban. Sokan felkapták a fejüket, nincs másról szó, mint a Microsoft Azure adatközpontjaiban, izolált hardveren, ESXi fölött futtathatunk virtuális gépeket, amelyek VSAN-on vannak elhelyezve. (egyelőre csak két US régióban érhető el) Új-e ez? Nem, mert AWS-ben eddig is lehetett ilyet, csak a másik fél választási lehetősége bővült az ügyfelek számára.

Költséghatékony-e? Biztosan van olyan eset, mikor igen, de szerintem az esetek 98%-ban nem. Nyilvánvalóan nem tudom azt, hogy melyik nagy ügyfélnek, milyen megállapodása van a Microsoft-tal, így milyen kedvezményeket kap a listaárakból, de érezhető a következő ábrán milyen nagyságrenbe tartozó kiadással számolunk.

Nem hiszem, hogy elírás lenne a havi költség, de ezekből a VSAN követelményei miatt kell legalább három darab. Egy évre, egy ilyen három node-ból álló klaszter körülbelül kétszázezer euróba kerül. Ennek felét mondjuk megkapjuk kedvezményesen, de szorozzuk is be hattal, mert egy nagyobb ügyfélről beszélünk. Tehát 600 ezer euró per év, a felhőben 9,2TB RAM, 202,5 TB storage – nem számolva gondolom a RAID1/5/6 veszteségével. Hatszázezer euróból, azért elég szép adatközpontot tudunk fenntartani, eszközökkel együtt.

Amire én várok és szerintem ténylegesen megváltoztatná a felhő elfogadottságát és elősegítené annak szélesebb és mélyebb elterjedését, az az lenne, hogy a felhős szolgáltatók összekapcsolják hálózataikat és ne fizettessenek adatforgalmi díjat a kifelé menő forgalom után.

Elgondolásom egy olyan csomópont, vagy csomópontok többsége lenne, mint az Internet Exchange a telekommunikációs szolgáltatók számára. Azaz egy hely, ahol a nemzetközi sávszélesség utáni fizetendő költségek nélkül, kicserélhetik egymás között az előfizetőik közötti forgalmat. Ilyenre lenne szükség az összes Gartner ábrán prosperáló szolgáltató között. Csak akkor lehet lendületet adni a felhőbe költözésnek, ha az adatforgalom alacsonyabb szintjeiben nem sarcolják meg a vásárlóikat. Értem én az Express Route és a Route 53 stb. előnyeit, de nem mindenki vehet ilyet, illetve ha nekem kell on premises megoldani a kettő közti adatcserét vagy direktben valósítok meg VPN-t a kettő között, akkor bár működőképes lehet a megoldás, de egészen biztosan jó sokat fogok fizetni.

Szintén fel kell mérni egy vállalaton belül, hogy érdemes-e pusztán IaaS-ben tartani az alkalmazásokat. Egészen biztos, hogy java részüket át lehet írni – ez is magas költség – felhős natív működésre. Tehát egy IIS weboldal, ami mögött saját magán van az MSSQL de egy virtuális gépben jó példa lehet, arra hogy az weboldal mehet pl Azure-ba mint szolgáltatás, az MSSQL pedig szintén szolgáltatásként kerül alá. Itt nem lesz – általunk menedzselt – virtuális gép, másképp árazódik, másképp skálázódik. Mérlegelni kell azt a tényezőt is, hogy a felhőben futó virtuális gép másik szolgáltatóhoz történő migrációja vagy visszahozása saját infratstruktúrára, milyen bonyolultsággal és kiadással bír. Ebből a szempontból megértem, hogy miért konzervatív sok ügyfél és maximum IaaS-ig megy el. Könnyebb visszahozni, mint ha SaaS/PaaS-ban futtatná ugyanazt.

Stratégia

Kizárni a felhő használatát nem javasolt. Az nagyon rossz stratégia, hogy nem veszünk tudomást a felhő puszta létezéséről sem. Mivel kis túlzással havonta változik, milyen szolgáltatások érhetőek el, mennyiért és hol, ezért könnyen előfordulhat, hogy előáll olyan felhasználási eset, ahol hasznát tudjuk venni.

Kézenfekvő első sorban offsite mentésre használni, természetesen a megfelelő biztonsági és adatvédelmi feltételek mellett. Itt gondolok a saját kulcs használatára a felhős szolgáltatónál – ekkor ha akarná sem tudná megnézni az adatainkat. Ezekre már van megoldás akkor is, ha saját magam nem szeretnék csak erre eszközt venni és saját adatközpontba tenni azt a kulcstárat. A Thales ad például ilyen szolgáltatást, azaz HSM as a Service-t, saját adatközpontjából.

Az IaaS jó irány, de mindig kell terv és becslés arra, hogy mennyi idő alatt és milyen költségek mellett tudjuk elhagyni az adott szolgáltatót. Változhatnak az árak, a stratégia, ezekre fel kell készülni.

Jól ki kell számolni az on premises és felhős költségek összehasonlítására használt döntési anyagot. A saját adatközpont drága, de alapvetően minél több – határok között – infrastuktúrát teszünk be oda, annál olcsóbbra jön ki per unit – rack unit. Itt nem számolom az eszközök költségét sem a licenszeket, a támogatást sem.

A saját adatközpont és infrastuktúra üzemeltetéséhez szükséges emberi tudás és IT gárda, nem olyan tényező, amit pár hónap alatt újra össze lehet állítani. Ha a felhőbe költözik az ügyfél, akkor más tudásra van szükség, más összetétellel. Ha újra a földre hoznánk a rendszereket, akkor az a tudás ami ehhez kell, lehet már másnál dolgozik vagy éppen feledésbe merült. Kiváló példa az, hogy például az amerikai űrsiklók SSME hajtóműveit állítólag újra nem tudnák legyártani, mert a tudás ami kell hozzá, már eltávozott. A tudás elillant, a képesség is.