A privát felhő létrehozásának buktatói (írta: Laár András verse)

 Az alábbi szösszenet egy Netflix sorozat és egy informatikai probléma alkohol hatására létrejött béna ötvözete, majd egyszer megírom rendesen is. 

A technológiaválasztás

Az első kérdés az, hogy tulajdonképpen mit is szeretnénk szolgáltatni: IaaS-t, (lánykori nevén VM-eket), PaaS-t (viva la devops), netán konténereket, mivel a világ a microservice-k felé halad. A problémát persze a múlt jelenti, ti. egy nagyvállalat több évtized alatt felhalmozott alkalmazás portfolióval bír, ami alatt több tucat adatbázis kezelő és operációs rendszer kombináció található, nem beszélve a már bejáratott mentési rendszerekről, magas rendelkezésre állást és katasztrófa utáni üzemmenetet biztosító megoldásokról. A hangsúly itt az alkalmazás réteg által diktált platform megoldások sokszínűségén van.

Ha lecövekelsz azon tézis mellett, hogy (induláskor) csak 3 fajta VM-et szolgáltatsz, egyfajta hypervisor-ral, direct attached storage-el és API-t sem adsz hozzá, csak GUI-t, akkor kezelhető nagyságú scope-ot definiáltál, de fennáll a veszélye, hogy a vadászkutyát sem érdekli majd a terméked, ti. nem kompatibilis a már meglévő alkalmazás réteggel. Arra persze senki sem szán pénzt, hogy migrálja a meglévő alkalmazását az új privát felhőre, hiszen állandóan nyaggatja az üzlet a legújabb funkcionális igényekkel. (a tech debt kialakulásának klasszikus példája.)

Adott tehát a késztetés a több hypervisor, OS, HW méret, SAN storage, API-n keresztül elérhető funkcionalitás támogatására. A dolog csapdája az, hogy a scope lassan kezd hasonlítani az Amazon vagy a Microsoft által kínált publikus szolgáltatások funkcionalitásához. És itt van a bibi, te nem vagy az Amazon, sem a Microsoft. Sem szaktudásban, sem a fejlesztőid létszámát tekintve nem vagy versenyképes ezekhez a fiúkhoz képest, arról nem is beszélve, hogy ők 12-14 évvel korábban kezdtek a kérdéssel foglalkozni.

A platform választás

Tegyük föl, hogy sikerült lebeszélned a huhogókat kedvenc hypervisor-ukról, maradt a jó öreg VMWare, (hiszen ehhez értenek az embereid). Te D’Artagnan-ként már készülhetsz is a délután 3 órás párbajra, ti. minimum 3 virtualizált OS-t kell majd támogatnod (RHEL 7.x nélkül a Linux hívők vetnek máglyára, Windows Server 2016 is kell, mert a pénzügy erre esküszik, a DWH-sok meg Solaris-t vagy legalább Oracle Linux-ot akarnak.) Közben szól a főnököd, hogy mégiscsak kell a Hyper-V és sajnos a Kubernetes támogatás is.

Itt hirtelen egy másik vallásháború kellős közepén találod magad: plain vanilla Kubernetes a nyerő (csak tiszta forrásból, ugye és ráadásul kimondottan versenyképes az ára) vagy az Openshift-re szavazol, mondván, az Kubernetes extrákkal – ami nagyban megkönnyíti az üzemeltetők életét. Igen ám, de az egy drága IBM fizetős cucc… Ahogy a Vaják mondaná, amikor megharapták a zombik: a picsába… (ti. ezt hallgatom, miközben ezt a cikket írogatom:- https://www.youtube.com/watch?v=hqbS7O9qIXE )

Az automatizálás

No igen, eljött az igazság pillanata, le kell fejleszteni egy csinos provisioning megoldást, ráadásul a VM-eket le is kéne tudnod pörgetni, nem csak fel. Hibakezelés, jogosultság kezelés, kvóták, mindezt 3 guest OS négy verziójára, némi web- és alkalmazásszerver támogatással, Java, dotNet (you name it) keretrendszerekkel, nem beszélve arról az iciri-piciri gondról, hogy a terméket bele kéne regisztrálni a DNS-be, (ja, hogy a TOR switch portok nem virtuálisak, azok elfogytak biza.. lásd a Vaják korábbi észrevételét…) 

Ekkor, ahogy a régi Gazdálkodj okosan játékban, sajnos egyest dobtál, azaz a négy Python fejlesztődből kettő lelépett egy most induló startup-hoz, ahol a kerítés is kolbászból van (vagy lesz izibe). A maradék két fejlesztőd – némileg joggal – jelezte, hogy az eredetileg megbeszélt határidő alma és hogy őket is megkereste egy fejvadász.

A projekt szponzora szólt, hogy a leendő felhasználók egyike, hogy nem szeretne osztozkodni a hardveren másokkal, neki dedikált vas kell. (tulajdonképpen feltalálta a reserved instance fogalmát, a bibi csak az, hogy ha még páran követik a példáját, akkor elfogy a vas.) A PM végtelen bölcsességétől vezérelve javasolja, hogy az egyszerűség kedvéért válasszátok le a rendelkezésre álló vasról a fenti erő(s)ember igényét. Hurrá, már két felhőnk is van.

Mivel késlekedtél és az egyik (az egyetlen) kommitált vevődnek határidőre kellett a gép, ezért a nekik szánt kapacitást nemes egyszerűséggel átallokálták az ő projektjükbe, mint nyersvasat. Sietünk, a virtualizáció sem kell… A gond az, hogy a storage-ből elvitték a DR site kapacitásának a felét, mert csak. Innentől aszimmetrikus a felállás, no de majd kezeljük SW-ből.

A tooling

A tooling lényegében mindent jelent, ami a provisioning, decomissioning, config management, monitoring feladatok ellátása során kell ahhoz, hogy működni tudj. A gond ott kezdődik, amikor a tuti új VM-jeidet át akarod adni üzemeltetésre. Az infrások jelzik, hogy ez rendben is lesz, feltéve, hogy integráltad a cumódat a meglévő monitoring és management rendszerekbe, értsd VSphere. A SNOW-s csávó is megjelent és mondta, hogy az új VM-eknek benne kell lennie az éppen készülő CMDB-ben (már csak hónapok kérdése és tuti kész lesz). Egy szó, mint száz, scope-ot kell vágni, hogy le tudj szállítani valami működőnek látszó holmit.

Az árazás

Szenzáció, van egy műdökő VM-ünk, már órák óta stabilan megy, bár tilos hozzá nyúlni, olyan szép… És ekkor megjelenik egy pénzügyes és megkérdi, hogy mennyibe is kerül ez per VM. Azt tudod, hogy olcsóbbnak kell lenned, mint egy mezei HW, különben senki nem veszi meg a motyódat, ellenben ha a teljes HW és storage költséget (no persze levonva belőle, amit korábban leraboltak) szétterheled arra a pár VM-re, amit jelenleg tesztelésre használsz, az igen drága lesz. Kéne egy ár. A jó hír, hogy nem tudod előre, hogy mekkora VM-eket fognak kérni a felhasználók, azt meg főleg nem, hogy mennyi diszket kérnek hozzá, így marad a guessing. Kici-ócó VM-et tesszék..

Az eszközpark kapacitásbővítése

Sajnos a beszerzésnek senki sem szólt, hogy te egy belső felhő szolgáltató lettél, pont úgy négy hónapos átfutási idővel kapod a vasat, mint bárki más. A bibi csak az, hogy ennyi idő alatt bárki megkapja, és a 4 hónapra vetítve az az egy nap, amíg létrehozod a kért VM-et, már nem sokkal jobb, mintha maradnátok a megszokott módszernél. Aztán kiderül, hogy a „no approval, just billing” javaslatodat lekukázták, tehát pont úgy meg kell igényelni a privát felhőben lévő VM-et, mint a hagyományos vasat és kb. ugyanannyi időbe is telik, mire megkapod a jóváhagyást. Ezen a napon kezdesz el érdeklődni a seppuku-hoz szükséges rövid japán kard, a tanto iránt. Look on the bright side: a számlázással amúgy sem lettünk készen..

Az övön aluli ütés

Az igazi probléma akkor áll elő, amikor valakinek eszébe jut a portékádat a nyilvános felhőszolgáltatók megoldásaihoz hasonlítani akár funkcionális, akár ár tekintetben. Az Úr áldja az MNB ajánlását, ami egyelőre tiltja a nyilvános felhő szolgáltatók használatát a pénzügyi szektorban…