A konzervatív IT vezető

Kezdjük a végével, ő az, aki közép távon káros, hosszú távon veszélyes. Gyakorta látni olyan vezetőket, akik a tényleges régi iskolát képviselik és nem dolgoztak egész pályájuk során az informatikában, tehát korábban születtek, mint a modern informatika vagy legalább az x86 megszületett volna. Nincs ezzel baj, akkor ha értik a változásokat és képesek azt oly módon felhasználni, hogy egyébként a nem informatikával foglalkozó vállalataik valamilyen előnnyel legyenek képesek kihasználni azokat. Ez talán az a szakma, amelyben a tapasztalat, mármint az, hogy látott már egy-két dolgot valaki, előny, de nem szabad annak fényében megítélni bármit.

Pedig pont ez történik, tehát elemi szinten azért választani IBM tárolót, mert azok 1956-ban jelentek meg először, az EMC-nél meg csak 1988-ban, az pont olyan dolog, hogy kit érdekel? Ebben a szakmában a régebbi nem biztos hogy jobb. Lehet a bor és a cognac ilyen cikk, de sem hardverre, sem szoftverre ez nem értelmezhető, értelmezendő.

A virtualizáció elterjedésével, amelyben nem kis szerepe van egyébként a VMware-nek, 2010 utáni pár évben rengeteg nagyobb rendszer épült, tehát de facto lett az x86 Intel alapon, központi tárólóval kiszolgált ESX/ESXi. Nincs ezzel baj, jó alapot adott a következő tíz év kihívásaira. De lesz-e ebben az egészben annyi, hogy egy újabb tíz évet kibírjon? Annyit, amennyi a felette bábáskodó IT vezetőknek a nyugdíjig még hátra van? Kevéssé hiszem.

Természetesen fenntartásokkal kell kezelni a legújabb, csillogó csomagolással reklámozott dolgokat, de nem szabad elmenni mellettük, legalább egy pillantást vetve rájuk. Főleg, hogy az elmúlt 10 évben ha történt egyáltalán fejlesztés, az lényegében a processzorok – indirekt módon a szerverek – cseréje volt újabb modellre, a tároló cseréje egy hasonszőrű másikra – talán beletéve pici SSD-t – a SAN switch-ek cseréje 8 Gbit-ről mondjuk 16Gbit-re, az ESXi, a Windows Server és egyéb operációs rendszerek támogatott szinten tartása. Szóval újra balzsamozásra került a múmia, ami fölé már épül a piramis, de keresik alóla a felkelő Nap fényét.

Kis lépésekben azért érdemes lenne a fejlesztésen gondolkodni. Főleg, hogy egyáltalán nem jelent új komponenst vagy eddig idegen terméket egy-egy fejlesztés. Hiszen nézzük meg például a felhőt. Abban van szerver? Van. Van benne hálózat? Van. Tároló? Van. Ha ezt VMware Cloud on AWS-ben vizsgálom például, akkor mik vannak abban, amit eddig nem is láttam on premises? Semmi.

Az almából is lehet püré, almalé, cider és calvados is. Ugyanaz az alapanyag, a végeredmény mégis teljesen más.

Ezért is furcsa olyat hallani hogy:

  • A HPE Nimble tároló csak egy átnevezett Netapp. Köze nincs a Netapp-hoz az érintett tárolónak például.
  • Azért rosszak a blade-ek, mert láttam már leégett teljes keretet. Nem, nem láttál, egy ember látott, mindenki más csak hallotta, hogy valaki látta.
  • Az all flash tároló nem a jövő. Nyilván nem, csak kár, hogy ma már elsődleges tárolóként hatékonyan és elfogadható sebességgel nem lehet pörgő médián kiszolgálni semmit.
  • Azért használjuk a legrégebbi támogatott ESXi-t, mert az újak tele vannak bug-gal. Mindenbe van bug és inkább valószínű, hogy az újabb verzióra koncentrál egy gyártó és nem a legrégebbire.
  • Túl új technológia, még nem bizonyított. Akkor definálni kellene, hogy mikortól minősül valami bizonyítottnak: Szóval mi a kritéria?
  • Nem akarunk új dolgot tanulni, egyszerűsíteni akarunk.

Na pont ez az utolsó a legérdekesebb. Ezek az elöregedő rendszerek szinte minden esetben azt a mentalitást tükrözik, hogy ne piszkáld ha működik. Ezek ezért vagy fényévekkel vannak lemaradva az életciklus ezen terén és őrületes projektek keretében kerülnek frissítésre, de nem teljes egészében, hanem akár egy ESXi upgrade-jében. Tehát egy komplex rendszer, annyi függőséggel rendelkezik, hogy alig lehet átlátni, de ha valaki mégis képes rá, nem vállal érte semmiféle felelősséget a magas kockázat miatt. Ez nemhogy egyszerűsítés, hanem egyenesen annak ellentéte.

Nézzünk egy silós rendszert:

  • szerverek: VMware ESXi
  • hálózat: ethernet és SAN
  • tároló: központi tároló
  • montoring
  • mentés

Van tíz klaszter mondjuk, mindegyik valamilyen specifikus alkalmazás kiszolgálására. A virtualizáció világában számít-e egy virtuális gépben futó alkalmazásnak, egy konténerben futó kódnak, az hogy DellEMC PowerEdge-en fut vagy Cisco UCS-en? Elárulom, nem számít. Számít-e azonban, hogy 5.5-ös ESXi-n futtatunk valamit vagy 7.0-n? Sokkal inkább. Az 5.5-ről 7-re történő frissítés során végre kell hajtani:

  • a szerverek beszerzését, beszerelését, telepítését és konfigurációját
  • a hálózati elemek adott esetben cseréjét, konfigurációját
  • a tároló adott esetben cseréjét, konfigurációját
  • a kapcsolódó rendszerek – monitoring, mentés stb – kompatibilitásának vizsgálatát

Ha ez mind kész, akkor fel kell készülni arra, hogy ez hogy marad friss, hogy lesz maga a konfiguráció mindenre érvényes, megismételhető és könnyen teríthető. Ha van 56 darab ESXi kiszolgálóm, tényleg kézzel szeretném minden frissítgetni? Ha kell egy újabb klaszter akkor tényleg újra le kell játszani a fenti sorozatot?

Ennek ékes példája a VMware Cloud Foundation, amivel szemben én azt látom gyakran, hogy hallatán már repül is a ringbe a törölköző. Holott a VCF-ben található komponenseket alapból használja már sok ügyfél, szóval mint fentebb írom, almával dolgozik, de mást állít elő belőle.

A VCF bevezetése például megváltoztatja a alkalmazások futását? Nem. Akkor mégis mit változtat meg? Körülbelül annyit, hogy picit segít a kialakított rendszer elemeinek frissen tartásában, illetve lehetőséget ad a bővítések és a későbbi fejlesztések gyors és mélyebb szaktudás nélküli végrehajtására. Teljesen rendben van, hogy nem használ valaki konténereket ma. A hansúly a “ma” részen van. De lehet, hogy fél év múlva igen és akkor lehet keresni az utat, hogy az mégis most hogy legyen kiszolgálva, egészen biztosan azt eredményezve, hogy létrejön egy külön sziget a konténerek számára, amely olyan testidegen, hogy senki sem érzi magáénak.

Ma már nagyon nehéz funkciók alapján dönteni vagy kiértékelni két-három gyártó versenyző termékét. Nézzünk például egy életszerű példát, a WC papírt. Milyen funciók mentén kellene megválasztani a gyártót:

  • hány méter papír van egy tekercsen?
  • milyen hosszú, széles egy lap?
  • perforált-e a tekercsen található szalag, lapokra szeletelve azt?
  • illatos-e?
  • lemegy-e a WC-n, ha ellátta feladatát?
  • mekkora kiszerelésben kapható?

Ennek fényében bemegyünk egy üzletbe és azt látjuk, hogy mindegyik gurigán 19,5 méternyi papír van. Egy lap mérete 10x13cm. Illatos és lemegy a WC-n. 8 tekercs van egy kiszerelésben.

Akkor mi alapján lehet dönteni? A megszokás és az ár alapján. Az előbbit az IT-ban el kell felejteni – bár bekezdéssel feljebb írtam – szóval körülbelül az utóbbi alapján. Kivéve, ha van valami egyedi a termékben amit más WC-papír adott pillanatban nem tud, nekem viszont fontos. Tehát ha magát a tekercset alkotó papírt is le lehet húzni, az jó, mert nekem az lehet, hogy döntő tényező. Ezért például storage-et vásárolni igen nehéz pusztán adatlap szintjén. Minden könnyen beüzemelhető, minden gyors, minden bővíthető fel és széltében, minden hatékony. Nyilván, mert olyan WC-papírt se venne senki, ami mondjuk 25 méteres egy tekercsen, de nem látja el alapvető feladatát vagy nem lehet lehúzni a WC-n.

Az IT vezető feladata tehát megnézni az összes WC papír, minden tulajdonságát és megtalálni azt, amelyik a vállalat igényeinek a legjobban megfelel. Lehet, hogy a 8-as kiszerelés jó volt az elúlt 10 évben, de nem biztos, hogy megint az lesz.

Az IT vezető feladata 30%-ban a jelen menedzselése, 70%-ban a jövőre történő felkészülés. A horizontig mindenki lát, de mögé már kevesen. Ezért is fontos, hogy ne a jelen alapján tervezzük a jövőt, mert gyakorta konzerváljuk ami van.