စင်များပေါ်တွင် ဆာဗာမရှိပါ။

Serverless သည် ဆာဗာများ၏ ရုပ်ပိုင်းဆိုင်ရာ မရှိတော့ခြင်းနှင့် ပတ်သက်၍ မဟုတ်ပါ။ ၎င်းသည် ကွန်တိန်နာ လူသတ်သမား သို့မဟုတ် ဖြတ်သန်းနေသည့် လမ်းကြောင်းတစ်ခုမဟုတ်ပါ။ ဤသည်မှာ Cloud တွင် စနစ်များတည်ဆောက်ခြင်းအတွက် ချဉ်းကပ်မှုအသစ်ဖြစ်သည်။ ယနေ့ဆောင်းပါးတွင် Serverless applications များတည်ဆောက်ပုံနှင့်ပတ်သက်ပြီး ကျွန်ုပ်တို့သည် Serverless ဝန်ဆောင်မှုပေးသူနှင့် open-source ပရောဂျက်များ၏အခန်းကဏ္ဍကို ကြည့်ကြပါစို့။ နောက်ဆုံးအနေနဲ့ Serverless အသုံးပြုခြင်းဆိုင်ရာ ကိစ္စရပ်များကို ဆွေးနွေးကြပါစို့။

အက်ပလီကေးရှင်းတစ်ခု (သို့မဟုတ် အွန်လိုင်းစတိုး) ၏ ဆာဗာအစိတ်အပိုင်းတစ်ခုကို ရေးလိုပါသည်။ ၎င်းသည် ချတ်လုပ်ခြင်း၊ အကြောင်းအရာထုတ်ဝေခြင်းဝန်ဆောင်မှုတစ်ခု သို့မဟုတ် load balancer ဖြစ်နိုင်သည်။ မည်သို့ပင်ဆိုစေ၊ ခေါင်းကိုက်စရာများစွာရှိလိမ့်မည်- သင်အခြေခံအဆောက်အအုံကိုပြင်ဆင်ရန်၊ အသုံးချပလီကေးရှင်းမှီခိုမှုကိုဆုံးဖြတ်ရန်နှင့် host operating system ကိုစဉ်းစားရန်လိုလိမ့်မည်။ ထို့နောက် ကျန်ရှိသော monolith ၏ လည်ပတ်မှုကို မထိခိုက်စေသော သေးငယ်သော အစိတ်အပိုင်းများကို အပ်ဒိတ်လုပ်ရန် လိုအပ်ပါသည်။ ကောင်းပြီ၊ ဝန်အောက်စကေးချခြင်းကို မမေ့ပါနှင့်။

လိုအပ်သော မှီခိုအားထားမှုများကို ကြိုတင်ထည့်သွင်းထားပြီးဖြစ်သည့် ပေါ်ပင်ကွန်တိန်နာများကို ကျွန်ုပ်တို့ယူဆောင်ပြီး ကွန်တိန်နာများကို ၎င်းတို့အချင်းချင်းနှင့် လက်ခံဆောင်ရွက်ပေးသည့် OS တို့မှ သီးခြားခွဲထုတ်ထားလျှင်ကော။ ကျွန်ုပ်တို့သည် monolith ကို microservices များအဖြစ် ပိုင်းခြားပြီး တစ်ခုချင်းစီကို အခြားအရာများနှင့် သီးခြားမွမ်းမံပြီး အဆင့်မြှင့်တင်နိုင်ပါသည်။ ကုဒ်ကို ထိုကဲ့သို့သော ကွန်တိန်နာတစ်ခုတွင် ထည့်ခြင်းဖြင့် မည်သည့်အခြေခံအဆောက်အအုံတွင်မဆို ၎င်းကို ကျွန်ုပ်သုံးနိုင်သည်။ ပိုကောင်းနေပြီ။

ကွန်တိန်နာများကို မပြင်ဆင်လိုပါက မည်သို့လုပ်ဆောင်မည်နည်း။ အပလီကေးရှင်းကို ချဲ့ထွင်ဖို့ မစဉ်းစားချင်ဘူး။ ဝန်ဆောင်မှုတွင် ဝန်အနည်းငယ်သာရှိသောအခါ ရပ်နားထားသောကွန်တိန်နာများအတွက် ကျွန်ုပ်ငွေမပေးချင်ပါ။ ကုဒ်ရေးချင်လို့ပါ။ စီးပွားရေးယုတ္တိကိုအာရုံစိုက်ပြီး ထုတ်ကုန်များကို အလင်းအလျင်ဖြင့် ဈေးကွက်သို့ပို့ဆောင်ပါ။

ထိုသို့သောအတွေးများက ကျွန်ုပ်အား ဆာဗာမဲ့ကွန်ပြူတာဆီသို့ ဦးတည်စေခဲ့သည်။ ဤကိစ္စတွင် Serverless ကိုဆိုလိုသည်။ ဆာဗာများ၏ ရုပ်ပိုင်းဆိုင်ရာ မရှိတော့ခြင်းမဟုတ်သော်လည်း အခြေခံအဆောက်အအုံ စီမံခန့်ခွဲမှု မရှိခြင်းမှာ ခေါင်းကိုက်ခြင်း ဖြစ်သည်။

အယူအဆမှာ အပလီကေးရှင်းလော့ဂျစ်ကို သီးခြားလုပ်ဆောင်ချက်များအဖြစ် ပိုင်းခြားထားသည်။ သူတို့မှာ ပွဲဖွဲ့စည်းပုံရှိတယ်။ လုပ်ဆောင်ချက်တစ်ခုစီသည် “မိုက်ခရိုတာ့ခ်” တစ်ခုလုပ်ဆောင်သည်။ ဆော့ဖ်ဝဲရေးသားသူထံမှ လိုအပ်သည့်အရာအားလုံးမှာ cloud ဝန်ဆောင်မှုပေးသူမှ ပံ့ပိုးပေးထားသည့် ကွန်ဆိုးလ်ထဲသို့ လုပ်ဆောင်ချက်များကို တင်ပြီး ၎င်းတို့ကို ဖြစ်ရပ်အရင်းအမြစ်များနှင့် ဆက်စပ်နေရန်ဖြစ်သည်။ ကုဒ်ကို အလိုအလျောက်ပြင်ဆင်ထားသော ကွန်တိန်နာတစ်ခုတွင် တောင်းဆိုမှုအရ လုပ်ဆောင်မည်ဖြစ်ပြီး၊ လုပ်ဆောင်ချိန်အတွက်သာ ကျွန်ုပ်ပေးချေပါမည်။

အခု Application Development Process က ဘယ်လိုပုံစံလဲဆိုတာ ကြည့်လိုက်ရအောင်။

developer ဘက်မှ

အစောပိုင်းတွင် ကျွန်ုပ်တို့သည် အွန်လိုင်းစတိုးတစ်ခုအတွက် လျှောက်လွှာတစ်ခုအကြောင်း စတင်ပြောဆိုခဲ့သည်။ သမားရိုးကျချဉ်းကပ်မှုတွင်၊ စနစ်၏အဓိကယုတ္တိကို monolithic အပလီကေးရှင်းဖြင့်လုပ်ဆောင်သည်။ ဝန်မရှိသော်လည်း အပလီကေးရှင်းဖြင့် ဆာဗာသည် အဆက်မပြတ်လည်ပတ်နေပါသည်။

ဆာဗာမဲ့သို့ ရွှေ့ရန်၊ ကျွန်ုပ်တို့သည် အပလီကေးရှင်းကို မိုက်ခရိုတာ့စ်များအဖြစ် ခွဲထားသည်။ ကျွန်ုပ်တို့သည် ၎င်းတို့တစ်ဦးစီအတွက် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်လုပ်ဆောင်ချက်ကို ရေးသားထားသည်။ လုပ်ဆောင်ချက်များသည် တစ်ခုနှင့်တစ်ခု အမှီအခိုကင်းပြီး နိုင်ငံပိုင်အချက်အလက်များကို သိမ်းဆည်းခြင်းမပြုပါ (နိုင်ငံမဲ့)။ ၎င်းတို့ကို ဘာသာစကားအမျိုးမျိုးဖြင့် ရေးသားနိုင်သည်။ ၎င်းတို့ထဲမှတစ်ဦး "ပြုတ်ကျ" ပါက၊ အပလီကေးရှင်းတစ်ခုလုံးရပ်တန့်မည်မဟုတ်ပါ။ အပလီကေးရှင်းတည်ဆောက်ပုံသည် ဤကဲ့သို့ဖြစ်နေလိမ့်မည်-

Serverless တွင် လုပ်ဆောင်ချက်များကို ပိုင်းခြားခြင်းသည် မိုက်ခရိုဆားဗစ်များနှင့် လုပ်ဆောင်ခြင်းနှင့် ဆင်တူသည်။ သို့သော် microservice သည် အလုပ်များစွာကို လုပ်ဆောင်နိုင်ပြီး လုပ်ဆောင်ချက်တစ်ခုသည် အကောင်းဆုံးလုပ်ဆောင်သင့်သည်။ အလုပ်မှာ စာရင်းဇယားများကို စုဆောင်းပြီး သုံးစွဲသူ၏ တောင်းဆိုချက်အရ ၎င်းတို့ကို ပြသရန်ဖြစ်ကြောင်း စိတ်ကူးကြည့်ကြပါစို့။ microservice ချဉ်းကပ်မှုတွင်၊ ဝင်ပေါက်အချက်နှစ်ချက်ပါသော ဝန်ဆောင်မှုတစ်ခုမှ လုပ်ဆောင်သည်- စာရေးခြင်းနှင့် စာဖတ်ခြင်း။ ဆာဗာမဲ့ ကွန်ပြူတာတွင်၊ ၎င်းတို့သည် တစ်ခုနှင့်တစ်ခု မသက်ဆိုင်သော မတူညီသော လုပ်ဆောင်ချက်များ နှစ်ခုဖြစ်လိမ့်မည်။ ဥပမာအားဖြင့် စာရင်းဇယားများကို ဒေါင်းလုဒ်လုပ်ထားသည်ထက် မကြာခဏ အပ်ဒိတ်လုပ်ပါက ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ကွန်ပျူတာအရင်းအမြစ်များကို သိမ်းဆည်းသည်။

ဆာဗာမဲ့လုပ်ဆောင်ချက်များကို ဝန်ဆောင်မှုပေးသူမှ ဆုံးဖြတ်သည့် အချိန်တိုအတွင်း (အချိန်ကုန်) လုပ်ဆောင်ရပါမည်။ ဥပမာအားဖြင့်၊ AWS အတွက် အချိန်ကုန်ဆုံးမှုသည် 15 မိနစ်ဖြစ်သည်။ ဆိုလိုသည်မှာ လိုအပ်ချက်များနှင့် ကိုက်ညီစေရန် တာရှည်ခံလုပ်ဆောင်ချက်များကို ပြောင်းလဲရမည်ဖြစ်ပြီး၊ ၎င်းသည် ယနေ့ခေတ်ရေပန်းစားသော အခြားနည်းပညာများ (ကွန်တိန်နာနှင့် ဝန်ဆောင်မှုအဖြစ် ပလပ်ဖောင်း) နှင့် Serverless တို့ကို ခွဲခြားထားသည်။

ကျွန်ုပ်တို့သည် လုပ်ဆောင်မှုတစ်ခုစီအတွက် ဖြစ်ရပ်တစ်ခုကို သတ်မှတ်ပေးသည်။ ဖြစ်ရပ်တစ်ခုသည် လုပ်ဆောင်ချက်တစ်ခုအတွက် အစပျိုးတစ်ခုဖြစ်သည်-

အဖြစ်အပျက်
လုပ်ဆောင်သည့်လုပ်ဆောင်ချက်

ကုန်ပစ္စည်းပုံတစ်ပုံကို သိုလှောင်ရုံသို့ အပ်လုဒ်တင်လိုက်ပါပြီ။
ပုံကိုချုံ့ပြီး လမ်းညွှန်တစ်ခုသို့ အပ်လုဒ်လုပ်ပါ။

ရုပ်ပိုင်းဆိုင်ရာ စတိုးဆိုင်လိပ်စာကို ဒေတာဘေ့စ်တွင် အပ်ဒိတ်လုပ်ထားသည်။
တည်နေရာအသစ်တစ်ခုကို မြေပုံများတွင် တင်ပါ။

ဖောက်သည်သည် ကုန်ပစ္စည်းအတွက် ပေးချေသည်။
ငွေပေးချေမှုကို စတင်ပါ။

အစီအစဉ်များသည် HTTP တောင်းဆိုမှုများ၊ ဒေတာထုတ်လွှင့်ခြင်း၊ မက်ဆေ့ချ်တန်းစီခြင်း စသည်တို့ ဖြစ်နိုင်သည်။ ဖြစ်ရပ်အရင်းအမြစ်များသည် ဒေတာပြောင်းလဲမှုများ သို့မဟုတ် ဖြစ်ပေါ်မှုများဖြစ်သည်။ ထို့အပြင်၊ လုပ်ဆောင်ချက်များကို timer ဖြင့် အစပျိုးနိုင်သည်။

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

ပံ့ပိုးပေးသူဘက်မှ

ပုံမှန်အားဖြင့်၊ serverless computing ကို cloud ဝန်ဆောင်မှုပေးသူများက ကမ်းလှမ်းသည်။ ၎င်းတို့ကို ကွဲပြားစွာခေါ်သည်- Azure Functions၊ AWS Lambda၊ Google Cloud Functions၊ IBM Cloud Functions။

ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုပေးသူ၏ ကွန်ဆိုးလ် သို့မဟုတ် ကိုယ်ရေးကိုယ်တာအကောင့်မှတစ်ဆင့် ဝန်ဆောင်မှုကို အသုံးပြုပါမည်။ လုပ်ဆောင်ချက်ကုဒ်ကို အောက်ပါနည်းလမ်းများထဲမှ ဒေါင်းလုဒ်လုပ်နိုင်ပါသည်။

• ဝဘ်ကွန်ဆိုးလ်မှတဆင့် built-in တည်းဖြတ်သူများတွင်ကုဒ်ရေးပါ။
• ကုဒ်ဖြင့် archive ကိုဒေါင်းလုဒ်လုပ်ပါ၊
• အများသူငှာ သို့မဟုတ် ပုဂ္ဂလိက git repositories နှင့် အလုပ်လုပ်ပါ။

ဤတွင် ကျွန်ုပ်တို့သည် လုပ်ဆောင်ချက်ကို ခေါ်သည့် ဖြစ်ရပ်များကို သတ်မှတ်ပေးပါသည်။ မတူညီသော ဝန်ဆောင်မှုပေးသူများအတွက် အစီအစဉ်အစုံသည် ကွဲပြားနိုင်ပါသည်။

ဝန်ဆောင်မှုပေးသူက ၎င်း၏အခြေခံအဆောက်အအုံတွင် Function as a Service (FaaS) စနစ်အား တည်ဆောက်ပြီး အလိုအလျောက်လုပ်ဆောင်ပေးသည်-

1. လုပ်ဆောင်ချက်ကုဒ်သည် ဝန်ဆောင်မှုပေးသူဘက်မှ သိုလှောင်မှုတွင် အဆုံးသတ်သည်။
2. ဖြစ်ရပ်တစ်ခုဖြစ်ပေါ်သောအခါ၊ ပြင်ဆင်ထားသောပတ်ဝန်းကျင်တစ်ခုပါရှိသောကွန်တိန်နာများကိုဆာဗာပေါ်တွင်အလိုအလျောက်အသုံးချသည်။ လုပ်ဆောင်ချက်တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် သီးခြားကွန်တိန်နာ ရှိသည်။
3. သိုလှောင်မှုမှ၊ လုပ်ဆောင်ချက်ကို ကွန်တိန်နာသို့ ပို့ပြီး၊ တွက်ချက်ပြီး ရလဒ်ကို ပြန်ပေးသည်။
4. အပြိုင်ဖြစ်ရပ်များ တိုးပွားလာသည် - ကွန်တိန်နာအရေအတွက် တိုးလာသည်။ စနစ်က အလိုအလျောက် ချိန်ခွင်။ အသုံးပြုသူများသည် လုပ်ဆောင်ချက်ကို မသုံးစွဲပါက၊ ၎င်းသည် မလှုပ်ရှားတော့ပါ။
5. ဝန်ဆောင်မှုပေးသူက ကွန်တိန်နာအတွက် ရပ်နားချိန်ကို သတ်မှတ်ပေးသည် - ဤအချိန်အတွင်း လုပ်ဆောင်ချက်များသည် ကွန်တိန်နာတွင် မပေါ်ပါက၊ ၎င်းသည် ပျက်စီးသွားမည်ဖြစ်သည်။

ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် Serverless ကို အကွက်ထဲမှ ထုတ်ယူနိုင်မည်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် သင်သွားလိုသည့်ပုံစံကို အသုံးပြု၍ ဝန်ဆောင်မှုအတွက် ပေးချေမည်ဖြစ်ပြီး အသုံးပြုသည့်လုပ်ဆောင်ချက်များအတွက်သာ၊ ၎င်းတို့ကိုအသုံးပြုသည့်အချိန်အတွက်သာ ကျွန်ုပ်တို့ပေးချေပါမည်။

ဝန်ဆောင်မှုအား developer များအား မိတ်ဆက်ပေးရန်၊ ဝန်ဆောင်မှုပေးသူများသည် အခမဲ့ စမ်းသပ်ခြင်း ၁၂ လအထိ ပေးစွမ်းသော်လည်း စုစုပေါင်းတွက်ချက်ချိန်၊ တစ်လလျှင် တောင်းဆိုမှုအရေအတွက်၊ ရန်ပုံငွေ သို့မဟုတ် ပါဝါသုံးစွဲမှုကို ကန့်သတ်ထားသည်။

ဝန်ဆောင်မှုပေးသူနှင့် အလုပ်လုပ်ခြင်း၏ အဓိကအားသာချက်မှာ အခြေခံအဆောက်အအုံများ (ဆာဗာများ၊ အတုအယောင်စက်များ၊ ကွန်တိန်နာများ) နှင့်ပတ်သက်ပြီး စိတ်မပူရန်ဖြစ်သည်။ ၎င်း၏အစိတ်အပိုင်းအတွက်၊ ဝန်ဆောင်မှုပေးသူက FaaS ကို ၎င်း၏ကိုယ်ပိုင်တိုးတက်မှုများကို အသုံးပြု၍ open-source tools များကို အသုံးပြု၍ နှစ်မျိုးလုံးအကောင်အထည်ဖော်နိုင်သည်။ သူတို့အကြောင်း ဆက်ပြောကြရအောင်။

open source ဘက်မှ

Open-source အသိုင်းအဝိုင်းသည် လွန်ခဲ့သော နှစ်အနည်းငယ်ကတည်းက Serverless ကိရိယာများပေါ်တွင် တက်ကြွစွာ လုပ်ဆောင်နေပါသည်။ အကြီးဆုံးစျေးကွက်ကစားသူများသည် ဆာဗာမဲ့ပလပ်ဖောင်းများ ဖွံ့ဖြိုးတိုးတက်ရေးကို ပံ့ပိုးပေးသည်-

• Google developer များအား ၎င်း၏ open-source tool ကို ပေးသည်- တတ်မြောက်သော. IBM၊ RedHat၊ Pivotal နှင့် SAP တို့သည် ၎င်း၏ ဖွံ့ဖြိုးတိုးတက်မှုတွင် ပါဝင်ခဲ့သည်။
• IBM က Serverless ပလပ်ဖောင်းပေါ်တွင်အလုပ်လုပ်ခဲ့သည်။ OpenWhiskထို့နောက် Apache Foundation ၏ ပရောဂျက်တစ်ခု ဖြစ်လာခဲ့သည်။
• Microsoft က ပလက်ဖောင်းကုဒ်ကို တစ်စိတ်တစ်ပိုင်း ဖွင့်ထားသည်။ Azure လုပ်ဆောင်ချက်များ.

ဆာဗာမဲ့ မူဘောင်များ ၏ ဦးတည်ရာ တွင်လည်း တိုးတက်မှု များကို လုပ်ဆောင်နေပါသည်။ Kubeless и ခွဲစိတ် ကြိုတင်ပြင်ဆင်ထားသော Kubernetes အစုအဝေးများအတွင်းတွင် ဖြန့်ကျက်ချထားသည်၊ OpenFaaS Kubernetes နှင့် Docker Swarm နှစ်ခုလုံးနှင့် အလုပ်လုပ်သည်။ framework သည် controller အမျိုးအစားတစ်ခုအနေဖြင့် လုပ်ဆောင်သည် - တောင်းဆိုချက်အရ၊ ၎င်းသည် cluster အတွင်းရှိ runtime ပတ်ဝန်းကျင်ကို ပြင်ဆင်ပြီး ၎င်းတွင် function တစ်ခုကို စတင်သည်။

Frameworks များသည် သင့်လိုအပ်ချက်များနှင့်ကိုက်ညီသော tool ကို configure လုပ်ရန်အတွက် နေရာလွတ်ကျန်ခဲ့သည်။ ထို့ကြောင့်၊ Kubeless တွင်၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦးသည် လုပ်ဆောင်ချက်လုပ်ဆောင်မှုအချိန်ကုန်ဆုံးမှုကို စီစဉ်သတ်မှတ်နိုင်သည် (မူလတန်ဖိုးမှာ 180 စက္ကန့်ဖြစ်သည်)။ Fission သည် အအေးမိခြင်းပြဿနာကို ဖြေရှင်းရန် ကြိုးပမ်းမှုတွင် အချို့သော ကွန်တိန်နာများကို အချိန်တိုင်းလည်ပတ်နေစေရန် အကြံပြုသည် (၎င်းတွင် အရင်းအမြစ်များ ရပ်နားချိန် ကုန်ကျစရိတ်များ ပါဝင်သော်လည်း)။ နှင့် OpenFaaS သည် အရသာနှင့် အရောင်တိုင်းအတွက် အစပျိုးမှုအစုံကို ပေးသည်- HTTP၊ Kafka၊ Redis၊ MQTT၊ Cron၊ AWS SQS၊ NATs နှင့် အခြားအရာများ။

စတင်ခြင်းအတွက် လမ်းညွှန်ချက်များကို မူဘောင်များ၏ တရားဝင်စာရွက်စာတမ်းများတွင် တွေ့ရှိနိုင်ပါသည်။ ၎င်းတို့နှင့်အလုပ်လုပ်ခြင်းသည် ဝန်ဆောင်မှုပေးသူနှင့်အလုပ်လုပ်သောအခါထက် အနည်းငယ်ပိုကျွမ်းကျင်မှုရှိရန် လိုအပ်သည် - ၎င်းသည် အနည်းဆုံး CLI မှတစ်ဆင့် Kubernetes အစုအဝေးတစ်ခုကို စတင်နိုင်သည့်စွမ်းရည်ဖြစ်သည်။ အများစုမှာ အခြား open-source ကိရိယာများ (ဥပမာ၊ Kafka တန်းစီမန်နေဂျာ) ပါဝင်သည်။

ကျွန်ုပ်တို့သည် Serverless နှင့် မည်သို့အလုပ်လုပ်သည်ဖြစ်စေ - ဝန်ဆောင်မှုပေးသူမှတဆင့် သို့မဟုတ် open-source ကိုအသုံးပြုသည်ဖြစ်စေ Serverless ချဉ်းကပ်မှု၏ အားသာချက်များနှင့် အားနည်းချက်များစွာကို ကျွန်ုပ်တို့ရရှိမည်ဖြစ်ပါသည်။

အားသာချက်၊ အားနည်းချက်တွေကို ရှုထောင့်ကနေ ကြည့်တယ်။

ဆာဗာမဲ့သည် ကွန်တိန်နာအခြေခံအဆောက်အအုံနှင့် မိုက်ခရိုဝန်ဆောင်မှုချဉ်းကပ်မှုဆိုင်ရာ အကြံဉာဏ်များကို ဖော်ဆောင်ပေးပါသည်။ အဖွဲ့များသည် ပလက်ဖောင်းတစ်ခုနှင့် ချိတ်ဆက်ခြင်းမရှိဘဲ ဘာသာစကားမျိုးစုံမုဒ်ဖြင့် လုပ်ဆောင်နိုင်သည်။ စနစ်တစ်ခုတည်ဆောက်ခြင်းသည် ရိုးရှင်းပြီး အမှားများကိုပြင်ရန် ပိုမိုလွယ်ကူသည်။ မိုက်ခရိုဆားဗစ်ဗိသုကာသည် သင့်အား monolithic အပလီကေးရှင်းတစ်ခုထက် များစွာပိုမိုမြန်ဆန်သောစနစ်တွင် လုပ်ဆောင်ချက်အသစ်များကို ထည့်သွင်းနိုင်စေပါသည်။

Serverless သည် ဖွံ့ဖြိုးတိုးတက်မှုအချိန်ကို ပိုမိုလျှော့ချပေးသည်၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာအား အပလီကေးရှင်း၏လုပ်ငန်းဆိုင်ရာ ယုတ္တိဗေဒနှင့် ကုဒ်ရေးခြင်းအပေါ်သာ အာရုံစိုက်ခွင့်ပြုပါ။ ရလဒ်အနေဖြင့် ဖွံ့ဖြိုးတိုးတက်မှုအတွက် စျေးကွက်ရှာဖွေရန် အချိန်ကို လျှော့ချခဲ့သည်။

အပိုဆုအနေဖြင့် ကျွန်ုပ်တို့သည် ဝန်အတွက် အလိုအလျောက် အတိုင်းအတာကို ရရှိသည်၊ ကျွန်ုပ်တို့သည် အသုံးပြုသည့် အရင်းအမြစ်များအတွက်သာ ပေးချေပြီး ၎င်းတို့ကို အသုံးပြုသည့်အချိန်တွင်သာ ပေးဆောင်ပါသည်။

မည်သည့်နည်းပညာကဲ့သို့ပင်၊ Serverless တွင်အားနည်းချက်များရှိသည်။

ဥပမာအားဖြင့်၊ ထိုသို့သောအားနည်းချက်သည် အေးသောစတင်ချိန် (JavaScript၊ Python၊ Go၊ Java၊ Ruby ကဲ့သို့သော ဘာသာစကားများအတွက် ပျမ်းမျှ 1 စက္ကန့်အထိ) ဖြစ်နိုင်သည်။

တစ်ဖက်တွင်၊ အမှန်တကယ်တွင်၊ အေးခဲသောစတင်ချိန်သည် ကိန်းရှင်များစွာပေါ်တွင်မူတည်သည်- လုပ်ဆောင်ချက်ကိုရေးသားသည့်ဘာသာစကား၊ စာကြည့်တိုက်အရေအတွက်၊ ကုဒ်ပမာဏ၊ အပိုအရင်းအမြစ်များနှင့် ဆက်သွယ်မှု (တူညီသောဒေတာဘေ့စ်များ သို့မဟုတ် အထောက်အထားစိစစ်ခြင်းဆာဗာများ)။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ဤကိန်းရှင်များကို ထိန်းချုပ်ထားသောကြောင့် စတင်ချိန်ကို လျှော့ချနိုင်သည်။ သို့သော် အခြားတစ်ဖက်တွင်၊ developer သည် container ၏ startup time ကို မထိန်းချုပ်နိုင်ဘဲ - အားလုံးသည် ပံ့ပိုးပေးသူပေါ်တွင်မူတည်ပါသည်။

လုပ်ဆောင်ချက်တစ်ခုသည် ယခင်ဖြစ်ရပ်တစ်ခုမှစတင်ခဲ့သော ကွန်တိန်နာကို ပြန်လည်အသုံးပြုသည့်အခါ အအေးမိခြင်းစတင်မှုတစ်ခုအဖြစ် ပြောင်းလဲသွားနိုင်သည်။ ဤအခြေအနေသုံးမျိုးတွင် ဖြစ်ပေါ်လာလိမ့်မည် ။

• အကယ်၍ သုံးစွဲသူများသည် ဝန်ဆောင်မှုကို မကြာခဏအသုံးပြုကြပြီး လုပ်ဆောင်ချက်သို့ ခေါ်ဆိုမှုအရေအတွက် တိုးလာပါက၊
• ဝန်ဆောင်မှုပေးသူ၊ ပလပ်ဖောင်း သို့မဟုတ် မူဘောင်က သင့်အား ကွန်တိန်နာအချို့ကို အချိန်ပြည့်လည်ပတ်နေစေရန် ခွင့်ပြုပါက၊
• ဆော့ဖ်ဝဲဆော့ဖ်ဝဲသည် အချိန်တိုင်းကိရိယာပေါ်တွင် လုပ်ဆောင်ချက်များကို လုပ်ဆောင်ပါက (၃ မိနစ်တိုင်းပြောပါ)။

အပလီကေးရှင်းများစွာအတွက်၊ အအေးခံခြင်းသည် ပြဿနာမဟုတ်ပါ။ ဤနေရာတွင် သင်သည် ဝန်ဆောင်မှု၏ အမျိုးအစားနှင့် လုပ်ဆောင်ချက်များကို တည်ဆောက်ရန် လိုအပ်ပါသည်။ တစ်စက္ကန့်၏ စတင်နှောင့်နှေးမှုသည် လုပ်ငန်းလျှောက်လွှာအတွက် အမြဲတမ်း အရေးကြီးသည်မဟုတ်သော်လည်း ဆေးဘက်ဆိုင်ရာဝန်ဆောင်မှုများအတွက် အရေးပါလာနိုင်သည်။ ဤကိစ္စတွင်၊ ဆာဗာမဲ့ချဉ်းကပ်မှုသည် သင့်လျော်တော့မည်မဟုတ်ပါ။

Serverless ၏နောက်ထပ်အားနည်းချက်မှာ လုပ်ဆောင်ချက်တစ်ခု၏ သက်တမ်းတိုခြင်း (လုပ်ဆောင်ချက်ကို လုပ်ဆောင်ရမည့်အချိန်ကာလ) ဖြစ်သည်။

သို့သော်၊ သင်သည် ရေရှည်အလုပ်များဖြင့် လုပ်ကိုင်ရပါက၊ သင်သည် ဟိုက်ဘရစ်ဗိသုကာကို အသုံးပြုနိုင်ပြီး၊ အခြားနည်းပညာနှင့် Serverless တို့ကို ပေါင်းစပ်နိုင်သည်။

စနစ်အားလုံးသည် Serverless scheme ကိုအသုံးပြု၍ အလုပ်လုပ်နိုင်မည်မဟုတ်ပါ။

အချို့သော အပလီကေးရှင်းများသည် လုပ်ဆောင်နေစဉ်အတွင်း ဒေတာကို သိမ်းဆည်းထားဆဲဖြစ်သည်။ အချို့သော ဗိသုကာလက်ရာများသည် monolithic ဖြစ်နေမည်ဖြစ်ပြီး အချို့သောအင်္ဂါရပ်များသည် ကြာရှည်ခံမည်ဖြစ်သည်။ သို့သော်လည်း (cloud နည်းပညာများနှင့် ကွန်တိန်နာများကဲ့သို့) Serverless သည် ကောင်းမွန်သောအနာဂတ်ရှိသော နည်းပညာတစ်ခုဖြစ်သည်။

ဤအကြောင်းအရာတွင်၊ ကျွန်ုပ်သည် Serverless ချဉ်းကပ်မှုပြဿနာကို ချောမွေ့စွာ ဆက်လက်တင်ပြလိုပါသည်။

လျှောက်လွှာဘက်မှ

2018 အတွက်၊ Serverless အသုံးပြုမှု ရာခိုင်နှုန်း တစ်ဆခွဲ တိုးလာတယ်။. ၎င်းတို့၏ ဝန်ဆောင်မှုများတွင် နည်းပညာကို အကောင်အထည်ဖော်ပြီးသော ကုမ္ပဏီများတွင် Twitter၊ PayPal၊ Netflix၊ T-Mobile၊ Coca-Cola ကဲ့သို့သော စျေးကွက်ဘီလူးကြီးများ ပါဝင်သည်။ တစ်ချိန်တည်းမှာပင်၊ Serverless သည် panacea မဟုတ်ဘဲ အချို့သောပြဿနာများကိုဖြေရှင်းရန် ကိရိယာတစ်ခုဖြစ်ကြောင်း သင်နားလည်ရန်လိုအပ်သည်-

• အရင်းအမြစ်များ ရပ်နားချိန်ကို လျှော့ချပါ။ ဖုန်းခေါ်ဆိုမှုအနည်းငယ်ရှိသော ဝန်ဆောင်မှုများအတွက် virtual machine ကို အမြဲမပြတ်ထားရှိရန် မလိုအပ်ပါ။
• ဒေတာပျံပေါ်တွင် စီမံဆောင်ရွက်ပါ။ ပုံများကိုချုံ့ပါ၊ နောက်ခံကိုဖြတ်ပါ၊ ဗီဒီယိုကုဒ်ကိုပြောင်းပါ၊ IoT အာရုံခံကိရိယာများနှင့်အလုပ်လုပ်ပါ၊ သင်္ချာဆိုင်ရာလုပ်ဆောင်ချက်များကိုလုပ်ဆောင်ပါ။
• အခြားဝန်ဆောင်မှုများနှင့်အတူ "ကော်" ။ အတွင်းပရိုဂရမ်များပါရှိသော Git repository၊ Slack တွင် Jira နှင့် ပြက္ခဒိန်ရှိ chat bot တို့။
• ပါရာစီတမော။ ဒီမှာ အနီးကပ်ကြည့်ရအောင်။

လူ 50 ကိုဆွဲဆောင်နိုင်သောဝန်ဆောင်မှုတစ်ခုရှိသည်ဆိုကြပါစို့။ သူ့အောက်မှာ အားနည်းတဲ့ hardware ပါတဲ့ virtual machine တစ်ခုရှိတယ်။ အခါအားလျော်စွာ၊ ဝန်ဆောင်မှုအပေါ်ဝန်ဆောင်ခသိသိသာသာတိုးလာသည်။ ဒါဆိုရင် အားနည်းတဲ့ hardware က ထိန်းနိုင်မှာ မဟုတ်ပါဘူး။

သင်သည် ဝန်ကို ဖြန့်ဝေပေးမည့် စနစ်တွင် ဟန်ချက်ညီသော စက်သုံးစက်ထက် ဟုဆိုနိုင်သည်။ ဤအဆင့်တွင်၊ ကျွန်ုပ်တို့သည် ဝန်အား တိကျစွာ ခန့်မှန်း၍မရသောကြောင့် အချို့သော အရင်းအမြစ်များကို "အရန်" တွင် လည်ပတ်နေပါသည်။ ပြီးတော့ ငါတို့က စက်ရပ်မှုအတွက် ပိုပေးတယ်။

ထိုသို့သောအခြေအနေမျိုးတွင်၊ ကျွန်ုပ်တို့သည် ပေါင်းစပ်ချဉ်းကပ်နည်းဖြင့် စနစ်အား အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်နိုင်သည်- ကျွန်ုပ်တို့သည် ဝန်ချိန်ခွင်လျှာနောက်ကွယ်တွင် virtual machine တစ်ခုကို ထားခဲ့ကာ လုပ်ဆောင်ချက်များဖြင့် Serverless Endpoint သို့ လင့်ခ်တစ်ခု ထည့်ထားသည်။ ဝန်သည် သတ်မှတ်ချက်ထက်ကျော်လွန်ပါက၊ ချိန်ခွင်လျှာသည် တောင်းဆိုမှုလုပ်ဆောင်ခြင်း၏ တစ်စိတ်တစ်ပိုင်းကို ကျော်လွန်သည့် လုပ်ဆောင်မှုဖြစ်ရပ်များကို စတင်သည်။

ထို့ကြောင့်၊ တောင်းဆိုချက်အများအပြားကို မကြာမကြာလုပ်ဆောင်ရန် လိုအပ်သောနေရာတွင် Serverless ကို အသုံးပြုနိုင်သည်။ ဤကိစ္စတွင်၊ လုပ်ဆောင်ချက်များစွာကို 15 မိနစ်ကြာလုပ်ဆောင်ခြင်းသည် virtual machine သို့မဟုတ် server ကိုအချိန်တိုင်းထိန်းသိမ်းထားခြင်းထက်ပိုမိုအကျိုးရှိသည်။

serverless computing ၏ အားသာချက်များအားလုံးဖြင့်၊ အကောင်အထည်မဖော်မီ၊ သင်သည် အပလီကေးရှင်းယုတ္တိကို ဦးစွာအကဲဖြတ်ပြီး သီးခြားကိစ္စရပ်တစ်ခုတွင် Serverless သည် မည်သည့်ပြဿနာများကို ဖြေရှင်းနိုင်သည်ကို နားလည်သင့်သည်။

Serverless နှင့် Selectel

Selectel မှာ ကျွန်တော်တို့ ရောက်နေပါပြီ။ Kubernetes နှင့် ရိုးရှင်းသော အလုပ် ကျွန်ုပ်တို့၏ control panel မှတဆင့်။ ယခု ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် FaaS ပလပ်ဖောင်းကို တည်ဆောက်နေပါသည်။ အဆင်ပြေပြေ ပြောင်းလွယ်ပြင်လွယ်ရှိသော အင်တာဖေ့စ်မှတဆင့် Serverless ကို အသုံးပြု၍ developer များအား ၎င်းတို့၏ ပြဿနာများကို ဖြေရှင်းနိုင်စေရန် ကျွန်ုပ်တို့ အလိုရှိသည်။

သင့်တွင် စံပြ FaaS ပလပ်ဖောင်းသည် မည်သည့်အရာဖြစ်သင့်သည်၊ သင့်ပရောဂျက်များတွင် Serverless ကိုမည်ကဲ့သို့အသုံးပြုလိုကြောင်း အကြံဥာဏ်များရှိပါက မှတ်ချက်များတွင် မျှဝေပါ။ ပလပ်ဖောင်းကို တီထွင်သောအခါတွင် သင်၏ဆန္ဒကို ထည့်သွင်းစဉ်းစားပါမည်။
 
ဆောင်းပါးတွင်အသုံးပြုသောပစ္စည်းများ

• Serverless အသုံးပြုမှု ရာခိုင်နှုန်းသည် တစ်ဆခွဲ တိုးလာသည် ( RightScale အပြည့်အစုံ အစီရင်ခံစာ )
• စတင်ချိန်မည်မျှအေးသည်ဖြစ်စေ အပလီကေးရှင်းဘာသာစကားပေါ်တွင်မူတည်သည်။

source: www.habr.com