# Cloud ဆိုသည်မှာ

Cloud ဆိုတဲ့ အသုံးအနှုန်းကို စာရေးသူစကြားဖူးတာ တော်တော်လေးကိုကြာခဲ့ပါပြီ။ တချိန်က အစိုးရကောလိပ်တခုမှာ ကျောင်းတဖက်နဲ့ အချိန်ပိုင်းစာသင်ပြတဲ့အချိန်က head teacher တစ်ယောက်က Microsoft Windows Server 2012 R2 ဘာသာရပ်ကို သင်ပြပေးဖို့ဆွေးနွေးကြရင်းနဲ့ သူက hybrid cloud နဲ့ public cloud အတွက် အလွယ်တကူတွဲပြီးတော့သုံးလို့ရကြောင်း Microsoft ရဲ့ Azure ဟာလည်းမသိမဖြစ်သိထားသင့်တဲ့ နည်းပညာတခုဖြစ်ကြောင်း ဆက်လက်ဆွေးနွေးဖြစ်ခဲ့ပါတယ်။ အဲ့ဒီတုန်းက စာရေးသူ တက္ကသိုလ်မှာလည်း ကျောင်းလည်းမပြီးသေး၊ cloud ဆိုတဲ့ဟာလည်း ကိုယ့်အတွက်လက်တွေ့ အသုံးမတည့်သေးတာမို့ ဒီအတိုင်းပဲမေ့မေ့ပျောက်ပျောက်ပဲ ထားလိုက်ပါတယ်။ အဲ့ဒါလွန်ခဲ့တဲ့ ၁၀နှစ်ကျော်ကျော်လောက်ကဖြစ်တဲ့ အဖြစ်တခုပေမယ့် မှတ်မှတ်ရရရှိနေသေးပါတယ်။ ပထမတခုက စာရေးသူကိုယ်တိုင်က ကျောင်းမှာစာသင်ကြားပြသနေတဲ့ အချိန်ပိုင်း IT ဆရာတယောက်ဖြစ်နေပြီး cloud ဆိုတဲ့ နည်းပညာကိုသေချာလုံးစေ့ပတ်စေ့ မသိသေးတာဖြစ်တဲ့အတွက် မသိစိတ်ကရှက်နေတာတကြောင်း၊ နောက်တခုက စာရေးသူကို Windows Server 2012 R2 ဘာသာရပ်ကို သင်ပေးဖို့အတွက်လာမေးတဲ့ head teacher ကို သင်ပေးနိုင်ကြောင်း ကတိပေးပြီးကာမှ ဖြစ်ပါ့မလားဆိုတဲ့ ကြောက်စိတ်လေးဝင်လာတာတကြောင်းရယ်ပါ။ အဲ့ဒီမတိုင်ခင်ကလည်း Windows Server 2008 ဘာသာရပ်ကိုလည်း ကျောင်းမှာသင်ပြလာတာလည်း semester ၂ခုလောက်ရှိတော့မယ်ထင်ပါတယ်။ သို့သော်လည်း အဲ့ဒီ head teacher နဲ့ Windows Server 2012 R2 ဟာ cloud-ready ဖြစ်တဲ့အကြောင်း ဆွေးနွေးပြီးတော့မှ cloud ဆိုတာ ငါမှ ကောင်းကောင်းမသိပဲနဲ့ဖြစ်ပါ့မလားဆိုပြီး သံသယစိတ်ဝင်လာပါတော့တယ်။ ဒါကြောင့်လည်း ဒီကိစ္စကိုကောင်းကောင်းကြီးမှတ်မိနေပါတော့တယ်။

နောက်ပိုင်းမှာတော့ AWS အပြင်၊ အခြားသော Cloud Service Providers (CSPs) တွေလည်း အများကြီးရှိကြောင်း တဖြေးဖြေးသိလာပါတော့တယ်။ စာရေးသူ တက္ကသိုလ်ကျောင်းပြီးတဲ့အထိ တစ်နှစ်ကျော်၊ နှစ်နှစ်လောက် အစိုးရကောလိပ်မှာ စာဆက်ပြီးတော့ သင်ဖြစ်ပါသေးတယ်။ အဲ့နောက်မှာတော့ ကိုယ်ဝါသနာပါတဲ့ technical ပိုင်းကိုလိုက်ချင်လို့ System/Network Administrator အဖြစ်နဲ့ company အသေးလေးတခုမှာ တစ်နှစ်ကျော်ကျော်လောက် ပြန်လည်အလုပ်ဝင်ခဲ့ပါတယ်။ အဲ့ဒီကနေမှတဆင့် အလတ်စား Managed Service Provider (MSP) တစ်ခုမှာ System Engineer အဖြစ် နှစ်နှစ်လောက် ဆက်လက် လုပ်ငန်းဝင်ခဲ့ပါတယ်။ MSP ဖြစ်တဲ့အတွက် small and medium-sized business (SMB) အများကြီးအတွက် Infrastructure နဲ့ system ပိုင်းတွေမှာ မလုပ်ဖူးတာမရှိသလောက် အစုံလုပ်ခဲ့ရပါတယ်။ Infrastructure ဆိုတဲ့နေရာမှာ on-prem infrastrature တွေပါသလို၊ data centre တွေ၊ co-location တွေအကုန်လုံးပါပါတယ်။ Server hardware တွေ၊ networking gears တွေကို rack-and-stack လုပ်တာပါသလို၊ basic configuration တွေအတွက်လည်း ကိုယ်ပဲအကုန်ပြင်ဆင်ရပါတယ်။ System ပိုင်းမှာဆိုလည်း Windows/Linux OS၊ Virtualisation၊ Storage၊ Monitoring နဲ့ Backup အပြင်၊ incident management အတွက်လည်း ကိုယ်တိုင် hands-on လုပ်ရတဲ့အပိုင်းတွေအများကြီးဖြစ်လာတယ်။ နည်းပညာပိုင်းမှာ အများကြီးလည်း မြင်ခဲ့ရတယ်၊ အများကြီးလည်း သင်ခဲ့ရတယ်ဆိုပါတော့။

ဒါ့ကြောင့် နည်းပညာပိုင်းမှာ အများကြီးလေ့လာချင်ရင် MSP environment ကအကောင်းဆုံးလို့ ဆိုရမယ်ထင်တယ်။ အဲ့ဒီ MSP မှာပဲ Network Operations Centre အတွက် night shift တွေပါလုပ်ခဲ့ရပါတယ်။ ပင်ပန်းတလောက် ကိုယ်သင်ယူနိုင်ရင် အများကြီးတတ်မြောက်နိုင်တဲ့ အခွင့်အလမ်းတခုပါ။ သို့သော်လည်း တစ်ယောက်နဲ့ တစ်ယောက်တော့ အလုပ်အပေါ်မှာထားတဲ့ အမြင်နဲ့ စိတ်ထားပေါ်မှာမူတည်ပြီးတော့ အဆင့်ဆင့်တက်လမ်းကြရပါတယ်။ အချို့လည်း NOC engineer ကနေဆက်မတက်တော့ပဲ၊ ဒီအတိုင်းဆက်လက် လုပ်ကိုင်နိုင်တာမျိုးလည်း မြင်ဖူးလို့ပါ။ ဒီလိုနဲ့ MSP မှာနှစ်နှစ်လောက်ပြီးတော့မှ Internet Service Provider (ISP) တခုမှာ Network Engineer အဖြစ်နဲ့ နောက်ထပ် နှစ်နှစ်လာက် ဆက်လက်လုပ်ကိုင်ခဲ့ပါတယ်။ MSP မှာလိုပဲ ISP က networking အတွက် အကုန်လုံး လေ့လာနိုင်တဲ့ environment တစ်ခုပါ။ Cisco၊ Huawei၊ Mikrotik၊ Fortinet နဲ့ Palo Alto networking devices တွေအပြင်၊ အခြားသော multi-vendor product တွေစတင်ထိတွေ့ခွင့်ရခဲ့ပါတယ်။ Network configuration တွေကို ကိုယ်တိုင် configure လုပ်နေကျမဟုတ်ရင် အနည်းငယ် စိမ်းနေသလိုဖြစ်တတ်သော်လည်း၊ configure လုပ်တာများလာတာနဲ့ အမျှ ဒီ concept ကိုပဲ မတူတဲ့ CLI syntax တွေ၊ implementation လုပ်ပုံတွေပဲ ကွာခြားသွားတယ်ဆိုတာနားလည်လာပါတော့တယ်။ Network engineer တစ်ယောက်အနေနဲ့ initial configuration တွေပြင်ဆင်ရသလို၊ network အတွင်းမှာလိုအပ်တဲ့ change ကို after hours တွေမှာ Data Centre တွေသွားပြီးတော့ configure လုပ်ရပါတယ်။ ထပ်ခါထပ်ခါ configure လုပ်ရတဲ့ network change တွေကို စာရေးသူ မကြိုက်ပါ။ နဂိုကတည်း လူကပျင်းတော့၊ တစ်ခါနှစ်ခါထပ်ပိုပြီးတော့ လုပ်ရတဲ့အလုပ်မျိုးကို အလွယ်တကူလုပ်နိုင်မယ့်နည်းကိုရှာရင်းနဲ့ Network Automation အတွက် Ansible ကိုစပြီးတော့ အသုံးပြုဖြစ်လာပါတော့တယ်။ အဲ့ဒီအထိကို cloud ဆိုတဲ့ ဝေါဟာရကို ဃဂနဏ စာရေးသူ သေချာနားလည်ပုံ မပေါက်ပါ။

စာရေးသူ ISP မှာ network engineer စလုပ်တဲ့အချိန်မှာတော့ လက်ဖော်ကိုင်ဖက်တစ်ယောက်က AWS Certificate သုံးခုလောက် အောင်ထားပြီး လုပ်ငန်းခွင်မှာလည်း မသုံးရလို့ စိတ်ပျက်လက်ပျက်ဖြစ်နေတာကြောင့် စကားစပ်မီပါတော့တယ်။ အဲ့ဒီလုပ်ဖော်ကိုင်ဖက်က Cloud က အနာဂတ်ဖြစ်ပြီး၊ Data Centre တွေမှာ co-location လုပ်တာ ဖြည်းဖြည်းချင်းနည်းလာမည်ဖြစ်ကြောင်း ပြောလာပါတော့တယ်။ အဲ့ဒီအချိန် လွန်ခဲ့တဲ့ ၅ နှစ်ကျော်ကျော် ၆နှစ်လောက်မှာ စာရေးသူကတော့ Data Centre co-location နဲ့ ပတ်သတ်တဲ့ အလုပ်တွေအများကြီးလုပ်ဖြစ်နေပါတယ်။ သူပြောတော့လည်း ကိုယ့်ဘက်က လက်ခံချင်တဲ့ပုံ မပေါက်လို့ သူက အကျိုးကြောင်းအစုံရှင်းပြလာပါတယ်။ ဒီလိုနဲ့ Cloud ဆိုတာဘာပါလိမ့်လို့ စပြီးခေါင်းထဲရောက်လာပါတော့တယ်။ ကိုယ်တိုင်က self-hosting နဲ့ data centre သမားမို့ ငွေကြေးအကုန်ကျခံပြီး cloud service providers တွေဆီဘာသွားလုပ်မှာလို့ အစကတော့ တွေးမိပါတယ်။ သို့သော်... အစပြုပြီးတော့ လေ့လာထားကာမှ မှီရုံရှိတဲ့ ဒီခေတ်သစ် နည်းပညာနယ်ပယ်ထဲမှာ လုပ်ကိုင်စားသောက်တဲ့သူမို့ အနည်းငယ်ပိုပြီးတော့ သက်သာတဲ့၊ ရိုးရှင်းတဲ့ CSP တွေဖြစ်တဲ့ Linode တို့၊ Vultr တို့လိုမျိုး platform တွေမှာ အလကားရတဲ့ $100 credit ကိုအစမ်းသုံးကြည့်ဖြစ်ပါတော့တယ်။

### Self-hosted နဲ့ Cloud ကွာခြားပုံ

စာရေးသူ အထက်မှာပြောတဲ့ ISP မှာ network engineer အနေနဲ့ အလုပ်ဝင်တဲ့အချိန်က၊ အဲ့ဒီ company မှာပဲ cloud team ဆိုတာရှိပါတယ်။ Cloud ဆိုတဲ့နေရာမှ AWS တို့၊ Azure တို့လို public cloud ကို manage လုပ်တဲ့ team တော့မဟုတ်ပါဘူး။ အရှင်းဆုံးပြောရရင် SMB ဖြစ်တဲ့အတွက်၊ ငွေဝင်နိုင်မည့် managed service မှန်သမျှကို invest လုပ်ထားတဲ့ သဘောမျိုးဖြစ်သလို၊ customer တွေရဲ့ demand နဲ့ လိုအပ်ချက်တွေအမှန်ရှိတာဖြစ်တဲ့အတွက် ထပ်ပြီးချဲ့တိုးထားတဲ့ business ပုံစံမျိုးပါ။ အဲ့ဒီ cloud team ကဘာတွေလုပ်သလဲဆိုတော့၊ VMware ရဲ့ virtualisation product တွေကို Data Centre နဲ့ co-location တွေမှာ အသုံးပြုပါတယ်။ ပြီးတော့ customer က လိုအပ်တဲ့ VM specs တွေရယ်၊ ဘယ် OS ကို install လုပ်ပြီး ဘာ application တွေ run ချင်တယ်ဆိုတာ service request ထဲမှာထည့်မှာလိုက်ပါတယ်။ အဲ့ဒါကို သတ်မှတ်ထားတဲ့ engineer က VMware platform ပေါ်မှာ customer မှာတဲ့အတိုင်း VM ကို create လုပ်တယ်၊ နောက် OS ကို install လုပ်တယ်၊ ပြီးတော့ လိုအပ်တဲ့ application ကိုလည်း အဆင့်ဆင့် install လုပ်ရပြန်ပါတယ်။ အဲ့ဒီ process ဟာပုံမှန်အားဖြင့် ၂ပတ်ကနေ ၃ပတ်လောက်ထိကြာတတ်ပါတယ်။ အကြာကြီး အဆင့်ဆင့်လုပ်ပြီး customer လက်ထဲရောက်မှ တခုခုအဆင်မပြေလို့ အစကနေပြန်ပြီးတော့လုပ်ရတဲ့ service request တွေလည်းရှိသလို၊ snapshot နဲ့ အလုပ်ဖြစ်သွားတဲ့ အလုပ်တွေလည်းရှိပါတယ်။

နောက်ပြီး အဲ့ဒီ cloud team ကပဲ compute အတွက်လိုတဲ့ HPE server တွေ၊ Lenovo server တွေကို Data Centre မှာငှားထားတဲ့ rack မှာ rack-and-stack လုပ်ရပါတယ်။ SAN storage အတွက် Dell EMC နဲ့ HPE 3PAR တွေလို hardware တွေကိုလည်း manage လုပ်ရပါတယ်၊ configure လုပ်ရပါတယ်။ ဒီ့အပြင် Enterprise Networking အတွက် switches တွေ၊ routers တွေ၊ firewall တွေကိုလည်း manage လုပ်ရပြန်ပါတယ်။ WAN connections အတွက်လိုအပ်တာရှိရင်တော့ စာရေးသူလုပ်တဲ့ ISP team ကိုထပ်ဆင့် internal request လုပ်ရပြန်ပါတယ်။ အဲ့ဒီမှာတင် ကြည့်လိုက်ရင် operation တစ်ခုလုံးက IaaS လိုလို၊ PaaS လိုလို၊ SaaS လိုလိုနဲ့ ဘာမှန်းကိုမသိတော့ပါဘူး။ စလယ်ဆုံး အကုန်လုံး ကိုယ့်ခြေကိုယ့်လက်နဲ့ အဆင့်ဆင့်လုပ်ရတာဖြစ်တဲ့ အတွက် တော်တော်လည်းလက်ဝင်ပါတယ်။ အမှားလည်း အရမ်းကိုများတာမို့ တော်တော်လည်း စိတ်ပျက်လက်ပျက်ရှိခဲ့ရပါတယ်။ အဲ့ဒီတုန်းက စဉ်းစားမိတာ cloud ဆိုပြီးတော့၊ လုပ်ရတဲ့ operation က self-hosting နဲ့ ဘာမှကို မကွာခြားတဲ့အပြင် friction အရမ်းကိုများတဲ့ workflow တစ်ခုပါ။ သို့သော် operation တစ်ခုလုံးက အလုပ်ဖြစ်တယ်။ Customer ရှိတယ်။ Cloud team လို့သမုတ်သော်လည်း Managed Service Provider (MSP) နဲ့ပိုပြီးတော့ဆင်တူပါတယ်။

တပြိုင်တည်းမှာဆိုသလို စာရေးသူ ကိုယ်တိုင်ကလည်း DevOps တို့၊ Automation တို့ကိုစပြီးတော့ ရင်းနှီးကျွမ်းဝင်လာတာနဲ့ အမျှ၊ အစလည်ဆုံး manual လုပ်ရတဲ့ အလုပ်ဆိုရင် သဘောမတွေ့တော့တဲ့ အချိန်မို့၊ public cloud မှာဘယ်လိုမျိုး ကွာခြားနိုင်သလဲလို့လည်း စဉ်းစားမိပြန်ပါတယ်။ ဒီလိုနဲ့ အလုပ်တခုကနေတခုပြောင်းရင်း private cloud ကို ကိုယ်တိုင် manage လုပ်ရတဲ့ အလုပ်ကိုဝင်ရပြန်ပါတယ်။ အဲ့ဒီ role မှာတော့ OpenStack လို platform မျိုးနဲ့ စတင်ပြီးတော့ ထိတွေ့ရပါတယ်။ OpenStack လို့ဆိုတဲ့နေရာမှာလည်း VMware ရဲ့ VMware Integrated OpenStack (VIO) ကို manage လုပ်ရပါတယ်။ အရှင်းဆုံးပြောရရင်တော့ OpenStack မှာ flavour တွေအများကြီးရှိတဲ့ထဲမှာမှ VMware ကနေ integrate လုပ်ထားတဲ့ product တစ်ခုပါ။ OpenStack ကို Red Hat ကလည်း product and support တခုအနေနဲ့ ရောင်းသလို၊ Rackspace ကလည်း သူ့ဟာနဲ့သူ ရှိပါတယ်။ အခြား flavour ကိုသုံးဖူးသူတွေပြောသလောက်တော့ Red Hat ရဲ့ OpenStack ကအလုပ်ပိုဖြစ်တယ်လို့ဆိုပါတယ်။ VMware ရဲ့ VIO ကတော့ ပြဿနာတော်တော်များတဲ့ platform တခုပါ။ Support ကလည်း ထင်ထားသလောက် မကောင်းပါဘူး။ Firefighting လုပ်ရတာလည်း ခဏခဏပါပဲ။ OpenStack ကိုယ်တိုင်ကိုက manage လုပ်ရတာလွယ်တဲ့ platform တစ်ခုမဟုတ်ပါဘူး။ သူ့မှာလည်း components ပေါင်းများစွာနဲ့ စုစည်းထားတဲ့ platform ပါ။ Component တစ်ခုချင်းစီမှာလည်း ရွေးချယ်စရာ နည်းပညာတွေက အများကြီးထပ်ရှိပြန်ပါတယ်။ အသေးစိတ်တော့ ထည့်ပြီးတော့ မရေးတော့ပါဘူး။ OpenStack ရဲ့ backend ကို manage လုပ်လေလေ ဘာဖြစ်လို့ DevOps သမားတွေ public cloud တွေဖြစ်တဲ့ AWS၊ Azure နဲ့ GCP ကိုကြိုက်သလဲ့ ဆိုတာပိုပြီးတော့ ထင်သာမြင်သာ ရှိလာပါတော့တယ်။

ဒီလိုနဲ့ နောက်ထပ် role တခုပြောင်းတော့ကာမှ Azure Cloud ကိုစပြီးတော့သုံးဖြစ်တယ်။ အလုပ်သဘောသဘာဝ အရက automation ဘက်မှာ အလေးပေးပြီးတော့ cloud ဘက်ကိုလိုမှသာ အနည်းငယ်ထိတွေ့ရပါတော့တယ်။ သို့သော် automation engineer တယောက်အတွက် cloud ဟာတော်တော်လေး အသုံးတည့်သလို၊ ဘယ်လောက်တောင် လွယ်သွားသလဲဆိုတာ ထင်သာမြင်သာ တခါရှိလာပြန်ပါတယ်။ စာရေးသူ အနေနဲ့ infrastructure team ထဲမှာဆိုပေးမည့် cloud ကိုသုံးရတဲ့ team ထဲမှာပါတဲ့အတွက် hardware ဘက်မှာအများကြီးလိုက်လုပ်စရာ မလိုပါဘူး။ လိုအပ်တဲ့ resource တွေကို လိုအပ်တဲ့ Ansible module တွေအသုံးပြုပြီး construct လုပ်သွားရုံပါပဲ။

### ပြန်လည်သုံးသပ်ကြည့်ခြင်း

အားလုံးပြန်လည် သုံးသပ်ကြည့်မယ်ဆိုရင် စာရေးသူရဲ့ လုပ်ငန်းခွင်အစပိုင်းမှာ on-prem၊ Data Center တို့ဘက်ကနေစခဲ့ပြီးတော့၊ rack-and-stack လိုမျိုး အောက်ခြေသိမ်းအလုပ်တွေအကုန်လုပ်ခဲ့ရပါတယ်။ အဲ့ဒီတုန်း cloud team နဲ့ အလုပ် အများကြီးလုပ်ခဲ့ရလို့ cloud တခုကိုဘယ်လိုမျိုးတည်ဆောက်ရလည်း ဆိုတာမြင်ခဲ့ တွေ့ခဲ့ ရပါတယ်။ AWS၊ Azure နဲ့ GCP မှာတော့ data centre engineer တွေက၊ hardware logistics နဲ့ installation တွေကိုလုပ်မယ်၊ SRE တွေ automation tools တွေကိုသုံးပြီးတော့ platform တွေကို deploy လုပ်မယ်။ စာရေးသူအတွက်တော့ hardware installation ကနေပြီးတော့ service တွေအကုန် အဆင်သင့်ဖြစ်တဲ့အထိ ကိုယ်တိုင်လုပ်ရပါတယ်။ ရှိသမျှအလုပ်တွေ အကုန်လုံးက manual တွေချည်းပါပဲ။ မမိုက်ပါဘူး။ သို့သော် manual process သိခြင်းအားဖြင့်၊ ရှိသမျှ အစိတ်အပိုင်းတွေ အကုန်လုံး ဘယ်လိုမျိုးအလုပ်လုပ်သလဲဆိုတာ ခြုံငုံပြီးတော့ ရိပ်စားမိပါတယ်။ အဲ့ဒီအတွက် အကျိုးရှိပါတယ်။

အဲ့ကနေမှဆင့် VMware ရဲ့ VIO ကိုကြည့်လိုက်ပြန်ရင်လည်း private cloud ဆိုတာဘာဖြစ်လို့ ဖြစ်လာသလဲ၊ ဘယ်လိုမျိုးနေရာမှာအသုံးဝင်ပြီးတော့၊ manage လုပ်ရတဲ့ workload နဲ့ complicity ဘယ်လောက်တောင်များသလဲဆိုတာ သိလာပြန်ပါတယ်။ OpenStack ဟာထင်သလောက် မလွယ်သလို၊ ဖိဖိစီးစီး ပိုင်နိုင်ဖို့ဆိုတာလည်း အချိန်တွေအများကြီး၊ ပညာရှင်တွေအများကြီးနဲ့ ဖွဲ့စည်းထားတဲ့ team တခုဖြစ်ဖို့လိုပါတယ်။ VIO လိုမျိုး product နဲ့ အလုပ်လုပ်ပြီးတဲ့နောက်၊ သိလာတာတခုက VMware လိုမျိုး company ကြီးထဲမှတောင် အဲ့ဒီ product အကြောင်းကို လုံးစေ့ပတ်စေ့သိတဲ့ engineer တွေ၊ developer တွေအများကြီးမရှိပါဘူး။ ဒါကြောင့် တခုခုဖြစ်လို့ troubleshoot လုပ်မယ်ဆိုရင်တောင်၊ အချိန်အများကြီး ကုန်ပါတယ်။ ပျော်စရာလုံးဝ မကောင်းပါဘူး။ ကိုယ်တိုင်က support လိုလို့ VMware ကိုဆက်သွယ်ကာမှ support engineer တချို့က product ကိုကိုယ့်လောက်မသိပဲနဲ့ bridge ကို join လာတာမျိုးလည်းရှိပါတယ်။ Firefighting လုပ်ရတာများလာတော့၊ တချို့ဟာတွေလည်း ကိုယ်တိုင်လေ့လာရင်း product နဲ့ ရင်းနှိီးလာတဲ့သဘောပါ။ ရေရှည်အတွက်တော့ ဘယ်လိုမှအဆင်မပြေနိုင်ပါ၊

ဒါကြောင့် CSPs တွေထဲမှာမှ big three လို့ခေါ်တဲ့ AWS၊ Azure နဲ့ GCP တို့လိုမျိုးမှာတော့ ကိုယ့်အလုပ်ရဲ့ nature မှာမူတည်ပြီးတော့ heavy-lifting လုပ်ရတဲ့ကိစ္စမရှိသလောက်ဖြစ်သွားပါတယ်။ အားလုံးပြီးပြည့်စုံတဲ့ ရွေးချယ်စရာတခုလားဆိုတော့လည်း မဟုတ်သေးပါဘူး။ အချို့သော troubleshoot တွေမှာဆို ဘာဖြစ်လို့ဖြစ်မှန်းလည်း မသိဘူး၊ Azure ကို support ticket ဖွင့်တော့လည်း သူတို့ပြောသလောက်နဲ့ပဲ ကိုယ့်မှာကျေနပ်ရတဲ့ ကိစ္စတွေ ရှိပါတယ်။ ရှိသမျှ logs တွေကိုမြေလှန်ရှာလို့ မရတော့တဲ့ အတွက် ပြဿနာတခုတက်ပြီဆိုရင် အတိုင်းအတာတခုထိပဲ လက်လျှော့လိုက်ရတာတွေလည်း ရှိပါတယ်။

ဒီတော့ cloud ဆိုတာဘာနဲ့တူသလဲဆိုရင်၊ T-shirt တထည်ကို ကိုယ်တိုင် ပိတ်စဝယ်၊ ပြီးရင် လိုအပ်တဲ့အတိုင်းအတာလုပ် ဖျက်စရာရှိတာဖျက်၊ အားလုံးပြီးတော့မှ ချုပ်စက်နဲ့ တထည်စီ ချုပ်မယ့်အစား၊ အနီးစပ်ဆုံး Small (S)၊ Medium (M)၊ Large (L) size ကို စိတ်ကြိုက် အရောင်နဲ့ ပုံစံကို လေအေးစက်ဖွင့်ထားတဲ့ shopping mall ထဲမှာ စျေးကြီးပေးဝယ်သလိုပါပဲ။ ကိုယ်တိုင် ချုပ်ရင် သိထားရမယ့် အရာတွေအများကြီးရှိသလို၊ ဖျက်တာ size မှားလို့ အလေအလွင့်တွေလည်းရှိနိုင်ပါတယ်။ ဒီလိုမှမဟုတ်ပဲ shopping mall မှာသွားဝယ်ရင် စိတ်ကြိုက်ရွေးဝယ်လို့ရနိုင်သလို၊ ဆိုင်ကဝန်ထမ်းတွေက သင့်တော်သလို ရှင်းပြမယ်၊ အကြံပေးမယ်၊ ပြီးတော့ size မှားတာပဲဖြစ်ဖြစ်၊ စိတ်ပြောင်းပြီးတော့ exchange လုပ်ချင်ရင်၊ refund လုပ်ချင်ရင်လည်း အလွယ်တကူလုပ်နိုင်တာမို့ အဆင်ပြေပါတယ်။


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://my.itmatic101.com/virtualisation-and-cloud/cloud-saothimha.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.