Cloud computing কী — NIST-এর সংজ্ঞা, ভাড়ার কম্পিউটার আর cloud-এর আগের পৃথিবী

১ · Cloud-এর আগের পৃথিবী — server কিনতে হতো মাস ধরে

ধরুন ২০০৪ সাল। আপনি আর দুই বন্ধু মিলে একটি অনলাইন বাজারের ওয়েবসাইট বানাচ্ছেন। কোড লেখা শেষ। এবার সেটি চালাতে একটি server লাগবে, মানে এমন কম্পিউটার যা দিনরাত চালু থাকে আর ব্যবহারকারীর অনুরোধের জবাব দেয়। তখন আপনার সামনে মোটামুটি তিনটি পথ ছিল।

এই তিন পথের মাঝামাঝি আরও কিছু ছিল, যেমন dedicated server ভাড়া আর VPS. তবে সবগুলোর সমস্যা একই জায়গায়: সিদ্ধান্ত নিতে হয় আগে, ব্যবহার হয় পরে। নতুন যন্ত্র চাইলে দরপত্র, অনুমোদন, আমদানি, যন্ত্র বসানো আর সেটআপ মিলিয়ে কয়েক সপ্তাহ থেকে কয়েক মাস চলে যেত। আর একবার কিনলে সেটি বেচে দেওয়া সহজ নয়।

এই দুই ভুলের নাম আছে। চাহিদার চেয়ে বেশি যন্ত্র কিনে বসে থাকা হলো over-provisioning. চাহিদার চেয়ে কম যন্ত্র রাখা হলো under-provisioning. Provisioning শব্দের অর্থ কাজে লাগানোর জন্য যন্ত্র বা সম্পদ তৈরি করে দেওয়া। আগেই বলে রাখি, দুটি ভুলই টাকার ভুল। প্রথমটিতে টাকা যায় অলস যন্ত্রে, দ্বিতীয়টিতে টাকা যায় ফিরে যাওয়া গ্রাহকের সাথে।

নিচের ধাপগুলোতে একটি কাল্পনিক অনলাইন বাজার অ্যাপের চাঁদরাত দেখুন। প্রতিটি সংখ্যা ধরে নেওয়া। “পরে” চাপুন আর দুই কলামের পার্থক্য খেয়াল করুন।

২ · ভাড়ার কম্পিউটার — CNG আর বিদ্যুৎ বিলের যুক্তি

Cloud-এর মূল চিন্তা খুব সাধারণ। আপনি নিজের গাড়ি না কিনে প্রয়োজনের সময় CNG ডাকতে পারেন। আবার বাড়িতে বিদ্যুৎ কেন্দ্র না বসিয়ে মিটার ধরে বিল দেন। Cloud একই কাজ করে কম্পিউটারের সাথে।

শেষ সারিটি লক্ষ করুন। যাঁর চাহিদা স্থির, তাঁর জন্য ভাড়া সবসময় সস্তা নয়। Cloud-এর আসল মূল্য তখনই, যখন চাহিদা ওঠানামা করে বা অনিশ্চিত। এই কথাটি পুরো কোর্সে বারবার ফিরে আসবে।

৩ · NIST-এর সংজ্ঞা — পাঁচ, তিন আর চার

“Cloud” শব্দটি বিজ্ঞাপনে এত ব্যবহার হয়েছে যে একসময় এর অর্থই ঝাপসা হয়ে গিয়েছিল। তাই যুক্তরাষ্ট্রের মান-নির্ধারণী সংস্থা NIST ২০১১ সালে একটি ছোট নথি প্রকাশ করে: SP 800-145, লিখেছেন Peter Mell ও Timothy Grance. নথিটি মাত্র কয়েক পৃষ্ঠার, কিন্তু আজও পরীক্ষা আর ইন্টারভিউতে এটিই সবচেয়ে বেশি উদ্ধৃত সংজ্ঞা।

সংজ্ঞাটি একবারে মনে রাখা কঠিন। তাই NIST একে তিন ভাগে ভেঙেছে: ৫টি অপরিহার্য বৈশিষ্ট্য, ৩টি service model আর ৪টি deployment model.

পাঁচটি বৈশিষ্ট্য মুখস্থ না করে একটি গল্পে দেখা ভালো। একটি কাল্পনিক অনলাইন বাজার অ্যাপের রাতের শিফটে আছেন রিমা। তাঁর এক রাতের কাজের ভেতরেই পাঁচটি বৈশিষ্ট্য চলে আসে।

রিমা নিজেই ২টি server চাইলেন
ফোন, ইমেইল বা মানুষের হাত লাগেনি
অবস্থা: কয়েক মিনিটেই চালু

ল্যাপটপের browser   → console
ফোনের browser       → console
অফিসের script       → API
পথ একটাই: standard network

রিমার VM
অন্য গ্রাহকের VM
আরও এক গ্রাহকের VM
রিমা জানেন শুধু region, যন্ত্রটি নয়

রাত ৯টা   ২ ██
রাত ১০টা ১০ ██████████  ← সেল শুরু
রাত ১টা   ২ ██           ← সেল শেষ

১০টি server × ৩ ঘণ্টা = ৩০ server-ঘণ্টা
 ২টি server × ২১ ঘণ্টা = ৪২ server-ঘণ্টা
মোট ৭২ server-ঘণ্টা × $0.10
এই ২৪ ঘণ্টার বিল = $7.20

এবার বাকি দুটি ভাগ শুধু চিনে রাখুন। পরের দুই পর্বে এগুলো নিয়ে বিস্তারিত আলোচনা আছে।

৪ · চাহিদা বনাম capacity — অপচয় আর হারানো গ্রাহকের হিসাব

এবার অনুভূতি ছেড়ে সংখ্যায় যাই। Capacity মানে আপনার ব্যবস্থা একসাথে কতটা কাজ সামলাতে পারে। আর utilization মানে সেই ক্ষমতার কত শতাংশ সত্যিই কাজে লাগছে।

একটি হাতে-কলমে হিসাব। একটি ব্যবস্থায় সর্বোচ্চ চাহিদা ৪০টি server, কিন্তু মাসের গড় চাহিদা ১২টি। চূড়া সামলাতে ৪০টি কেনা হলো। ৩০ দিনের মাসে:

• চালু server-ঘণ্টা = ৪০ × ৭২০ = ২৮,৮০০
• ব্যবহৃত server-ঘণ্টা = ১২ × ৭২০ = ৮,৬৪০
• Utilization = ৮,৬৪০ ÷ ২৮,৮০০ = ০.৩০, অর্থাৎ ৩০%
• অলস = ২৮,৮০০ − ৮,৬৪০ = ২০,১৬০ server-ঘণ্টা

মানে ১০০ টাকায় কেনা ক্ষমতার ৭০ টাকার অংশ অলস থাকে। লক্ষ করুন, যন্ত্র নষ্ট নয়, হিসাবে ভুলও নেই। চূড়ার জন্য তৈরি থাকার দামই এটি।

নিচের ডায়াগ্রামে একটি কাল্পনিক ওয়েবসাইটের এক সপ্তাহের চাহিদা ঘণ্টা ধরে আঁকা। রবিবার থেকে শনিবার, দিনে একটি ঢেউ, আর শুক্রবার সন্ধ্যায় সেলের ধাক্কা। একই সপ্তাহে তিনটি পরিকল্পনা পাশাপাশি দেখুন।

এই সংখ্যাগুলো হাতে বানানো নয়। নিচের সিমুলেটরটি চালালেই একই ফল আসবে। পরিকল্পনার তালিকায় অন্য capacity বসিয়ে, অথবা শুক্রবারের গুণক 3 বদলে পরীক্ষা করে দেখুন কী ঘটে।

// One week, hour by hour: demand vs capacity. Every number here is assumed.
function mulberry32(a) { return function () {
  a |= 0; a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rnd = mulberry32(2026);
const PER_SERVER = 1000;                 // one server: 1000 requests per hour
const demand = [];                       // requests in each hour (Sunday first)
for (let h = 0; h < 7 * 24; h++) {
  const hour = h % 24, day = Math.floor(h / 24);
  let need = 12 + 8 * Math.sin((hour - 9) / 24 * 2 * Math.PI); // daily wave
  if (day === 5 && hour >= 18 && hour <= 23) need *= 3;        // Friday-evening sale
  demand.push(Math.round((need + rnd() * 2) * PER_SERVER));
}
function simulate(capacityAt) {          // capacityAt(h) = servers switched on
  let paid = 0, used = 0, lost = 0;
  demand.forEach((d, h) => {
    const cap = capacityAt(h) * PER_SERVER;
    paid += capacityAt(h);
    used += Math.min(d, cap) / PER_SERVER;
    lost += Math.max(0, d - cap);
  });
  return { paid, idle: Math.round(paid - used), lost };
}
const total = demand.reduce((a, b) => a + b, 0);
console.log("total:", total, " peak hour:", Math.max(...demand));
const elastic = h => h === 0 ? 14 : Math.ceil(demand[h - 1] * 1.25 / PER_SERVER);
console.log("plan      paid  idle  lost    lost%  busy%");
for (const [name, fn] of [["fixed 14", () => 14], ["fixed 25", () => 25], ["fixed 56", () => 56], ["elastic", elastic]]) {
  const r = simulate(fn);
  console.log(name.padEnd(9), String(r.paid).padEnd(5), String(r.idle).padEnd(5), String(r.lost).padEnd(7),
    (100 * r.lost / total).toFixed(1).padEnd(6), (100 * (r.paid - r.idle) / r.paid).toFixed(0));
}

total: 2337544  peak hour: 54939
plan      paid  idle  lost    lost%  busy%
fixed 14  2352  505   490109  21.0   79
fixed 25  4200  1951  88295   3.8    54
fixed 56  9408  7070  0       0.0    25
elastic   3013  707   31715   1.4    77

Provisioning delay — অপেক্ষা নিজেই একটি খরচ

Elasticity শুধু “বাড়ানো যায়” নয়, “কত দ্রুত বাড়ানো যায়” সেটিও। ধরুন একটি প্রচারের কারণে চাহিদা ২০ থেকে ৪৫ server-এ উঠল, চলবে ১৪ দিন। বাড়তি ২৫টি server কত দ্রুত পাবেন, তার ওপর ফল পুরো বদলে যায়। নিচে অপেক্ষার সময়গুলো ধরে নেওয়া, তবে তুলনার মাত্রাটি বাস্তব।

// A demand surge lasts 14 days. How long until extra servers arrive? Assumed numbers.
const BASE = 20, SURGE = 45;      // servers needed: normal days vs the surge
const EXTRA = SURGE - BASE;       // 25 more servers are needed during the surge
const PER_SERVER = 1000;          // requests per hour, per server
const SURGE_HOURS = 14 * 24;
const HORIZON = 90 * 24;          // judge each choice over 90 days
const ways = [
  // wait = hours until extra servers work; keep = do we stay stuck with them?
  { name: "buy hardware",   wait: 8 * 7 * 24, keep: true  },  // 8 weeks
  { name: "colo spare",     wait: 3 * 24,     keep: true  },  // 3 days
  { name: "cloud (manual)", wait: 0.5,        keep: false },  // 30 minutes
  { name: "cloud (auto)",   wait: 5 / 60,     keep: false },  // 5 minutes
];
console.log("way             wait(h)  lost req   idle server-h");
for (const w of ways) {
  const shortHours = Math.min(w.wait, SURGE_HOURS);
  const lost = Math.round(shortHours * EXTRA * PER_SERVER);
  const idleFrom = Math.max(w.wait, SURGE_HOURS);   // surge over: extras do nothing
  const idle = w.keep ? (HORIZON - idleFrom) * EXTRA : 0;
  console.log(w.name.padEnd(15), String(+w.wait.toFixed(2)).padEnd(8),
    String(lost).padEnd(10), idle);
}

way             wait(h)  lost req   idle server-h
buy hardware    1344     8400000    20400
colo spare      72       1800000    45600
cloud (manual)  0.5      12500      0
cloud (auto)    0.08     2083       0

৫ · যে প্রযুক্তি cloud-কে সম্ভব করল — virtualization আর API

Provider কীভাবে এক মিনিটে আপনাকে “নতুন কম্পিউটার” দেন? কেউ দৌড়ে গিয়ে যন্ত্র বসান না। আসলে একটি বড় physical server-কে সফটওয়্যার দিয়ে অনেক ছোট কম্পিউটারে ভাগ করা হয়। এই কৌশলের নাম virtualization. প্রতিটি ছোট কম্পিউটার হলো একটি virtual machine বা VM, আর ভাগ করার সফটওয়্যারের নাম hypervisor.

তবে virtualization একা cloud নয়। দ্বিতীয় উপাদানটি হলো API, মানে প্রোগ্রাম থেকে সেবা চাওয়ার নির্দিষ্ট পথ। “একটি server দিন” কথাটি যদি একটি HTTP অনুরোধ হয়, তবে server বানানো আর মানুষের হাতের কাজ থাকে না, হয়ে যায় সফটওয়্যারের কাজ। DevOps-এর প্রায় সব কিছু এই এক বদলের ওপর দাঁড়িয়ে আছে।

Provider-এর ভেতরে দুটি অংশ আছে। যে অংশ অনুরোধ নেয় আর সিদ্ধান্ত দেয়, তাকে বলে control plane. আর যে যন্ত্রগুলোতে আপনার VM চলে, সেগুলো data plane-এর অংশ। নিচে একটি কাল্পনিক provider-এর API call অনুসরণ করুন। আসল provider-এর নাম আর ক্ষেত্র আলাদা হবে, ধাপগুলোর ধারা মোটামুটি একই।

{
  "name": "bazaar-web-1",
  "size": "2-cpu-4gb",
  "image": "ubuntu-24-04",
  "region": "example-south-1"
}

পরিচয় ঠিক আছে?        হ্যাঁ
এই কাজের অনুমতি আছে?  হ্যাঁ
Quota বাকি আছে?         হ্যাঁ, 3 / 20
state: pending

host-a  খালি CPU 0   ✗ জায়গা নেই
host-b  খালি CPU 1   ✗ জায়গা কম
host-c  খালি CPU 8   ✓ বেছে নেওয়া হলো

disk    → image কপি থেকে তৈরি
network → virtual card, private IP
id      → vm-0a1b2c
state: pending

hypervisor: 2 vCPU, 4 GB RAM দিল
hypervisor: disk আর network জুড়ল
VM power on

bootloader → Linux kernel → systemd
cloud-init: hostname বসানো
cloud-init: SSH key বসানো
cloud-init: শুরুর script চালানো

{
  "id": "vm-0a1b2c",
  "state": "running",
  "private_ip": "10.0.1.15"
}
বিলের মিটার চলছে

একই কাজ তিন বড় provider-এর command-line tool-এ দেখতে কেমন, নিচে তার উদাহরণ। এটি শুধু চেহারা বোঝার জন্য। এখানে চালাবেন না। Flag আর image-এর নাম version-ভেদে বদলায়, আর সত্যিকারের account-এ চালালে খরচ হতে পারে। পর্ব ৬-এ এসব নিরাপদে শিখবেন।

# AWS
aws ec2 run-instances --image-id ami-0abc1234 \
  --instance-type t3.micro --count 1

# Azure
az vm create -g demo-rg -n demo-vm \
  --image Ubuntu2204 --size Standard_B1s \
  --generate-ssh-keys

# Google Cloud
gcloud compute instances create demo-vm \
  --zone=asia-south1-a --machine-type=e2-micro

৬ · Cloud-এর শরীর — একটি data centre আসলে কী

Cloud কোনো মেঘ নয়। এটি গুদামঘরের মতো বিশাল ভবন, যেখানে সারি সারি লোহার তাকে হাজার হাজার server বসানো। ওই তাকের নাম rack. আপনার ফোনের ছবি “cloud-এ আছে” মানে সেটি এমন কোনো ভবনের disk-এ আছে।

• বিদ্যুৎ: সাধারণত একাধিক সংযোগ, ব্যাটারিভিত্তিক UPS আর বড় জেনারেটর। Load-shedding হলে বাড়িতে যা হয়, তা এখানে হতে দেওয়া যায় না।
• ঠান্ডা রাখা: Server-এর প্রায় সব বিদ্যুৎই শেষে তাপ হয়। বাতাস বা পানি দিয়ে সেই তাপ সরাতে বিপুল শক্তি লাগে।
• নেটওয়ার্ক: প্রতি rack-এর ওপরে একটি switch, তার ওপরে আরও switch-এর স্তর, আর বাইরে fibre. গভীর আলোচনা Computer Networks কোর্সের data center network পর্বে।
• মানুষ আর পাহারা: নষ্ট disk বদলানো, প্রবেশে কড়াকড়ি, আগুন নেভানোর ব্যবস্থা। একটি বড় ভবনে কিছু না কিছু প্রতিদিনই নষ্ট হয়, তাই নকশার শুরুই হয় “যন্ত্র নষ্ট হবেই” ধরে।

বাংলাদেশের পাঠকের জন্য একটি বাস্তব কথা। লেখার সময়ে আমাদের জানামতে বড় তিন provider-এর (AWS, Azure, Google Cloud) নিজস্ব region দেশের ভেতরে নেই, যদিও কাছের দেশে আছে। তাই অনুরোধকে সমুদ্রের নিচের কেবল ধরে যেতে হতে পারে। ফলে latency বাড়ে, আর কোনো কোনো খাতে তথ্য কোথায় রাখা হবে সে নিয়ে নিয়মও থাকতে পারে। অবস্থা বদলাতে পারে, তাই নিজে যাচাই করে নিন। পর্ব ৫-এ এ নিয়ে বিস্তারিত আছে।

৭ · ইতিহাস — বিদ্যুতের মতো কম্পিউটিং

Cloud নতুন শব্দ হলেও চিন্তাটি পুরোনো। ১৯৬০-এর দশকে কম্পিউটার ছিল বিশাল আর দামি, তাই একটি যন্ত্র অনেকে মিলে ব্যবহার করতেন, যাকে বলে time-sharing. Utility computing-এর চিন্তা, মানে পানি-বিদ্যুতের মতো মিটারে কম্পিউটিং কেনা, এখান থেকেই আসে।

৮ · Cloud যা সমাধান করে না

Cloud-কে অনেকে জাদুর ওষুধ ভাবেন। নতুনদের সবচেয়ে বড় ভুল এটি। মনে রাখুন, cloud আপনার যন্ত্র কেনার সমস্যা নিয়ে নেয়, চিন্তা করার দায়িত্ব নয়।

এখানে shared responsibility কথাটি গুরুত্বপূর্ণ। ভবন, যন্ত্র আর hypervisor সাধারণত provider-এর দায়িত্ব। কিন্তু আপনার VM-এর ভেতরের সফটওয়্যার, তথ্য আর অনুমতি সাধারণত আপনার। বাড়ির মালিক দরজা বানিয়ে দেন, তালা লাগাতে ভুলে গেলে সেটি ভাড়াটিয়ার দায়। সীমারেখা service-ভেদে সরে, যা পর্ব ২-এ দেখবেন।

৯ · Cloud আর DevOps-এর সম্পর্ক, আর এই কোর্সের মানচিত্র

কোর্সের নামে দুটি শব্দ আছে, আর দুটি এক জিনিস নয়। Cloud হলো কোথায় চলছে: ভাড়া করা, API দিয়ে নিয়ন্ত্রণ করা যায় এমন অবকাঠামো। DevOps হলো কীভাবে দল কাজ করে: যাঁরা সফটওয়্যার বানান আর যাঁরা চালান, তাঁদের দেয়াল ভেঙে ছোট ছোট পরিবর্তন দ্রুত আর নিরাপদে পৌঁছে দেওয়া। শব্দটি জনপ্রিয় হয় Patrick Debois-র উদ্যোগে ২০০৯ সালের প্রথম DevOpsDays সম্মেলনের মাধ্যমে।

দুটিকে আলাদাও পাওয়া যায়। নিজের server room-এ দারুণ DevOps চলতে পারে। আবার cloud-এ প্রতিটি server হাতে ক্লিক করে বানানো দলও আছে, যাদের DevOps নেই। তবে দুটি একসাথে শক্তিশালী, কারণ cloud অবকাঠামোকে API বানিয়ে দেয়, আর API-কে কোড দিয়ে চালানো যায়। তাই server বানানো, পরীক্ষা আর deploy, সবই একটি pipeline-এর অংশ হতে পারে। এর সফটওয়্যার-প্রকৌশল দিকটি আছে Continuous Delivery ও DevOps পর্বে। এই কোর্স দেখায় তা চালানো হয় কীভাবে।

নিচে পুরো কোর্সের ১৪টি মডিউল। কোনো একটি মডিউলে আটকে গেলে সরাসরি পরেরটিতে যাওয়া যায়, তবে মডিউল ১ আর ২ প্রায় সবার জন্য দরকারি।

১০ · AI-এর যুগে cloud শেখা

AI আপনাকে কয়েক সেকেন্ডে cloud কমান্ড, Terraform ফাইল বা Kubernetes YAML লিখে দিতে পারে। শুনতে দারুণ। কিন্তু অন্য কোডের সাথে পার্থক্য আছে: ভুল প্রোগ্রাম সাধারণত আপনার কম্পিউটারেই আটকে যায়; ভুল cloud কমান্ড চললে সত্যিকারের টাকা খরচ হয়, তথ্য মুছে যায়, বা ব্যক্তিগত তথ্য সবার জন্য খুলে যায়।

AI-এর লেখা cloud কমান্ড বা ফাইল চালানোর আগে

• প্রতিটি কমান্ড কী বদলাবে, নিজের ভাষায় বলতে পারি
• প্রথমে --dry-run বা terraform plan চালিয়ে diff পড়েছি
• Flag আর resource-এর নাম official docs-এ মিলিয়েছি
• অনুমতি আর network যতটা সম্ভব সরু, * বা 0.0.0.0/0 নেই
• আলাদা পরীক্ষার পরিবেশে আগে চালিয়েছি, production-এ নয়
• Budget alert আছে, আর কাজ শেষে সব মুছে ফেলার ধাপ জানি
• Prompt-এ কোনো key, password বা আসল account নম্বর দিইনি