လွယ်လွယ်ပြောရရင် Multi-Cloud ဆိုတာ Cloud Provider တစ်ခုတည်းကို မသုံးဘဲ AWS, Google Cloud, Azure လို Provider နှစ်ခု ဒါမှမဟုတ် ဒီထက်များတာကို တွဲသုံးတဲ့ နည်းလမ်းပါ။ အလုပ်တစ်ချို့ကို AWS မှာထားတယ်၊ တချို့ကို Google Cloud မှာထားတယ်၊ တချို့ကို Azure မှာထားတယ် — ဒါမျိုး။
ကျွန်တော် ဒီအကြောင်းကို အရင်က “ကုမ္ပဏီကြီးတွေမှ လုပ်တာ” လို့ ထင်ခဲ့တယ်။ ကိုယ်က တစ်ယောက်တည်း developer ဆိုရင် Cloud တစ်ခုတည်းနဲ့တင် လုံလောက်တယ်လေ။ ဒါပေမယ့် 2021 ခုနှစ်မှာ AWS ကြီး တစ်ခါ ပျက်သွားဖူးတယ်။ အဲဒီတုန်းက AWS တစ်ခုတည်းကို မှီထားတဲ့ Website, App တွေ အများကြီး တစ်ပြိုင်နက် ကျသွားတယ်။ အဲဒီအချိန်မှာမှ “တစ်ခုတည်းကို မှီထားတာ ဘယ်လောက် အန္တရာယ်များလဲ” ဆိုတာ လူတွေ သဘောပေါက်သွားတယ်။
ဈေးတစ်ဆိုင်တည်းကပဲ ဝယ်ရင်
ဈေးဝယ်တာနဲ့ နှိုင်းကြည့်ရအောင်။ သင် နေ့တိုင်း လိုအပ်တဲ့ ပစ္စည်းအားလုံးကို ဆိုင်တစ်ဆိုင်တည်းကပဲ ဝယ်တယ်ဆိုပါစို့။ ဆိုင်က ဈေးတက်ရင် သင်လည်း လိုက်ပေးရတယ်။ ဆိုင်က ပိတ်သွားရင် သင် ဘာမှ ဝယ်လို့မရဘူး။ ဆိုင်က သင့်ကို ဝန်ဆောင်မှု မကောင်းတော့လည်း ပြောင်းဖို့ ခက်တယ် — ဘာလို့လဲဆိုတော့ သင့်ရဲ့ ဝယ်ယူမှုမှတ်တမ်း၊ အကြွေး၊ အလေ့အကျင့်အားလုံးက အဲဒီဆိုင်မှာပဲ ရှိနေလို့ပဲ။
Cloud Provider တစ်ခုတည်းကိုပဲ သုံးတာလည်း အဲဒီလိုပဲ။ ဒါကို Vendor Lock-in လို့ ခေါ်တယ်။ AWS ရဲ့ အထူး Service တွေကို သုံးထားရင် Google Cloud ကို ပြောင်းချင်တဲ့အခါ Code အများကြီး ပြန်ရေးရတယ်။ Provider က ဈေးတက်ရင် ပေးရတယ်။ Provider ကြီး ပျက်ရင် ကိုယ့် Service လည်း ကျတယ်။
Multi-Cloud က အဲဒီပြဿနာကို ဖြေရှင်းတယ်။ တစ်ဆိုင်တည်း မှီမထားဘဲ ဆိုင်များများက ခွဲဝယ်သလိုပဲ။
Multi-Cloud က ဘာအကျိုးရှိလဲ?
ပျက်လည်း မကျဘူး — AWS ပျက်သွားရင် အရေးကြီး Service တွေက Google Cloud မှာ ဆက်ပြီး run နေနိုင်တယ်။ အရေးပေါ်အချိန်မှာ အသက်ကယ်တယ်။
ဈေးနှိုင်းပြီး ရွေးလို့ရတယ် — Storage က GCP မှာ ဈေးသက်သာရင် အဲဒီမှာ ထား၊ AI Service က Azure မှာ ကောင်းရင် အဲဒီမှာ သုံး။ Provider တစ်ခုချင်းစီရဲ့ အားသာချက်ကို ယူလို့ရတယ်။
ဈေးညှိလို့ရတယ် — Provider ကို တစ်ခုတည်းနဲ့ ချုပ်မထားတော့ “ဈေးမလျှော့ရင် တခြား Provider ကို ပြောင်းမယ်” လို့ ပြောလို့ရတယ်။ ကုမ္ပဏီကြီးတွေအတွက်တော့ ဒါက ငွေအများကြီး သက်သာစေတယ်။
နိုင်ငံအလိုက် စည်းမျဉ်းကို လိုက်နာလို့ရတယ် — တချို့နိုင်ငံတွေမှာ ဒေတာကို အဲဒီနိုင်ငံထဲမှာပဲ ထားရမယ်လို့ စည်းမျဉ်းရှိတယ်။ Provider တစ်ခုက အဲဒီနိုင်ငံမှာ Data Center မရှိရင် တခြား Provider ကို သုံးလို့ရတယ်။
Multi-Cloud ရဲ့ ခက်ခဲချက်တွေ
အကျိုးရှိသလို ခက်ခဲတာတွေလည်း မနည်းဘူး။ ဒါကြောင့် လူတိုင်းအတွက် မသင့်တော်ဘူး။
စီမံရတာ ရှုပ်တယ် — Provider တစ်ခုချင်းစီမှာ Setting လုပ်ပုံ၊ ဈေးနှုန်း၊ Security စည်းမျဉ်း မတူဘူး။ သုံးခုလုံးကို ကျွမ်းကျင်ဖို့ လူပိုလိုတယ်၊ အချိန်ပိုလိုတယ်။
ဒေတာ ရွှေ့ရင် ငွေကုန်တယ် — Provider တစ်ခုကနေ တခြားတစ်ခုကို ဒေတာ ပို့ရင် Data Transfer Fee ကောက်တယ်။ ဒေတာ အများကြီးကို မကြာခဏ ရွှေ့ရင် ကုန်ကျစရိတ်က အံ့ဩစရာကောင်းလောက်အောင် တက်လာတယ်။
Security က ပိုခက်တယ် — Provider သုံးခုရဲ့ လုံခြုံရေးကို သုံးမျိုးလုံး စောင့်ကြည့်ရတယ်။ တစ်နေရာမှာ အားနည်းချက် ကျန်ခဲ့ရင် အဲဒီကနေပဲ ဝင်တိုက်လို့ရတယ်။
ပြဿနာရှာရခက်တယ် — Service တစ်ခုက နှေးနေရင် ဘယ် Provider ဘက်က ပြဿနာလဲဆိုတာ ရှာရခက်တယ်။ Log တွေက သုံးနေရာမှာ ကွဲနေလို့။
ဒီခက်ခဲချက်တွေကို လျှော့ဖို့ Terraform လို Infrastructure as Code tool တွေနဲ့ Kubernetes လို Container tool တွေကို သုံးတယ်။ Terraform က Provider သုံးခုလုံးကို Code တစ်ထပ်တည်းနဲ့ စီမံနိုင်တယ်။ Kubernetes က ဘယ် Cloud မှာပဲဖြစ်ဖြစ် Container တွေကို အတူတူပဲ run ပေးတယ်။ ဒီနှစ်ခုရှိမှ Multi-Cloud က လက်တွေ့မှာ အလုပ်ဖြစ်တယ်။
ကိုယ့်အတွက် Multi-Cloud လိုလား?
ရိုးရိုးပြောရရင် ကိုယ်တစ်ယောက်တည်း၊ ဒါမှမဟုတ် အဖွဲ့ငယ်လေးနဲ့ App လုပ်နေရင် Multi-Cloud မလိုသေးဘူး။ Cloud တစ်ခုတည်းကို သေချာ သုံးတတ်ဖို့က ပိုအရေးကြီးတယ်။ Provider သုံးခုလုံးကို တစ်ပြိုင်နက် သင်နေရင် ဘယ်တစ်ခုကိုမှ မကျွမ်းကျင်ဘဲ ဖြစ်သွားမယ်။
Multi-Cloud က ဒီအခြေအနေတွေမှာ သင့်တော်တယ် —
Service က တစ်မိနစ်မှ မကျလို့မရတဲ့ အရေးကြီးတဲ့ Service ဖြစ်နေရင်
ကုမ္ပဏီက နိုင်ငံများစွာမှာ ဒေတာ စည်းမျဉ်းကို လိုက်နာရရင်
ကုန်ကျစရိတ်က တစ်လကို သောင်းချီ ရှိနေပြီး ဈေးနှိုင်းဖို့ လိုအပ်လာရင်
မဟုတ်ရင် အရင်ဆုံး Cloud တစ်ခုတည်းကို ကောင်းကောင်းသုံးပါ။ နောက်မှ လိုအပ်လာရင် တစ်ဆင့်ချင်း ချဲ့ပါ။ Multi-Cloud က ပန်းတိုင်မဟုတ်ဘူး၊ လိုအပ်ချက်ရှိမှ သုံးတဲ့ နည်းလမ်းပဲ။ 🙂
