IaaS, PaaS, SaaS আর FaaS — কে কী সামলায় আর shared responsibility

১ · “আমরা cloud-এ আছি” — তার মানে কী?

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। এক দুপুরে একজন কর্মীর ভুলে order-এর table মুছে গেল। দলের প্রধান শান্তভাবে বললেন, “চিন্তা নেই, আমরা তো cloud-এ আছি।” কিন্তু খোঁজ নিয়ে দেখা গেল, কেউ কখনো backup চালু করেননি। সবাই ভেবেছিলেন, কাজটি cloud-এর।

এই ভুল বোঝাবুঝি খুব সাধারণ। কারণ “cloud” একটিমাত্র জিনিস নয়। আগের পর্বে দেখেছেন, cloud মানে প্রয়োজনমতো ভাড়া নেওয়া computing. কিন্তু ভাড়ার মধ্যে কতটুকু আছে, সেটি আপনি কী ভাড়া নিচ্ছেন তার ওপর নির্ভর করে। মেসের একটি ঘর ভাড়া নিলে রান্না আপনার; হোটেলে উঠলে রান্না হোটেলের। দুটোই ভাড়া, কিন্তু কাজের ভাগ আলাদা।

Cloud-এ এই ভাগটির নাম service model: provider কতটুকু সামলাবে আর আপনি কতটুকু। বোঝার সবচেয়ে সহজ পথ রান্না।

মিলটি কোথায় থামে, সেটিও জানা দরকার। রেস্তোরাঁয় গেলেও আপনার খাবারে অ্যালার্জি আছে কি না, সেটি আপনাকেই জানাতে হয়; মানিব্যাগ টেবিলে ফেলে গেলে দায় আপনার। Cloud-এও সবচেয়ে ওপরের model-এ কিছু দায় আপনার থেকে যায়। এই কথাটিই পর্বের কেন্দ্র।

FaaS-কে ভাবতে পারেন প্লেট-প্রতি ক্যাটারিং হিসেবে: বাবুর্চি বসে থাকলে বিল নেই, যত প্লেট তত বিল। আর CaaS হলো ভাড়া করা রান্নাঘরে নিজের রেসিপি আর মসলা বাক্সে বেঁধে নিয়ে যাওয়া, চুলা জ্বালানোর কাজটি রান্নাঘরের লোক করেন।

২ · দায়িত্বের স্তূপ — আটটি স্তর, ছয়টি model

যেকোনো অনলাইন app চলতে হলে নিচ থেকে ওপরে আটটি স্তর লাগে। প্রথমে স্তরগুলো চিনে নিন:

• Network, storage, servers: তার, switch, disk আর আসল কম্পিউটার। Data center-এর হার্ডওয়্যার।
• Virtualization: একটি বড় server-কে কয়েকটি ছোট virtual machine-এ ভাগ করার স্তর। এটি চালায় hypervisor নামের software.
• OS: Linux বা Windows, যার ওপর সব চলে।
• Runtime: আপনার কোড চালানোর পরিবেশ, যেমন Node.js, Python, JVM. অনেক ছকে এখানে middleware আলাদা স্তর থাকে; আমরা দুটিকে এক ঘরে রাখছি।
• Data: আপনার ব্যবহারকারীর তথ্য।
• Application: আপনার কোড আর তার library.

নিচের stepper-এ model ধরে ধরে এগিয়ে যান। প্রতি ধাপে একটি কলাম চিহ্নিত হবে। খেয়াল করুন, কমলা ঘর কীভাবে নিচ থেকে ওপরে সরে যাচ্ছে। এই সরে যাওয়াটিই পুরো পর্বের সারকথা।

৩ · ছয়টি model কাছ থেকে — AWS, Azure আর Google Cloud-এ

নিচের টেবিলে তিন provider-এর পরিচিত service দেওয়া হলো। নাম মুখস্থ করার দরকার নেই; প্রথমে ঘরটি চিনুন, নামটি পরে আসবে। নাম সময়ের সাথে বদলায়, তাই provider-এর সাম্প্রতিক docs দেখে নেবেন।

৪ · “X as a Service”-এর ভিড় আর NIST-এর তিনটি model

২০১১ সালে আমেরিকার মান সংস্থা NIST তাদের SP 800-145 দলিলে (লেখক Peter Mell ও Timothy Grance) মাত্র তিনটি service model দিয়েছিল: SaaS, PaaS, IaaS. পরীক্ষায় “NIST-এর মতে service model কয়টি” জিজ্ঞেস করলে উত্তর তিন। CaaS আর FaaS সেখানে নেই, কারণ ২০১৩ সালে Docker আর ২০১৪ সালে AWS Lambda আসার আগেই দলিলটি লেখা।

তাহলে কি NIST ভুল? না। নতুন শব্দগুলো তিনটি ঘরের মাঝের জায়গাকে আরও সূক্ষ্মভাবে ভাগ করে। CaaS বসে IaaS আর PaaS-এর মাঝে; FaaS-কে অনেকে PaaS-এর একটি বিশেষ রূপ বলেন। এগুলো শিল্পের ব্যবহারিক শব্দ, কোনো এক কর্তৃপক্ষের সংজ্ঞা নয়।

এর পর শব্দের বন্যা এসেছে। DBaaS (Database as a Service) সবচেয়ে কাজের: database engine provider চালায়, আপনি schema, query আর ডেটা সামলান। এটি মূলত ডেটাবেসের জন্য PaaS, বিস্তারিত পর্ব ২২-এ, আর তত্ত্ব আছে DBMS কোর্সের cloud database পর্বে।

শব্দের ভিড়ে না হারিয়ে দুটি প্রশ্ন করুন: “কোন স্তর পর্যন্ত provider সামলাচ্ছে?” আর “এই সংক্ষিপ্ত রূপটি লেখক কোন অর্থে ব্যবহার করছেন?”

Serverless শব্দটিও এখানে গোলমাল বাধায়। FaaS একটি নির্দিষ্ট model. Serverless একটি বড় ধারণা: server-এর সংখ্যা ভাবতে হয় না, ব্যবহার অনুযায়ী বিল, শূন্যে নামতে পারে। FaaS serverless-এর উদাহরণ, কিন্তু object storage বা কিছু serverless database-ও এই দলে পড়ে। আর server অবশ্যই আছে; শুধু আপনি সেগুলো দেখেন না।

৫ · Shared responsibility — কার দায় কোথায় শেষ

স্তরের ছক বলে কে চালায়। নিরাপত্তার ক্ষেত্রে একই কথাকে বলা হয় shared responsibility model. AWS কথাটি দুটি বাক্যাংশে বলে: provider সামলায় security of the cloud (data center-এর দরজা, হার্ডওয়্যার, hypervisor), আর আপনি সামলান security in the cloud (আপনার ডেটা, অনুমতি, সেটিং)। Azure আর Google Cloud-এর docs-এও ভাগটি একই রকম, শব্দ একটু আলাদা।

রেখা ওপরে উঠলে provider-এর অংশ বাড়ে, কিন্তু তিনটি জিনিস প্রায় কখনোই সরে না।

নিচের টেবিলে সবচেয়ে সাধারণ ভুল ধারণাগুলো দেখুন। শর্ত provider আর পণ্যভেদে আলাদা, তাই নিজের চুক্তি আর docs মিলিয়ে নিতে হবে।

এবার কথাটি হিসাবে দেখি। নিচের ছোট calculator-এ MODEL বদলে “চালিয়ে দেখুন” চাপুন। এটি আগের ছকটিই কোডে রেখে বলে দেয়, ঐ model-এ আপনাকে কী কী patch করতে হবে। Patch মানে ত্রুটি সারানোর আপডেট।

// Responsibility calculator. Change MODEL, then press Run.
const MODEL = "paas";   // onprem | iaas | caas | paas | faas | saas
// One letter per layer: Y = you, S = shared, P = provider.
const LAYERS = ["network", "storage", "servers", "virtualization",
                "os", "runtime", "data", "application"];
const WHO = { onprem: "YYYYYYYY", iaas: "PPPPYYYY", caas: "PPPPSYYY",
              paas:   "PPPPPSYY", faas: "PPPPPSYY", saas: "PPPPPPYP" };
const PATCH = {
  network: "switch, router and firewall firmware",
  storage: "disk and storage controller firmware",
  servers: "BIOS and server firmware",
  virtualization: "hypervisor",
  os: "OS and kernel",
  runtime: "language runtime and web server",
  application: "your code and its libraries",     // data is protected, not patched
};
const SHARED = {
  os: "node OS: you roll out new node images, unless the provider runs the nodes",
  runtime: "runtime: provider patches it, you leave versions near end of support",
};
const ALWAYS = ["identity and access", "backups you have test-restored",
                "settings you choose (public or private, encryption)"];
const list = (m, ch) => LAYERS.filter((l, i) => WHO[m][i] === ch && PATCH[l]);
function report(m) {
  console.log(`MODEL: ${m}\nYOU patch:`);
  const mine = list(m, "Y");
  (mine.length ? mine.map(l => PATCH[l]) : ["(nothing)"]).forEach(x => console.log("  - " + x));
  console.log("SHARED:");
  const both = list(m, "S");
  (both.length ? both.map(l => SHARED[l]) : ["(nothing)"]).forEach(x => console.log("  - " + x));
  console.log(`PROVIDER patches ${list(m, "P").length} of 7 patchable layers`);
  console.log("ALWAYS yours: " + ALWAYS.join("; "));
}
report(MODEL);

৬ · একই ঘটনা, ভিন্ন model — দুটি incident

তত্ত্ব পরীক্ষা হয় খারাপ দিনে। প্রথম ঘটনা: সোমবার সকালে Linux kernel-এর একটি গুরুতর নিরাপত্তা ত্রুটি প্রকাশিত হলো, patch-ও বেরিয়েছে। কাল্পনিক অনলাইন বাজার অ্যাপটি ৩টি server-এ চলে। Model বদলে বদলে দেখুন, আজ কার ফোন বাজবে।

দ্বিতীয় ঘটনাটি আরও শিক্ষণীয়। মঙ্গলবার দুপুর ২টায় একজন কর্মী production-এ ভুলে DROP TABLE orders চালালেন। অ্যাপে ঘণ্টায় গড়ে ৩০টি order আসে (ধরে নেওয়া সংখ্যা), আর শেষ পুরো backup রাত ২টার। অর্থাৎ শুধু সেই backup-এ ফিরলে ১২ ঘণ্টা × ৩০ = ৩৬০টি order হারাবে।

৭ · নিয়ন্ত্রণ, গতি, খরচ, lock-in — কীভাবে বেছে নেবেন

কোনো model সবচেয়ে ভালো নয়। প্রতিটি একটি জিনিস দিয়ে আরেকটি কেনে। Lock-in মানে অন্য provider-এ সরে যাওয়ার খরচ ও কষ্ট।

খরচ শুধু বিলের অঙ্ক নয়। Server পাহারা দিতে মানুষের যে সময় যায়, তার দামও ধরতে হয়। একটি সহজ হিসাব দেখি, যেখানে সব দাম ধরে নেওয়া গোল সংখ্যা, আসল দাম নয়: ঘণ্টায় ops কাজের খরচ $১০। VM-এর বিল মাসে $৪০ আর কাজ ১২ ঘণ্টা; PaaS-এর বিল $৭০ আর কাজ ৩ ঘণ্টা; FaaS-এ প্রতি ১০ লাখ অনুরোধে $১ আর কাজ ১ ঘণ্টা।

// Monthly cost = cloud bill + people's time. ALL prices are ASSUMED round numbers.
const RATE = 10;                       // assumed cost of one hour of ops work ($)
const PLAN = [
  { name: "VM",   bill: () => 40,    hours: 12 },
  { name: "PaaS", bill: () => 70,    hours: 3 },
  { name: "FaaS", bill: mil => mil,  hours: 1 },   // assumed $1 per million requests
];
const total = (p, mil) => p.bill(mil) + p.hours * RATE;
console.log("million req |   VM | PaaS | FaaS | cheapest");
for (const mil of [1, 10, 50, 90, 150, 200]) {
  const rows = PLAN.map(p => ({ name: p.name, cost: total(p, mil) }));
  const low = Math.min(...rows.map(r => r.cost));
  const best = rows.filter(r => r.cost === low).map(r => r.name).join(" = ");
  const cells = rows.map(r => String(r.cost).padStart(4)).join(" | ");
  console.log(`${String(mil).padStart(11)} | ${cells} | ${best}`);
}
const fixedPaas = total(PLAN[1], 0), faasBase = PLAN[2].hours * RATE;
console.log(`FaaS = PaaS at ${fixedPaas - faasBase} million requests a month`);

বাছাইয়ের নিয়ম: ওপর থেকে নিচে নামুন

একটি কাজের নিয়ম হলো, সবচেয়ে ওপরের model থেকে শুরু করে প্রতিটির জন্য জিজ্ঞেস করা, “এটি কেন চলবে না?” স্পষ্ট কারণ পেলে তবেই এক ধাপ নিচে নামা। কারণ হতে পারে:

1. কাজটি কি সবার মতোই? ইমেইল, বেতন, হিসাব আপনার ব্যবসার বিশেষত্ব নয়। SaaS নিন।
2. কাজটি কি ছোট আর হঠাৎ আসে? FaaS মানায়। অনেকক্ষণ চলা কাজ বা স্থায়ী connection মানায় না।
3. সাধারণ web app কি? PaaS দিয়ে শুরু করুন।
4. অনেকগুলো service আর container-এ অভ্যস্ত দল আছে? CaaS বিবেচনা করুন।
5. বিশেষ OS, kernel module বা নির্দিষ্ট OS-এ বাঁধা license-এর software লাগে? IaaS.
6. আইন বা হার্ডওয়্যারের কারণে ডেটা নিজের জায়গায় রাখতে হবে? On-premises বা private cloud; পর্ব ০৩ দেখুন। বাংলাদেশে কোন ডেটার জন্য কী নিয়ম, তা বদলাতে পারে; নির্ভরযোগ্য আইনি পরামর্শ ও সর্বশেষ নীতিমালা দেখে নেবেন।

নিচের helper ঠিক এই পদ্ধতিতে চলে। শর্ত ভাঙলে model বাদ যায়, যা বাকি থাকে তার সবচেয়ে ওপরেরটি নেওয়া হয়। choose(...) লাইনগুলো বদলে নিজের প্রকল্প দিয়ে চালান।

// Decision helper: remove models that break a requirement,
// then take the HIGHEST model left (least work for you).
const ORDER = ["saas", "faas", "paas", "caas", "iaas", "onprem"];
// keep = the value that lets a requirement pass; any other value fires the rule.
const RULES = [
  { need: "commodity",  keep: true,  drop: ["saas"], why: "no ready product does this job" },
  { need: "longTask",   keep: false, drop: ["faas"], why: "runs past a function time limit" },
  { need: "steadyHigh", keep: false, drop: ["faas"], why: "steady heavy load, per-call billing costs more" },
  { need: "osControl",  keep: false, drop: ["saas", "faas", "paas", "caas"],
    why: "needs its own OS agent or kernel module" },
  { need: "noOpsTeam",  keep: false, drop: ["caas", "iaas", "onprem"],
    why: "nobody to run nodes or patch an OS" },
  { need: "onSiteOnly", keep: false, drop: ["saas", "faas", "paas", "caas", "iaas"],
    why: "data or hardware must stay on your own site" },
];
function choose(name, req) {
  const out = new Map();                       // model -> first reason it was removed
  for (const r of RULES) {
    if (Boolean(req[r.need]) === r.keep) continue;   // rule does not fire
    for (const m of r.drop) if (!out.has(m)) out.set(m, r.why);
  }
  const left = ORDER.filter(m => !out.has(m));
  console.log(`${name}: ${left.length ? left[0].toUpperCase() : "NONE, relax a requirement"}`);
  console.log(`  still possible: ${left.join(", ") || "-"}`);
  out.forEach((why, m) => console.log(`  no ${m}: ${why}`));
}
const base = { commodity: false, longTask: false, steadyHigh: false,
               osControl: false, noOpsTeam: false, onSiteOnly: false };
choose("office email",   { ...base, commodity: true, noOpsTeam: true });
choose("thumbnail job",  { ...base, noOpsTeam: true });
choose("live order map", { ...base, longTask: true, noOpsTeam: true });
choose("legacy billing", { ...base, osControl: true });
choose("impossible mix", { ...base, osControl: true, noOpsTeam: true });

একটি জিনিস মনে রাখবেন: পুরো system-এ একটিই model হতে হবে, এমন নিয়ম নেই। বাস্তবের অনলাইন বাজারে ইমেইল SaaS-এ, মূল app PaaS-এ, ছবি ছোট করা FaaS-এ, আর ডেটা DBaaS-এ থাকতে পারে।

৮ · একটি app-কে IaaS থেকে PaaS-এ সরানো

রেখা সরানো মানে শুধু অন্য জায়গায় কোড copy করা নয়। PaaS-এ instance যেকোনো সময় বদলে যেতে পারে, আর একাধিক instance একসাথে চলে। তাই VM-এর local disk-এ রাখা জিনিসের ওপর ভরসা করা যায় না। App-কে stateless করতে হয়: কোনো instance-এর নিজের ভেতরে গুরুত্বপূর্ণ কিছু থাকবে না। এই চিন্তাটি বিখ্যাত হয় Twelve-Factor App নামের নির্দেশিকায়, যা PaaS প্রতিষ্ঠান Heroku-র প্রকৌশলীরা লিখেছিলেন।

ধাপগুলো হয়ে গেলে platform-এর config দেখতে এমন হতে পারে। এটি Google App Engine-এর app.yaml-এর একটি উদাহরণ, শুধু পড়ার জন্য। অন্য PaaS-এ ফাইলের নাম ও ধরন আলাদা, আর runtime-এর নাম সময়ের সাথে বদলায়। আসল cloud-এ deploy করলে খরচ হতে পারে; পরীক্ষা করলে কাজ শেষে app বন্ধ করে দেবেন আর provider-এর docs অনুযায়ী resource মুছে ফেলবেন।

runtime: python312
instance_class: F1
automatic_scaling:
  min_instances: 1
  max_instances: 5
env_variables:
  UPLOAD_BUCKET: "example-bucket"
  LOG_LEVEL: "info"

৯ · AI-এর যুগে service model বাছাই

AI-কে “আমার app কোথায় deploy করব?” জিজ্ঞেস করলে সে খুব আত্মবিশ্বাসে একটি উত্তর দেয়। কিন্তু সে আপনার দলের আকার, বাজেট বা ডেটার নিয়ম জানে না। আর সে শেখা তথ্যে পিছিয়ে থাকতে পারে, তাই service-এর নাম, সীমা বা দাম পুরোনো হতে পারে। Cloud-এর কাজে AI-এর ভুলগুলো সাধারণত একই ছাঁচের।

AI-এর পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Service-টি কোন ঘরে পড়ে আর তার shared responsibility কী, provider-এর docs-এ মিলিয়েছি
• Backup কে নেবে, কতদিন থাকবে, আর restore কীভাবে পরীক্ষা হবে, লিখে রেখেছি
• কোনো অনুমতিতে অকারণ * নেই, কোনো port অকারণে 0.0.0.0/0-তে খোলা নেই
• Secret কোডে, config-এ বা AI-এর prompt-এ নেই
• আদেশ আগে dry-run বা plan দিয়ে দেখেছি, throwaway পরিবেশে চালিয়েছি, diff পড়েছি
• Budget alert বসিয়েছি, আর কাজ শেষে কী মুছতে হবে তার তালিকা রেখেছি