Konténerizáció vagy virtuális szerverek?

Egy új belső alkalmazás elindítása sok vállalatnál nem a fejlesztésen akad el. Az alkalmazás elkészül, de utána megjelennek a kérdések: melyik szerverre kerüljön, hogyan lesz mentése, ki frissíti, mi történik hiba esetén, és hogyan lehet később bővíteni? A konténerizáció vagy virtuális szerverek kérdése ezért nem pusztán infrastruktúra-választás. Meghatározza, mennyire kiszámíthatóan működik egy üzletileg kritikus rendszer, és mennyi figyelmet kér majd az IT-csapattól.

A jó döntés nem abból indul ki, melyik technológia korszerűbb. Előbb azt kell megérteni, milyen üzleti folyamatot támogat az alkalmazás, mekkora kiesést okozna egy hiba, milyen gyorsan változik a rendszer, és van-e valódi üzemeltetési felelőse.

Először ne szervert válasszunk, hanem kockázatot mérjünk fel

Vegyünk egy gyakori helyzetet. A webshop rendelései egy egyedi integráción keresztül jutnak el a készletkezelőbe, majd a számlázóba és a futárszolgálat rendszerébe. Napi néhány száz rendelésnél ez az összekötő alkalmazás már nem mellékes technikai elem. Ha leáll, a raktár nem tudja, mit kell összekészíteni, az ügyfélszolgálat pedig nem látja a rendelés valódi állapotát.

Ebben a helyzetben a lényeg nem az, hogy a program virtuális gépen vagy konténerben fut. A lényeg az, hogy visszaállítható-e, felügyelt-e, elkülönülnek-e a hibák, dokumentált-e a működése, és ki tud beavatkozni akkor is, ha az eredeti fejlesztő nem elérhető.

A döntéshez általában öt kérdés ad használható keretet:

• Egyetlen alkalmazásról van szó, vagy több, egymással együtt változó szolgáltatásról?
• Milyen gyakran kerül ki új verzió vagy javítás?
• Kell-e rövid időn belül kapacitást bővíteni?
• Van-e házon belül megfelelő üzemeltetési tudás és felelősségi rend?
• Mennyibe kerül egy óra kiesés a rendelésfeldolgozásban, termelésben vagy ügyfélkiszolgálásban?

Ezekre adott válaszok gyakran többet mondanak, mint egy hosszú technológiai összehasonlítás.

Mit ad a virtuális szerver?

A virtuális szerver egy fizikai gépen elkülönített, saját operációs rendszerrel működő környezet. Úgy kezelhető, mint egy hagyományos szerver: saját tárhelye, hálózati beállítása, felhasználói jogosultságai és rendszerfrissítései vannak. Egy vállalat számára ez sokszor jól érthető, bevált működési modell.

Kifejezetten indokolt lehet, ha egy régebbi üzleti alkalmazás csak adott operációs rendszerrel, speciális komponensekkel vagy gyártói előírások szerint működik. Ugyanez igaz lehet egy gyártástámogató rendszerre, egy régi adatbázisra vagy olyan szoftverre, amelyet külső szolgáltató támogat, és pontos telepítési feltételeket határoz meg.

A virtuális szerver előnye a viszonylag egyértelmű határvonal. Egy alkalmazásnak saját gépe lehet, amelyet menteni, monitorozni és szükség esetén visszaállítani is lehet. Ez kisebb vagy ritkán változó rendszereknél egyszerűbb üzemeltetést jelenthet.

Van azonban ára ennek az egyszerűségnek. Minden virtuális szerver saját operációs rendszert igényel, amit frissíteni, védeni, felügyelni kell. Ha az évek során minden új igényhez létrejön egy új szerver, hamar megjelenik a szerverhalmozódás: senki sem teljesen biztos benne, mi fut rajta, kell-e még, és egy frissítés milyen üzleti folyamatot érinthet.

A virtuális szerver tehát nem elavult megoldás. Akkor megfelelő, ha az alkalmazás stabil, jól körülhatárolható, a változás ritka, és az operációs rendszer szintjén is elkülönítésre van szükség.

Mit old meg a konténerizáció?

A konténerizáció során az alkalmazás és a futásához szükséges komponensek egy szabályozott, hordozható csomagban futnak. A konténer nem teljes virtuális szerver: jellemzően a gazdarendszer erőforrásait használja, miközben az alkalmazást elkülönített környezetben tartja.

Üzleti szempontból ennek legfontosabb előnye a megismételhetőség. Ha a fejlesztői, teszt- és éles környezet ugyanabból a meghatározott csomagból épül fel, kisebb az esélye annak a jól ismert problémának, hogy „a tesztkörnyezetben még működött”. A telepítés nem egy hosszú, részben kézzel végzett leírás alapján történik, hanem ellenőrizhető módon ismételhető.

Ez különösen hasznos olyan rendszereknél, amelyek gyakran változnak. Például egy webshop-integrációban új futárszolgálat, új fizetési mód vagy új raktári szabály jelenik meg. Ha a fejlesztések rendszeresek, a konténeres működés gyorsabb és kiszámíthatóbb kiadási folyamatot támogathat.

A konténerek jól illeszkednek akkor is, amikor egy üzleti funkció több különálló szolgáltatásból áll. Egyik komponens fogadja a rendeléseket, másik szinkronizálja a készletet, harmadik dokumentumokat állít elő, negyedik értesítéseket küld. Ezek nem feltétlenül igényelnek külön virtuális szervert, de külön verziózhatók, monitorozhatók és szükség esetén külön bővíthetők.

A konténerizáció viszont nem automatikusan egyszerűbb. A megfelelő működéshez szabályozott image-kezelés, jogosultságkezelés, naplózás, hálózati kialakítás, titokkezelés, mentési stratégia és monitorozás kell. Több konténer koordinált működtetése már külön üzemeltetési fegyelmet kíván. Ha ez hiányzik, a vállalat nem kevesebb, hanem csak más jellegű komplexitást kap.

A konténer nem helyettesíti az architektúrát

Gyakori félreértés, hogy a konténerek önmagukban magas rendelkezésre állást teremtenek. Nem teremtenek. Egy rosszul kezelt adatbázis, egyetlen hibapontot jelentő integráció vagy dokumentálatlan külső függőség konténerben is ugyanúgy üzleti kockázat marad.

A rendelkezésre állás tervezési kérdés. Meg kell határozni, mi történik szerverhiba, hálózati hiba, hibás kiadás vagy adatvesztés esetén. Kell-e automatikus újraindítás? Milyen gyors helyreállítás elfogadható? Mentjük-e csak az adatokat, vagy rendszeresen ellenőrizzük is, hogy a mentésből valóban visszaállítható a működés?

Konténerizáció vagy virtuális szerverek: mikor melyik ésszerű?

Egy stabil, régi alkalmazásnál, amelyhez évente néhány alkalommal nyúlnak hozzá, a virtuális szerver gyakran fegyelmezettebb és arányosabb döntés. Nem érdemes összetett konténerplatformot építeni csak azért, mert technológiailag lehetséges.

Egy rendszeresen fejlesztett, több integrációt kezelő vagy több környezetben futó alkalmazásnál viszont a konténerizáció jelentős működési előnyt adhat. Gyorsabbá válhat a hibajavítás kiadása, követhetőbb lesz, mi fut élesben, és kisebb a környezeti eltérésekből eredő hiba esélye.

Sok esetben a helyes válasz nem vagy-vagy. A konténerek futhatnak virtuális szervereken is. Ez gyakori és indokolt átmeneti vagy tartós architektúra: a virtuális gép biztosítja az infrastruktúra-szintű elkülönítést, a konténerek pedig az alkalmazások szabályozott telepítését. Így nem kell egyetlen nagy technológiai ugrással átalakítani minden rendszert.

Érdemes az adatok természetét is külön kezelni. Az alkalmazásszerverek, integrációs szolgáltatások és feldolgozó folyamatok általában könnyebben konténerizálhatók. Egy nagy, üzletileg kritikus adatbázisnál azonban a mentés, teljesítmény, tárolás és helyreállítás követelményei elsőbbséget élveznek a telepítési divatokkal szemben.

A rejtett költség az üzemeltetési bizonytalanság

Infrastruktúra-döntéseknél sokszor csak a havi szerverköltség kerül az összehasonlításba. Pedig a nagyobb tétel gyakran a kiszámíthatatlan munka: amikor egy hibát csak egy ember tud megoldani, amikor nincs naprakész dokumentáció, vagy amikor egy frissítés előtt senki nem tudja biztosan, mi fog leállni.

A technikai választásnak ezért támogatnia kell az átláthatóságot. Legyen ismert, melyik alkalmazás milyen üzleti folyamatot szolgál, hol vannak az adatai, milyen rendszerekkel kommunikál, ki felel érte, és milyen feltételekkel lehet változtatni rajta. Ez nem adminisztratív teher, hanem az üzletmenet folytonosságának alapja.

A jó infrastruktúra nem attól értékes, hogy modern címkéket visel. Attól értékes, hogy egy új rendelési csúcs, egy rendszerfrissítés vagy egy kulcsember távolléte nem állítja meg a napi működést. Ha a választás előtt ezt a működési képet tisztázzák, a technológia már nem bizonytalan kockázat, hanem ellenőrizhető eszköz lesz.