Thuta Learning
Cloud Providers & Platforms
ExercisesDevOps & Toolsintermediate

လေ့ကျင့်ခန်း - Platform အမျိုးအစားအလိုက် ပြဿနာရှာခြင်း

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • လေ့ကျင့်ခန်း - Platform အမျိုးအစားအလိုက် ပြဿနာရှာခြင်း concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram/table ကို ဖတ်ပြီး platform/provider category တွေ ဘယ်လို ကွာခြားသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် project အတွက် ဘယ် platform category ကို ဘယ်လို ရွေးချယ်သင့်သလဲ ရှင်းပြနိုင်ရန်

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

Cloud & Deployment ရဲ့ troubleshooting လေ့ကျင့်ခန်းက Build failure, Runtime, DNS, HTTPS, Error, Database, API ဆိုပြီး linear flow တစ်ခုတည်းကို လိုက်ခဲ့ပါတယ်။ အဲဒီ flow က Deployment target တစ်ခုတည်းကိုသာ ယူဆထားပါတယ်။

Major Cloud, PaaS, BaaS ကြားက ရွေးချယ်ရတော့မယ်ဆိုရင် ပြဿနာစတင်ချက်တူတူပဲဖြစ်ပေမယ့် Platform Type တစ်ခုစီက Stack Layer မတူညီတာကို ဖုံးကွယ်/ဖော်ပြထားလို့ ပထမစစ်ဆေးရမယ့်အချက် လုံးဝကွဲပြားနိုင်ပါတယ်။

Instinct မှန်တယ်၊ Platform မှားတယ်

'Security group ကို စစ်ပါ' ဆိုတာက Major Cloud အတွက်မှန်ပေမယ့် VPC concept မရှိတဲ့ BaaS မှာ အဓိပ္ပာယ်မရှိပါဘူး။ ဆန့်ကျင်ဘက်၊ 'API key type ကို စစ်ပါ' ဆိုတာက BaaS diagnostic step ပထမတန်းစားဖြစ်ပေမယ့် Raw VM မှာ သိပ်မသက်ဆိုင်ပါဘူး။

ပြဿနာ အမျိုးအစားPlatform Type အလိုက် ဘာကွဲလဲ
Database connectionMajor Cloud - Network/VPC ကို ကိုယ်တိုင်ထိန်းချုပ်ရ; PaaS - Platform ရဲ့ Connection config/Add-on link; BaaS - Key type နဲ့ Row-Level Security ။
Environment variableMajor Cloud - variable ကို ဘယ်နေရာမှာ set လုပ်ခဲ့ပြီး redeploy/restart လိုလား; PaaS - Dashboard ရဲ့ Variable list; BaaS - Client bundle ဘက်လား Server ဘက်လား ။
Deployed but errorsMajor Cloud - Instance application log; PaaS - Dashboard ရဲ့ Build/Runtime log; BaaS - Function/API log နဲ့ Client SDK key ။

ဒီနေရာမှာ လေ့ကျင့်နေတဲ့ Skill က Fix တစ်ခုမလုပ်ခင် Platform Type ကို ဦးစွာ ခွဲခြားသိမှတ်တာပါ၊ Flowchart ရှည်ရှည်တစ်ခုကို အလွတ်ကျက်တာ မဟုတ်ပါဘူး။

text
SAME PROBLEM, DIFFERENT FIRST CHECK
-----------------------------------
App can't connect to the database
                |
   +------------+----------------+
   |                             |
MAJOR CLOUD      PaaS                BaaS
(AWS/GCP/Azure) (Railway/Render) (Supabase/Firebase)
   |                |                |
Check VPC /      Check platform's  Check API key
security group   env vars + confirm  type (anon vs
+ DB connection  DB add-on is       service) + RLS
settings         linked to service  rules blocking it

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

အောက်က firstDiagnosticStep function ဟာ အထက်က reasoning ကို run နိုင်တဲ့ lookup table တစ်ခုအဖြစ် ထုပ်ပိုးထားပါတယ်။ problemType နဲ့ platformType ကို လက်ခံပြီး အဲဒီ combination အတွက် ပထမဆုံးစစ်ဆေးချက်ကို ပြန်ပေးပါတယ်။

db-connection နဲ့ major-cloud အတွက် Networking/Connection-settings ကို ပြန်ပေးပေမယ့် baas ပေါ်က ပြဿနာတူတူအတွက်တော့ API key type နဲ့ Row-Level Security အကြောင်း လုံးဝကွဲပြားတဲ့ အဖြေတစ်ခု ပြန်ရပါတယ်၊ Network layer စစ်ဆေးစရာ လုံးဝမရှိလို့ပါ။

Environment-variable case မှာလည်း PaaS ဆို Dashboard variable list ကို၊ BaaS ဆို Variable ဟာ Client bundle ဘက်လား Server ဘက်လား ဆိုတာကို ဦးစွာစစ်ရပါတယ်။

Function ဘာမှမလုပ်ပေးဘူး

Function က ပြဿနာကို ပြင်ပေးမယ်လို့ လုံးဝ မပြောပါဘူး - ရှေ့မှာရှိတဲ့ Platform Type အတွက် အမြန်ဆုံး ပထမဆုံးစစ်ဆေးချက်ကိုသာ ညွှန်ပြပေးတာပါ။

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

javascript
function firstDiagnosticStep(problemType, platformType) {
  const table = {
    "db-connection": {
      "major-cloud": "Check VPC/security group rules and the managed database's connection settings (host, port, SSL mode).",
      "paas": "Check the platform's environment variable / connection string config and confirm the database add-on is linked to the service.",
      "baas": "Check whether you're using the correct API key type (anon/public vs service/secret) and whether Row-Level Security rules are blocking the query."
    },
    "env-var-not-applied": {
      "major-cloud": "Check whether the variable was set in the right place (task definition, launch config, or instance user-data) and whether a redeploy/restart is needed to pick it up.",
      "paas": "Check the platform dashboard's environment variable list for typos and confirm you triggered a redeploy after adding it.",
      "baas": "Check whether the variable belongs to the client bundle (must be prefixed for the framework) or is server-only, since BaaS projects often mix both."
    },
    "deployed-but-errors": {
      "major-cloud": "Check the compute instance's application logs (CloudWatch, Cloud Logging, or equivalent) for a stack trace.",
      "paas": "Check the platform's build and runtime logs in its dashboard for the first error line.",
      "baas": "Check the BaaS dashboard's function/API logs and confirm the client SDK is initialized with the correct project keys."
    }
  };

  const step = table[problemType] && table[problemType][platformType];
  return step || "Unknown combination - check the problem type and platform type spelling.";
}

console.log(firstDiagnosticStep("db-connection", "major-cloud"));
console.log(firstDiagnosticStep("db-connection", "baas"));
console.log(firstDiagnosticStep("env-var-not-applied", "paas"));
console.log(firstDiagnosticStep("deployed-but-errors", "baas"));
console.log(firstDiagnosticStep("db-connection", "azure-vm"));
You should see
Console output (line ၅ လိုင်း) - (၁) Major Cloud အတွက် VPC/security group + connection settings စစ်ဖို့ message; (၂) BaaS အတွက် API key type + RLS စစ်ဖို့ message; (၃) PaaS အတွက် Dashboard variable list စစ်ဖို့ message; (၄) BaaS အတွက် Function/API log စစ်ဖို့ message; (၅) 'azure-vm' ဆိုတဲ့ မသိတဲ့ platformType အတွက် 'Unknown combination - check the problem type and platform type spelling.' ။

၅ မိနစ် စမ်းကြည့်

သင့် Team က App တစ်ခုတည်းကို နေရာနှစ်ခု - Google Cloud ပေါ်ရှိ Kubernetes cluster တစ်ခုနဲ့ Railway service တစ်ခု - ကို Deploy လုပ်ထားပါတယ်။ Deploy ပြီးနောက် Railway version က Request တိုင်းအတွက် 500 error ပြန်ပေးနေပေမယ့် GKE version ကတော့ ပုံမှန် အလုပ်လုပ်နေပါတယ်။ Codebase တူတူသုံးထားပြီး Environment variable တွေလည်း တူတူ set ထားတယ်လို့ ယူဆထားပါတယ်။ Railway ဘက်မှာ ပထမဆုံး ဘာကို စစ်ဆေးမလဲ၊ GKE ဘက်မှာ စစ်ဆေးမယ့်အချက်နဲ့ ဘာကြောင့်ကွဲပြားနိုင်လဲ ဆိုတာကို Dashboard ကို မသွားမီ ကိုယ်ပိုင် Reasoning အနေနဲ့ ရေးချပါ။

သတိလေးတစ်ချက်

Platform တစ်ခုပေါ်မှာ အလုပ်ဖြစ်ခဲ့တဲ့ Fix ကို Platform Type တခြားဆီမှာ ဘာဟာဗျူ ဖော်ပြထားလဲ ပြန်မစစ်ဘဲ တိုက်ရိုက် သယ်သွင်းသုံးခြင်း။

Platform-level layer (Network, Env var scope, Key type) ဘယ်ဟာက ပြဿနာအမှန် ဖြစ်စေတယ်ဆိုတာ မသေချာမီ Application code ကို အရင်ပြောင်းခြင်း။

Supabase Docs: Row Level SecurityCloud Providers & Platforms

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • Platform တစ်ခုပေါ်မှာ အလုပ်ဖြစ်ခဲ့တဲ့ Fix ကို Platform Type တခြားဆီမှာ ဘာဟာဗျူ ဖော်ပြထားလဲ ပြန်မစစ်ဘဲ တိုက်ရိုက် သယ်သွင်းသုံးခြင်း။
  • Platform-level layer (Network, Env var scope, Key type) ဘယ်ဟာက ပြဿနာအမှန် ဖြစ်စေတယ်ဆိုတာ မသေချာမီ Application code ကို အရင်ပြောင်းခြင်း။
  • ဒီ course က provider/platform landscape ကို comparison-level မှာသာ သင်ပေးပါတယ် — AWS, Docker, CI/CD, Firebase, deployment fundamentals ကို နက်နက်ရှိုင်းရှိုင်း လေ့လာချင်ရင် AWS Fundamentals, Docker, CI/CD, Firebase, Cloud & Deployment tutorial တွေဆီ ဆက်သွားပါ။

လေ့ကျင့်ခန်း

သင့် Team က App တစ်ခုတည်းကို နေရာနှစ်ခု - Google Cloud ပေါ်ရှိ Kubernetes cluster တစ်ခုနဲ့ Railway service တစ်ခု - ကို Deploy လုပ်ထားပါတယ်။ Deploy ပြီးနောက် Railway version က Request တိုင်းအတွက် 500 error ပြန်ပေးနေပေမယ့် GKE version ကတော့ ပုံမှန် အလုပ်လုပ်နေပါတယ်။ Codebase တူတူသုံးထားပြီး Environment variable တွေလည်း တူတူ set ထားတယ်လို့ ယူဆထားပါတယ်။ Railway ဘက်မှာ ပထမဆုံး ဘာကို စစ်ဆေးမလဲ၊ GKE ဘက်မှာ စစ်ဆေးမယ့်အချက်နဲ့ ဘာကြောင့်ကွဲပြားနိုင်လဲ ဆိုတာကို Dashboard ကို မသွားမီ ကိုယ်ပိုင် Reasoning အနေနဲ့ ရေးချပါ။

You'll know it worked when: Console output (line ၅ လိုင်း) - (၁) Major Cloud အတွက် VPC/security group + connection settings စစ်ဖို့ message; (၂) BaaS အတွက် API key type + RLS စစ်ဖို့ message; (၃) PaaS အတွက် Dashboard variable list စစ်ဖို့ message; (၄) BaaS အတွက် Function/API log စစ်ဖို့ message; (၅) 'azure-vm' ဆိုတဲ့ မသိတဲ့ platformType အတွက် 'Unknown combination - check the problem type and platform type spelling.' ။

လေ့ကျင့်ခန်း - Platform အမျိုးအစားအလိုက် ပြဿနာရှာခြင်း | Thuta Learning