Serverless နှင့် Edge Computing

နားလည်ထားရမယ့် အချက်

"Serverless" ဆိုတာ လှည့်ဖြားနေတဲ့ နာမည်တစ်ခုပါ — server တွေက ရှိနေဆဲ၊ code ကိုလည်း run ပေးနေဆဲပါ။ ပြောင်းလဲသွားတာက ဘယ်သူက ကိုင်တွယ်လဲဆိုတဲ့ အချက်ပါ — provision, patch, scale တွေကို သင့်အစား platform က လုပ်ပေးပါတယ်။

Developer က function တစ်ခု ပေးလိုက်ရုံပါ၊ platform က on demand run ပေးပြီး instance ကို automatic scale လုပ်ကာ idle server time မဟုတ်ပဲ တကယ့် usage အလိုက် bill ချပါတယ်။ ဒီ pay-per-use model က serverless ရဲ့ appeal အကြီးဆုံးတစ်ခုပါ။

• Cold start – function တစ်ခု idle နေပြီးနောက် ပထမဆုံးအကြိမ် run တဲ့အခါ platform က initialize လုပ်နေစဉ် ကြုံရတဲ့ delay
• Execution time နဲ့ resource limit တွေရှိပေမယ့် provider အလိုက်နဲ့ အချိန်နဲ့ ပြောင်းနေလို့ number memorize မလုပ်ပဲ documentation လက်ရှိကို စစ်ပါ

Edge computing ကတော့ code ကို central location တစ်ခုတည်းမှာမဟုတ်ပဲ user တွေနဲ့ physically ပိုနီးတဲ့ location များစွာမှာ run ပေးလို့ network distance ကို ဖြတ်တောက်ပေးပါတယ် — central database တစ်ခုတည်းဆီ round trip နှေးနေတုန်း ဆက်စောင့်နေရရင်တော့ workload အားလုံး အကျိုးမရှိနိုင်ပါ။

SERVERLESS AND EDGE COMPUTING
-----------------------------
Request --> [ Function runs on-demand ] --> Response
             (platform manages the servers)

TRADITIONAL SERVER VS EDGE LOCATION
-------------------------------------
User (Yangon) ----------------> Server (far away region)
                 (long trip, slower)

User (Yangon) --> Edge Location (nearby) --> Response
                 (short trip, often faster)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Workload တစ်ခုက bursty ဒါမှမဟုတ် server တစ်ခုကို အဆက်မပြတ် run ထားစရာမလိုအောင် ရှိရင် serverless ကို ရွေးပါ — webhook event တစ်ခါတစ်ရံ ကိုင်တွယ်တာ၊ image resize လုပ်တာ၊ တစ်နေ့တစ်ကြိမ် task run တာစသည်။

Persistent connection၊ အချိန်ကြာကြာ run ရမယ့် job၊ request တိုင်းအတွက် low latency လိုအပ်တဲ့ ကိစ္စတွေအတွက်တော့ အသင့်တော်နည်းပါတယ်၊ ဘာလို့ဆိုတော့ cold start က always-on server မှာ ဘယ်တော့မှ မရှိမယ့် delay တစ်ခါတစ်ရံ ဖြစ်စေလို့ပါ။

Request တစ်ခုကို အနီးအနားက ရရှိနိုင်တာနဲ့ပဲ ဖြေရှင်းလို့ရရင် edge computing ကို ရွေးထိုက်ပါတယ် — cache လုပ်ထားတဲ့ response တစ်ခု၊ auth header စစ်ဆေးခြင်းလိုမျိုး။ Call တိုင်းမှာ central database တစ်ခုတည်းကနေ data အသစ်ဖတ်ရမယ့် logic အတွက်ကတော့ အကျိုးနည်းပါတယ်။

ဒီ lesson က concept level မှာသာ တမင်ထားထားပါတယ် — Lambda function တစ်ခု တကယ်ရေး၊ deploy လုပ်၊ ချိတ်ဆက်တာကို ဒီဆိုက်ရဲ့ AWS Fundamentals tutorial မှာ လက်တွေ့ ဆွေးနွေးထားပါတယ်။

• Serverless ဆိုတာ server မရှိဘူးလို့ မဆိုလိုပါ — platform က သင့်အစား ကိုင်တွယ်ပေးတာကို ဆိုလိုတာပါ။
• Pay-per-use pricing နဲ့ automatic scaling တွေမှာ cold start၊ execution limit လို tradeoff အစစ်တွေ ပါလာပါတယ်။
• Edge computing က locally ရရှိနိုင်တဲ့ content အတွက် latency လျှော့ပေးပေမယ့် distant database လိုအပ်တဲ့ logic အတွက်တော့ မဟုတ်ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

// Illustrative only: shows the SHAPE of a serverless function handler,
// not a real deployed function on any specific platform.
function handler(request) {
  return { status: 200, body: `Hello, ${request.name}!` };
}

console.log(handler({ name: "Aye" }));
console.log(handler({ name: "Ko Ko" }));

{ status: 200, body: 'Hello, Aye!' }
{ status: 200, body: 'Hello, Ko Ko!' }
(handler() ကို data ကွဲပြားစွာနဲ့ ခေါ်တိုင်း response အသစ်ကို ပြန်ပေးတာကို သတိပြုပါ — ဒါက function shape ကိုသာ ပြသတာဖြစ်ပြီး တကယ်ဆွဲကြိုးထားတဲ့ platform မဟုတ်ပါ)

Serverless Computing — Wikipedia — Cloud & Deployment