Kubernetes érthetően - 2. Microservice vs Monolith

A előző (Kubernetes érthetően — 1. Mi a kubernetes) cikkben a monolitikus alkalmazásokról olyan érzés jöhetett le, hogy ördögtől valóak. Természetesen nem ez volt a cél, ezért is írom a sorozat következő cikkét e két architektúráról és nem a virtualizációról.

Köszönöm a sok feedbacket Sági-Kazár Márknak.

Vágjunk is bele, hogy azért kicsit árnyaljuk a képet, mikor mit érdemes használni és mikor nem.

A Microservice architektúra egy modern szoftverfejlesztési irány, amely az alkalmazás egységeit kisebb, önálló egységekre bontja. Előnyei között szerepel a skálázhatóság és a rugalmasság.

Ez annak köszönhető, hogy ideális esetben az egyes microservice-ek önállóak, így könnyen fejleszthetők és karbantarthatók. A microservice alkalmazás esetén egy fejlesztőnek nem kell megérteni a teljes alkalmazás működését annak érdekében, hogy tudja fejleszteni az adott microservice-t. Ezzel a microservice “learning curve”-je kicsi, és gyorsabban tudunk emberi erőforrás oldalon skálázódni.

Nyilván a fejlesztés és a karbantartás függ attól, hogy milyen komplexitású az adott application stack, amit fejlesztünk. Minél több microservice-t tartalmaz az adott stack, annál nagyobb a komplexitás, így a karbantartás egyre bonyolultabb lesz és drágább. Arról nem is beszélve, hogy a microservice környezetben sokkal bonyolultabb az integráció és a kommunikáció az egyes egységek között. A tesztelésről és az erőforrásról ne is beszéljünk. :) Tapasztalataim alapján sajnos nem feltétlenül úgy vannak tervezve és fejlesztve a microservice-ek, ahogy a nagykönyvben le van írva, így általában az ideális eset, azaz a microservice mellett kiemelt előnyök ritkán valósulnak meg, ellenben a költségek ott maradnak.

Itt nyilván felvetődik a kérdés, hogy akkor miért használjunk microservice architektúrát, ha ilyen nehézkes. A választ nem feltétlenül nekem kell megadni, de alapvetően az egy ökölszabálynak kimondható, hogy elsősorban nézzük meg a use case-t, és a fejlesztő csapatok segitségével legyen meghatározva az irány; ne egy üzleti döntés határozza meg, hogy mi legyen a fejlesztési konvenció. Nyilván fel lehet ülni a bandwagonra, de nem biztos, hogy kifizetődő.

Azért előnye is van a microservice architektúrának, nemcsak hátránya, így például a skálázhatóság és a hibatűrés. A microservice rendszer lehetővé teszi, hogy az egyes egységeket külön-külön skálázzuk, ami segít a rendszer teljesítményének növelésében. Természetesen ehhez szükséges az előző cikkben említett kubernetes platform, aminek ugye az üzemeltetése sincs ingyen.

Véleményem szerint az architektúra rugalmassága abban rejlik, hogy az egyes egységek könnyen cserélhetők és bővíthetők, így könnyebben alkalmazkodhatunk a változó igényekhez. Természetesen ennek alapfeltétele az, hogy megfelelően daraboljuk az alkalmazásokat. Ennek hiányában, ha nem valósul meg ez a peremfeltétel, nem feltétlenül érvényesülnek a fent említett előnyök.

A következő dolgokban segíthet nekünk a Microservice környezet:

• Skálázhatóság: A microservice-ek bevezetésének fő oka a méretezhetőség. A szolgáltatások önállóan fejleszthetők és release-elhetőek anélkül, hogy nagyszabású szervezeten belüli koordinációs erőfeszítéseket kellene tenni (nyilván ez függ a szervezettől is).
• Hiba izolálása: Az elosztott rendszer előnyei az egyszeri hibapontok elkerülése. Felhőalapú technológiákkal különböző rendelkezésre állási zónákban telepíthetünk mikroszolgáltatásokat, így biztosítva, hogy a felhasználók soha ne tapasztaljanak kimaradást.
• Kisebb csapatok: A microservice fejlesztőcsapata kicsi és összetartó maradhat. Minél kisebb a csapat, annál kevesebb a kommunikáció és annál jobb az együttműködés. Persze ez is egy ideális világot feltételez. :) https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html (Two-Pizza Teams) A cross-team kommunikáció ennek ellenére nagyon fontos egy microservice/monolith fejlesztés esetén is.
• Technológia: A microservice környezetben az adott feladatra a legmegfelelőbb technológiát, vagy technológiákat használhatjuk.
• Gyakoribb deploy: A fejlesztési és tesztelési ciklus rövidebb, mivel a kis csapatok gyorsabban iterálnak. És mivel a frissítéseiket bármikor telepíthetik, a mikroszolgáltatások sokkal gyakrabban telepíthetők, mint egy monolith.

Azért a sok előnnyel elég komoly kihívások is járnak. :)

• Kicsi: a csapat méretére és a kódbázisra egyaránt vonatkozik. A microservice-nek elég kicsinek kell lennie ahhoz, hogy egy személy teljesen megértse.
• Egy dologra összpontosítva: a szolgáltatásnak a probléma egy aspektusára kell összpontosítania, vagy csak egy feladatot kell végrehajtania. Nyilván ez egy ideális világ, igy inkább arra kell készülni, hogy ezek a peremfeltetelek nem valósulnak meg.
• Autonóm: az autonómia lehetővé teszi a csapat számára a legmegfelelőbb nyelv és adatmodell kiválasztását. Ez általában azt jelenti, hogy minden microservice-nek saját adatbázisa van, amely nincs megosztva más szolgáltatásokkal.
• Cost: A mai világban mindenki microservice architektúrában szeretne fejleszteni, mert az trendi. De természetesen ennek ára van. Alapvetően, ahogy már említettem, az első és legfontosabb dolog, hogy a fejlesztőket edukálni kell annak érdekében, hogy megfelelő MS kódok szülessenek. Nyilván ez emberi tényező, és azzal főzünk amink van. Amivel számolni kell még, azok a microservice platformhoz szükséges költségek, melyek a monolitikus alkalmazással szembeállítva, annak többszörösei. Ugye amikor egy microservice architektúráról beszélünk, nem feltétlenül gondolunk arra, hogy milyen egyéb költségek vannak. Csak hogy néhányat említsek. Monitoring, Tracing, Logging, stb.

Ezzel szemben a Monolitikus architektúra az alkalmazást egy egységként kezeli. Előnyei között szerepel a könnyebb tesztelés és integráció. Nyilván minden függ az alkalmazásunk komplexitásától és méretétől. 🙂

A monolitikus rendszer egységes, így a karbantartás könnyebb, mint egy microservice architektúra esetén, mivel minden funkció egy helyen található. Az egységes rendszer lehetővé teszi a könnyebb tesztelést és integrációt is, mivel minden részegység együtt van a rendszerben.

Az architektúra hátrányai közé tartozik a skálázhatóság és a rugalmasság hiánya. A monolitikus rendszer nehezebben skálázható, mivel minden funkció egyben van, így ha egy része a rendszernek túlterheltté válik, akkor az egész rendszert érinti. Emellett a monolitikus rendszer kevésbé rugalmas, mivel ha változtatni kell egy funkción, akkor az egész rendszert kell módosítani.

Összefoglalva, a microservice architektúra számos előnnyel és hátránnyal is rendelkezik, mint például a könnyű fejlesztés, karbantartás, skálázhatóság és rugalmasság, ugyanakkor hátrányai is vannak, mint például a bonyolultabb integráció és kommunikáció, valamint a több erőforrás igény. A monolitikus architektúra könnyebben kezelhető, de skálázhatósága és rugalmassága korlátozott. Microservice architektúra jobban alkalmazható nagy terhelésű és gyakran változó rendszerek esetén, persze ez nem azt jelenti hogy monolitikus alkalmazásokkal nem lehet megoldani ezeket a dolgokat. :)

Csináltam egy kis táblázatot, hogy lássátok, hogy mi is a különbség, és ahogy látható nincs ingyen ebéd. Tehát amikor elkezdjük az alkalmazásunk fejlesztését, valami biztosan sérülni fog, és mérlegelnünk kell, hogy mi a fontosabb.

Nyilván a táblázatban lévő dolgok is sokmindentől függnek, így egzakt módon nem lehet szerintem megmondani melyik irány a megfelelő. Nagyban függ az adott környezettől és hogy mi a feladat.