পাঠ ০৩ · ৫৭-এর মধ্যে · মডিউল ১
Home / Courses / Cloud Computing & DevOps / ইকোনমিক্স

ক্লাউড ইকোনমিক্স — CapEx বনাম OpEx

Cloud economics — CapEx vs OpEx
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • CapEx ও OpEx-এর সংজ্ঞা এবং কেন ক্লাউড কম্পিউটিং একটি খরচ-মডেল পরিবর্তনও বটে
  • Total Cost of Ownership (TCO) কীভাবে হিসাব করা হয় — শুধু কাঁচা কম্পিউট-ঘণ্টার দাম নয়
  • ওভার-প্রভিশনিং ও আন্ডার-প্রভিশনিংয়ের ঝুঁকি অন-প্রিমাইজ ক্যাপাসিটি পরিকল্পনায়
  • Python দিয়ে একটি ৩-বছরের অন-প্রিমাইজ বনাম ক্লাউড খরচ তুলনার হিসাব

১ · CapEx বনাম OpEx

ঐতিহ্যবাহী IT বিনিয়োগ ছিল প্রধানত CapExCapital Expenditureফিজিক্যাল সম্পদ (যেমন সার্ভার হার্ডওয়্যার) কেনার জন্য একটি বড় আগাম বিনিয়োগ, যা কয়েক বছর ধরে হিসাবের খাতায় ডেপ্রিসিয়েট (মূল্য-হ্রাস) হতে থাকে। — একবারে বড় অঙ্কের টাকা দিয়ে সার্ভার হার্ডওয়্যার কেনা, যা কয়েক বছর ধরে ব্যবহার করা হয় এবং ধীরে ধীরে হিসাবের খাতায় ডেপ্রিসিয়েট (মূল্য-হ্রাস) হয়। এর জন্য নির্ভুলভাবে ভবিষ্যতের সর্বোচ্চ চাহিদা অনুমান করে ক্যাপাসিটি ঠিক করতে হয় — একবার হার্ডওয়্যার কেনা হয়ে গেলে তা বাড়ানো সহজ নয়।

ক্লাউড কম্পিউটিং এই মডেলকে OpExOperational Expenditureচলমান, ব্যবহার-ভিত্তিক খরচ — যেমন মাসিক ক্লাউড বিল — যেখানে কোনো বড় আগাম বিনিয়োগ ছাড়াই ব্যবহার অনুযায়ী টাকা দেওয়া হয়। -এ রূপান্তরিত করে — কোনো আগাম বিনিয়োগ ছাড়াই, ঠিক যতটুকু ব্যবহার করেছেন ততটুকুর জন্য মাসিক বিল আসে। এতে ছোট শুরু করে ধীরে ধীরে স্কেল করা সহজ হয়ে যায়, এবং ভুল ক্যাপাসিটি অনুমানের ঝুঁকিও প্রোভাইডারের ঘাড়ে চলে যায়।

CapEx (অন-প্রিমাইজ)
বড় আগাম খরচ, বছরের পর বছর ডেপ্রিসিয়েশন, নির্ভুল ক্যাপাসিটি পূর্বাভাস দরকার।
OpEx (ক্লাউড)
কোনো আগাম খরচ নেই, ব্যবহার-অনুযায়ী মাসিক বিল, চাহিদা অনুযায়ী তাৎক্ষণিক স্কেলিং।
ওভার-প্রভিশনিং — CapEx মডেলের লুকানো খরচ

যেহেতু হার্ডওয়্যার কেনার পর বাড়ানো কঠিন, প্রতিষ্ঠানগুলো প্রায়ই ভবিষ্যতের সর্বোচ্চ সম্ভাব্য চাহিদা ধরে ক্যাপাসিটি কেনে ("নিরাপদ থাকার জন্য")। ফলাফল — বেশিরভাগ সময় সেই ক্যাপাসিটির একটি বড় অংশ অলস পড়ে থাকে (ওভার-প্রভিশনড), যার জন্য টাকা দেওয়া হয়েছে কিন্তু ব্যবহার হচ্ছে না। ক্লাউডে এই অপচয় দূর হয় — মেজার্ড সার্ভিস (L01) মডেলে শুধু প্রকৃত ব্যবহারের জন্য বিল হয়।

২ · Total Cost of Ownership (TCO) — শুধু কাঁচা দামের হিসাব নয়

অনেকে ভুল করে শুধু "কম্পিউট-ঘণ্টা প্রতি দাম" তুলনা করেন এবং সিদ্ধান্তে আসেন অন-প্রিমাইজ সস্তা। কিন্তু TCOTotal Cost of Ownershipএকটি সিস্টেম চালানোর সম্পূর্ণ প্রকৃত খরচ — শুধু হার্ডওয়্যার/কম্পিউট দামই নয়, স্টাফিং, রক্ষণাবেক্ষণ, বিদ্যুৎ, ঠান্ডা রাখা ও ওভার-প্রভিশনিংয়ের অপচয়ও। হিসাবে যোগ করতে হয় — সার্ভার রুম রক্ষণাবেক্ষণকারী স্টাফের বেতন, বিদ্যুৎ ও কুলিং খরচ, হার্ডওয়্যার ব্যর্থতার মেরামত, এবং সবচেয়ে বড় বিষয় — ওভার-প্রভিশনিংয়ের কারণে অলস পড়ে থাকা ক্যাপাসিটির খরচ। এই সবকিছু হিসাবে নিলে ক্লাউড প্রায়ই TCO-তে জেতে, যদিও কাঁচা কম্পিউট-ঘণ্টার দামে এটি সবসময় সবচেয়ে সস্তা নাও হতে পারে।

৩ · একটি ৩-বছরের খরচ তুলনা — উদাহরণ

নিচের কোড সেলে আমরা একটি ইলাস্ট্রেটিভ উদাহরণ হিসাব করব — একটি ফিক্সড অন-প্রিমাইজ সার্ভার কেনা (আগাম CapEx + বার্ষিক রক্ষণাবেক্ষণ) বনাম একটি ক্লাউড ইনস্ট্যান্স যা প্রকৃত (ওঠানামা করা) মাসিক ব্যবহার অনুযায়ী ঘণ্টাপ্রতি বিল হয়।

Python
# ৩-বছরের খরচ তুলনা: অন-প্রিমাইজ (CapEx) বনাম ক্লাউড (OpEx) — সব সংখ্যা ইলাস্ট্রেটিভ

# --- অন-প্রিমাইজ (CapEx) ---
server_purchase_cost = 300_000       # আগাম হার্ডওয়্যার খরচ (টাকা)
annual_maintenance_cost = 40_000     # বার্ষিক রক্ষণাবেক্ষণ (স্টাফ, বিদ্যুৎ, কুলিং)
years = 3

on_prem_total = server_purchase_cost + (annual_maintenance_cost * years)

# --- ক্লাউড (OpEx) ---
hourly_rate = 15                     # প্রতি ঘণ্টা ইনস্ট্যান্স খরচ (টাকা)
# প্রতি মাসে ব্যবহারের ঘণ্টা ওঠানামা করে (কম-ট্রাফিক ও উচ্চ-ট্রাফিক মাস মিশিয়ে)
monthly_usage_hours = [
    400, 420, 380, 500, 600, 720,   # বছর ১ — ধীরে ধীরে বৃদ্ধি
    650, 600, 550, 500, 480, 460,   # বছর ২ — স্থিতিশীল
    500, 520, 540, 560, 580, 600,   # বছর ৩ — সামান্য বৃদ্ধি
] * 2  # ৩৬ মাস তৈরির জন্য পুনরাবৃত্তি (উদাহরণের সরলীকরণ)
monthly_usage_hours = monthly_usage_hours[:36]

cloud_total = sum(hours * hourly_rate for hours in monthly_usage_hours)

print(f"অন-প্রিমাইজ ৩-বছরের মোট খরচ: {on_prem_total:,} টাকা")
print(f"ক্লাউড ৩-বছরের মোট খরচ:     {cloud_total:,} টাকা")

if cloud_total < on_prem_total:
    savings = on_prem_total - cloud_total
    print(f"→ ক্লাউড সাশ্রয়ী: {savings:,} টাকা কম (স্টাফিং/ওভার-প্রভিশনিং হিসাব ছাড়াই)")
else:
    extra = cloud_total - on_prem_total
    print(f"→ অন-প্রিমাইজ সস্তা: {extra:,} টাকা কম (কিন্তু TCO-তে স্টাফিং/কুলিং যোগ করলে ফলাফল পাল্টাতে পারে)")

    
এই হিসাবে অন-প্রিমাইজের বার্ষিক রক্ষণাবেক্ষণ খরচ ধরা হয়েছে, কিন্তু স্টাফ নিয়োগ, ওভার-প্রভিশনিংয়ের অপচয়, বা হঠাৎ হার্ডওয়্যার ব্যর্থতার মতো খরচ ধরা হয়নি — বাস্তব TCO হিসাবে এগুলো যোগ করলে ক্লাউডের পক্ষে ব্যবধান সাধারণত আরও বাড়ে। সংখ্যাগুলো ইলাস্ট্রেটিভ — বাস্তব সিদ্ধান্তে আপনার নিজস্ব প্রকৃত ব্যবহারের প্যাটার্ন বিশ্লেষণ করা জরুরি।

৪ · কখন CapEx এখনও যুক্তিসঙ্গত হতে পারে

TCO প্রায়ই ক্লাউডের পক্ষে গেলেও, এর মানে এই নয় CapEx সবসময় ভুল। খুব স্থিতিশীল, পূর্বাভাসযোগ্য, দীর্ঘমেয়াদী উচ্চ-ভলিউম ওয়ার্কলোডের ক্ষেত্রে (যেখানে ব্যবহার প্রায় কখনও ওঠানামা করে না এবং ক্যাপাসিটি সবসময় প্রায় সম্পূর্ণ ব্যবহৃত হয়) অন-প্রিমাইজ হার্ডওয়্যার এখনও কাঁচা খরচে প্রতিযোগিতামূলক হতে পারে — এই সিদ্ধান্ত-কাঠামো L08 ও L49-51-এ (কম্পিউট সার্ভিস সিলেকশন ও FinOps) আরও বিস্তারিতভাবে ফিরে আসবে।

মূল কথা · Key takeaway

ক্লাউড শুধু একটি প্রযুক্তিগত পরিবর্তন নয় — এটি একটি আর্থিক মডেল পরিবর্তনও (CapEx → OpEx)। সিদ্ধান্ত নেওয়ার সময় শুধু কাঁচা কম্পিউট-ঘণ্টার দাম নয়, বরং সম্পূর্ণ TCO (স্টাফিং, রক্ষণাবেক্ষণ, ওভার-প্রভিশনিং) বিবেচনা করা জরুরি — এবং সেই হিসাবের জন্য আপনার নিজস্ব ব্যবহারের প্যাটার্ন বুঝতে হবে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন শুধু "প্রতি কম্পিউট-ঘণ্টা দাম" তুলনা করে ক্লাউড বনাম অন-প্রিমাইজ সিদ্ধান্ত নেওয়া বিভ্রান্তিকর হতে পারে?

কারণ এতে TCO-এর অনেক লুকানো উপাদান বাদ পড়ে যায় — স্টাফিং, বিদ্যুৎ/কুলিং, হার্ডওয়্যার ব্যর্থতার মেরামত, এবং সবচেয়ে গুরুত্বপূর্ণ, ওভার-প্রভিশনিংয়ের কারণে অলস ক্যাপাসিটির অপচয়। শুধু কাঁচা দাম তুলনা করলে অন-প্রিমাইজকে ভুলভাবে সস্তা মনে হতে পারে, যখন প্রকৃতপক্ষে সম্পূর্ণ প্রকৃত খরচ হিসাব করলে ক্লাউড জিততে পারে।

প্র ০২ একটি অত্যন্ত স্থিতিশীল, সবসময়-উচ্চ-ব্যবহারের ওয়ার্কলোডের জন্য কেন CapEx এখনও প্রতিযোগিতামূলক হতে পারে?

যদি ক্যাপাসিটি প্রায় সবসময় সম্পূর্ণ ব্যবহৃত হয় (কোনো ওভার-প্রভিশনিংয়ের অপচয় নেই) এবং ব্যবহারের প্যাটার্ন বছরের পর বছর অনুমানযোগ্য থাকে, তাহলে ক্লাউডের "নমনীয়তার প্রিমিয়াম" (যা প্রোভাইডার তার বিলে ধরে) থেকে কোনো সুবিধা পাওয়া যায় না — কারণ কখনওই স্কেল আপ/ডাউন করার প্রয়োজন হয় না। এই বিশেষ ক্ষেত্রে অন-প্রিমাইজ হার্ডওয়্যার কাঁচা খরচে প্রতিযোগিতামূলক থাকতে পারে।

প্র ০৩ ওভার-প্রভিশনিং কেন শুধু আর্থিক অপচয় নয়, বরং একটি অপারেশনাল ঝুঁকিও তৈরি করে?

ওভার-প্রভিশনিং মানে হলো ভুল অনুমান — যদি অনুমান খুব বেশি হয় তাহলে টাকা অপচয় হয়, কিন্তু যদি অনুমান কম হয়ে যায় (আন্ডার-প্রভিশনিং) তাহলে হঠাৎ ট্রাফিক স্পাইকে সিস্টেম ওভারলোড হয়ে পড়ে যেতে পারে — উভয়ই একই মূল সমস্যার দুই দিক (ভবিষ্যতের চাহিদা নিখুঁতভাবে অনুমান করার অক্ষমতা)। ক্লাউডের ইলাস্টিসিটি (L01) এই গোটা সমস্যাটিই দূর করে দেয়, কারণ ক্যাপাসিটি প্রকৃত চাহিদা অনুযায়ী রিয়েল-টাইমে সামঞ্জস্য হয়।

অনুশীলন

  1. চিন্তা করুন: আপনার পরিচিত একটি ছোট প্রতিষ্ঠানের কথা চিন্তা করুন — তাদের জন্য CapEx (নিজস্ব সার্ভার) নাকি OpEx (ক্লাউড) বেশি যুক্তিসঙ্গত হবে বলে মনে করেন, এবং কেন?

    বেশিরভাগ ছোট/নতুন প্রতিষ্ঠানের জন্য OpEx (ক্লাউড) যুক্তিসঙ্গত — সীমিত আগাম মূলধন, অনিশ্চিত ভবিষ্যৎ চাহিদা, এবং ইন-হাউস IT স্টাফের অভাব থাকার কারণে বড় CapEx বিনিয়োগ ও পরিচালন-দায়িত্ব বহন করা কঠিন। ব্যতিক্রম হতে পারে যদি প্রতিষ্ঠানটির নিজস্ব ডেটা সেন্টার চালানোর গভীর অভিজ্ঞতা ও অত্যন্ত পূর্বাভাসযোগ্য উচ্চ-ভলিউম ওয়ার্কলোড থাকে।

  2. পরীক্ষা করুন: উপরের কোড সেলে `hourly_rate`-কে ২৫ টাকায় বাড়িয়ে আবার চালান — কোন পয়েন্টে ক্লাউড আর সাশ্রয়ী থাকে না?

    `hourly_rate` বাড়ালে `cloud_total` বাড়বে, এবং একটি নির্দিষ্ট রেটের পর তা `on_prem_total`-কে ছাড়িয়ে যাবে — এটি দেখায় প্রতিটি সিদ্ধান্ত নির্দিষ্ট সংখ্যার (দাম, ব্যবহারের প্যাটার্ন) উপর নির্ভরশীল, কোনো চিরন্তন সত্য নয়। বাস্তব সিদ্ধান্তে সবসময় আপনার নিজস্ব প্রকৃত রেট ও প্যাটার্ন দিয়ে হিসাব করা জরুরি।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
পাবলিক, প্রাইভেট ও হাইব্রিড ক্লাউড