Prej kohësh kam dashur të shkruaj një artikull për arkitekturën me mikrosherbime, por gjithmonë më kanë ndalur dy gjëra: sa më thellë hyja në këtë temë, aq më shumë më dukej se ajo që di është e vetëkuptueshme, ndërsa ajo që nuk di kërkon ende shumë studim. Nga ana tjetër, mendoj se tashmë ka mjaftueshëm material për reflektim edhe për një audiencë më të gjerë. Prandaj, mendimet alternative janë të mirëpritura.
Ligji i Conway dhe lidhja mes biznesit, organizatës dhe sistemit të informacionit
Edhe një herë po i lejoj vetes të citoj:
«Ădo organizatĂ« qĂ« projekton njĂ« sistem (nĂ« kuptimin e gjerĂ«) do tĂ« prodhojĂ« njĂ« dizajn, struktura e tĂ« cilit pasqyron strukturĂ«n e ekipeve brenda asaj organizate»
â Melvyn Conway, 1967
Sipas mendimit tim, ky ligj lidhet mĂ« shumĂ« me mĂ«nyrĂ«n e arsyeshme tĂ« organizimit tĂ« biznesit sesa drejtpĂ«rdrejt me sistemin e informacionit. Po e shpjegoj me njĂ« shembull. Le tĂ« supozojmĂ« se kemi njĂ« mundĂ«si biznesi mjaft tĂ« qĂ«ndrueshme, me njĂ« cikĂ«l jetĂ«sor aq tĂ« gjatĂ« sa tĂ« ketĂ« kuptim tĂ« ngrihet njĂ« ndĂ«rmarrje pĂ«r tĂ« (kjo nuk Ă«shtĂ« gabim shtypi, por mĂ« pĂ«lqen shumĂ« ky term qĂ« e kam huazuar). Natyrisht, sistemi mbĂ«shtetĂ«s i kĂ«tij biznesi do tâi pĂ«rputhet atij nga ana organizative dhe e proceseve.
Orientimi i sistemeve të informacionit ndaj biznesit
Po e shpjegoj me njĂ« shembull. Le tĂ« supozojmĂ« se ekziston njĂ« mundĂ«si biznesi pĂ«r organizimin e njĂ« biznesi tĂ« shitjes sĂ« picĂ«s. NĂ« versionin V1 (ta quajmĂ« para-informativ), kompania pĂ«rbĂ«hej nga njĂ« piceri, njĂ« arkĂ« dhe njĂ« shĂ«rbim dĂ«rgese. Ky version jetoi gjatĂ« nĂ« kushte tĂ« njĂ« ndryshueshmĂ«rie tĂ« ulĂ«t tĂ« botĂ«s pĂ«rreth. MĂ« pas erdhi versioni 2 â mĂ« i avancuar dhe i aftĂ« tĂ« pĂ«rdorte nĂ« themel njĂ« sistem informacioni pĂ«r njĂ« biznes me arkitekturĂ« monolitike. Dhe kĂ«tu, sipas mendimit tim, lind njĂ« padrejtĂ«si vĂ«rtet e madhe ndaj monoliteve â gjoja arkitektura monolitike nuk pĂ«rputhet me modelin domenor tĂ« biznesit. Po tĂ« ishte kĂ«shtu, sistemi nuk do tĂ« mund tĂ« funksiononte fare â nĂ« kundĂ«rshtim si me ligjin e Conway-t, ashtu edhe me logjikĂ«n e shĂ«ndoshĂ«. Jo, arkitektura monolite i pĂ«rshtatet plotĂ«sisht modelit tĂ« biznesit nĂ« kĂ«tĂ« fazĂ« tĂ« zhvillimit tĂ« kompanisĂ« â natyrisht kam parasysh fazĂ«n kur sistemi tashmĂ« Ă«shtĂ« krijuar dhe vĂ«nĂ« nĂ« pĂ«rdorim. NjĂ« fakt vĂ«rtet i rĂ«ndĂ«sishĂ«m Ă«shtĂ« se, pavarĂ«sisht qasjes arkitekturore, si arkitektura e orientuar drejt shĂ«rbimeve versioni 3, ashtu edhe arkitektura me mikrosherbime versioni N do tĂ« funksionojnĂ« po aq mirĂ«. Ku qĂ«ndron thelbi?
Gjithçka rrjedh, gjithçka ndryshon, ose mikrosherbimet â mjet pĂ«r tĂ« luftuar kompleksitetin?
Përpara se të vazhdojmë, le të shqyrtojmë disa keqkuptime rreth arkitekturës me mikrosherbime.
Mbështetësit e qasjes me mikrosherbime shpesh thonë se ndarja e monolitit në mikrosherbime e thjeshton zhvillimin falë zvogëlimit të bazës së kodit të secilit shërbim veçmas. Sipas mendimit tim, kjo tezë është krejtësisht absurde. Sinqerisht, a ju duket kompleks ndërveprimi i drejtpërdrejtë brenda një monoliti dhe një kodi homogjen? Po të ishte vërtet kështu, të gjitha projektet do të ndërtoheshin që në fillim si mikrosherbime, ndërsa praktika tregon se migrimi nga monoliti drejt mikrosherbimeve është shumë më i zakonshëm. Kompleksiteti nuk zhduket askund; ai thjesht kalon nga modulet e veçanta te ndërfaqet (qoftë autobusë të të dhënave, RPC, API apo protokolle të tjera) dhe te sistemet e orkestrimit. Dhe kjo është e vështirë!
Edhe pĂ«rparĂ«sia e pĂ«rdorimit tĂ« njĂ« stack-u heterogjen mbetet e diskutueshme. Nuk do tĂ« kundĂ«rshtoj se kjo Ă«shtĂ« e mundur, por nĂ« praktikĂ« haset rrallĂ« (duke paraprirĂ« â kjo duhet tĂ« ndodhĂ«, por mĂ« tepĂ«r si pasojĂ« sesa si avantazh).
Cikli jetësor i produktit dhe cikli jetësor i shërbimit
Shikojeni edhe njĂ« herĂ« diagramin e mĂ«sipĂ«rm. Nuk e kam theksuar rastĂ«sisht shkurtimin e ciklit jetĂ«sor tĂ« çdo versioni tĂ« veçantĂ« tĂ« biznesit â nĂ« kushtet moderne, pikĂ«risht pĂ«rshpejtimi i kalimit tĂ« biznesit nga njĂ« version nĂ« tjetrin Ă«shtĂ« pĂ«rcaktues pĂ«r suksesin e tij. Suksesi i produktit pĂ«rcaktohet nga shpejtĂ«sia me tĂ« cilĂ«n testohen hipotezat e biznesit nĂ« tĂ«. Dhe pikĂ«risht kĂ«tu, sipas mendimit tim, qĂ«ndron avantazhi kryesor i arkitekturĂ«s me mikrosherbime. Por le ta marrim me radhĂ«.
Le tĂ« kalojmĂ« nĂ« shkallĂ«n tjetĂ«r tĂ« evolucionit tĂ« sistemeve tĂ« informacionit â te arkitektura SOA e orientuar nga shĂ«rbimet. Pra, nĂ« njĂ« moment tĂ« caktuar, ne veçuam nĂ« produktin tonĂ« shĂ«rbime afatgjata â afatgjata nĂ« kuptimin qĂ«, gjatĂ« kalimit mes versioneve tĂ« produktit, ka gjasa qĂ« cikli jetĂ«sor i shĂ«rbimit tĂ« jetĂ« mĂ« i gjatĂ« se cikli jetĂ«sor i versionit tĂ« radhĂ«s tĂ« produktit. Logjikisht, do tĂ« ishte mĂ« mirĂ« tĂ« mos i ndryshonim fare â pĂ«r ne Ă«shtĂ« e rĂ«ndĂ«sishme pikĂ«risht shpejtĂ«sia e kalimit nĂ« versionin e ardhshĂ«m. Por, fatkeqĂ«sisht, jemi tĂ« detyruar tĂ« bĂ«jmĂ« ndryshime tĂ« vazhdueshme nĂ« shĂ«rbime â dhe kĂ«tu na vlejnĂ« tĂ« gjitha: praktikat DevOps, kontejnerizimi e tĂ« tjera â gjithçka qĂ« na vjen nĂ« mendje. Por kjo ende nuk janĂ« mikrosherbime!
Mikrosherbimet si mjet për të luftuar kompleksitetin⊠e menaxhimit të konfigurimit
Dhe pikĂ«risht kĂ«tu mĂ« nĂ« fund mund tĂ« kalojmĂ« te roli pĂ«rcaktues i mikrosherbimeve â ky Ă«shtĂ« njĂ« qasje qĂ« thjeshton menaxhimin e konfigurimit tĂ« produktit. MĂ« saktĂ«, funksioni i secilit mikrosherbim pĂ«rshkruan pikĂ«risht njĂ« funksion biznesi brenda produktit sipas modelit tĂ« domenit â dhe kĂ«to tashmĂ« janĂ« gjĂ«ra qĂ« nuk jetojnĂ« brenda njĂ« versioni afatshkurtĂ«r, por brenda njĂ« aftĂ«sie biznesi afatgjatĂ«. Kalimi nĂ« versionin tjetĂ«r tĂ« produktit ndodh fjalĂ« pĂ«r fjalĂ« nĂ« mĂ«nyrĂ« tĂ« padukshme â ju ndryshoni/shtoni njĂ« mikrosherbim, ose ndoshta vetĂ«m skemĂ«n e ndĂ«rveprimit tĂ« tyre, dhe papritur e gjeni veten tashmĂ« nĂ« tĂ« ardhmen, duke lĂ«nĂ« pas konkurrentĂ«t e dĂ«shpĂ«ruar qĂ« vazhdojnĂ« tĂ« hidhen mes versioneve tĂ« monoliteve tĂ« tyre. Tani imagjinoni se ekziston njĂ« vĂ«llim mjaft i madh mikrosherbimesh me ndĂ«rfaqe dhe aftĂ«si biznesi tĂ« pĂ«rcaktuara paraprakisht. Dhe ju vini e ndĂ«rtoni strukturĂ«n e produktit tuaj nga mikrosherbime tĂ« gatshme â thjesht duke vizatuar, pĂ«r shembull, njĂ« diagram. Urime â ju Ă«shtĂ« krijuar njĂ« platformĂ« â dhe tani mund ta zgjeroni biznesin sipas dĂ«shirĂ«s. Ăndrra, Ă«ndrra.
PĂ«rfundimet
- Arkitektura e sistemit duhet të përcaktohet nga cikli jetësor i përbërësve që e përbëjnë. Nëse një komponent jeton brenda kornizës së versionit të produktit, nuk ka kuptim të rritet kompleksiteti i sistemit duke zbatuar qasjen e mikrosherbimeve.
- Arkitektura e mikrosherbimeve duhet tĂ« bazohet nĂ« modelin e domenit â pĂ«r arsye se aftĂ«sia e biznesit Ă«shtĂ« fusha mĂ« afatgjatĂ«
- Praktikat e shpërndarjes (praktikat DevOps) dhe orkestrimit janë ndër më të rëndësishmet për arkitekturën e mikrosherbimeve, sepse rritja e shpejtësisë së ndryshimeve në komponentë vendos kërkesa më të larta për shpejtësinë dhe cilësinë e shpërndarjes.
Burimi: habr.com
