A microservices mint a fejlődés következő lépcsőfoka
Az elmúlt évtizedekben a tudományok olyan léptékben fejlődtek, mint soha a korábbi évszázadok során. A leggyorsabb ütemű fejlődést az informatika mutatja, aminek mára nemcsak a hadsereg vagy a gigacégek, hanem kisebb vállalkozások sőt a háztartások is örülhetnek.
Létezik továbbá egy közös pont az emberi fejlődés és a vállalkozások növekedésével kapcsolatban. Ez pedig nem más, mint az innováció, az új, használható trendek mielőbbi felismerése és adaptálása. Az IP Systemsnél ebben hiszünk. Ezért is építettük be egy microservices architektúra tervezési mintáit.
Egyáltalán mi az microservices?
Lényegében egy olyan szoftvertervezési minta, ahol az architektúra kisebb alkalmazásokból épül fel, és különböző csatornákon kommunikálnak a rendszer részét képező egyéb alkalmazásokkal, így alkotva meg az adott cég komplett IT-rendszerét.
Hogy ez miben más a hagyományos szoftverfejlesztéstől?
A szokásos heterogén rendszerek működése a legtöbb esetben egyáltalán nem szolgáltatásorientált. Ez azt jelenti, hogy valós integráció nélkül, egy processzben futó, silószerű felépítésük miatt a rendszerek üzemeltetése körülményes, és viszonylag sok fennakadással és üzemszünettel jár.
A hagyományos módszerrel tervezett szoftverek verziófrissítése például az adott időre megakaszthatja a szoftver működését. Egy monolitikus alkalmazás telepítése az esetek többségében időigényes feladat (pl. leállítás, DB frissítés, újraindítás), amely idő alatt a teljes rendszer nem elérhető. Az ilyen rendszerek skálázódása hardverigény szempontjából rendkívül költséges, hiszen a párhuzamos futás (a régi rendszer egy időben működik a háttérben futó ujjal) megvalósítása igen bonyolult.
Egy microservices architektúra esetében azonban sokkal granuláltabb módon történnek a különféle verziófrissítések. Ezáltal az üzemeltetési költségek jobban optimalizálhatók, s közben az alkalmazásnak csupán egyetlen része áll le, a többi zavartalanul működik. Különböző telepítési technikákkal, mint pl. blue-green deployment, elérhető az, hogy a felhasználó semmit nem vesz észre az egészből.
Összefoglalva tehát, a microservices architektúra lehetővé teszi olyan alkalmazások és szoftverek tervezését, amelyek külön folyamatokat futtató, kisebb szolgáltatások összességéből felépülő, egymással valamilyen egyszerű metódus (pl. HTTP API) segítségével kommunikáló rendszereket tesznek ki.
A microservices-nek több definíciója ismert, mi leginkább Martin Fowlerét ajánljuk.
Hogyan segít a microservices architektúra egy magyar kkv-nek?
Akik számára ismerős a microservices kifejezés, azok feltehetőleg már arról is hallottak, hogy ennek a modellnek az olyan nagy nemzetközi cégek az úttörői, mint az Amazon, a Netflix vagy a Spotify.
Sokan ebből az információból azt a következtetést vonják le, hogy a modell előnyeit kizárólag nagy cégek képesek kihasználni, illetve megfizetni. Ez azonban tévedés.
Hogy mi az igazság?
A microservices számtalan olyan technikai előnyt képes realizálni kisebb cégek számára is, amelyekkel azok hatékonyabbá tehetik a működésüket, és ennek többek között eredményeképpen magasabb bevételt realizálhatnak.
Vegyük például a skálázódás problémáját. Mindannyian tisztában vagyunk vele, hogy a Black Friday egyik legnagyobb haszonélvezője az Amazon (különösen a fent említett cégek között).
De csak az Amazonnak vannak Black Friday akciói, és ezáltal a tapasztaltnál háromszor, négyszer vagy akár tízszer magasabb forgalma és bevétele?
Egyértelműen nem. A Black Friday már a legtöbb magyar kkv számára is opció, sőt lemaradni róla legalább akkora hiba, mint weboldal nélkül vállalkozni 2018-ban.
De hogyan segít ebben a microservices?
Egy-egy ilyen időszakos kampány során jelentősen megnő az egyes rendszerek terheltségi szintje. Ennek megoldása a skálázódás, mely a hagyományos szisztémák Achilles-sarka. A microservices architektúra segítségével azonban viszonylag könnyedén kezelhetők ezek a skálázódások.
Annak köszönhetően ugyanis, hogy ezeknél a komponensek mind teljesen különálló folyamatok, képesek egymással távoli aszinkron hívásokkal is kommunikálni, aminek eredményeképpen a különböző komponensek egymástól függetlenül frissíthetők, publikálhatók és bővíthetők.
Nem kell tehát az egész rendszert frissíteni – és időnként leállítani, újraindítani -, ha egy adott szegmenst (pl. webshop) bővíteni akarunk.
Ez természetesen karácsonyi időszakban, illetve egyéb szezonális kampányok során is rendkívüli előnyt jelenthet a piacon.
Egyetlen percre sincs megállás
A microservices rendszerek a nap 24 órájában futnak a világ minden táján – gondoljunk csak a mindig elérhető, és a fentiekben már említett Spotify-ra, Netflixre vagy Amazonra. A szolgáltatók tehát egyetlen másodpercnyi késést vagy leállást sem engedhetnek meg maguknak.
Ha a hagyományos módszerrel készült, egyetlen alkalmazás felel a szolgáltatásunk üzemeltetéséért, gyakorlatilag alapvetés, hogy frissítések idején a rendszer bizonyos időre leáll. És jobb esetben bár megoldható a kiesés mérséklése vagy teljes elkerülése, ez rendkívül költséges.
Nem úgy a microservices architektúra esetében, amelyben az ilyen frissítések és upgrade-ek kezelése sokkal finomabb, és kevésbé kockázatos. Ez annak köszönhető, adott időben kizárólag bizonyos szegmenseket telepítenek, s közben a többi problémamentesen működik tovább.
Ennek a módszernek ráadásul van még egy hatalmas előnye, hiszen ha valami rosszul sül el a fejlesztés során, nem szükséges a komplett rendszert visszaállítani az előző verzióra, elég csupán a problémás szegmenssel megtennünk ezt.
Mutasd a céged, megmondom milyen a szoftvered
A microservices architektúra megértéséhez vegyük elő Conyway törvényét:
“Azok a szervezetek, amelyek szoftvert terveznek, arra vannak korlátozva, hogy olyan terveket készítsenek, amelyek a saját kommunikációs struktúrájuknak másolata.”
Ahhoz, hogy egy szoftver két modulja tökéletesen együtt tudjon működni, azok tervezőinek és fejlesztőinek kommunikálniuk kell egymással. A szoftver struktúrája így követni képes a szervezet struktúráját.Hogy ez mit jelent pontosan?
Ez sokakat megrémiszt, pedig a törvény ismeretében képesek vagyunk úgy felépíteni a rendszert, hogy az alkalmazásokat kisebb szeletenként tervezzük meg, amelyből végül összeáll az egységes szervezeti alkalmazás.
Hogyan birkózunk meg a nehézségekkel?
A microservices architektúra segítségével már képesek vagyunk meghaladni a korábbi metódusokat, amelyek szerint egy szoftvernek egy adatbázisa van és egyképpen telepíthető.
Ennek természetesen ára is van.
A régi szoftverek üzemeltetése egyszerűbb volt, hiszen alapját egy alkalmazás és egy adatbázis adta. Ezzel szemben a microservices architektúra esetében külön kell üzemeltetnünk sok kisebb alkalmazást és a hozzájuk tartozó adatbázisokat, ennek eredményeképp azonban lényegesen más üzemeltetési modellre van szükség.
Egyetlen ember már képtelen átlátni és végrehajtani az üzemeltetéshez szükséges feladatokat.
A microservices forradalmasítja az automatizálást, hiszen történjen bármilyen módosítás a szoftver egyes részein, a telepítés, a frissítés, a monitorozás és a tesztelés is automatizáltan működik.
A szoftverfejlesztés másik nagy kihívása a futtatásért felelős környezet. A különféle virtuális környezeteket olyan környezetre optimalizálni, amelyek a mi rendszerünk szerint futnak, nagyon költséges lenne. Éppen ezért nem is szoftvereket szállítunk, hanem környezetre csomagolva adjuk át a szoftvert.
Hogy ez mit jelent?
A szaknyelven containerization-nek keresztelt művelet, amely garantálja, hogy a szoftver mindig ugyanabban a környezetben fusson. Ez ráadásul azzal az előnnyel is jár, hogy a fejlesztő már garantáltan abba a környezetbe fejleszt, amelyben a rendszer később élesben is fut – ezáltal a hagyományos rendszerek infrastruktúráján gyakorta előforduló kompatibilitási problémák sem jelentkeznek.
Nem jelent tehát problémát a Windows és különböző Linux operációs rendszerek kompatibilitása, hiszen – a hagyományos rendszerekkel ellentétben minden felületen ugyanúgy fut és minden kisegítő alkalmazás települ.
Így olyan problémák például elő sem fordulhatnak, hogy az ügyfél infrastruktúráján nincs – vagy éppen eltérő verzióban van – telepítve egy adott könyvtár vagy kisegítő alkalmazás (pl. http szerver), mivel mi már úgy adjuk át a környezetet egy konténerben, hogy az a tökéletes működés minden feltételét tartalmazza.
Ha tehát néhány szóban kellene összefoglalnunk, mit is ad a microservices szoftvertervezési módszertan, a következőket mondanánk:
- önszerveződő csapatok felelősek a saját kis alkalmazásukért, ez pedig jobb minőséget jelent;
- jól definiált határok adott üzleti domain/funkcionalitások körül, gyorsabban integrálható fejlesztők, könnyebben azonosítható feladatok, és tiszta kommunikációs csatornák, amely gyorsaságot eredményez;
- az új technológiák és trendek hatékony és gyors beépítése maximalizálja a tanulási lehetőségeket is, így maximális szaktudást biztosít.
A fentiek alapján kijelenthetjük, hogy a microservices architektúra a jövő, valójában azonban arról beszélhetünk, hogy ez a jelen. Elszalasztani ugyanis a módszer nyújtotta előnyöket, konkrét piaci hátrányt jelenthet.
Szögi Balázs – IP Systems Zrt.
A cikk szerzőiről
Az IP Systems-nél ezen előnyök (minőség, gyorsaság, szaktudás) mellett, amelyek cég értékei is, azért alkalmazzuk/követjük a hatékonyan a microservices architektúra tervezési mintát, mivel az energia piacon szerzett több éves tapasztalatot felhasználva, egy új energia piaci rendszer megalkotásánál, már könnyebben tudjuk a rendszer funkcionalitásait azonosítani, majd kisebb részegységekre bontani melyek majd az architektúra microservice-eit fogják alkotni. Egy microservices architektúra esetén mindig a legfontosabb(és legnehezebb) megtalálni ezeket határokat, és ezek közötti kommunikációs csatornákat amelyek később a rendszert alkotják. Ebből a tervezésből/modellből kiindulva a csapatok szervezése és köztük lévő kommunikáció kiépítése is könnyebben megy, hiszen egy scrum csapat egy(vagy több) jól definiált határokkal rendelkező service fejlesztésért felelős.
A cég profiljában a tervek alatt említett ukrán villamosenergia-hálózat kiegyensúlyozói, piacüzemeltető és elszámoló szoftverrendszer tervezése is már ezeken az alapokon történt. A rendszer komplexitása és nagysága miatt ez elkerülhetetlen volt, hiszen egy jövőbeni több csapatos fejlesztésről beszélünk. Hatékonyságukat az is növeli majd a fejlesztés során, hogy a régebbi projektjein során már jól kiépített DevOps-os automatizált folyamataink vannak, olyan technológiákat használva mint pl. Docker és egyéb modern monitorozási technológiák amelyek megkönnyítik az alkalmazósok fejlesztését és üzemeltetését. Fejlesztők pedig már szintén bevált eszköz halmazból választva már alkalmazott mintákat követve könnyedén hoznak létre és fejlesztenek újabb és újabb service-eket. Mindezt, úgy hogy, az olyan funkciókat, amelyek minden szoftverben megjelenek(pl. felhasználó kezelés), vagy éppen az microservices specifikus funkcionalitásokat (pl. service registration) nem nulláról írják újra, hanem legenerálják adott vázakból, így szinte azonnal megkezdődhet egy új service fejlesztése, ugyanazon feautre-ok újra írása nélkül.
