Microservices

Az alkalmazásmodernizáció királyi útja

Boutros Rachid • 2021. január 21.

A királyi úthoz sajnos még nincs meg a térképünk. De van két technológia, amit érdemes átgondolni, ha a legacy rendszerek modernizációja kerül szóba: a mikroszolgáltatásokat és a konténertechnológiát. Itt és most nem a technológiák műszaki részleteiről, sokkal inkább a mögöttük meghúzódó logikáról szeretnék beszélni.

Merthogy lenne itt egy fontos elv: ne akarjuk megjavítani, ami működik! És a legacy rendszerek így vagy úgy, de többnyire működnek, ezért is maradtak meg. Ám ez az elv, hangozzon bármilyen jól is, csak az eszközök egy bizonyos koráig igaz, Mindennek megvan az életciklusa – még a szoftvereknek is –, és egy bizonyos idő után a szoftverkód is elöregszik. Persze a dolog nem ennyire egyszerű. Amikor egy vállalat az IT-rendszereit fejleszti, jó esetben nem csak a fenti elvet követi, hanem egy másikat is: ahol cserélni kell, ott igyekszik jövőbe mutató technológiákba fektetni. A múlt és a jövő szoros egymás mellett élése azonban soha nem zökkenőmentes, mindig lesznek generációs konfliktusok.

Különösen igaz ez, amikor például az alkalmazások egy részét fel kell költöztetni felhőbe (ami önmagában sem egyszerű ügy: egy felhőbe vagy többe, és akkor melyiket melyikbe stb.). Nincs vállalat, amely képes lenne ilyenkor tabula rasat csinálni, és azt mondni: “zöldmezős” beruházással írjunk újra minden alkalmazást cloud-natív módon. De vannak más módszerek is arra, hogy korszerű, rugalmas, biztonságos, uram bocsá’ felhős vállalati alkalmazás-ökoszisztéma épüljön fel lépésről lépésre: a konténertechnológia és a mikroszolgáltatások. (Mint ahogy azt tanácsadók szokták volt okosan, ám kellően dodonai módon megfogalmazni: e két eszköz kiváló útja a modernizációnak, csak bevezetésekor mindig a megfelelő kérdéseket kell feltenni, és azokra jó válaszokat kell adni…)

Mikroszolgáltatások konténerekbe zárva

Mit is kell a két fogalom alatt érteni?

Nagyon leegyszerűsítve: a mikroszolgáltatások esetében a hagyományos monolit alkalmazásokat, melyeknél az alkalmazás összes eleme és funkciója egyetlen egységet képez, kisebb, gyorsan módosítható és függetlenül futtatható részekre, funkciókra bontjuk. Nem egy bonyolult, sokfunkciós gép készíti el nekünk a Mennybe Vivő Létrát, hanem sok kisebb egyszerű szerszám: az egyik megcsinálja a létra szárát, a másik a fokait faragja, a harmadik kiméri a fokok közti távolságot, a negyedik fúr, az ötödik… (Akit a monolit rendszerek és a mikroszolgáltatások részletesebb, műszakibb szemléletű összehasonlítása is érdekel előnyeikkel és hátrányaikkal együtt, egy kattintásnyira talál egy jó kis összefoglalót.)

Ha megvannak a Mennybe Vivő Létra előállításához szükséges szerszámok, már csak azt kell elérni, hogy azok ne akadjanak össze, például a létra fokait készítő szaki ne fűrészelje ketté a létra lábát. Tehát meg kell oldani, hogy a mikroszolgáltatások zavartalanul tudjanak futni. Ebben segítenek a konténerek. A konténertechnológia (Docker, Kubernetes stb.) lényegében a virtualizáció egy sajátos formája. Egy konténer olyan zárt terület, ahol minden szükséges összetevő megvan az adott mikroszolgáltatás futtatásához: kód, függőségek, könyvtárak, bináris fájlokat és így tovább.

És hogy miért nem jó erre a hagyományos virtualizáció? A konténerek – ellentétben a virtuális gépekkel, melyek teljes másolatokat használnak – megosztják egymás között az operációs rendszer kernelét, emiatt helytakarékosabbak, és gyorsabban is indulnak el. Ez a felhőszolgáltatások megválasztásban is nagyobb szabadságot ad: ha például egy alkalmazás I/O-intenzív részét fel lehet rakni egy ilyen feladatokra optimalizált, jól skálázható bare-metal felhőszolgáltatásba, miközben más részei hagyományos helyi infrastruktúrán futnak – szintén mikroszolgáltatásként.

Tervezni, tervezni, tervezni

Mielőtt bárki beküldené vállalata alkalmazáserdejébe machetével a fejlesztőit, nem árt kicsit átgondolni, mit érdemes és mit fölösleges mikroszolgáltatássá alakítani. Van néhány ökölszabály, amit szem előtt kell tartani.

Mindenekelőtt beszéljünk a pénzről! Egy microservice architektúra kiépítése nem lesz olcsó, pontosabban egy ugyanolyan funkcionalitású monolit alkalmazásnál valószínűleg magasabb lesz az induló költsége, és a konténerizáció miatt az erőforrásigénye sem lesz feltétlenül kisebb azénál. Ez azonban a karbantartás-továbbfejlesztés során bőven megtérül, hiszen az egyes mikroszolgáltatások egymástól függetlenül, a kisebb kódbázis miatt gyorsabban és az alkalmazott alaptechnológiák szempontjából is rugalmasabban fejleszthetők. Nincs szükség egységes adatforrásokra: minden mikroszolgáltatáshoz azt lehet választani, ami neki megfelelő: ha csak egy kulcstár adatbázis kell neki, akkor elég azzal összekötni, miközben a másik, vele együttműködő mikroszolgáltatás használhat bármilyen más SQL vagy NoSQL adatbázist. Ha egy szolgáltatás leáll, nem ránt magával egy teljes üzleti folyamatot. Ezek mind fajsúlyos, pénzben (és időben) mérhető előnyök. Arról nem is beszélve, hogy a mikroszolgáltatás-architektúrával a gyors szállítás miatt az IT a teljes vállalat agilitásának driverévé tud válni.

Kockázatos hozzányúlni a valóban kőkorszaki alkalmazásokhoz (kihalófélben lévő nyelveken íródtak, mindenki által elfeledett adatbázisokat használnak stb.). Ezeket a legtöbbször gazadásosabb felhőnatív módon újraírni. Ugyanez igaz a rosszul megtervezett alkalmazásokra, valamint azokra, melyek szorosan integrálódtak az adattárházzal. Előbbit talán nem is kell magyarázni, utóbbinál az adat- és az alkalmazásréteg szétválasztása miatt keletkezhet annyi többletmunka, amit már nem ellensúlyoznak az előnyök.

 

Ha már eldőlt, hogy milyen alkalmazások élnek tovább mikroszolgáltatásként, konténerizálva, jöhet az érdemi munka. Első lépésként az alkalmazást szét kell bontania olyan elemekre, amiket majd önállóan konténerben szeretnénk helyezni (gyakorlatban ez a kód lebontása az ún. funkcionális primitívekig, majd azok összerakása mikroszolgáltatássá). Arra kell törekedni, hogy ennek során minél kevesebb módosítást kelljen elvégezni a kódon.

Meg kell oldani, hogy minden szolgáltatás megfelelő adattal dolgozhasson. Ehhez a legjobb módszernek az tűnik, ha kialakítunk egy adathozzáférési szolgáltatást, ami szétválasztja az adatokat és a konténereket egymástól. Mivel az összes adathívás itt fut keresztül, nem kell belenyúlni a mikroszolgáltatásba, ha annak változik az adatigénye, csupán az adathozzáférési réteget kell módosítani.

És amit soha nem lehet elhagyni: a tesztelés. Mind a white box, mind a black box teszteket el kell végezni. Hiába történik kód-újrahasznosítás, az alkalmazás architektúrája alapvetően megváltozik, új szolgáltatásfüggőségek jönnek létre stb.

Ma elhatározom, holnap megcsinálom…

Zárhatnám azzal, hogy azon melegében vágjunk is bele… Alapvetően erre is biztatnék mindenkit. De a fentiekből talán az is kiderült: bár hosszabb távon nagyon is megéri monolitikus rendszerekről mikroszolgáltatásokra váltani, az nem annyi, hogy ma elhatározom, holnap megcsinálom. Még akkor sem, ha a váltás a szervezeten belül teljes elfogadottságot élvez, ami persze szintén fontos a sikerhez. Ahogy a poszt elején írtam, ha van is királyi út, egyelőre térképünk még nincs hozzá. Vannak azonban olyan tapasztalatok, jó gyakorlatok, business case-ek, melyeket fel lehet használni, sőt nem csak lehet, érdemes is! És szerencsére vannak már ezen a területen jártas, felkészült szakértők is.

Amit személy szerint tanácsolni tudnék:

1. Érdemes mihamarabb belevágni, mert hosszabb távon a mikroszolgáltatások kínálta üzleti rugalmasság, biztonság, megbízhatóság stb. bőven megtérül.

2. Ha már váltunk, ne csak holnapig lássunk. Tervezzünk hosszú távra!

3. Nézzük meg, mások hogyan csinálták, vagy kérjünk tanácsot azoktól, akiknek van tapasztalata ezen a téren – sokat tanulhatunk mások sikereikből (és kudarcaiból is).

+1. És ha túljutottunk a nehezén, osszuk meg másokkal is a tapasztalatainkat, hogy gyarapodjon közös tudásunk.