Tekintettel arra, hogy a megismerés egyik legfontosabb eszköze az analógia, valamint arra, hogy a konyha mindenkihez közel áll, a jelen blogsorozat konyhai analógiákon keresztül, konyhanyelven közelíti meg a microservices architektúra egyes kérdéseit, problémáit. Képzeljük el, hogyan tudna egy kukta segíteni egy informatikusnak a microservies architektúrával kapcsolatban.
A blogsorozat elemei:
- Terítéken a microservices architektúra: Bevezető gondolatok a microservices architektúra főbb előnyeiről, ahogy ezt egy kukta látja egy rendezvény konyhájából.
- Kés alatt a microservices architektúra: A pályáját a honvédségi konyhán kezdő kukta tanácsai a monolitikus alkalmazások microservices service-ekké darabolásával kapcsolatban.
- Mi sül ki a microservices architektúrából? Elmélkedés a kuglófról, mazsolákról, muffinekről és csokoládédarabokról, azaz microservices és self-contained systems a sütőből.
Kés alatt a Microservices architectúra
Az előkészítés fontossága
Bizonyára mindenki járt már olyan konyhában, ahol éppen főztek. Aki szerencsésebb, láthatta, hogy a gyakorlott amatőr vagy profi szakácsok hogyan dolgoznak. Az egyik legizgalmasabb s egyben az egyik legfárasztóbb lépés a hozzávalók előkészítése. Ennek egyes elemei kevésbé látványosak, míg bizonyos előkészítő lépések önmagukban is művészi tevékenységnek tekinthetők. Ritkán látunk zöldséghámozást a főzőműsorokban, pedig bizony a zöldségeket rendszerint meg kell hámozni. Egyszerűen nem látványos, és viszonylag kevés művészi értékkel bír (bár ahogy egy profi szakács hagymát darabol...). A húsok előkészítése pedig egyenesen átlóg egy rokon szakma, a hentes tevékenységi körébe.
A rosszul előkészített főzés, legyenek az előkészítést követő lépések bármily profin is kivitelezve, rossz eredménnyel zárul. Gondoljunk csak egy nem kellőképpen megtisztított csirkeszárnyra vagy csirkecombra. A legtökéletesebb sütés után is tönkreteszik a végeredményt az ottmaradt tollvégek, szőrök.
Probléma
Maradván a csirkénél mint konkrét főzési alapanyagnál, gyakran ütközünk abba a problémába, hogy a csirke egészben nő. Azaz eredendően van a monolitikus csirke, és nem nőnek külön szárnyak meg combok, pláne nem nőnek külön alsó és felső combok. Valahogy fel kell darabolni a madarat. Ez úgy nagyvonalakban menni is szokott, mindenki érzi, hogy megközelítőleg hogyan kellene. Aztán kiderül, hogy nem olyan egyszerű, mert ott van egy fránya csont. Az eltökéltebb harcosok (különösen a honvédségi konyhán) ilyenkor nem esnek kétségbe, erőből megoldják a darabolási kérdést, olykor kés helyett bárdot használva. Így jön létre a „robbantott csirke”, amikor is a darabolás fő szempontja a méret. Persze ezek után bármily tökéletes a főzés, a gasztronómiai élményt tönkreteszik a fogunk alatt ropogó csontszilánkok.
Javaslat
A csirkét próbáljuk meg az ízületek, kapcsolódási pontok mentén darabolni. Kellő gyakorlat hiányában érdemes a csirke egyes „alkatrészeit” kicsit megmozgatni, hogy kiderüljön, mely részei mozognak külön, hol vannak a kapcsolódási pontok. E pontok mentén a madár egy egyszerű konyhakéssel, bárd használata nélkül is könnyedén feldarabolható.
Konklúzió
A microservices architektúra esetén is, mint oly sokszor, felülről lefelé történik a tervezés, a modellezés. A rendszerszintű modellt valamiképp fel kell darabolni apróbb részekre. Nem megfelelő darabolás esetén, bármely tökéletesen is valósítjuk meg az egyes micorservice-eket, a végeredmény nem lesz megfelelő. Azaz a darabolás, és úgy általában a tervezés, a miroservices architektúra esetén kulcsfontosságú.
Az egyes service-ek határait a rendszer „ízületei”, természetes kapcsolódási pontjai mentén érdemes kialakítani. Ebben segítségünkre lehet egy másik „szörnyeteg”. A science fiction- és a fantasy-irodalomban gyakori megoldás, hogy egy szörny legyőzéséhez főhősünk egy másik szörny segítségét veszi igénybe (Jurassic Park, Star Wars, Harry Potter stb.). E kicsit sablonos fordulatot alkalmazva: hívjuk segítségül a domain driven designt. A DDD nem áll távol a microservices architektúrától, olyannyira nem, hogy sokak szerint a microservices architektúra egyik nagy érdeme a DDD-ből származó bounded context fogalom komolyan vétele és kikényszerítése.
Az alkalmazást domain driven design-megközelítésben tervezve megjelennek a bounded contextek. A bounded contextek tekinthetők a microservice-ekre való darabolás első szintű egységeinek, azaz egy-egy contextből lehet egy-egy microservice. Az egyes contextek további subcontextekre bontva mehetünk tovább a darabolásban, azaz az egyes subcontextekből lehetnek microservice-ek.
A domain driven design valószínűleg sok fejlesztőhöz ösztönösen közel áll, és bizonyos elemeit ösztönösen művelik is. Érdemes ezt egy kicsit tudatosabban is művelni. A fenti példán kívül számos hasznos elemet átvehetünk a DDD-ből; fejlesztők, termékmenedzserek egyaránt.
Szkiba Iván, System Architect, NNG Kft.
Cikksorozatunk első részéhez kattints ide!
Amennyiben szeretnél hasonló tartalmakat olvasni, kövess minket a Facebook oldalunkon is!
