Régiből újat: így szedtünk építőelemeire egy banki monolit rendszert
Mit tehetünk, ha az üzleti fejlődés gátja maga a vállalati IT rendszer? Hogyan érdemes nekilátni a célokat beárnyékoló alkalmazás-monstrum lebontásának? Létezik-e alternatíva a monolit rendszerek kiváltására?
Hasonló kérdésekkel fordult hozzánk hazai pénzintézeti ügyfelünk is, mikor segítségünket kérte az egyik központi alkalmazásuk feltérképezésében, valamint a leendő, új architektúra megtervezésében és kialakításában. A probléma nagyon is gyakori: sok közép- és nagyvállalatnál okoz fejtörést a túl nagyra nőtt rendszerek kezelése, frissen tartása vagy épp kiváltása, ezért elhatároztuk, bemutatjuk, milyen metodika alapján hajtottuk végre a ránk bízott feladatot és milyen eredményt sikerült elérnünk végül. De ne szaladjunk ennyire előre…
Tartalomjegyzék
Hogyan válhat akadállyá egy támogató rendszer?
Sok cég esetében van egy vagy több folyamatosan fejlődő projekt, melyek az évek során újabb és újabb funkcióval bővülnek. Egy-egy ilyen fejlesztés alkalmával még senki nem gondol arra, hogy át kellene alakítani az aktuális architektúrát, tovább bővítik a meglévőt, a felismerés pedig már későn érkezik, hogy a kezdeti – gyakran – célszoftverből egy gigantikus csillagromboló lett.
Miért probléma ez?
Mivel évek hosszú sora alatt fejlődött ki a mostanra kaotikussá vált óriás, előfordulhat, hogy aki tervezte már rég nem elérhető, aki pedig az új funkciókat fejleszti nem tud a régiekről semmit. Esetleg a régi kódrészleteket meg sem merik bolygatni, mert nem tudni, miért vannak ott, van-e még relevanciájuk, használja-e még őket valaki vagy valami. A rendszer karbantartása és frissítése pedig egyre nehezebbé válik, míg nem támogatás helyett elkezdi akadályozni az üzleti folyamatokat gyakori leállások, meghibásodások, korlátozott funkciók vagy épp kompatibilitási problémák formájában.
További gátló tényező lehet a fejlesztői csapattól való függés is: mindegy, hogy külső vagy belső csapatról van szó, minden esetben erős függés alakul ki a fejlesztők és az alkalmazás között. A belsős kollégákat nem lehet átvinni más projektre mert „elveszik” a tudás, betanítani valakit pedig túl költséges lenne. Külső fejlesztői csapatok esetén ez a függés még jelentősebbé válhat, hiszen ekkor a beszállítóra van utalva az adott rendszer és ezáltal a teljes vállalat. Ez a kiszolgáltatottság nem csak időbeli csúszásokat és növekvő költségeket okozhat, hanem egy folyamatos fejlődési korlátot is, ami kártékonyan befolyásolhatja a cég üzleti lehetőségeit.
Bár a fenti problémák külön-külön is jelentősen megnehezíthetik a cég mindennapi működését, idővel ezek egyre inkább összeérnek. Ekkor érkezik el a mérlegelés pillanata: maradjon a meglévő rendszer vagy mennie kell?
Izgalmas kezdet: 1000+ szolgáltatás, egyetlen beszállító
A fenti dilemmával keresett meg minket banki ügyfelünk is: egyetlen beszállítóval dolgoztak, aki a kódot ismeri és szállítja, így eleve egy erős külsős függés akadályozta a vállalatot. Az alkalmazás 1000+ szolgáltatást tartalmazott, melyek között voltak üresek, csak proxy szolgáltatások, és használaton kívüliek, a több év alatt kialakult monolit szolgáltatások pedig tele voltak már nem használt kódrészletekkel.
Egy ilyen hatalmas alkalmazás esetén egy-egy új verzió elkészítése óriási munkával jár, hiszen egy funkció lefejlesztése után az egész rendszert tesztelni kell, hogy nem romlott-e el valami. A szállítói kitettség miatt az átfutási idő pedig a leterheltségtől is erősen függött.
Ezen okok elegendőek voltak arra, hogy a meglévő monolit alkalmazás működését és funkcionalitását felülvizsgáljuk. A legfontosabb szempont a szolgáltatások felmérése és dokumentálása volt, hogy megfelelő alapot biztosíthassunk a későbbi tervezéshez.
Hogyan álljunk neki a tervezésnek?
Felmérés
Magától értetődőnek tűnhet, hogy nulladik lépésként fontos a felméréssel kezdeni. A szóban forgó projekt esetében is így tettünk, minden egyes szolgáltatást megvizsgáltunk, hogy megérthessük a működésüket, céljukat és, hogy feltérképezzük a hozzájuk kapcsolódó rendszereket és függőségeket.
Fontos: ne vegyük félvállról és szánjunk elegendő időt erre a szakaszra! Első ránézésre biztosan kevesebbet mondunk, mint amennyi idő valójában szükséges lesz, ezért becsüljük meg még egyszer!
Egy többezer processből álló rendszer-óriás felmérése bonyolult és aprólékos munka, de megéri a belefektetett időt, még akkor is, ha a végső döntés az lesz, hogy nem nyúlunk a jelenlegi rendszerhez. Ha megmarad a mostani, akkor is nyertünk egy jól dokumentált rendszert, amit a felmérés során feltárt információkkal a kezünkben könnyebben racionalizálhatunk. Amennyiben pedig a váltás mellett döntünk, kiváló alapot biztosít a tervezéshez.
Mi a cél?
A tervezés első lépése a végső cél meghatározása. Vizsgáljuk meg, mi esett ki a felmérésből és ez alapján döntsünk: A jelenlegi rendszer annyira mégsem rossz, megtartjuk? Multivendoros megoldást szeretnénk, mert a függés mértékét szeretnénk csökkenteni? Marad a régi platform vagy valami újat szeretnénk a későbbiekben? Mi a fontos számunkra? Akarjuk racionalizálni, korszerűsíteni, a jelenkor igényeinek megfelelően?
Projektünk esetében a felmérés végeztével kirajzolódott, hogy a jelenlegi rendszer ugyan nagy és vannak benne felesleges részek, de, ha ezeket javítják, kivezetik, még megmaradhat a ráncfelvarrás után. Ez az eset ritkán fordul elő, hiszen a kiváltó okok általában jóval komolyabb problémákra világíthatnak rá.
A racionalizáció mellett több beszállítót szerettünk volna a projekt megvalósításához, hogy könnyebben és gyorsabban lehessen haladni a fejlesztésekkel és csökkenjen az átfutási idő mindamellett, hogy a korábbi beszállítói függés is megszűnik. Azonban a több, különböző beszállítót és fejlesztői csapatot, akik egymás munkáit nem ismerik és esetleg a programozói stílusuk is eltérő nehéz egyszerre elindítani.
Egységes alapok a fejlesztéshez
Ahhoz, hogy valamilyen egységességet ki lehessen alakítani, célszerű előre elkészíteni egy fejlesztői útmutatót, ami alapján a különböző csapatok dolgozni tudnak. Ezen iránymutatás mellett egységesíthető a fejlesztés és egy közös fejlesztési utat is meg tud határozni. Egy ilyen dokumentum kialakítása nem egyszerű feladat, hiszen részletesen tartalmaznia kell számos terület részletes leírását, mint például:
- Alkalmazások elkészítése (nyelv, névkonvenció, SOAP szabványok...stb.)
- Milyen API-k használata ajánlott a fejlesztés során?
- Cache kialakítása - Hogyan és miként?
- Monitorozás kialakítása (Openshift, Prometheus...stb.)
- Tesztelés - Hogyan, milyen eszközökkel, milyen mennyiségben és minőségben?
- Perzisztencia - Hol és hogyan tároljuk az adatainkat?
- Rendszerek integrációja - Milyen eszközön, milyen kommunikációval?
- Dokumentációs elvárások - Hova és hogyan dokumentáljunk?
- CI/CD folyamatok kialakítása - Mit tudjon majd?
A fenti témák egyike sem kis szelet a mostani fejlesztői világban, mindről külön-külön is rengeteg dokumentáció és leírás található, így ezek egységesítése és a szükséges elvárások megfogalmazása újabb komoly feladatnak ígérkezett. Ráadásul mindezek nemcsak az IT struktúra kialakítását, hanem a belső szervezeti felépítést is befolyásolják.
A platform kiválasztása szintén egy kritikus kérdés, mivel figyelembe kell venni számos tényezőt, ilyenek például, hogy mennyire elterjedt, van-e már ismeret cégen belül, elérhető-e hozzá megfelelő támogatás és, ha igen, meddig.
Ha már hozzányúlunk, érdemes racionalizálni is az alkalmazást, frissíteni, hogy az elkészült rendszer még inkább időtálló legyen. Ezért ilyenkor érdemes feltenni a kérdést: maradjunk-e a már megszokott technológiánál vagy váltsunk inkább?
Projektünk esetében számos workshopon keresztül, közös ötletelés, tervezés, összehasonlítás történt, hogy a lehető legjobb döntést tudjuk meghozni. Már a legelején a tervezett beszállítókkal közösen haladtak a megbeszélések. Minden egyes egyeztetés során sikerült egy-két témában közös nevezőre jutni, így folyamatosan tudtunk előre haladni.
Merre? Hogyan? Mivel? - Technológiák és fejlesztési irányok meghatározása
Első körben a technológiák meghatározása volt a cél, illetve a fejlesztési irány kijelölése.
Az eddig töretlen sikerességet követően – a főleg nagyvállalati környezetben használt J2EE megoldások mellett – a megrendelői oldalon érezhetően megnőtt az igény a kisebb erőforrás igényű lightweight keretrendszerek használatára (SpringBoot, Eclipse microprofile).
Az már az elején biztosra vehető volt, hogy a klasszikus alkalmazás-szerverre alapuló megoldást le szeretnék cserélni és áttérni a manapság igen népszerű konténerizált megoldások valamelyikére. A bank hosszas belső mérlegelés és összehasonlítások után arra a döntésre jutott, hogy követi a jelenlegi IT irányvonalat és a nagy monolit alkalmazását lecseréli egy microservice architektúra alapú környezetre.
A Workshopok keretében megvizsgáltuk, hogy milyen ismeret van az ügyfél oldalán, melyik megoldás miért lenne jó, melyik lehet ezek alapján az optimális választás. A folyamatos egyeztetések alapján pedig végül a docker lett az új irányvonal.
Az is biztos volt már a legelején, hogy több beszállítóval szeretnének majd a későbbiekben együtt dolgozni. Ezen igény miatt a következő lépcső – ami szintén sok időt emésztett fel – az egységes fejlesztési irányvonal megalkotása volt. Ezt folyamatosan dokumentáltuk és végül egy teljeskörű fejlesztési füzet jött létre, amely meghatározta a fejlesztési módszertanokat, a kommunikációs módokat az alkalmazható technológiákat, és a névkonvenciókat is. A fejlesztési nyelv továbbra is a Java maradt, hiszen az eddigi megoldások során komoly ismeretanyag halmozódott fel házon belül is, illetve a beszállítói oldalon egyaránt.
Megvalósítás: elsőre semmi sem egyszerű
A technológiai és fejlesztési irányok meghatározása nem egyszerű feladat, főleg, ha egy új terület, új dolgok bevezetése a cél. Ha nincs tapasztalat az adott technológiához, mert – mondjuk – még egyszer sem próbáltuk, nagyon nehéz dönteni, hiszen az internet tele van információval, mindenki a saját termékét dicséri, azonban arról, hogy később, összetettebb környezetben hogyan lehet használni már nem esik szó. Ezek alapján nem meglepő, hogy a microservice-ek végleges kialakításához sem egyenes út vezetett.
Technológia
Kezdetben a korábbi alkalmazás-kezdeményeket egy konténerizált weblogicon használtuk, ám ez túlságosan nagy erőforrást emésztett fel több modul futtatása esetén. Hogy erőforrást spóroljunk, de megmaradjunk a JavaEE vonalon, kipróbáltuk a Thorntail-t, ami hozta ugyan az elvárt erőforrás megtakarítást, viszont a támogatása nem volt biztosított hosszútávon.
Az első két eredménytelen megoldás után jutottunk el a végső SpringBoot alapú microservice-ekhez. Ez azért is volt nagy lépés és nehezen megléphető, mert egy ismeretlen terület volt, ami miatt a projekt résztvevők jelentős része idegenkedett tőle. Azonban ma már látszik, hogy ez volt a jó döntés és egy könnyen kezelhető, lightweight megoldást sikerült választani, amit jelenlegi információink alapján kellően időtállónak tartunk.
Kommunikáció
A kommunikáció az elején eldőlt, hogy webservice alapú lesz, de a megannyi, microservice-ek közötti kommunikáció (amelyek mindegyike azonos névkonvenció mellett született) mégsem volt egyértelmű. Egy-egy microservice több példányban futott, hogy a magas rendelkezésre állás biztosított legyen, így ezek címeit egységesen kellett kezelni. Ennek megoldására első körben Apache Load Balancer került kiválasztásra, majd a könnyebbséget a Traefik bevezetés hozta el, míg végül a Kubernetes bevezetése bizonyult a legjobb választásnak.
Struktúra
Végül szükséges volt meghatározni, hogy pontosan hogyan is daraboljuk fel az alkalmazást, ennek a végső megoldása az lett, hogy egy szolgáltatáshalmaz lesz egy microservice (domain service) amelyek így funkcionalitásukban és a kezelt adatkörben jól szeparálhatók. A felmérések végén kialakult az egyes szolgáltatás halmaz, amelyek segítették a szolgáltatások körének meghatározását egy adott csomaghoz.
Milyen buktatók várhatnak egy ilyen monolit rendszer csere során?
Lassú kommunikáció
Több beszállító esetén gyakran felmerülő probléma, hogy az információáramlás lassabb, hiába a telefon és a közös levelező csoportok, valahogy mégis növekszik az átfutási idő, ami mögött a különböző beszállítók által fejlesztett szolgáltatások közötti függés érhető tetten. Ennek kiküszöbölésére a rendszeres beszállítói státuszok adhatnak megoldást. Egy heti rendszerességgel megtartott státusz segíthet az elért eredmények és az esetlegesen felmerülő problémák megvitatásában. A közös probléma és eredmény megosztás tovább növelheti a hatékonyságot, hiszen lehet, hogy egy beszállítónak még valami újdonság addig a másiknak már rutinszerű a megoldás.
Tranzakciókezelés microservice architektúra esetén
Egy másik gyakori probléma – a tranzakciókezelés – akkor szokott jelentkezni, amikor egy nagy monolit alkalmazást szeretnénk felbontani elemi szolgáltatásokra. Egy monolit alkalmazásban egy szolgáltatáson belül történik meg minden és a modern alkalmazás szerverek képesek ezt egy tranzakcióként kezelni. Ha hiba történik mindent vissza tudnak állítani. Egy elosztott architektúrában ez nem lehetséges, hiszen az egyes lépések egymástól elkülönült rendszerekben találhatók, így minden rendszer a saját adatköréért felel. Hiba esetén minden korábbi rendszert, ami érintett értesíteni kell, hogy tudja biztosítani a helyreállítást. Ez egy összetett feladat, persze, erre is van már számos megoldási javaslat (2PC, Saga, stb), azonban megvalósításuk nem egyszerű. A legtöbb esetben érdemes az üzleti folyamatot újragondolni és ezáltal csökkenteni az ilyen jellegű feladatokat.
Üzemeltetési kihívások
További gondot jelenthet, az új funkciók és alkalmazások bevonása, melyek szükségesek ahhoz, hogy a microservice világban is megfelelő eredményeket tudjunk elérni. Ilyen új eszközök lehetnek például a CI/CD, Devops folyamatok és az üzemeltetéshez szükséges új csapat megjelenése vagy akár a központi naplózás kialakítása. A CI/CD fontossága az új architektúrában szinte elengedhetetlen, hiszen sok kis alkalmazás kerül kialakításra, amelyek külön buildelési, telepítési igényeket hoznak magukkal.
Könnyen belátható, hogy több alkalmazás és több környezet esetén már szinte lehetetlen kézzel, egyesével felügyelni, üzemeltetni a szolgáltatásokat. Erre ad megoldást a CI/CD bevezetése, melynek megvalósítására remek eszköz a Jenkins, amit projektünk során mi is alkalmaztunk.
Azonban, ha már implementáljuk a Jenkinst, akkor az üzemeltetéséről sem feledkezhetünk meg. A CI/CD folyamatok nem csak a Jenkins üzemeltetését jelentik, hanem ide tartozik a kialakított platformok kezelése és karbantartása is. Mivel ez speciális szakértelmet igényel, érdemes fontolóra venni egy dedikált DevOps csapat kialakítását.
Naplózás és monitoring
Amíg egy monolit alkalmazás esetén a futtatást végző alkalmazás szerverén képződnek a log állományok és minden egy helyen elérhető, addig elosztott környezetben sok kis alkalmazás a saját logjait kezeli, ezért szükséges bevezetni egy eszközt, ami képes a sok kis logot összefésülni és egy helyen elérhetővé tenni. Így egy esetleges hibafeltárás során nem kell minden kis alkalmazás saját logjait külön-külön megvizsgálni.
A projektben ennek megoldására vezettük be az ELK-t (Elastic Stack), ami remek eszköz a különböző log állományok begyűjtésére, indexelésére, analizálására. Ezen termék része a Kibana, amely az előálló logbejegyzéseken tud szűréseket végezni és megjeleníteni azokat.
Verziókövetés és frissítés
A másik gondot jelentő probléma, hogy az új terület, amit elkezdünk használni rohamosan fejlődik és sorra jönnek ki újabb és újabb verziók, alkalmazások, amik még könnyebbé tehetik a fejlesztést, üzemeltetést. Ha már úgyis hozzányúltunk be szeretnénk vonni minél több mindent az új elképzelésbe ezáltal egy folyamatosan változó keretrendszer jön létre, ami persze egyre jobb és jobb lesz, de ennek lekövetése folyamatos feladatot eredményez.
Nem csak az IT, az üzleti folyamatok megújítása is fontos
Már a munka kezdetén látható volt, hogy az ügyfél oldalán is szükség lesz a megfelelő szervezeti hierarchia kialakítására. Fontos volt, hogy legyen egy mindent átfogó projektmenedzser, aki képes kézben tartani a projektet. Továbbá szükség volt a döntéshozókra, akik a végső döntést meghozzák. Ez nagy felelősség, főleg egy ilyen szintű átalakítás során. Ahhoz pedig, hogy a legjobb döntés születhessen meg, szükség volt a különböző streameknek külön felelősöket kiválasztani, hogy javaslatot tudjanak tenni az egyes technológiai vagy szakmai kérdésekben.
Rendet raktunk a csillagrombolóban - a projekt során elért eredmények
Bár a projektfolyamat még nem ért véget, vannak megoldandó kérdések, mégis számos eredményt sikerült elérnünk eddig is:
- Készült egy széleskörű fejlesztői leírás, amely alapján egy új beszállító is az eddig elért egységes metodika alapján tudja elkezdeni a munkát.
- A monolit alkalmazásból kiválasztott szolgáltatáshalmaz teljeskörű dokumentálása és ezek jó részének újrakiadása már a meghatározott microservices környezetben.
- Egy megfelelően kialakított CI/CD lánc, ami a több környezetes működést is képes kiszolgálni és, ami végig tudja vezetni a folyamatot a buildeléstől egészen a telepítésig.
- Számos új technológia és rendszer bevezetése és élesítése (SpringBoot, Jenkins, Docker, Kubernetes, Apache Kafka, Kibana...stb.)
- A feltérképezett függőségek alapján elkezdődött a rendszerek átállítása az új szolgáltatásokra.
Visszatekintve a jelenlegi állapotból a kiindulásira, látni lehet, hogy rengeteg időt – több mint két évet – emésztett fel eddig a projekt, de a számos elért eredmény és a már most megjelenő költségcsökkenés mind azt mutatják, hogy megérte belevágni az átalakításba. Az idő előrehaladtával a költségcsökkenés várhatóan még szembetűnőbb lesz, hiszen egy-egy élesítés átfutási ideje jelentősen csökkenni fog, csakúgy, mint a tesztelés költsége is, a szállítói függés megszűnése pedig további költségcsökkenést eredményezhet.
Mindezen előnyök mellett, ügyfelünk egy nagyon jól dokumentált, hatékonyabb alapokon nyugvó rendszert kap, amelynek üzemeltetése és fejlesztése sokkal könnyebb feladat lesz a jövőben.
