Microservices dhidi ya Monolithic Architecture: Unapaswa Kujenga Nini?
Mwanzilishi mmoja aliwahi kuniomba nirejelee pendekezo la usanifu (architecture pitch).
Wakala ule ulipendekeza huduma kumi na moja, message queue, na service mesh. Hii ilikuwa kwa ajili ya kifaa rahisi cha kukata nafasi (booking tool) ambacho hakikuwa na mtumiaji hata mmoja.
Hilo ni mtego.
Maamuzi ya usanifu huamua gharama zako za hosting, kasi ya kutoa bidhaa, na mpango wako wa kuajiri. Lazima ujue gharama kabla ya kumpa mwanaunda programu (developer) bajeti.
The Monolith Monolith hutumia codebase moja, deployment moja, na database moja. Ni rahisi.
Siku ya kwanza, hujui mipaka ya uwanja wako (domain boundaries). Ukigawanya huduma mapema mno, utatumia muda kubadilisha mipaka ambayo haikupaswa kuwepo. Monolith ni rahisi zaidi kusimamia wakati timu yako ni ndogo. Unaita function badala ya kuandaa API. Wakati hitilafu (bug) inapotokea saa nane usiku, kosa huonyesha sehemu ya kodi, siyo hitilafu ya mtandao.
Microservices Microservices hutatua matatizo ya kiutendaji. Huwaruhusu timu tofauti kutoa kodi kulingana na ratiba zao wenyewe. Netflix huzitumia ili kuzuia hitilafu moja isiharibu mfumo mzima.
Hata hivyo, unalipia hili kila siku. Mawasiliano ya mtandao (network calls) huongeza ucheleweshaji (latency). Uwiano wa data (data consistency) unakuwa mgumu. Unahitaji zana maalum na timu kubwa kusimamia logs na tracing. Bila idadi sahihi ya wafanyakazi, utajikuta na distributed monolith. Hii inakupa utata wote wa mtandao bila kuwa na uhuru wowote.
The Modular Monolith Hii ni njia ya kati. Ni programu moja yenye mipaka imara kati ya sehemu tofauti za kodi. Mfumo wa malipo (billing) hauwezi kuingilia sehemu za ndani za oda zako.
Shopify na GitHub hutumia mbinu hii. Unapata mipaka safi na kuepuka gharama za ziada za mtandao (network tax). Sehemu ya programu yako inapohitaji kutanuka (scale) peke yake, unaweza kuigawanya kwa urahisi kwa sababu mipaka imeshaainishwa.
Jinsi ya kuamua:
- Ukubwa wa timu: Ikiwa una watu watatu, huwezi kusimamia huduma tofauti na mzunguko wa walio tayari kuhudumia hitilafu (on-call rotation) unaohitajika.
- Uthabiti wa bidhaa: Ikiwa bidhaa yako inabadilika kila wiki, mipaka ya huduma zako itakuwa imepitwa na wakati ifikapo mwezi ujao.
- Uendeshaji (Operations): Je, una mifumo ya kurudisha nyuma mabadiliko (automated rollbacks) na ukusanyaji wa logs (log aggregation)? Kama sivyo, microservices zitakuletea matatizo.
- Ukubwa (Scale): Usijenge kwa ajili ya ukuaji wa kufikirika. Jenga kwa ajili ya njia halisi unayoiona.
Ikiwa majibu yako ni "bado," jenga modular monolith.
Usiombe microservices kwa sababu neno hilo linaonekana la kisasa. Mwambie mshirika wako bidhaa inafanya nini na nani ataisimamia.
Bidhaa hufeli kwa sababu hazitolewi sokoni kamwe. Monolith safi ndiyo njia ya haraka zaidi ya kuwafikia watumiaji. Jenga hiyo kwanza. Ruhusu idadi ya watumiaji ikuambie wakati unapaswa kuanza kuvunja mifumo hiyo vipande vipande.
Jumuiya ya hiari ya kujifunza: https://t.me/GyaanSetuAi