A microservice-architektúrát olyan technológiai óriások népszerűsítették, mint a Netflix, Spotify, Uber vagy Amazon, akik a mikroszolgáltatások előnyeit kihasználva tudtak maguknak jelentős piaci előnyt kovácsolni. Az ehhez hasonló, nagy méretű szolgáltatások esetében magasabb produktivitást, könnyebb méretezhetőséget és gyorsabb termékfejlesztést hozott. De az architektúra nem mindenkinek való, például magas a beruházási költsége, alkalmanként nagyobb IT-csapatot kíván, és sok külső partnerrel kell együttműködni.
Vannak azonban olyan területek, ahol a mikroszolgáltatások előnyei maguktól értetődők. Például, ha egy saját fejlesztésű webáruház meg szeretné változtatni a fizetési lehetőségeket, akkor a módosításokat csupán a fizetési mikroszolgáltatásba kell átvezetni, a rendszer többi része érintetlenül működik. A mikroszolgáltatás-architektúrák növelhetik a vállalat agilitását és javíthatják az alkalmazás, termék méretezhetőségét, de nem minden esetben. (Előnyeiről lásd „A mikroszolgáltatás előnyei” című keretet!) Ha rosszul közelítik meg a kérdést, sok probléma merülhet fel. A mikroszolgáltatás-architektúra használata előtt a fejlesztőcsapat vezetőjének választ kell találnia az alábbi három, alapvető kérdésre.
Miért?
Ideális esetben a válasz egy olyan üzleti befektetést jelent, amelynek világosan látjuk megtérülését. A szoftverfejlesztők többnyire azért használják a mikroszolgáltatás-architektúrát, hogy folyamatosan új funkciókat tudjanak szállítani. Ha ez nem tartozik a vállalati célok közé, akkor érdemes egy másik architektúrában gondolkodni.
A „miért” kérdés megválaszolásakor a döntéshozó mindenképp tartsa szem előtt az alábbiakat.
– A mikroszolgáltatás-architektúra megteremti azt az agilis DevOps környezetet és folyamatos fejlesztési gyakorlatot, amelynek segítségével a fejlesztő csapatok nagyobb gyakorisággal, gyorsabban dobhatják piacra az új fejlesztéseket.
– A mikroszolgáltatás-architektúra nem egyszerű. Arra összpontosít, hogy a funkcionalitást olyan elosztott komponensként teremtse meg, amelyet függetlenül lehet fejleszteni tesztelni, bevezetni, méretezni és frissíteni – ehhez komplex tervezés szükséges.
– A mikroszolgáltatás-architektúra nem jelent költségmegtakarítást. Bevezetése tipikusan sokkal többe kerül, mint a monolitikus architektúráé.
– A mikroszolgáltatások nem API-k. Az architektúra egy módszer arra, hogy megteremtsünk egy API mögötti funkcionalitást, de különbözik magától az API-tól.
– A mikroszolgáltatások nem konténerek. A legtöbb csapat konténerekben használja a mikroszolgáltatásokat, de csak akkor használható a mikroszolgáltatás-architektúra, amikor a tervezés biztosítja a komponensek függetlenségét.
|
Nanonlexikon A mikroszolgáltatás egy olyan alkalmazáskomponens, amely célzott hatókörű, erősen beágyazott, lazán csatolt, függetlenül telepíthető és méretezhető. A mikroszolgáltatás architektúra komoly üzleti hasznot hozhat, de a siker gyakran elmarad, mert félreértések övezik, hogy pontosan miért, mikor és hogyan használható. Forrás: Gartner |
Mikor?
Akkor jön el az ideje a mikroszolgáltatás-architektúrának, ha a fejlesztőcsapat már használja a miniszolgáltatásokat, belekóstolt az agilis DevOps-ba, és a folyamatos fejlesztési gyakorlatot is ismeri, de mégsem éri el a kívánt frissítési ritmust.
Egy tagolt alkalmazás nem minden részét kell szükségszerűen mikroszolgáltatásba kiszervezni. Tervezéskor nagyon fontos, hogy a csapat pontosan megértse, mikor szabad a különböző funkciókat szétválasztani függetlenül használható szolgáltatásokba. A szétválasztást irányító elv: ami együtt változik, az maradjon is együtt.
|
A mikroszolgáltatás-architektúra előnyei A különálló, kis méretű szolgáltatások halmazának minden eleme egyetlen üzleti funkciót lát el. Ezek a szolgáltatások más-más programozási nyelvben íródhatnak, általában rövidebb, könnyebben átlátható kódsorokat jelentenek. A különböző szolgáltatások kommunikálnak egymással, de függetlenül is megállják helyüket. Ez azt jelenti, hogy a programozók könnyebben, jobban átláthatják a kódot, hiszen egy konkrét részegységre tudnak összpontosítani, így hatékonyabban tudnak dolgozni. Az új kollégák betanítása is rövidebb, hiszen nem kell az egész, nagy monolit struktúrát átlátniuk, elég az egyik szolgáltatással megismerkedniük. A mikroszolgáltatások telepítése komplex, időigényes feladat, de hiba esetén csak egy mikroszolgáltatás érintett, könnyebb a hibaelhárítás, mintha a monolit szerkezetbe kellene belenyúlni. Karbantartásuk, tesztelésük is gyorsabb. Az összetevők stabilak és megbízhatóak. Ha az egyik elemben hiba jelentkezik, az nem hat a teljes alkalmazásra, nincs leállás. Emiatt gyorsabb a fejlesztés és az implementálás is, hiszen a szolgáltatások egymástól függetlenül fejlődnek. A méretezhetőség is könnyen, gyorsan megoldható. |
Hogyan?
Ahhoz, hogy a mikroszolgáltatásokkal sikeresek legyünk, a fejlesztőcsapatnak át kell vizsgálnia és változtatnia kell:
– a csapatstruktúrát és felelősségi köröket;
– a működési modellt;
– az agile és DevOps használatát;
– a megosztott számítástechnikai architektúraminták ismeretét és használatát.
A fejlesztőcsapat struktúráját a mikroszolgáltatásokhoz kell igazítani. A csapat termékorientált modellel működik a legjobban. A tagok dönthetnek a termékekkel kapcsolatban, ehhez üzleti teljesítménymutatók (KPI-k) szerint mérik azokat.
Vass Enikő
