လွယ်လွယ်ပြောရရင် microservices ဆိုတာ app ကြီးတစ်ခုကို အလုပ်သေးသေးလေးတွေ ခွဲပြီး တစ်ခုချင်းစီ သီးခြား run ထားတဲ့ ဗိသုကာပုံစံပါ။

စားသောက်ဆိုင်ကြီးနဲ့ ဥပမာ

စားသောက်ဆိုင်ကြီးတစ်ဆိုင်ကို တွေးကြည့်ပါ။ ဆိုင်မှာ အဖွဲ့တွေ သီးခြားစီရှိတယ် — မီးဖိုခန်းအဖွဲ့၊ ငွေကောင်တာအဖွဲ့၊ delivery အဖွဲ့။

တစ်နေ့ delivery ဆိုင်ကယ် ပျက်သွားတယ်ဆိုပါတော့။ ဆိုင်ထဲက ဧည့်သည်တွေက ဆက်စားလို့ရတုန်းပဲ။ မီးဖိုခန်းက ဆက်ချက်နေတုန်းပဲ။ ကောင်တာက ငွေဆက်ကောက်နေတုန်းပဲ။ တစ်ခုပျက်တာ ကျန်တာကို မထိဘူး — ဘာလို့လဲဆိုတော့ အဖွဲ့တွေ သီးခြားစီ အလုပ်လုပ်နေလို့ပါ။

Microservices လည်း ဒီအတိုင်းပဲ။

ဆန့်ကျင်ဘက်ကတော့ monolith — အိမ်တစ်လုံးတည်းမှာ အကုန်စုထားသလိုမျိုး။ မီးဖိုပျက်သွားရင် တစ်အိမ်လုံး ရပ်သွားတယ်။ အရင်က app တော်တော်များများက ဒီပုံစံပဲ — code အားလုံး တစ်ခုတည်းမှာ စုထား၊ ပြင်ချင်ရင် တစ်ခုလုံး ပြန်တင်ရတယ်။

Netflix နောက်ကွယ်မှာ

တကယ့်ဥပမာနဲ့ ပြောရရင် Netflix ကို ကြည့်ပါ။

Netflix က app တစ်ခုတည်း မဟုတ်ဘူး။ နောက်ကွယ်မှာ service တွေ အများကြီး သီးခြားစီ run နေတာ —

Login service — ဝင်ရောက်မှုစစ်တာ
Search service — ရှာဖွေတာ
Video streaming service — ရုပ်ရှင်ပို့တာ
Payment service — ငွေကောက်တာ

Payment service ပျက်သွားတယ်ဆိုပါတော့။ ကိုယ်က ရုပ်ရှင်ကြည့်နေတုန်းပဲ — ကြည့်လို့ရတုန်းပဲ။ Login service က သီးခြားမို့ ဘာမှမဖြစ်ဘူး။ ပြဿနာရှိတဲ့ အပိုင်းကိုပဲ သီးခြား ပြင်လို့ရတယ်။

Amazon, Facebook လို ကုမ္ပဏီကြီးတွေလည်း ဒီပုံစံပဲ သုံးတယ်။

မနေ့က Kubernetes အကြောင်း ရေးခဲ့တယ် မဟုတ်လား? အဲဒီ Kubernetes ဆိုတာက ဒီ microservices တွေကို အုပ်ချုပ်တဲ့ captain ပဲ။ Service တွေ များလာတော့ ဘယ်ဟာက ဘယ်မှာ run နေလဲ၊ တစ်ခုကျသွားရင် ဘယ်လို ပြန်ထူမလဲဆိုတာ စီမံပေးတာ။

ကောင်းတာ၊ ဆိုးတာ

ဘာလို့ ကုမ္ပဏီကြီးတွေ ဒီနည်းကို ကြိုက်လဲဆိုတာ အကြောင်းရှိတယ်။

ကောင်းတဲ့အချက်တွေ —

တစ်ခုပျက်လည်း ကျန်တာ ဆက်အလုပ်လုပ်တယ် — ဆိုင်ဥပမာလိုပေါ့
Team တစ်ခုချင်းစီ သီးခြား တိုးတက်လို့ရတယ် — payment team က သူတို့အပိုင်းပဲ ပြင်တယ်၊ video team ကို မထိဘူး
Scale လုပ်ရလွယ်တယ် — ညနေပိုင်း လူကြည့်များတော့ video streaming service ကိုပဲ server တိုးပေးလိုက်ရုံပဲ၊ ကျန်တာတွေ မထိဘူး
တစ်ခုချင်းစီကို နည်းပညာမတူနဲ့ ရေးလို့ရတယ် — search service ကို Python နဲ့၊ video service ကို Go နဲ့

ဆိုးတဲ့အချက်တွေ —

စီမံရခက်တယ် — service အခု ၅၀၊ ၁၀၀ ဖြစ်လာရင် ဘယ်ဟာက ဘာလုပ်နေလဲ လိုက်ရတာ မလွယ်ဘူး
တစ်ခုနဲ့တစ်ခု ဆက်သွယ်မှု ရှုပ်တယ် — network ပြဿနာတက်ရင် ဘယ်အပိုင်းက လွဲလဲ ရှာရခက်တယ်
အသေးစား project အတွက် overkill — လူ ၃ ယောက်တည်း ရေးတဲ့ app သေးသေးလေးကို microservices ခွဲတာ အလုပ်ပိုတယ်

ဒါကြောင့် စည်းမျဉ်းလေးတစ်ခု ရှိတယ် — app သေးရင် monolith နဲ့ စ၊ ကြီးလာမှ ခွဲ။ အစကတည်းက ခွဲထားတာ အမြဲမှန်တာမဟုတ်ဘူး။

နောက်တစ်ခါ Netflix ကြည့်ရင်း payment error တက်နေတာ တွေ့ရင် တွေးကြည့်လိုက်ပါ — “အော်၊ ဒါ microservices ရဲ့ အလုပ်ပဲ” လို့။ App ကြီးတွေရဲ့ နောက်ကွယ်မှာ ဒီလို အပိုင်းသေးသေးလေးတွေ ဘယ်လောက်တောင် အလုပ်လုပ်နေလဲဆိုတာ သိရင် တော်တော် စိတ်ဝင်စားဖို့ကောင်းတယ်။