• Mik azok a mikroszolgáltatások?

• Mi az a monolit kód?

• Miért választanád az előbbi vagy az utóbbi architektúrát? Meddig?

• Kéz a kézben járnak?

• Az egyik az ellentéte a másiknak?

• Mit jelent az architektúra?

• Milyen „mikro” kellene, hogy legyen a mikro?

Ezek mind fejfájást okozó kérdések egy kezdő DevOps fejlesztő számára, akiknek az agya forr a tanulási görbéjétől. Megpróbálom megválaszolni őket neked a saját kutatásaim alapján, de először hadd fessek fel egy képet.

Minden egy ötlettel kezdődik. Még jobb, ha az jó ötlet, ugye? Egy nap felkelsz és rájössz mindenre: Akarsz egy e-kereskedelmi weboldalt építeni, és jelentős termékeket eladni az embereknek, amelyek pozitív változást hozhatnak. Vagy csak pénzt akarsz keresni, mindkettőhöz egy összetett teljes stacket kívánó webalkalmazásra van szükséged, az biztos. Leülsz az azonos hullámhosszon lévő társaiddal, megnyitjátok a távoli adattáratokat, elkezditek fejleszteni a webalkalmazásotokat, és a csapatból árad a kód.

Ez fantasztikus! Körülbelül egy hét múlva elkészül az első futó verzió localhoston.

Mindannyian kezdő fejlesztők vagytok, és fejest ugrotok a küzdelembe párna és sisak nélkül, csak az lelkesedéssel felfegyverkezve. Annak ellenére, hogy a fejlesztői konzol tele van figyelmeztetésekkel és hibákkal a böngészőn belül, megérezitek az első siker ízét. Aznap este mindannyian kinyittok néhány sört, és hajnalig ötleteltek. Ez egy pet-projekt, tehát időd van bőven.

Még nem is gondolkodsz a projekted hosztolásán, de ez nem is tartozik ebbe a cikkbe. A tegnapi ötletelés egy jelentős adag ötletet hozott, amelyekből készítettél egy teendőlistát a megvalósítandó funkciókról és a megoldandó problémákról. Kezdjünk neki!

Hetek telnek el, a webalkalmazásod ígéretesen néz ki, és a funkciók megjelennek, sőt megfelelően működnek is. Az egyik barátod, nevezzük őt Billy-nek, rájön, hogy a kódbázis egyre nagyobb, mint egy vastag fiú, nehezen kezelhető. Tudtodon kívül megvizsgálja ezt a kis dolgot, amit architektúrának hívnak. Nem, nem hídak és felhőkarcolók építésére gondolok. Szoftverarchitektúráról beszélünk.

Úgy tűnik, hogy ez is létezik, és érezni fogjátok a hiányát. Tehát szoftver architektúra. Miután beírja a keresőmezőbe a „segítség, a kódbázisom túl nagy és kezelhetetlen lesz” keresést, belebotlik ebbe a kis dolgokba, amit mikroszolgáltatásoknak hívnak. Megosztja felfedezéseit a csapattal, de mindenki más elégedett azzal, ahogy a dolgok alakulnak.

Mindenki egyetért abban, hogy ezzel valamikor foglalkozni kell majd, de hagyják, hogy ez legyen a holnap problémája. Modularitás? Robosztusság? Tulajdonjog? Rugalmasság? Á, nem most. Fókuszáljunk a fejlesztésre. Így is könnyebb tesztelni a kódunkat, egy monolitikus rendszer marad.

Szegény Billy, nem hallgattak rá…

Még néhány hét telik el, a projekt egyre jobban néz ki, de ebben a pontban a kódbázis kezelése kezd nehézkessé válni. Most nem, viszont van egy másik ötlet! Reklámozzunk! A csapat megállapodik abban, hogy bevezeti a tipikus „vegyél egyet, kapsz egyet ingyen” ajánlatot a közelgő nagy megnyitóra. Mennyire eredeti.

Úgy végzed, hogy viszonylag könnyű lenne hozzáadni némi logikát a kocsi funkcióhoz, ami kivonja a legolcsóbb termék költségét. Könnyű, mint az egyszer egy! Elköteleződőt, eltolod és büszkén kopogtatsz a mellkasodon.

A barátod azt mondja, hogy statisztikák elengedhetetlenek, és igaza van, mindenki rájön, hogy szükséges a hatások követése érdekében az eladás nyomtatása. Egy pillanat, ez is pofonegyszerű, adj némi kódot a kocsilogikához, amely egy Boole-értékhez igaz értéket állít be az adatbázis új oszlopában, így követhetitek, hogy az adott eladás a promóció részét képezte. Kész, folytassuk.

A másik barátod rájön, hogy előnyös ezt csak egyszer elérhetővé tenni fejenként. Végül is nem akarsz csődbe menni az elején, ugye? Valahogy meg kell jelölni a felhasználókat. Tehát még egy sor kód a kocsi funkcióban, egy újabb Boole az adatbázisban, de még rendben vagyunk.

El is kell rejtenie a promóciós bannert az első oldalon azoknak a felhasználóknak, akik már felhasználták ezt, és e-maileket kell küldeni azoknak a felhasználóknak, akik még nem használták fel a promóciót, és amíg ott vagyunk, marketingcélokra hírlevél-statisztikák készítése is jól jönne.

Ezek mind nagyon hatékony ötletek, amelyeket a csapat megvalósított. Jó munka srácok, de van egy probléma!

A csapat hideg póker arccal bámulja a kocsi funkcióját, miközben a ventilátorok állandó zümmögése a számítógépekben egyre hangosabbá válik a fejedeidben. Ezenfelül rájönnek, hogy a kocsi funkció több mint 500 sor kódot tartalmaz. Úgy gondoljátok, hogy ez túl hosszú.

És ne feledkezzünk meg az egy további funkcióról sem! A döntés megszületett, az alkalmazás élőben van, és az üzlet beindul. Mi tehet kárt benne?

Nos, sok minden, úgy tűnik. Egy év, és néhány további funkció után a tranzakciós adatbázis túl nagyra nőtt. Egy teljesen új és felülvizsgált adatbázisra sürgősen szükség van. Sajnos a régi adatbázis a kódban mindenhol hivatkozásként szerepel, ami ekkora szinten már teljesen kezelhetetlenné válik. Minden hivatkozás áváltoztatása az új adatbázisra az egész projekt nagy átalakítása, és boom, mint a dinamit. Kiderül, hogy az ellenállás útja csak bizonyos pontig visz el, komoly fájdalom nélkül a hosszú távon.

Nos, a csapat meghallgathatta volna Billyt, igen, de nem állítom, hogy a monolitikus kód nem megfelelő. Itt arról van szó, hogy helyesen történt-e vagy az adott felhasználási esetre választott. Csak egy bizonyos pontig használatos az üzlet első növekedési fázisában. Bizonyos üzletek esetén bizonyos követelményekkel és felhasználási esetekkel, még hosszú távon is bölcs választás lehet. Lehet, hogy van egy égető kérdés a fejedben:

Mi az a monolit kód?

Ez egy olyan szoftverarchitektúra formája, amely egyetlen önálló, egységes szoftver alkalmazásra utal, amely önállóan létezik és nem függ más szoftver alkalmazástól. A kódbázis általában egy adattárban található meg, közös build rendszert és közös könyvtárakat használva. Három fő összetevője van. A kliensoldali felhasználói felület, a szerveroldali alkalmazás és az adatok interfésze, mind ugyanazon adatbázissal lép kölcsönhatásba. Mint láthatod, a rugalmasság és a moduláris leválasztás itt nem szerepelnek napirenden. A következő dolog, ami biztosan eszedbe jut:

Mi az a szoftver architektúra?

Amikor szoftver architektúráról beszélünk, a szoftverrendszer alapvető szerkezetére, csontvázára gondolunk. Az ilyen szerkezetek és bonyolult rendszerek létrehozásának tudományát is fontolóra vesszük. Ez az összetett szoftverrendszer tervrajza, ahol minden szerkezet szoftverelemekből, azok közötti kapcsolatokból és mind az elemek, mind a kapcsolatok tulajdonságaiból áll. Ez a fejlesztési projekt tervrajza maga felhasználható az összes szükséges feladatok extrapolálására, amelyeket csapatoknak, fejlesztőknek és más résztvevőknek el kell végezniük. Nem hangzik ez bonyolultnak és egyben izgalmasnak is?

Igen. Mondhatnánk, hogy ez az egész szoftverrendszer és fejlesztési projekt magas szintű áttekintése, tervezése és koordinálása. Ez is egy hasonlat az építészeti építkezésekhez.

Vizsgáljuk meg, miről beszélt Billy az elején…

Mik azok a mikroszolgáltatások?

A mikroszolgáltatás architektúra egy architekturális minta, amely egy szoftver alkalmazást lazán összekapcsolt, finomszemcsés szolgáltatások gyűjteményeként szervez. A mikroszolgáltatások egy nagyon specifikus, végpontok közötti domént vagy üzleti képességet valósítanak meg egy adott kontextus határain belül. Ezek önállóan létrehozottak és bevezethetők. Képzelj el minden szolgáltatást egy szoftverrendszer vagy alkalmazás részeként, amelynek egyetlen, korlátozott felelőssége van a fent említett előre beállított kontextus határain belül.

Majdnem mint egy objektum az OOP paradigmában, ebben az értelemben, ahol minden objektumnak (többek között) egyetlen, előre meghatározott felelőssége kell legyen a SOLID programozási elvek alapján. Ezek az objektumok/komponensek specifikus kommunikációs protokollok és követelmények alapján kommunikálnak egymással. A monolitikus architektúrával ellentétben itt látható, hogy az egész rendszer részekre van osztva, mint Lego kockák.

A rugalmasság és a lazán csatolt kapcsolat a fejlesztési fegyelem és tervezés kulcsfontosságú részei.

Tegyük őket összehasonlításba...

Nem teljesen korrekt azt mondani, hogy a mikroszolgáltatások a monolitok ellentéte. Ehelyett mindkettő különböző módszerek a szoftvertervezésre és problémamegoldásra, miközben figyelembe veszik az igényeket.

Dióhéjban, a monolitikus architektúra egyszerű alkalmazásokhoz megfelelő, amelyek nem gyakran vagy csak minimálisan változnak. Ezek közé tartozik szövegszerkesztők vagy a Linux-os operációs rendszerek legtöbb kernelje. Az ilyen típusú architektúra előnyei közé tartozik a könnyebb tesztelés, hibakeresés és egyszerűség. Csak egy önálló alkalmazást kell üzembe helyezni, tesztelni és követni. Ugyanezt megtenni egy mikroszolgáltatások alapú szoftverrel kihívást jelenthet és időigényes lehet.

A teljesítmény hatalmas tényező, amelyben a monolitikus kód jeleskedik, mivel a rendszerhívások elvégezhetők a kommunikációs felek közötti költségek nélkül. Az egyik súlyos hátrány a fent említett példa, hogy ha rossz esetválasztásra vagy rosszul valósították meg, az nagyon gyorsan kicsúszhat a kézből. Annak ellenére, hogy egy új projekt elindítása könnyebb és gyorsabb egy monolitikus architektúrával, a történetünk összegez minden hátrányt. Rugalmasság hiánya, szegényes integrálhatóság a frissített funkciókkal vagy új technológiával.

Mi van a megbízhatósággal? Egyetlen hiba vagy rossz konfiguráció az egész webalkalmazást ledöntheti, mint a dominók, ahelyett, hogy egyetlen rész tönkremegy, de minden más továbbra is a tervezett módon működik. Például, ha külön mikroszolgáltatásokról beszélünk, ha a vélemények betöltése hibás egy bug miatt, a vásárlók még mindig használhatják az oldalt vásárlásra vagy más funkciók használatára. Azonban egy összetett szoftverrendszer építése, amely mikroszolgáltatásokból áll, bonyolult és nagyon finomítható lehet.

Gondolj a magasabb és költségesebb hálózati használatra és az időigényes, kiterjedt tesztre, amit igénybe venne. És mi van a karbantartással és az üzemeltetéssel? Mindkét esetben hosszúra nyúlnak. Egy túlnőtt és összetett monolit karbantarthatósága fájdalmas lehet. Azonban egy komplex mikroszolgáltatás-architektúra rendszer futtatása általában bonyolultabb annak jellegénél fogva. Mindez a választáson múlik. Hol használjuk milyen architektúrát? Válassz okosan.

Összefoglalásként, egyik sem jobb a másiknál általános értelemben. Mindkét architektúra előnyökkel és hátrányokkal rendelkezik, és két különböző világ. Tartsd ezt szem előtt! A tervezés kulcsfontosságú; meg kell tervezned a továbblépéseidet.

Kérdezd meg magadtól: mik az én pontos céljaim és követelményeim? Végezz kutatást, majd döntsd el, hogyan folytatod. Hívd fel Billyt. Lehet, hogy a csapatodban szeretnéd őt, ő okos.

Milyen mikro kellene, hogy legyen a mikro?

Ó, igen, a forró téma. Látod, ez mindig izgalmas vitákat indíthat mérnökök és hasonlók között. Az eddigi tudásom alapján helyezem el a tétet. Először is, a mikroszolgáltatás kifejezés félrevezető. Mi az a „mikro”? Mindannyian egyedi emberek vagyunk különböző nézőpontokkal és tapasztalatokkal, tehát főként a nézőponttól és az eset felhasználásától függ.

Az ilyen típusú architektúrákkal nincsenek világos határok és nincsenek rögzített szabályok sem, ezért segítene megtalálni a belső békémet, ha egyszerűen csak szolgáltatásoknak neveznénk őket, de ha erről nem, akkor abban meg tudunk egyezni, hogy nem értünk egyet.

Újra segítségül hívom két kedvenc szövetségesemet, az OOP paradigmát és a SOLID elveket. Remek dolgok! Kritikus fontosságú, hogy ne essünk túlzásba ezzel kapcsolatban. Ez azt jelenti, hogy a szolgáltatások „túl kicsivé” tételének célja a moduláris kód értelmetlen lesz. A szolgáltatás logikája és adatai egy egész résznek kell, hogy értelme legyen, hasonlóan az osztály adataihoz és módszereihez. Újra az osztályok felé fordulva egy tökéletes analógiát, gondolj az Java állomány objektumra és annak módszereire.

Olvashatsz és írhatsz az állomány objektumaidra, például. Külön FileWriter vagy FileReader osztályok különállósága túl modularizációt jelenthet, és ez azt jelenti, hogy az egész mikro túl mikro lett. A valós helyzetekben azonban sokkal nehezebb és bonyolultabb látni, hogy hol van ez a vékony és finom vonal a túlmodularizáció és a szolgáltatásaidhoz túl nagy hatókör biztosítása között. Ezért a munka méretének és hatókörének helyes meghatározása egy művészet.

Ne tedd őket a lehető legkisebbre csak a méretük kedvéért. Néhány szolgáltatás hatalmas lehet a kódsorok tekintetében. Azonban a legfontosabb dolog, amit figyelemmel kell kísérned, hogy egyetlen szolgáltatás hajtson-e végre kettő vagy több, nem összefüggő dolgot. Az lesz a problémád és nagy fejfájás később!

Mint a fiúk és az e-kereskedelmi weboldaluk példájából is láttuk, a legkisebb ellenállás útja csak egy pontig működik. Ha változtatást vagy funkciót kell alkalmaznod, ami nem illeszkedik egy szolgáltatásodhoz, hozz létre egy újat, ha lehetséges.

Monolitok hatékony és egyszerű módja lehet az indulásnak, de a szolgáltatások, más néven mikroszolgáltatások, a komplex és érett vagy érő rendszerek kezelésének módja, és természetes választássá válhatnak a továbblépéshez, ahogy a szervezet fejlődik és bővül üzleti képességeit illetően. Az, hogy megértsük, hogyan tartsuk meg vagy hozzuk létre ezt a fajta architektúrát, segíthet versenyképes maradni és értékesebbé tenni téged a vállalatod számára. Ennyi, emberek!

A történet tanulsága mindig:

Végezz kutatást, gondold végig, számíts a váratlanra és legyen terv!

Szerző: Gergely Bálint