Serverless ဆိုတာ ဘာလဲ။ Serverless Computing ကို ရိုးရှင်းစွာ ရှင်းပြချက်

Serverless ဆိုသည်မှာ ဆာဗာများကို ကိုယ်တိုင် တပ်ဆင်ခြင်း သို့မဟုတ် စီမံခြင်း မလုပ်ရသော code run နည်းလမ်း ဖြစ်သည်။ သင့် code ကို cloud provider သို့ ပေးလိုက်ပြီး ဝဘ် request၊ ဖိုင် upload၊ ငွေပေးချေမှု အကြောင်းကြားချက် ကဲ့သို့ တစ်စုံတစ်ခုက အစပျိုးမှသာ run ပြီး ထို့နောက် ရပ်သည်။ ပုံမှန်အားဖြင့် ပိတ်မည့် စက်အတွက်မဟုတ်ဘဲ code တကယ် run နေသည့် အချိန်အတွက် ငွေပေးရသည်။

AI ဖြင့် တည်ဆောက်သည့်အခါ serverless ဘာကြောင့် အရေးကြီးသလဲ

AI ဖြင့် အက်ပ်တည်ဆောက်ပြီး hosting ရွေးချယ်စရာများ သို့မဟုတ် code ကို ကြည့်သောအခါ "serverless function", "edge function" သို့မဟုတ် "cloud function" ကို တွေ့ရမည်။ Hosting platform များစွာက ၎င်းတို့ကို ပေးပြီး AI builder အချို့က backend များကို ဤနည်းဖြင့် deploy လုပ်သည်။ ပုံစံကို နားလည်ခြင်းက လက်တွေ့ မေးခွန်း သုံးခုကို ဖြေရှင်းရာတွင် ကူညီသည်:

• ကုန်ကျစရိတ်။ ဘယ်သူမှ မသုံးနေချိန်တွင် အက်ပ်က ငွေကုန်မလား။
• အမြန်နှုန်း။ အနည်းငယ် ငြိမ်ဆိတ်ပြီးနောက် ပထမ request က ဘာကြောင့် ပိုနှေးသလဲ။
• ကန့်သတ်ချက်များ။ ဘာကြောင့် ကြာရှည်သော အလုပ် (ကြီးမားသော report ထုတ်ခြင်း၊ ဗီဒီယို လုပ်ဆောင်ခြင်း) သည် timeout ဖြစ်သလဲ။

Serverless ဆိုသည်မှာ ဘာမဟုတ်သည်ကိုလည်း သိရန် အကျိုးရှိသည်: backend မရှိခြင်း မဟုတ်ပါ။ သင်သည် ဆာဗာ-ဘက် code ရှိနေဆဲ ဖြစ်ပြီး စက်များကို အခြားသူက run ပေးသည်သာ။ အခြေခံအတွက် ဆာဗာ ဆိုတာ ဘာလဲ ကို ကြည့်ပါ။

နေ့စဉ်ဘဝမှ ဥပမာ

ရိုးရာ ဆာဗာသည် ကား ပိုင်ဆိုင်ခြင်းနှင့် ဆင်တူသည်။ အမြဲရှိနေပြီး ချက်ချင်း သွားနိုင်သည်၊ သို့သော် မောင်းသည်ဖြစ်စေ မမောင်းသည်ဖြစ်စေ — အာမခံ၊ ရပ်နားခ၊ ပြုပြင်ထိန်းသိမ်းမှု — ငွေပေးရသည်။

Serverless သည် တက္ကစီခေါ်ခြင်းနှင့် ဆင်တူသည်။ သွားသော ခရီးအတွက်သာ ငွေပေးရသည်၊ လူတစ်ရာ တစ်ပြိုင်နက် ကားလိုအပ်လျှင် ကားတစ်ရာ ရောက်လာသည်။ သို့သော် ကားရောက်လာရန် တိုတိုစောင့်ရမည် (cold start)၊ ခရီးတစ်ခုစီ၏ အမြင့်ဆုံးကြာချိန် ရှိပြီး ယာဉ်မောင်းက သင့်ကို နောက်ဆုံးခရီးမှ မမှတ်မိပါ (function များသည် stateless ဖြစ်သည်)။

Serverless function အလုပ်လုပ်ပုံ

အသုံးအများဆုံး ပုံစံဖြစ်သော functions as a service တွင်:

1. Function ကို ရေးသည် — /api/bookings သို့ POST တစ်ခုကို ကိုင်တွယ်သော အသေးစား code အစိတ်အပိုင်း။
2. Deploy လုပ်သည်။ Provider က သိမ်းပြီး trigger တစ်ခုနှင့် ချိတ်သည်: URL၊ အချိန်ဇယား၊ storage တွင် ဖိုင်အသစ်၊ queue ရှိ message။
3. Event ရောက်လာသည်။ Provider က function ၏ ကော်ပီတစ်ခုကို စတင် (သို့မဟုတ် ပူနွေးနေသည်ကို ပြန်သုံး) run ပြီး ရလဒ်ကို ပြန်ပေးသည်။
4. အလိုအလျောက် အရွယ်ကြီးသည်။ Request တစ်ထောင် တစ်ပြိုင်နက် ရောက်လာလျှင် provider က ကော်ပီများစွာကို အပြိုင် run သည်၊ သင့်အကောင့် ကန့်သတ်ချက်အထိ။
5. အလုပ်မလုပ်ဘဲ နေသည်။ Traffic ရပ်သောအခါ ကော်ပီများ ပိတ်သည်။ ဘာမျှ run မနေလျှင် compute အတွက် ဘာမျှ မပေးရပါ။

JavaScript ဖြင့် serverless function သေးသေးလေးတစ်ခုသည် ဤသို့ ဖြစ်နိုင်သည်:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

ဆာဗာ စတင်ရန်၊ port ဖွင့်ရန် သို့မဟုတ် process ကို run ထားရန် code မလိုပါ။ Platform က ထိုအရာအားလုံးကို ကိုင်တွယ်သည်။

"Serverless" ကို အကျယ်ပြန့်စွာ အခြား managed service များအတွက်လည်း သုံးသည် — အလိုအလျောက် အရွယ်ကြီးပြီး အသုံးပြုသလောက် ငွေယူသော ဝန်ဆောင်မှုများ၊ ဥပမာ အလုပ်မလုပ်သောအခါ ခဏရပ်သော serverless database များ။

အဓိက ဝေါဟာရများ

လက်တွေ့ ဥပမာ: အသေးစား booking site

Yoga စတူဒီယို၏ booking site သည် အပတ်စဉ် တနင်္ဂနွေညနေ အချိန်ဇယားအသစ် တင်သည့်အချိန်တွင် traffic အများအပြား ရောက်ပြီး ကျန်ရက်များတွင် အနည်းငယ်သာ ရောက်သည်။

• အမြဲဖွင့်ထားသော ဆာဗာဖြင့် စတူဒီယိုသည် ၂၄/၇ စက်တစ်လုံးကို ပေးပြီး တနင်္ဂနွေညနေ အမြင့်ဆုံး traffic အတွက် အရွယ်ချိန်ထားရပြီး ကျန်အချိန်များတွင် အလုပ်မလုပ်ဘဲ နေသည်။
• Serverless function များဖြင့် GET /api/classes နှင့် POST /api/bookings သည် function များ ဖြစ်သည်။ တနင်္ဂနွေ၏ အလုပ်များသော အချိန်တွင် ကော်ပီများစွာ အလိုအလျောက် စတင်ပြီး၊ အေးဆေးသော ဗုဒ္ဓဟူးနေ့မနက်တွင် ဘာမျှ မ run ဘဲ ငွေပေးချေမှု နီးပါးသုည ဖြစ်သည်။

အားနည်းချက်များလည်း ပေါ်သည်။ ဗုဒ္ဓဟူးနေ့မနက် ဆိုက်ကို ပထမဆုံး ဖွင့်သူက cold start အတွက် အပိုအချိန် စောင့်ရနိုင်သည်။ Database က function ကော်ပီများ အများအပြားမှ တိုတောင်းသော connection များကို ကိုင်တွယ်ရမည်ဖြစ်ပြီး connection pooler လိုအပ်နိုင်သည်။ စတူဒီယိုက နောင်တွင် "အသင်းဝင်အားလုံး၏ နှစ်ပတ်လည် တက်ရောက်မှု PDF ထုတ်ပေးခြင်း" task ကို လိုချင်လျှင် function ၏ အချိန်ကန့်သတ်ချက်ကို ကျော်နိုင်ပြီး နေရာတစ်ခုခုတွင် run ရန် လိုနိုင်သည်။

Serverless သင့်တော်သည့်အခါနှင့် မသင့်တော်သည့်အခါ

အများဆုံး ဖြစ်တတ်သော အယူအဆမှားများ

• "Serverless ဆိုသည်မှာ backend မရှိခြင်း။" စီမံရန် ဆာဗာ မရှိခြင်း ဖြစ်သည်။ သင်သည် backend code ကို ရေးပြီး လုံခြုံအောင် ထားရမည်။
• "Serverless သည် အမြဲတမ်း ပိုစျေးသက်သာသည်။" ပမာဏနည်းလျှင် စျေးသက်သာသော်လည်း တစ်ခုချင်း request စျေးနှုန်းသည် ပမာဏမြင့်၍ တည်ငြိမ်လျှင် ပေါင်းလာနိုင်သည်။
• "Serverless သည် အဆုံးမရှိ scale လုပ်နိုင်သည်။" Platform များတွင် concurrency ကန့်သတ်ချက်များ ရှိပြီး သင့် database သည် function များထက် ပိုစောစွာ ပိတ်ဆို့ချက် ဖြစ်နိုင်သည်။
• "Function တွင် သိမ်းထားသော ဖိုင်များသည် နောက်တစ်ကြိမ်လည်း ရှိနေမည်။" Local storage သည် ယာယီဖြစ်သည်။ Database သို့မဟုတ် file storage ကို သုံးပါ။
• "Scale-to-zero သည် serverless နှင့် အတူတူပင်။" ဆက်စပ်သော်လည်း တူညီခြင်း မဟုတ်ပါ။ Platform အချို့က သင့်အက်ပ်ကို ပုံမှန် ဆာဗာအဖြစ် run ပြီး အလုပ်မလုပ်သောအခါ အိပ်ကာ နောက် request တွင် နိုးသည် — ဆင်တူသော အချွေတာမှုနှင့် ပထမ request နှောင့်နှေးမှု ရှိသော်လည်း request တစ်ခုချင်းစီ၏ function-style အချိန်ကန့်သတ်ချက် မရှိပါ။

AI builder အား ဘာတောင်းရမလဲ

• "ဤ backend သည် serverless function များအဖြစ် run မလား၊ သို့မဟုတ် အမြဲဖွင့်ထားသော သို့မဟုတ် အိပ်ရန် ဆာဗာအဖြစ် run မလား။ ၎င်းက ကုန်ကျစရိတ်အတွက် ဘာကို ဆိုလိုသလဲ။"
• "လုပ်ငန်းအချို့သည် platform ၏ အချိန်ကန့်သတ်ချက်ထက် ကြာနိုင်ပါသလား။ ဟုတ်လျှင် ၎င်းတို့ကို ဘယ်လို ကိုင်တွယ်မလဲ။"
• "ဆက်ရှိနေရမည့် အရာအားလုံးကို memory သို့မဟုတ် local ဖိုင်များတွင် မထားဘဲ database သို့မဟုတ် file storage တွင် ထားပါ။"
• "Function အများအပြား တစ်ပြိုင်နက် run သောအခါ database connection များကို ဘယ်လို စီမံမလဲ။"
• "အက်ပ် ငြိမ်သက်နေပြီးနောက် ပထမ request ၏ နှောင့်နှေးချိန်က ဘယ်လောက်လဲ။"

Mythex တွင် အက်ပ်များ hosting

Mythex သည် ၎င်း၏ hosting ကို serverless function များဟု ဖော်ပြခြင်း မရှိပါ။ Publish လုပ်သောအခါ သင့်အက်ပ်သည် Mythex က စီမံသော ပုံမှန် web app သို့မဟုတ် container အဖြစ် run သည် — hosting တပ်ဆင်ရန် မလိုပါ။ ၎င်းသည် scale-to-zero ဖြစ်သည်: publish လုပ်ထားသော အက်ပ်များနှင့် database များသည် အလုပ်မလုပ်သောအခါ အိပ်ပြီး နောက်ဆိုက်ဝင်သည့်အခါ နိုးသည်၊ အိပ်နေသော အက်ပ်သည် compute အတွက် ဘာမျှ မကုန်ကျပါ၊ traffic များသောအခါသာ အပို စက်များ စတင်သည် (Pro တွင် service တစ်ခုလျှင် အများဆုံး ၃ လုံး)။ ပူးတွဲထားသော Postgres database သည်လည်း အလုပ်မလုပ်သော ၅ မိနစ်ကြာပါက အိပ်ပြီး နိုးနေချိန်အတွက်သာ ငွေယူသည်။ ထို့ကြောင့် "အသုံးပြုသလောက် ပေးခြင်း" အကျိုးကို ရရှိပြီး ငြိမ်သက်ချိန်ပြီးနောက် ပထမ request နှောင့်နှေးမှု အမျိုးအစားတူ ရှိသည်။ Docs ရှိ hosting limits ကို ကြည့်ပါ၊ နှင့် ကျွန်ုပ်တို့၏ web hosting နှင့် hosting ကုန်ကျစရိတ် လျှော့ချနည်း လမ်းညွှန်များ။

မေးခွန်းများ