Public, private, hybrid আর multi-cloud — কোথায় চালাবেন

১ · প্রশ্নটি নতুন: আপনার সার্ভার কোথায় থাকবে, কার সাথে

পর্ব ০২-এ প্রশ্ন ছিল, কে কোন স্তর সামলায়। IaaS, PaaS, SaaS সেই উত্তর দেয়। এবার প্রশ্ন আলাদা: যন্ত্রগুলো কোথায় আছে, আর আপনি সেগুলো কার সাথে ভাগ করে ব্যবহার করেন? এই উত্তরকে বলে deployment model.

দুটি প্রশ্ন একে অপরের থেকে স্বাধীন। Private cloud-এ IaaS চালানো যায়, আবার public cloud-এ SaaS. তাই “আমরা PaaS-এ আছি” বললে এখনো জানা যায় না ডেটা কোথায় আছে।

২ · NIST-এর চারটি সংজ্ঞা, আর পরে আসা multi-cloud

পর্ব ০১-এ দেখা NIST SP 800-145 (২০১১) নথিটিই এখানেও ভিত্তি। মাত্র কয়েক পাতার এই নথি চারটি deployment model বলে। মূল শব্দগুলো ইংরেজিতেই পড়া ভালো, কারণ পরীক্ষা আর আলোচনায় এগুলোই ঘুরে আসে।

তিনটি জিনিস অনেকেই ভুল বলেন। প্রথমত, NIST-এর private cloud-এর শর্ত হলো “একক প্রতিষ্ঠানের একান্ত ব্যবহার”, “নিজের ভবনে থাকা” নয়। তৃতীয় পক্ষের ডেটা সেন্টারেও private cloud হতে পারে। দ্বিতীয়ত, public cloud-কে NIST বলে provider-এর জায়গায় থাকা। তৃতীয়ত, hybrid-এর সংজ্ঞায় NIST নিজেই উদাহরণ দেয়: cloud bursting, cloud-এর মধ্যে load ভাগের জন্য।

Community cloud: খাতায় আছে, মুখে কম

আজ community cloud শব্দটি কম শোনা যায়, কিন্তু ধারণাটি মরেনি। সরকারি সংস্থাগুলোর জন্য আলাদা করে রাখা পরিবেশ এই ধরনের কাছাকাছি। যেমন আমেরিকার FedRAMP কর্মসূচিতে “government community cloud” ধরনটি আছে। কয়েকটি হাসপাতাল বা বিশ্ববিদ্যালয় মিলে একটি যৌথ পরিকাঠামো চালালেও একই কথা।

Multi-cloud: একটি পরের শব্দ

Multi-cloud মানে সাধারণত একই প্রতিষ্ঠানের একাধিক public provider ব্যবহার। শব্দটি SP 800-145-এ নেই। এটি ২০১০-এর দশকে শিল্পের ব্যবহারে ছড়িয়েছে, তাই এর কোনো মান-নির্ধারিত সংজ্ঞাও নেই।

৩ · Private cloud বনাম শুধু on-premises

এই পার্থক্যটি সবচেয়ে বেশি গুলিয়ে যায়। On-premises কথাটি শুধু জায়গা বলে: যন্ত্র আপনার নিজের ভবনে। Private cloud কথাটি বলে আচরণ: যন্ত্র একান্ত আপনার, আর সেটি cloud-এর মতো চলে। লেখকভেদে সীমারেখা একটু আলাদা, তবে NIST-এর পথ ধরলে পরীক্ষাটি পরিষ্কার: পর্ব ০১-এর পাঁচটি বৈশিষ্ট্য আছে কি?

একটি কাল্পনিক প্রতিষ্ঠানের server room-এ ২০টি সার্ভার আছে, সবগুলোতে virtualization চলে। ম্যানেজার বলছেন, “আমাদের তো private cloud আছে।” পাঁচটি পরীক্ষা চালিয়ে দেখি।

Private cloud কী দিয়ে বানানো হয়

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

Self-service আসলে দেখতে কেমন? নিচের দুটি কমান্ড পাশাপাশি দেখুন। প্রথমটি OpenStack-এর, দ্বিতীয়টি একটি public cloud-এর। দুটোই নমুনা, এখানে চালানোর কিছু নেই, মান দুটি ভুয়া। মিলটিই শিক্ষা: ticket নয়, API.

# Private cloud (OpenStack CLI): names below are samples
openstack server create --flavor m1.small \
  --image ubuntu-24.04 --network app-net web-01

# Public cloud (AWS CLI): ids below are fake
aws ec2 run-instances --instance-type t3.small \
  --image-id ami-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0

৪ · Hybrid-এর চারটি বাস্তব নকশা

“আমরা hybrid” কথাটি অস্পষ্ট। প্রশ্ন হলো, দুই পরিবেশের মধ্যে ঠিক কী যায় আসে? বাস্তবে চারটি নকশা বেশি দেখা যায়।

দুই পরিবেশ সাধারণত দুভাবে জোড়া হয়: ইন্টারনেটের ওপর এনক্রিপ্ট করা VPN, অথবা dedicated link, যেমন AWS Direct Connect, Azure ExpressRoute বা Google Cloud Interconnect. বিস্তারিত পর্ব ২৮-এ। একটি কঠিন শিক্ষা মনে রাখুন: লিংক দুটোর মধ্যে নতুন একটি ব্যর্থতার বিন্দু। লিংক কাটলে cloud-এর অংশ কি নিজে চলতে পারে? না পারলে hybrid আপনার availability কমিয়েও দিতে পারে।

৫ · Cloud bursting: ঈদের সেল মিনিট ধরে

কাল্পনিক অনলাইন বাজার অ্যাপ bazar-এর নিজের যন্ত্রে ক্ষমতা ৪০০ req/s, অর্থাৎ প্রতি সেকেন্ডে ৪০০টি অনুরোধ। ঈদের আগের রাতে সেল। বাসের টিকিটের কাউন্টার ভাবুন: নিয়মিত কাউন্টারে লাইন উপচে পড়লে অস্থায়ী কাউন্টার খোলে, কিন্তু খুলতে সময় লাগে। এখানে নিয়ম কয়েকটি:

• প্রতি ৫ মিনিটে একবার হিসাব। প্রতিটি cloud VM সামলায় ১০০ req/s.
• অতিরিক্ত = চাহিদা − ৪০০. এই ধাপে প্রস্তুত VM যতটুকু পারে সামলায়, বাকিটা বাদ পড়ে (drop).
• পরের ধাপের VM সংখ্যা = ⌈অতিরিক্ত ÷ ১০০⌉. নতুন VM চালু হতে এক ধাপ লাগে। কমানো সাথে সাথে হয়।

শিক্ষাটি পরিষ্কার: bursting-এর শত্রু হলো দেরি। ক্ষমতা ফুরানোর পরে VM চাইলে দেরি হয়ে গেছে। তাই বাস্তবে trigger রাখা হয় ক্ষমতা ফুরানোর আগেই, আর VM-এর boot সময় যত কম, তত ভালো। নিচের simulator পুরো এক দিন চালায়, ২৮৮টি ধাপে। ভেতরের সংখ্যাগুলো সবই অনুমান। spare মানে কয়টি VM আগাম রাখা হবে। সংখ্যা বদলে চালিয়ে দেখুন।

// Cloud bursting: 1 day in 5-minute ticks. Every number is an assumption.
let seed = 2026;
function rand() {                 // mulberry32: seeded, so every run is the same
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const ON_PREM = 400, PER_VM = 100, PRICE = 0.20;  // req/s, req/s per VM, $/VM-hour
const demand = [];
for (let t = 0; t < 288; t++) {                   // 288 ticks = 24 hours
  const h = t / 12;
  const wave = 220 + 120 * Math.sin((h - 6) * Math.PI / 12);
  const sale = h >= 19 && h < 23 ? 480 * Math.sin((h - 19) * Math.PI / 4) : 0;
  demand.push(Math.round((wave + sale) * (0.95 + 0.1 * rand())));
}
const all = demand.reduce((a, b) => a + b, 0);
function run(spare) {
  let vms = 0, dropped = 0, vmTicks = 0, peakVms = 0;
  for (const d of demand) {
    const over = Math.max(0, d - ON_PREM);
    dropped += Math.max(0, over - vms * PER_VM);
    vmTicks += vms; peakVms = Math.max(peakVms, vms);
    vms = Math.ceil(Math.max(0, d + spare * PER_VM - ON_PREM) / PER_VM); // next tick
  }
  const hours = vmTicks / 12;
  console.log(`spare=${spare}  dropped=${(100 * dropped / all).toFixed(3)}%  ` +
    `peak VMs=${peakVms}  VM-hours=${hours.toFixed(1)}  cost=$${(hours * PRICE).toFixed(2)}`);
}
console.log('peak demand', Math.max(...demand), 'req/s');
[0, 1, 2, 3].forEach(run);

peak demand 644 req/s
spare=0  dropped=0.086%  peak VMs=3  VM-hours=4.9  cost=$0.98
spare=1  dropped=0.000%  peak VMs=4  VM-hours=14.5  cost=$2.90
spare=2  dropped=0.000%  peak VMs=5  VM-hours=31.4  cost=$6.28
spare=3  dropped=0.000%  peak VMs=6  VM-hours=54.6  cost=$10.92

কেন দুই জায়গায়: খরচের যুক্তি

ধরে নিই নিজের একটি সার্ভারের সব মিলিয়ে খরচ মাসে $১০০, অর্থাৎ বছরে $১,২০০, আর cloud-এর সমান VM ঘণ্টায় $০.২০. দুটিই অনুমান, আসল দর provider-এর pricing page-এ দেখে নিন। সমতার বিন্দু:

যে সার্ভার বছরে ৬,০০০ ঘণ্টার বেশি লাগে, এই অনুমানে সেটি কেনা সস্তা। যেটি কম লাগে, সেটি ভাড়া নেওয়া সস্তা। তাই hybrid-এর অর্থনৈতিক যুক্তি হলো: স্থায়ী ভিত্তির জন্য নিজের যন্ত্র, চূড়ার জন্য ভাড়া। বিয়েবাড়ির ক্যাটারিংয়ের মতো: পরিবারের রোজের রান্না নিজের চুলায়, হাজার অতিথির দিন বাবুর্চি ভাড়া। তবে এই হিসাবে লিংক, ডেটা-স্থানান্তর, কর্মীর সময় আর reserved দর ধরা হয়নি; সেগুলো পর্ব ০৪ আর ৭২-এ আসবে।

৬ · Multi-cloud: কেন আসে, আর দাম কত

প্রথমে দুটি আলাদা জিনিস আলাদা করুন। Portfolio multi-cloud: একটি কাজ cloud A-তে, আরেকটি কাজ cloud B-তে, দুটির মধ্যে যোগাযোগ কম। এটি খুব সাধারণ, আর প্রায়ই ইচ্ছা ছাড়াই ঘটে, যেমন অন্য কোম্পানি কিনে নেওয়ার পরে। Spanning multi-cloud: একটিই কাজ দুই provider-জুড়ে চলে, অথবা এক ক্লিকে সরে যেতে পারে। এটি কঠিন আর ব্যয়বহুল। “আমরা multi-cloud” শুনলে আগে জানতে চান, কোনটি।

আসল খরচ চারটি

• দক্ষতা: IAM, network, logging, billing, প্রতিটিই দুই provider-এ আলাদা। ছোট দলের মনোযোগ অর্ধেক হয়ে যায়।
• Networking: দুই cloud-এর মধ্যে নিরাপদ, দ্রুত পথ বানানো, ঠিকানা না মেলানো, DNS আর বিলম্ব সামলানো।
• Egress: Cloud থেকে ডেটা বাইরে গেলে সাধারণত টাকা লাগে, আর ভেতরে এলে সাধারণত লাগে না। দুই cloud-এর মধ্যে ডেটা চললে এই বিল বাড়তেই থাকে।
• সবচেয়ে ছোট সাধারণ ফিচার: দুই জায়গায় একই কোড চালাতে হলে শুধু দুটিতেই থাকা ফিচার ব্যবহার করা যায়। Managed সেবার অনেক সুবিধা ছেড়ে দিতে হয়, যে সুবিধার জন্যই cloud-এ আসা।

এবার সংখ্যা। ধরে নিই একটি provider-এর availability ৯৯.৯%. দুটি স্বাধীন provider-এ বদলি থাকলে দুটো একসাথে পড়ে যাওয়ার সম্ভাবনা ০.০০১ × ০.০০১. কিন্তু বদলির ব্যবস্থা নিজেও একটি অংশ, ধরে নিই তার availability ৯৯.৯৫%. তিনটি হিসাব আর একটি egress বিল নিচে চালিয়ে দেখুন।

// Does a second cloud help? All inputs are assumed, 30-day month.
const MIN = 30 * 24 * 60;
const line = (name, a) => console.log(name.padEnd(30) + (a * 100).toFixed(4) +
  '%  ' + ((1 - a) * MIN).toFixed(1).padStart(5) + ' min/month');

const one = 0.999;                     // one provider
const sw = 0.9995;                     // the failover layer itself
const two = 1 - (1 - one) * (1 - one); // both down at once (if independent)

line('one cloud', one);
line('two clouds, perfect switch', two);
line('two clouds, real switch', two * sw);

// App in cloud A, database in cloud B: every byte between them is egress.
const gbPerMonth = 50000, pricePerGB = 0.09;
console.log('cross-cloud traffic: $' + gbPerMonth * pricePerGB + ' per month');

one cloud                     99.9000%   43.2 min/month
two clouds, perfect switch    99.9999%    0.0 min/month
two clouds, real switch       99.9499%   21.6 min/month
cross-cloud traffic: $4500 per month

৭ · Sovereign cloud, government cloud আর ডেটা কোথায় থাকে

“ডেটা দেশে থাকতে হবে” বাক্যটি শুনতে সহজ, কিন্তু এর ভেতরে তিনটি আলাদা প্রশ্ন আছে।

Government cloud হলো সরকারি কাজের জন্য আলাদা রাখা পরিবেশ। AWS GovCloud (US) আর Azure Government এর পরিচিত উদাহরণ। Sovereign cloud নতুন একটি বাজারি শব্দ, যার অর্থ provider-ভেদে আলাদা: কোথাও শুধু ডেটার অবস্থান, কোথাও স্থানীয় কর্মী, কোথাও আলাদা আইনি সত্তা। তাই নামটি নয়, শর্তগুলো পড়ুন। ইউরোপে এই আলোচনা বিশেষভাবে জোরালো, সেখানে GDPR আছে, আছে নিজস্ব পরিকাঠামোর উদ্যোগও।

বাংলাদেশের প্রেক্ষাপট: সতর্কভাবে

এই অংশে আমরা ইচ্ছা করেই কোনো ধারা বা সীমা উদ্ধৃত করছি না, কারণ নিয়ম বদলায়। সাধারণভাবে যা বলা যায়:

• লেখার সময়ে আমাদের জানা মতে বড় তিনটি provider-এর কোনো পূর্ণ region বাংলাদেশের ভেতরে নেই। আশপাশের region-এর তালিকা ও অবস্থা provider-এর পাতায় মিলিয়ে নিন।
• দেশে সরকারি উদ্যোগের ডেটা সেন্টার আর স্থানীয় data center ও hosting প্রতিষ্ঠান আছে। তাদের সেবা NIST-এর অর্থে cloud কি না, পাঁচ পরীক্ষায় দেখে নিন।
• সরকারের আইন-ওয়েবসাইট bdlaws.minlaw.gov.bd অনুযায়ী এখন ব্যক্তিগত উপাত্ত সুরক্ষা আইন, ২০২৬ আর জাতীয় উপাত্ত ব্যবস্থাপনা আইন, ২০২৬ আছে। কিছু ধারা আর প্রবিধান পরে কার্যকর হতে পারে। ব্যাংক ও আর্থিক খাতে Bangladesh Bank-এর ICT সংক্রান্ত নির্দেশনাও প্রাসঙ্গিক। আপনার খাতে এখন ঠিক কী প্রযোজ্য, তা সরকারি মূল উৎস আর আইনি বা compliance দলের কাছ থেকে নিশ্চিত করুন।

৮ · Repatriation: cloud থেকে ফিরে আসার বিতর্ক

Repatriation মানে cloud-এর workload আবার নিজের বা ভাড়া করা যন্ত্রে ফিরিয়ে আনা। প্রকাশ্যে আলোচিত উদাহরণের মধ্যে আছে Dropbox-এর নিজস্ব storage-এ বড় অংশের ডেটা সরানো (২০১৬ সালে প্রকাশ্যে জানানো) আর 37signals-এর cloud ছাড়ার ঘোষণা (২০২২ থেকে তাদের লেখায় আলোচিত)। ২০২১ সালে Andreessen Horowitz-এর একটি লেখা বড় software কোম্পানির ক্ষেত্রে cloud-এর খরচ নিয়ে প্রশ্ন তোলে।

এই বিতর্কে কোনো শতাংশ আমরা দিচ্ছি না। বিভিন্ন সমীক্ষার সংখ্যা উৎসভেদে খুব আলাদা, প্রশ্নের ধরনও আলাদা, আর অনেক সমীক্ষা এমন প্রতিষ্ঠানের করানো যাদের বিক্রির স্বার্থ আছে। পরিণত দৃষ্টিভঙ্গি হলো: এটি “cloud ভালো না খারাপ” প্রশ্ন নয়। Workload ধরে হিসাব করুন, আগের অংশের সমতার বিন্দুর মতো। আর যাঁরা ফিরেছেন, তাঁদের সবাই সবকিছু ফিরিয়েছেন, এমনও নয়।

৯ · সিদ্ধান্তের কাঠামো: ছাঁকুন, তারপর ওজন দিন

“কোথায় চালাব” প্রশ্নের একটি ব্যবহারযোগ্য ক্রম আছে। ক্রমটি গুরুত্বপূর্ণ, কারণ প্রথম ধাপের উত্তর বাকিগুলোকে অর্থহীন করে দিতে পারে।

1. বাধ্যবাধকতা: আইন, চুক্তি, নিয়ন্ত্রকের শর্ত। এগুলো ওজন নয়, ছাঁকনি (filter): না মিললে বিকল্পটি বাদ।
2. ডেটা: ডেটা কোথায় আছে, কত বড়, কে ব্যবহার করে। ডেটা সরানো কঠিন হলে কাজ ডেটার কাছে যাবে।
3. বিলম্ব ও সংযোগ: ব্যবহারকারী বা যন্ত্র কত কাছে থাকা দরকার? সংযোগ গেলে কী হবে?
4. Load-এর ধরন: স্থির, না ঝটকায় বাড়ে? আগের সমতার হিসাবটি এখানে লাগে।
5. দলের দক্ষতা: কে রাত ৩টায় ঠিক করবেন? এই প্রশ্নের উত্তর না থাকলে নকশাটি কাগজের।
6. বেরোনোর পথ: সরতে হলে কত খরচ? Exit plan লিখে রাখা হয়েছে কি?

এরপর যে বিকল্পগুলো টিকে থাকে, সেগুলোর তুলনায় একটি weighted decision matrix কাজে লাগে: প্রতিটি মানদণ্ডের একটি ওজন, প্রতিটি বিকল্পের ১ থেকে ৫ নম্বর, আর ওজন-করা গড়। ধরুন cost ৩০, skills ৩০, elastic ২৫, control ১০, exit ৫ ওজন, মোট ১০০. Public বিকল্পের নম্বর ৪, ৪, ৫, ২, ২ হলে গড় = (৪×৩০ + ৪×৩০ + ৫×২৫ + ২×১০ + ২×৫) ÷ ১০০ = ৩৯৫ ÷ ১০০ = ৩.৯৫. নিচের simulator একই হিসাব তিন পরিস্থিতিতে চালায়। নম্বরগুলো একটি কাল্পনিক প্রতিষ্ঠানের জন্য অনুমান; সবার জন্য নয়।

// Weighted decision matrix with a hard filter. Scores 1-5 are assumptions.
// Criteria order: cost, skills, elastic, control, exit
const options = [
  { name: 'Public (foreign region)',  inCountry: false, s: [4, 4, 5, 2, 2] },
  { name: 'Private cloud (own DC)',   inCountry: true,  s: [2, 2, 2, 5, 4] },
  { name: 'Hybrid (own DC + cloud)',  inCountry: true,  s: [3, 3, 4, 4, 3] },
  { name: 'Multi-cloud (two public)', inCountry: false, s: [2, 1, 5, 2, 5] },
];
function rank(title, weights, mustBeInCountry) {
  const total = weights.reduce((a, b) => a + b, 0);
  const rows = options
    .filter(o => !mustBeInCountry || o.inCountry)     // hard rule: filter first
    .map(o => ({ name: o.name,
      score: o.s.reduce((sum, v, i) => sum + v * weights[i], 0) / total }))
    .sort((a, b) => b.score - a.score);
  console.log(title);
  rows.forEach(r => console.log('  ' + r.score.toFixed(2) + '  ' + r.name));
}
rank('A. No hard rule',             [30, 30, 25, 10, 5], false);
rank('B. Must stay in country',     [30, 30, 25, 10, 5], true);
rank('C. Same rule, control first', [15, 15, 15, 45, 10], true);

A. No hard rule
  3.95  Public (foreign region)
  3.35  Hybrid (own DC + cloud)
  2.60  Multi-cloud (two public)
  2.40  Private cloud (own DC)
B. Must stay in country
  3.35  Hybrid (own DC + cloud)
  2.40  Private cloud (own DC)
C. Same rule, control first
  3.60  Hybrid (own DC + cloud)
  3.55  Private cloud (own DC)

এক প্রতিষ্ঠান, অনেক উত্তর

এবার পুরো কাঠামোটি একসাথে। সঞ্চয়ঘর ফিন্যান্স একটি কাল্পনিক আর্থিক প্রতিষ্ঠান। তাদের অভ্যন্তরীণ policy ধরে নিচ্ছি: গ্রাহক শনাক্ত করা যায় এমন ডেটা দেশের ভেতরে থাকবে। এটি এই উদাহরণের অনুমান, কোনো বাস্তব নিয়মের উদ্ধৃতি নয়।

১০ · AI-এর যুগে “কোথায় চালাব” প্রশ্ন

AI খুব গুছিয়ে architecture লিখে দিতে পারে, আর সেখানেই বিপদ। সে আপনার চুক্তি, নিয়ন্ত্রক বা দলের ক্ষমতা জানে না। না জানলেও আত্মবিশ্বাস নিয়ে উত্তর দেয়। Hybrid আর multi-cloud-এ ভুল এক পরিবেশে থাকে না, দুই পরিবেশের মাঝের দরজায় থাকে।

AI-এর প্রস্তাব হাতে পেলে: যাচাইয়ের চেকলিস্ট

• প্রতিটি বাধ্যবাধকতা মূল নথিতে দেখেছি, AI-এর কথায় মেনে নিইনি
• Region আর service-এর নাম provider-এর পাতায় মিলিয়েছি
• Egress, লিংক আর কর্মীর খরচ অনুমান হিসেবে লিখেছি, budget alert রেখেছি
• দুই পরিবেশের মাঝের firewall আর IAM-এ 0.0.0.0/0 বা * নেই
• লিংক কাটলে কী চলবে, তা ফেলে-দেওয়া পরিবেশে পরীক্ষা করেছি
• Secret prompt-এ দিইনি, কোডেও বসাইনি; পরিবর্তনের diff নিজে পড়েছি