Microservices vs Monolith

နားလည်ထားရမယ့် အချက်

Monolith တစ်ခုက application တစ်ခုလုံးကို — feature၊ module အားလုံးကို — codebase တစ်ခု၊ build pipeline တစ်ခု၊ ပုံမှန်အားဖြင့် database တစ်ခုနဲ့ share ထားတဲ့ unit တစ်ခုတည်းအဖြစ် deploy လုပ်ပါတယ်။ အစောပိုင်းမှာ ဒါက အမှန်တကယ် အားသာချက်ပါ — နားလည်ဖို့ repo တစ်ခုတည်း၊ deploy လုပ်ဖို့ တစ်ခုတည်း၊ component တွေကြား network call အစား function call၊ shared database ကတစ်ဆင့် business logic တစ်ခုလုံးအတွက် 'အလကားရ' transaction။ Team နဲ့ codebase ကြီးထွားလာတာနဲ့အမျှ ပြဿနာက ပေါ်လာပါတယ် — payments module မှာ bug fix လုပ်ဖို့ဆိုရင် search လို မသက်ဆိုင်တဲ့ code အပါအဝင် application တစ်ခုလုံးကို redeploy ပြီး ပြန် test လုပ်ရပါတယ်၊ feature တစ်ခုတည်းက traffic (ဥပမာ video streaming) ရုတ်တရက်များလာရင် monolith တစ်ခုလုံးကို scale လုပ်ရမှာဖြစ်ပြီး မလိုအပ်တဲ့ part တွေအတွက် resource ဖြုန်းတီးရပါတယ်။ Microservices တွေက system ကို business boundary တွေအတိုင်း သီးခြား deploy/scale လုပ်နိုင်တဲ့ service တွေအဖြစ် ခွဲထုတ်ပြီး ပြဿနာနှစ်ခုစလုံးကို တိုက်ရိုက် ဖြေရှင်းပေးပါတယ် — ပြောင်းလဲသွားတာ ဒါမှမဟုတ် hot ဖြစ်နေတာကိုသာ deploy/scale လုပ်ခြင်း။ ဒါပေမဲ့ အလကားမရပါဘူး — process တစ်ခုတည်းအတွင်း function call ဟာ fail ဒါမှမဟုတ် timeout ဖြစ်နိုင်တဲ့ network call ဖြစ်လာပြီး ACID transaction တစ်ခုက shared database မရှိတော့တဲ့ service များစွာကို ဖြတ်သန်းရတော့မှာဖြစ်လို့ ဒီ course က တည်ဆောက်ပေးနေတဲ့ coordination pattern တွေ — service discovery, load balancing, eventual consistency — အတိအကျ လိုအပ်လာပါတယ်။ Microservices ဟာ development simplicity ကို operational flexibility နဲ့ လဲလှယ်တာဖြစ်ပြီး strict upgrade မဟုတ်ပါဘူး — company အများအပြားက engineer တွေ ခွဲထုတ်သင့်ပြီလို့ ယူဆတဲ့အချိန်ထက် နှစ်ပေါင်းများစွာ ကျော်လွန်အောင် monolith ကို အကျိုးရှိစွာ run နေကြပါတယ်။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Thuta Learning ဟာ Next.js monolith တစ်ခုတည်းအနေနဲ့ စတင်ခဲ့ပါတယ် — content, auth, progress tracking, search အားလုံး deployable app တစ်ခုထဲမှာ ရှိပြီး team သေးသေးလေးတစ်ခုအတွက် လျင်မြန်စွာ ships လုပ်ဖို့ ပြီးပြည့်စုံပါတယ်။ Platform က tutorial ဆယ်ချီပြီး concurrent quiz-taking traffic များလာတဲ့အခါ team က routine content-editing bug fix တစ်ခုအတွက် မပြောင်းလဲတဲ့ search index နဲ့ payment flow အပါအဝင် site တစ်ခုလုံးကို redeploy လုပ်ရတာကို သတိပြုမိပါတယ် — ပြီးတော့ peak hour မှာ platform ရဲ့ CPU အသုံးပြုမှု အများဆုံးဖြစ်တဲ့ search က responsive ဖြစ်နေအောင် app တစ်ခုလုံးကို scale လုပ်ခိုင်းနေတာကိုပါ။ Search နဲ့ progress-tracking ကို သီးခြား service အဖြစ် ခွဲထုတ်လိုက်တဲ့အခါ team က ဒါတွေကို သီးခြား scale/deploy လုပ်နိုင်လာပေမယ့် ယခု service discovery လိုအပ်လာပြီး partial failure ကို ကိုင်တွယ်ရတော့မှာဖြစ်လို့ ဒီ lesson ဖော်ပြထားတဲ့ trade-off အတိအကျပါပဲ။

Monolith တွေက စတင်တည်ဆောက်ဖို့နဲ့ deploy လုပ်ဖို့ ပိုလွယ်ကူပေမယ့် app တစ်ခုလုံးကို အတူတကွ scale/redeploy ဖြစ်စေရပါတယ်။
Microservices တွေက service တစ်ခုချင်းစီ သီးခြား deploy/scale လုပ်ခွင့်ပေးပေမယ့် function call နဲ့ local transaction တွေအစား network call နဲ့ distributed transaction တွေ ကုန်ကျပါတယ်။
ဒီရွေးချယ်မှုက development simplicity ကို operational flexibility နဲ့ လဲလှယ်တာဖြစ်ပြီး strict upgrade မဟုတ်ပါဘူး — company အများစုက monolith ကို နှစ်ပေါင်းများစွာ အကျိုးရှိစွာ ဆက်လက်အသုံးပြုနေကြပါတယ်။

အတူတူ စမ်းရေးကြည့်မယ်

text

MONOLITH                                MICROSERVICES
+---------------------------+           +----------+   +----------+
|      Tutorial Platform    |           | Content  |   |  Search  |
|  ------------------------ |           | Service  |   | Service  |
|  Content | Search | Auth  |           +----------+   +----------+
|  Progress | Payments      |                | HTTP/gRPC   | HTTP/gRPC
|  ------------------------ |           +----------+   +----------+
|     one codebase          |           |   Auth   |   |Progress  |
|     one deploy            |           | Service  |   | Service  |
|     one database          |           +----------+   +----------+
+---------------------------+                | HTTP/gRPC   |
                                         +----------+
                                         | Payments |
                                         | Service  |
                                         +----------+

EASIER in monolith:                    EASIER in microservices:
  - local function calls                 - scale only the hot service (Search)
  - one shared DB transaction             - deploy Payments without touching Search
HARDER in monolith:                    HARDER in microservices:
  - must scale everything together        - network calls can fail/timeout
  - one bug's redeploy affects all         - no single DB transaction across services

You should see

Diagram က monolith ရဲ့ ရိုးရှင်းမှု — deployable unit တစ်ခုတည်း — ဟာ microservices ရဲ့ လွတ်လပ်မှုနဲ့ တိုက်ရိုက် လဲလှယ်နေတာကို ပြသထားပြီး service တစ်ခုချင်းစီ တစ်ကိုယ်တည်း scale/deploy လုပ်နိုင်ပေမယ့် ယုံကြည်စိတ်ချရမှုမရှိတဲ့ network အပေါ်မှာ coordinate ပြန်လုပ်ရပါတယ်။

၅ မိနစ် စမ်းကြည့်

သင်သုံးနေတဲ့ platform တစ်ခုရဲ့ feature သုံးခု ဖော်ပြပါ (ဥပမာ - music app: playback, playlist, recommendation, payment)။ ဘယ်ဟာက microservice သီးခြားအဖြစ် ပထမဆုံး ခွဲထုတ်ရင် အကျိုးရှိဆုံးလဲ ဆုံးဖြတ်ပြီး 'microservices က ခေတ်မှီလို့' ဆိုတဲ့ အကြောင်းပြချက်မျိုးမဟုတ်ဘဲ scaling နဲ့ deploy-frequency ကို အခြေခံပြီး ရှင်းပြပါ။

သတိလေးတစ်ချက်

Team ဒါမှမဟုတ် traffic အမှန်တကယ် လိုအပ်မလာခင် microservices ခွဲထုတ်တာ — team သေးသေးလေးတစ်ခုက service ဆယ်ခုကျော်၊ message queue တွေ၊ service discovery ကို run/monitor လုပ်ရတော့မှာဖြစ်ပြီး monolith တစ်ခုတည်းက actual load ကို ကောင်းကောင်း ကိုင်တွယ်နိုင်မယ့်အခါမှာ ဒါက operational overhead အစစ်ပါပဲ။

Business boundary အစား technical layer အလိုက် service ခွဲခြားတာ (ဥပမာ 'database service' နဲ့ 'logic service' သီးခြားစီ) — ဒါက local operation တစ်ခုတည်းဖြစ်သင့်တဲ့အရာအတွက် network ကနေ အဆက်မပြတ် ခေါ်ဆိုနေရတဲ့ chatty, tightly-coupled service တွေ ဖြစ်စေပြီး microservices ရဲ့ network overhead အားလုံးကို ရပေမယ့် independent-deployability အကျိုးကျေးဇူး လုံးဝမရပါဘူး။

Wikipedia — Microservices — System Design