A felhő gyors, rugalmas és olcsó. Legalábbis addig, amíg be nem költöztetünk egy olyan rendszert, amelyet nem erre a működésre terveztek.

Ilyenkor az infrastruktúra valóban modernebb helyre kerül. Az alkalmazás azonban nem lesz automatikusan skálázhatóbb, az üzemeltetés nem válik egyszerűbbé, a költség pedig könnyen egy nehezebben tervezhető havi számlává alakul.

A felhő nem jó vagy rossz célállomás. Egy másik működési modell. Akkor teremt értéket, ha az adott rendszer tulajdonságai, a szervezet képességei és az elérni kívánt üzleti eredmény ugyanabba az irányba mutatnak.

Miért akarunk egyáltalán felhőbe menni?

Ezt a kérdést még a szolgáltató, a régió és a technológia kiválasztása előtt érdemes feltenni.

A „cloud-first stratégia”, a közelgő hardvercsere vagy a menedzsment által kitűzött migrációs dátum önmagában még nem mondja meg, milyen értéket várunk a költözéstől.

A cél lehet gyorsabb környezetépítés, változó terhelés kezelése, földrajzi elérhetőség, jobb helyreállíthatóság, menedzselt szolgáltatások használata vagy egy új termék gyors piacra vitele. Ezek már vizsgálható állítások. Mérhetővé teszik, hogy a migráció után valóban jobb helyen van-e a rendszer.

Ha nincs konkrét válasz arra, mit szeretnénk javítani, akkor a felhő könnyen céllá válik eszköz helyett.

A lift-and-shift költözés, nem modernizáció

Egy virtuális gépet viszonylag gyorsan át lehet vinni egy cloud környezetbe. Vele együtt azonban megérkezik az alkalmazás minden korábbi tulajdonsága is: a fix kapacitásigény, a szoros rendszerkapcsolatok, a kézi telepítés, a régi licencmodell és az üzemeltetési rutinok.

Ez bizonyos helyzetekben tudatos átmeneti lépés lehet. Csökkentheti egy adatközpont bezárásának kockázatát, vagy időt nyerhet egy későbbi modernizációhoz. Attól még nem használja ki automatikusan a felhő legfontosabb előnyeit.

Ha ugyanazt a folyamatosan futó, túlméretezett infrastruktúrát béreljük ki, amelyet korábban megvásároltunk, akkor nem fogyasztási modellt építettünk. Csak más lett a számla feladója.

Melyik rendszer érzi jól magát a felhőben?

A cloud különösen erős lehet ott, ahol a terhelés időben változik, a környezeteket gyorsan kell létrehozni és megszüntetni, vagy a megoldás menedzselt szolgáltatásokból érdemi előnyt nyer.

Jó jelölt lehet például egy rendszer, ha:

  • időszakosan nagy, máskor alacsony számítási kapacitást igényel;
  • gyorsan kell új fejlesztői, teszt- vagy ügyfélkörnyezetet létrehoznia;
  • több régióból vagy változó helyszínekről kell elérhetőnek lennie;
  • automatizálható a telepítése, skálázása és helyreállítása;
  • menedzselt adatbázissal, eseménykezeléssel vagy más platformszolgáltatással csökkenthető a saját üzemeltetési teher;
  • a gyors változtatás nagyobb üzleti értéket ad, mint a teljesen kiszámítható infrastruktúraköltség.

Ezekben a helyzetekben a felhő rugalmassága nem technológiai dísz, hanem a workload természetére adott válasz.

És melyik maradhat nyugodtan a földön?

Egy stabil, jól ismert és folyamatosan magas kihasználtságú rendszer esetén a saját vagy dedikált infrastruktúra továbbra is gazdaságos lehet. Különösen akkor, ha az eszközök már rendelkezésre állnak, a működés kiforrott, és a következő évek terhelése jól becsülhető.

A migráció értékét csökkentheti az is, ha:

  • az alkalmazás késleltetésérzékeny helyi rendszerekhez kapcsolódik;
  • nagy mennyiségű adatot kell folyamatosan ki- és bemozgatni;
  • a licencelés cloud környezetben kedvezőtlenül változik;
  • az alkalmazás rövid időn belül kivezetésre vagy cserére kerül;
  • a szabályozási vagy adatelhelyezési követelmények erősen szűkítik a lehetőségeket;
  • a szervezet még nem tudja automatizáltan felügyelni, védeni és költségként követni a cloud erőforrásokat.

Az ilyen rendszer nem elavult azért, mert helyben marad. Lehet, hogy egyszerűen ott illeszkedik legjobban a saját követelményeihez.

Nem a virtuális gép árát kell összehasonlítani

A cloud üzleti esete ritkán dönthető el egy szerver és egy hasonló méretű virtuális gép havi díjának összevetésével.

Az egyik oldalon ott van a hardver, a tárolás, a hálózat, az energia, a helyigény, a karbantartás, a tartalék kapacitás és az üzemeltetői munka. A másik oldalon a compute, a storage, a hálózati forgalom, a támogatás, a biztonsági és megfigyelési szolgáltatások, a licencek, valamint a folyamatos optimalizálás költsége jelenik meg.

Ehhez jön maga az átalakítás: felmérés, újratervezés, migráció, tesztelés, párhuzamos működés, oktatás és a régi környezet kivezetése.

A jó összehasonlítás ezért nem két árcédulát, hanem két teljes működési modellt vizsgál. A költség mellett pedig az időt, a kockázatot és az üzleti alkalmazkodóképességet is figyelembe veszi.

Nem szervezetek, hanem workloadok migrálnak

Egy vállalati alkalmazásportfólió ritkán kap egyetlen helyes választ.

Az egyik rendszert érdemes megszüntetni. A másikat SaaS-megoldással kiváltani. A harmadik átköltözhet kevés módosítással, mert gyorsan kell elhagyni a jelenlegi környezetet. A negyediket újra kell platformozni vagy részben át kell tervezni, hogy valóban kihasználja a cloud szolgáltatásait. Egy ötödik pedig maradhat ott, ahol van.

üzleti cél
  → workload és függőségek felmérése
  → teljes költség és működési képesség
  → célarchitektúra és migrációs stratégia
  → kontrollált migrációs hullám
  → mérés és folyamatos optimalizálás

Ez a sorrend azért fontos, mert a migrációs módszer nem lehet előre rögzített válasz. A rendszer üzleti és technikai tulajdonságaiból kell következnie.

Öt kérdés a döntés előtt

Egy workload cloud-alkalmassága gyorsan körbejárható öt kérdéssel:

  1. Milyen mérhető üzleti eredményt várunk a migrációtól?
  2. Ismerjük a rendszer terhelését, adatait, licenceit és függőségeit?
  3. A költözés elegendő, vagy az alkalmazást is át kell alakítani?
  4. Megvan a biztonságos, automatizált és költségtudatos működés képessége?
  5. A teljes életciklust számolva jobb lesz a célállapot a jelenleginél?

Ha ezekre nincs válasz, még nem migrációs tervünk van, csak irányunk.

Ne a legnagyobb rendszerrel kezdjünk

Az első migrációs hullám legyen elég valós ahhoz, hogy megmutassa a szervezet hiányzó képességeit, de elég körülhatárolt ahhoz, hogy a tanulás kezelhető maradjon. Indulás előtt érdemes rögzíteni a jelenlegi költséget, teljesítményt, helyreállítási időt és változtatási sebességet. A költözés után ugyanazokat a mutatókat kell újra megmérni.

A migráció pedig nem a cutovernél ér véget. A régi környezet kivezetése, a cloud erőforrások finomhangolása és a következő hullám döntéseinek javítása ugyanúgy a folyamat része. Így minden átköltöztetett workload tudást is termel a következőhöz.

A lényeg

A felhő akkor gyors, ha a szervezet képes gyorsan és automatizáltan működni benne. Akkor rugalmas, ha az alkalmazás architektúrája is tud alkalmazkodni. És akkor gazdaságos, ha a fogyasztás látható, felelőshöz rendelhető és folyamatosan optimalizált.

Nem attól modern egy szervezet, hogy minden rendszere a felhőben fut. Attól modern, hogy minden rendszeréről tudja, miért ott működik, ahol.

Források és további olvasmányok