Usanifu wa Microservices: Dhana, Sababu, na Mbinu za Utekelezaji

1. Utangulizi na Muhtasari

Maudhui haya yanatokana na kipindi cha podikasti ya Software Engineering Radio (kipindi cha 213), kilichojadiliwa na Johannes Thönes na James Lewis kuhusu mada ya microservices. Mazungumzo yanachunguza ufafanuzi, sababu, na mambo ya vitendo yanayozunguka mtindo huu wa usanifu, ambao ulikuwa ukipata umaarufu mkubwa mwanzoni mwa mwaka 2015 kama jibu la changamoto za kudumisha programu kubwa na zenye muundo mmoja (monolithic).

2. Kufafanua Microservices

Microservice inaelezewa kama kijenzi kidogo cha programu kilicholenga kazi maalum.

2.1 Sifa Muhimu

Kulingana na mazungumzo, microservice ina sifa kadhaa muhimu:

Utekelezaji wa Kujitegemea: Inaweza kutekelezwa bila kuhitaji mabadiliko kwenye huduma zingine.
Kupanua Kwa Kujitegemea: Inaweza kupanuliwa kwa usawa au wima kulingana na mzigo wake maalum.
Kujaribu Kwa Kujitegemea: Inaweza kuthibitishwa peke yake.
Wajibu Mmoja: Ina sababu moja kuu ya kubadilika au kubadilishwa. Inafanya kazi moja yenye umoja na inaeleweka kwa urahisi.

2.2 Mifano ya Wajibu Mmoja

"Kitu kimoja" kinachofanywa na microservice kinaweza kuwa cha kazi (functional) au cha kuvuka kazi (cross-functional):

Cha Kazi (Functional): Kutoa rasilimali maalum ya kikoa (mfano, huduma ya Mtumiaji, huduma ya Makala, huduma ya Kuhesabu hatari katika bima).
Cha Kuvuka Kazi (Cross-functional): Kichakataji cha foleni kinachosoma ujumbe, kutumia mantiki ya biashara, na kuupitisha. Wajibu wa mahitaji maalum yasiyo ya kazi kama vile kuhifadhi kwenye kache (caching) au kurekodi matukio (logging).

3. Kuongezeka kwa Microservices

3.1 Sababu za Umaarufu

Umaarufu wa microservices unahusishwa na tatizo la kawaida katika tasnia: programu ya monolithic isiyoweza kudhibitiwa. Mashirika yanakabiliana na programu ambazo zimekua kwa zaidi ya miaka 5-10, na kuwa ngumu sana kubadilisha, kutekeleza kama SaaS, au kupanua kwa ufanisi kwenye wingu.

3.2 Kukabiliana na Deni la Kiufundi

Microservices zilitokea kama suluhisho la kugawanya programu hizo za monolithic kuwa vijenzi vidogo vinavyoshirikiana na vinavyofanya kazi nje ya mchakato mmoja. Njia hii, iliyoonyeshwa kwa kiwango kikubwa na kampuni kama Netflix, inaruhusu udumishaji, upanuzi, na ubadilishaji wa kujitegemea. Sababu kuu ni hitaji la kutoa programu kwa haraka na kuchukua fursa za mazoea kama uwasilishaji endelevu (continuous delivery), ambayo huzuiwa na usanifu wa monolithic.

4. Mbinu za Kukubali na Utekelezaji

4.1 Greenfield dhidi ya Brownfield

Swali kuu ni kama kuanza mradi mpya na microservices (greenfield) au kurekebisha programu ya monolithic iliyopo kuwa microservices (brownfield). Mazungumzo yanabainisha kuwa kwa uzoefu, mashirika mengi huanza na programu ya monolithic na baadaye hurekebisha, wakikabiliana na changamoto ya kutambua mipaka ya muktadha na sehemu za kugawanyika ndani ya msingi wa msimbo uliopo.

4.2 Ugumu wa Uendeshaji

Sehemu ya podikasti inataja kuwa mipaka ya nafasi ilizuia majadiliano kamili kuhusu ugumu wa uendeshaji na athari yake kwenye DevOps. Hii inamaanisha kuwa wakati microservices zinatatua matatizo ya ukuzaji na uwezo wa kupanua, zinatanguliza changamoto mpya katika ufuatiliaji, uratibu wa utekelezaji, na uaminifu wa mtandao.

5. Ufahamu Muhimu na Uchambuzi

Ufahamu Msingi

Microservices sio teknolojia ya suluhisho kamili; ni jibu la kikundi na kiuchumi kwa kikwazo cha ukuzaji wa programu ya monolithic. Thamani halisi, kama ilivyoonyeshwa na mfano wa Netflix, ni kuwezesha mitiririko ya kujitegemea na sambamba ya utoaji wa thamani. Usanifu huu unalenga moja kwa moja gharama za uratibu na msuguano wa utekelezaji unaowakera timu kubwa zinazofanya kazi kwenye msingi mmoja wa msimbo, tatizo lililowekwa rasmi na methali ya Melvin Conway kwamba "mashirika yanayobuni mifumo... yanalazimika kutengeneza miundo ambayo ni nakala ya miundo ya mawasiliano ya mashirika hayo." Microservices hujaribu kubadilisha hili kwa kubuni mifumo inayolazimisha miundo ya mawasiliano inayotakikana.

Mtiririko wa Mantiki

Simulizi hii inafuata mnyororo wenye nguvu wa sababu na athari: (1) Programu za monolithic hukusanya deni la kiufundi na kuwa zisizoweza kubadilika. (2) Biashara inahitaji uwezo wa kupanua kwenye wingu na utoaji endelevu. (3) Usanifu wa monolithic kimsingi haufanani na malengo haya kwa sababu ya muunganisho wake. (4) Suluhisho ni kuvunja programu ya monolithic kwenye mipaka ya muktadha, na kuunda vitengo vinavyoweza kutekelezwa kwa kujitegemea. Mantiki hii ni sahihi lakini haichunguzi ugumu mkubwa wa katikati—"jinsi" ya kuvunja hiyo.

Nguvu na Mapungufu

Nguvu: Mwelekeo kwenye uwezo wa kutekelezwa kwa kujitegemea kama sifa kuu ni sahihi kabisa. Hii ndiyo lever inayofungua uhuru wa timu na mizunguko ya haraka ya kutolewa. Uhusiano na Sheria ya Conway na CQRS (iliyotajwa kama mada zilizokosa) unaonyesha ufahamu wa mifumo ya kina ya kijamii na kiufundi inayocheza.

Mapungufu: Mtazamo wa mwaka 2015 unaonekana kuwa na matumaini juu ya urahisi wa kufafanua "wajibu mmoja." Uzoefu wa baadaye wa tasnia umefunua hili kuwa sehemu ngumu zaidi—laana ya mipaka duni ya huduma inayosababisha programu za monolithic zilizosambazwa. Nakala pia inapuuza kwa hatari mzigo wa uendeshaji. Kama makala muhimu ya Fowler ilivyoelezea baadaye, unabadilisha ugumu wa ukuzaji na ugumu wa uendeshaji. Kutaja Docker kama "kipande maarufu" ni picha ya kihistoria; mfumo wa vyombo (containerization) ndio uwezeshaji wa uendeshaji uliokosekana ambao ulifanya microservices ziwezekane kwa vitendo kwa kiwango kikubwa.

Ufahamu Unaotumika

Kwa viongozi: Msianze na microservices kwa sababu ziko kwenye mtindo. Anzisha kwa kupima muda wa kuongoza kwa mabadiliko na mzunguko wa utekelezaji. Ikiwa ni duni kwa sababu ya uratibu wa msingi wa msimbo, fikiria microservices. Kwa wasanifu: Zana kuu ya muundo sio orodha ya teknolojia bali ni ramani ya muktadha ya muundo unaoongozwa na kikoa (DDD). Fafanua mipaka kulingana na uwezo wa biashara, sio tabaka za kiufundi. Kwa timu: Wekeza katika uhandisi wa jukwaa mapema—utekelezaji wa kiotomatiki, ugunduzi wa huduma, na uangalizi sio mawazo ya baadaye; ndio msingi. Njia inayopendekezwa—kurekebisha kutoka kwa programu ya monolithic—bado ndiyo yenye hekima zaidi. Tumia Muundo wa Mti wa Strangler Fig kubadilisha sehemu za programu ya monolithic kwa huduma hatua kwa hatua, kwani hii inadhibiti hatari na kuruhusu kujifunza.

6. Mfumo wa Kiufundi na Mifano ya Kihisabati

Ingawa podikasti ni ya mazungumzo, kanuni za msingi zinaweza kuwekwa rasmi. Mfano muhimu ni uhusiano kati ya ukubwa wa timu (N), njia za mawasiliano, na muunganisho wa usanifu.

Katika usanifu wa monolithic wenye timu N, njia zinazowezekana za mawasiliano huongezeka kulingana na $O(N^2)$, kwani mabadiliko katika moduli moja yanaweza kuathiri nyingine nyingi. Hii huleta mzigo wa uratibu. Microservices zinalenga kupunguza hili kwa kulazimisha mipaka ya muktadha na API. Lengo ni kufanya gharama ya mawasiliano kati ya huduma, $C_{comm}$, iwe kubwa wazi kupitia mihitaji ya mtandao, na hivyo kuhimiza umodulishaji mkali ndani ya huduma ambapo gharama ya mabadiliko, $C_{internal}$, ni ndogo.

Mfano rahisi wa uwezekano wa kueneza mabadiliko ($P_{prop}$) unaweza kuwa:

$P_{prop} \approx \frac{C_{comm}}{C_{comm} + C_{internal}}$

Ambapo usanifu mzuri wa microservices hupunguza $P_{prop}$ kwa mabadiliko yasiyohusiana kwa kufanya $C_{comm}$ (ucheleweshaji wa mtandao, toleo la API) kuwa sababu kuu ya mabadiliko ya kuvuka mipaka.

7. Matokeo ya Majaribio na Misaala ya Kesi

Podikasti inataja Netflix kama kesi kuu ya kusoma. Kufikia 2015, Netflix ilikuwa imegawanya sehemu yake ya nyuma ya monolithic kuwa mamia ya microservices, na kuwezesha:

Kupanua Kwa Kujitegemea: Huduma kama mapendekezo ya sinema au bili zinaweza kupanuliwa kwa kujitegemea wakati wa mizigo ya kilele.
Ubunifu wa Haraka: Timu zinaweza kutekeleza huduma zao mara nyingi kwa siku bila uratibu wa mfumo mzima.
Utofauti wa Teknolojia: Huduma tofauti zinaweza kuandikwa kwa lugha inayofaa zaidi kwa kazi yao (mfano, Java, Node.js).

Maelezo ya Chati (Kinadharia): Chati ya baa inayolinganisha programu ya monolithic na usanifu wa microservices kwenye shoka mbili: (1) Mzunguko wa Utekelezaji (Utekelezaji/Kwa Siku): Monolith inaonyesha baa ya chini (mfano, 0.1), Microservices zinaonyesha baa ya juu (mfano, 50+). (2) Muda wa Wastani wa Kurejesha (MTTR) kutoka kwa hitilafu: Monolith inaonyesha baa ya juu (mfano, saa 4), Microservices zinaonyesha baa ya chini (mfano, dakika 30), kwani hitilafu zinaweza kutengwa kwenye huduma maalum.

Utafiti wa baadaye, kama ule uliorejelewa katika Ripoti ya Hali ya DevOps, umeshirikishanisha kwa takwimu usanifu wenye muunganisho duni na unaolenga huduma na utendaji wa juu wa utoaji wa programu.

8. Mfumo wa Uchambuzi: Mfano wa Vitendo

Muktadha: Programu ya monolithic ya biashara ya mtandaoni inapambana na visasisho. Mabadiliko ya kipengele cha "kutoa malipo" yanahitaji kujaribu kwa urejeshaji kamili na yanagombana na visasisho vya "orodha ya bidhaa."

Utumiaji wa Mfumo:

Tambua Mipaka ya Muktadha: Kwa kutumia Muundo Unaongozwa na Kikoa (DDD), tambua vikoa vikuu: Kuagiza, Orodha, Hifadhi, Usimamizi wa Watumiaji, Malipo.
Fafanua Mipaka ya Huduma: Unda microservice kwa kila muktadha. Huduma ya Maagizo inamiliki mantiki ya kutoa malipo na data ya maagizo.
Weka Mikataba: Fafanua API wazi. Huduma ya Maagizo itaita API ya Huduma ya Malipo processPayment(orderId, amount) na API ya Huduma ya Hifadhi reserveStock(itemId, quantity).
Umiliki wa Data: Kila huduma inamiliki hifadhi data yake. Huduma ya Maagizo ina jedwali lake la "maagizo"; haichungui moja kwa moja hifadhi data ya Hifadhi.
Utekelezaji & Uangalizi: Kila huduma huwekwa kwenye chombo (containerized), hutekelezwa kwa kujitegemea, na huchapisha vipimo (ucheleweshaji, kiwango cha makosa) kwenye dashibodi kuu.

Matokeo: Timu ya kutoa malipo sasa inaweza kutekeleza visasisho kwenye Huduma ya Maagizo bila kuhusisha timu za orodha au hifadhi, na hivyo kupunguza kwa kiasi kikubwa mzigo wa uratibu na kuongeza mzunguko wa utekelezaji.

9. Matumizi ya Baadaye na Mwelekeo wa Utafiti

Mageuzi ya microservices yanaendelea zaidi ya mtazamo wa 2015:

Mtandao wa Huduma (Service Meshes): Teknolojia kama Istio na Linkerd zimetokea kushughulikia masuala yanayovuka kazi (usalama, uangalizi, usimamizi wa trafiki) kwenye tabaka ya miundombinu, na hivyo kupunguza mzigo wa msimbo kwenye huduma binafsi.
Bila Seva & FaaS: Kazi-kama-Huduma (Functions-as-a-Service, mfano, AWS Lambda) inawakilisha aina kali ya microservices, ikisukuma ugumu wa uendeshaji kabisa kwa mtoa huduma wa wingu na kuwezesha upanuzi wa kina zaidi.
Ujumuishaji wa AI/ML: Microservices zinakuwa muundo wa kawaida wa kutekeleza miundo ya ML kama huduma za utabiri zinazojitegemea, na kuwezesha kujaribu A/B na kurudia haraka kwa algoriti.
Kompyuta ya Ukingo (Edge Computing): Kutekeleza microservices nyepesi kwenye vifaa vya ukingo kwa usindikaji wa ucheleweshaji mdogo katika hali ya IoT na uchambuzi wa wakati halisi.
Mwelekeo wa Utafiti: Utafiti wa baadaye unahitajika katika zana za kugawanya huduma kiotomatiki, utabiri wa makini wa hitilafu katika mifumo iliyosambazwa, na uthibitishaji rasmi wa mwingiliano katika ngoma za huduma (service choreographies).

10. Marejeo

Lewis, J., & Fowler, M. (2014). Microservices. MartinFowler.com. Imepatikana kutoka https://martinfowler.com/articles/microservices.html
Newman, S. (2015). Building Microservices. O'Reilly Media.
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28-31.
Google Cloud. (2019). The 2019 Accelerate State of DevOps Report. DORA.
Netflix Technology Blog. (Various). https://netflixtechblog.com/