Nem túlzás azt állítani, hogy minden cégnél, ahol IT van, felmerül a felhő használatának lehetősége, illetve annak vizsgálata, hogy egyáltalán érdemes-e ezzel foglalkozni, ha igen akkor milyen mértékben. Teljesen világos és azt hiszem minden veszély nélkül kijelenthető, hogy az on premises (utálom az on premise kifejezést) van és mindig maradni fog, a csúszka változik szervezetről szervezetre vagy éppen egy szervezeten belül az idő folyamán. A felhő nem az evolúció következő lépcsője, bár minden gyártónál ez állt a marketing fő üzeneteinek centrumában, ezért sokan elhihették azt, hogy ezt a csúszkát teljesen el lehet tolni a publikus felhő irányába, on premises meg semmi sem marad. Erre a gyártók is rájöhettek és ma már inkább a hibrid/multi-cloud a fősodor, ennek mentén elsődlegesen egy második telephelyként, felfújható buborékként vagy éppen DR telephelyként gondolnak a publikus felhőre.
Ennek akkor van realizása, ha on premises képesek vagyunk olyan szolgáltatásokat nyújtani, amelyeket amúgy az IT-tól elvárnak. Ha például a konténerizációt saját infrastruktrúrákban egyáltalán nem tudja szolgáltatni az IT, akkor minden bizonnyal vagy nem lesz kontéres alkalmazásfejlesztés, marad minden monolitikus az ezzel járó mindenféle hátránnyal együtt vagy éppen valamelyik publikus felhőben fogja ezt használni a fejlesztői csapat. Itt alapvetően nem hibrid felhőről van szó, hanem arról hogy egy adott szolgáltatást azért használok a felhőben, mert ez on premises nincs a katalógusomban.
Korábban írtam arról, hogy véleményem szerint az IaaS nagyon rossz irány a felhőben de ennek ellenére a felhős adaptáció és az on premises környezetekre épülő alkalmazások és szolgáltatások, nincsenek felkészítve a nem IaaS működésre. Ezért is kerül elő rengeteg alkalommal, hogy valahogy a publikus felhőbe képesek legyünk kimozgatni virtuális gépeket.
Itt alapvetően két út van:
- Saját adatközpontban pl VMware/HyperV/KVM akármi és a kiválasztott felhőszolgáltatónál ezzel vagy megegyező virtualizáció vagy éppen eltérő
- Saját adatközpontban például VMware és a publikus felhőben pedig lényegében bare metal-on futó VMware.
Ezek mentén azért kiszámolható, hogy ha van 100 darab virtuális gépem, átlagosan 4 vCPU-val, 16GB RAM-mal és 400GB SSD tárolóval, akkor az mennyibe kerül az első esetben és mennyibe a második opcióban, mikor lényegében megveszek egy 3-4 node-os klasztert ha kihasználom, ha nem.
„Rejtett” költségek
Migráció módja és költsége
Mibe kerül az adott on premises workload migrációja. Például a tool költsége, az ezen dolgozó szakemberek bére. Első esetben egy VMware ügyfélnél nem kézenfekvő, hogy lesz abból a VM-ből majd Azure-ban egy HyperV virtuális gép. Ezeket a migrációs lehetőségeket meg kell vizsgálni, kidolgozni, dokumentálni és tesztelni. Ha ez kielégítő akkor sokszor végrehajtani.
Megérteni az alkalmazásokat
Egy minimális impact-tal járó felhős migráció során csak úgy lehet alkalmazásokat mozgatni, hogy értjük a működésüket. A leállítási sorrent elég jó kezdet lehet, de nem elégséges. Pontosan tudni kell, hogy egy CRM rendszer, például melyik adatbáziskiszolgálón melyik adatbázist használja, mennyit forgalmaz, mennyire érzékeny az esetlegesen megugró késleltetésre – ha mégsem egyszerre mozgatnánk az adatbázisokat futtató VM-et és az azt használó alkalmazást futtató gépet. Ezeket mind mind fel kell rajzolni, validálni és kidolgozni azokat a „csomagokat” amelyek mentén fel lehet építeni a migráció sorozatát.
Ha megértettük az alkalmazásokat, akkor modernizálni őket ha lehet
Olyanra gondolok, hogyha például van 10 darab IIS kiszolgálóm, 10 különböző VM-ben, akkor lehet hogy elegendő ezek számára IaaS helyett csak Web App-ot vásárolni a felhőben. De még ez sem elégséges, meg kell érteni mennyit dolgozik és hogyan. Vagy például lehet, hogy érdemesebb egy teljes SQL szerver mozgatása helyett csak egy adatbázis mozgatni a felhőbe.
Adatforgalom
Szerintem ez a legdurvább tétel, amit kevéssé hangsúlyosan vizsgálnak. Nem mindenki teheti meg, hogy számára dedikált kapcsolatot vásároljon – pl Azure ExpressRoute – vagy AWS Direct Connect – itt azt hiszem a kimenőben nem is lehet korlátlant választani.
Szóval:
- kiknek szolgáltatok, kik az ügyfeleim és ez mennyi adatforgalmat generál ha az a szolgáltatás amit kimozgatok a felhőbe pont az amiket használnak?
- mely rendszerek beszélnek on premises irányba és mennyit? Mentek/replikálok-e bármit a felhőből a saját adatközpontomba?
Tegyük fel hogy naponta azért a mentést szeretném elhozni. A felhős gépeim/szolgáltatásaim úgy 100TB adatot használnak és ennek naponta 3%-a változik. Ez nagyon konvervatív becslés. Ez a 3TB mondjuk mindenféle mágia után 1,4TB-ra összevonható és én ezt szeretném saját adatközpontba letárolni. Havi 30 nappal számolva ez akár több ezer dolláros tétel is lehet és akkor még csak a mentésről beszéltünk – hangsúlyozom, hogy vannak korlátlan opciók, amiben nincs adatforgalmi díj, de annak is van egy költsége.
Hálózati kapcsolat
A saját adatközpontból történő szolgáltatás nem saját felhasználók számára, eddig is megkövetelt egy redundáns és megfelelő védelmet adó internetkapcsolatot és az ehhez szervesen hozzátartozó switch/router/tűzfal eszközöket. A saját felhasználók nem úgy és nem olyan szabályok mentén érik el a saját erőforrásokat, mint a publikus internet felől érkező ügyfelek. Viszont ha bemozgatjuk a felhőbe az egészet, akkor azért az ilyen belső felhasználási forgalom számára is meg kell alkotni azt a megoldást, amely line rate képes biztosítani a megfelelő tűzfalazási képességet hiszen attól, hogy valaki Express Route-ot vesz, még nem jelenti azt, hogy ott nem kell törődni a biztonsággal.
Szakértelem
Ha nem olyan publikus felhőt, illetve azon belül szolgáltatást választunk – VCF on Azure, VCF on AWS stb – amelynek üzemeltetési gyakorlata igen nagy részben már ismert saját adatközpontunkban, akkor az adott felhőt ismerő mérnököket meg kell fizetni. Mielőtt meg fizetnénk nekik, fontos őket megszerezni, amely a jelenlegi munkaerőpiacon erős kihívás, aztán megtartani őket, ami meg még komolyabb feladat.
Folyamatos önellenőrzés
Ennek saját infrastuktúrában is így kellene lennie, de az esetek 90%-ban egyáltalán nincs így. Arról van szó, hogy ha elindítok egy szervert/alkalmazást, akkor az ezeknek adott erőforrásokat meghatározott időnként újra és újra felülvizsgálom. Ha túl kevés, arra minden bizonnyal a megnyíló jegyek az ITSM rendszerben felhívják a figyelmet, ne adja az ég a felhasználók háborognak. Viszont az túl sok kapacitást már nehezebb fellelni, a túl sok CPU-ra, túl sok RAM-ra senki sem panaszkodik, pedig ezek pénzbe kerülnek. Igaz volt ez amúgy a saját adatközpontra is, de ott mindenki túlvásárolja magát és teszi ezt CAPEX alapon. Szóval ott ha bent van 44 darab ESXi, két processzorral és darabonként 512GB RAM-mal, akkor azt már kifiziettem, nem nagyon számít hogy 4 vagy 8GB RAM van az SQL alatt, mert amíg nem fogy el alatta a fizikai hardver, addig ez láthatatlan pazarlás.
Ezzel szemben a felhőben a havonta fizetendő összegben a 4 és 8GB között pontosan a két mennyiség közötti plusz költség fog megmutatkozni. Akkor pedig ha havonta látszódik ez, akkor érdemes megnézni, hogy tényleg kell-e az alkalmazás életciklusában, a projekt ezen fázisában e plusz erőforrás vagy csak ott maradt, mert volt egy könyvvizsgálat és kellett a plusz terhelés miatt.
Biztonság
Minél jobban elosztott egy rendszer, annál nehezebb biztonságban tudni. Itt end to end biztonságról beszélni igen szövevényes, mivel a felhőben használt tárolók titkosításától úgy körülbelül a különböző CASB megoldásokig minden ide tartozik. Az elsőre egy fizikai biztonsággal rendelkező adatközpontban nem kritikus használni, a felhőben viszont célszerű. Ha több felhőben is használok szolgáltatásokat, akkor egy jó Cloud Access Security Broker is kell – bár ez ugye elsőlegesen a felhasználók és a felhős szolgáltatások relációjában értelmezhető. Ezeknek mind van költsége, pont úgy licensz, mint olyan embereké akik ezeket ismerik és karbantartják a szabályokat stb. bennük.
Kis fény az alagút végén
Több gyártó is relizálta a jelentőségét a felhő OPEX alapú fogyasztásának kényelmét és próbálja azt on premises infrastuktúrában is biztosítani. Így vásárolható a rack-től, a szerveren át az utolsó switch-ig körülbelül minden. Ez picit elveszi az élét a felhőnek, bár az adatközpont és alapvetően az infrastuktúra alsóbb rétegeinek üzemeltetése továbbra is marad saját hatáskörben. Vannak törekvések amúgy a data center as a service lehetőségekre, amik szerintem eléggé előremutató alternatívák lehetnek a következő öt-tíz évben.
