কম্পিউট সার্ভিস সিলেকশন — কখন কোনটা বেছে নেবেন
এই পাঠে যা শিখবেন
- L05-L07-এর VM, অটো-স্কেলিং ও সার্ভারলেস ধারণাগুলো একটি একক সিদ্ধান্ত-কাঠামোয় কীভাবে একত্র হয়
- ট্রাফিক প্যাটার্ন, এক্সিকিউশন সময়, নিয়ন্ত্রণের প্রয়োজন ও টিমের পরিপক্বতা — চারটি মূল সিদ্ধান্ত-নির্ধারক
- প্রতিটি অপশন (VM/কন্টেইনার/সার্ভারলেস/PaaS) কখন সবচেয়ে যুক্তিসঙ্গত পছন্দ
- Python-এ একটি রুল-বেসড রিকমেন্ডেশন ফাংশন লিখে বাস্তব ওয়ার্কলোড প্রোফাইলে প্রয়োগ করা
১ · চারটি কম্পিউট অপশন — সংক্ষিপ্ত পুনরালোচনা
এই মডিউলে এ পর্যন্ত আমরা কম্পিউটের প্রধান অপশনগুলো দেখেছি — এখন সেগুলোকে একত্র করে একটি ব্যবহারিক সিদ্ধান্ত-কাঠামো তৈরি করব।
সম্পূর্ণ OS নিয়ন্ত্রণ, দীর্ঘস্থায়ী স্থির ওয়ার্কলোড, লিগ্যাসি অ্যাপ lift-and-shift।
মাইক্রোসার্ভিস, একাধিক পরিবেশে পোর্টেবিলিটি দরকার হলে।
বিক্ষিপ্ত/ইভেন্ট-ড্রিভেন কাজ, শূন্য আইডল কস্ট চাইলে।
শুধু কোডে ফোকাস করতে চান, ইনফ্রা নিয়ন্ত্রণ কম গ্রহণযোগ্য হলে।
২ · মূল সিদ্ধান্ত-নির্ধারক
- ট্রাফিক প্যাটার্ন — স্থির (steady) নাকি স্পাইকি/অনিয়মিত (spiky)?
- এক্সিকিউশন সময়কাল — কাজটি কি সেকেন্ড/মিনিটে শেষ হয়, নাকি দীর্ঘস্থায়ীভাবে চলতে থাকে?
- নিয়ন্ত্রণের প্রয়োজন — OS/রানটাইম-এ সম্পূর্ণ নিয়ন্ত্রণ সত্যিই দরকার, নাকি এটি ছেড়ে দিলে ক্ষতি নেই?
- টিমের অপারেশনাল পরিপক্বতা — টিমের কাছে কন্টেইনার/Kubernetes পরিচালনার দক্ষতা ও সময় আছে কি?
# একটি সরল রুল-বেসড কম্পিউট সার্ভিস রিকমেন্ডেশন ফাংশন
def recommend_compute_service(traffic_pattern, max_duration_sec, needs_full_control):
"""
traffic_pattern: "steady" (স্থির) বা "spiky" (অনিয়মিত/বিক্ষিপ্ত)
max_duration_sec: টাস্কের একটি এক্সিকিউশনের সর্বোচ্চ সময় (সেকেন্ডে)
needs_full_control: OS/রানটাইম-এ সম্পূর্ণ নিয়ন্ত্রণ সত্যিই দরকার কিনা
"""
if needs_full_control:
return "VM / IaaS — সম্পূর্ণ OS নিয়ন্ত্রণ দরকার অথবা লিগ্যাসি অ্যাপ lift-and-shift করতে হবে"
if traffic_pattern == "spiky" and max_duration_sec <= 900:
return "সার্ভারলেস / FaaS — বিক্ষিপ্ত ট্রাফিক, শর্ট-ডিউরেশন টাস্ক, আইডল কস্ট শূন্য (L07)"
if traffic_pattern == "steady" and max_duration_sec > 900:
return "VM / কন্টেইনার — দীর্ঘস্থায়ী স্থির ওয়ার্কলোড, সার্ভারলেসের কস্ট-ক্রসওভারের বাইরে (L07)"
if traffic_pattern == "steady":
return "PaaS / কন্টেইনার — স্থির ট্রাফিক কিন্তু ইনফ্রা ম্যানেজমেন্টের বোঝা কমাতে চান"
return "কন্টেইনার / Kubernetes — মাইক্রোসার্ভিস, একাধিক পরিবেশে পোর্টেবিলিটি দরকার"
workloads = [
{"name": "ইমেজ থাম্বনেইল জেনারেটর", "traffic_pattern": "spiky", "max_duration_sec": 5, "needs_full_control": False},
{"name": "লিগ্যাসি ERP সিস্টেম", "traffic_pattern": "steady", "max_duration_sec": 3600, "needs_full_control": True},
{"name": "স্থির-ট্রাফিক ওয়েব API", "traffic_pattern": "steady", "max_duration_sec": 200, "needs_full_control": False},
{"name": "মাইক্রোসার্ভিস ব্যাকএন্ড", "traffic_pattern": "spiky", "max_duration_sec": 1800, "needs_full_control": False},
]
for w in workloads:
rec = recommend_compute_service(w["traffic_pattern"], w["max_duration_sec"], w["needs_full_control"])
print(f"{w['name']:26} → {rec}")কোনো একক "সেরা" কম্পিউট সার্ভিস নেই — প্রতিটি অপশনের নিজস্ব ট্রেড-অফ আছে, এবং সঠিক পছন্দ নির্ভর করে ট্রাফিক প্যাটার্ন, এক্সিকিউশন সময়, নিয়ন্ত্রণের প্রয়োজন ও টিমের প্রস্তুতির উপর। এই M2 মডিউল এখানেই শেষ — পরবর্তী মডিউল M3 থেকে আমরা স্টোরেজ ও ডেটাবেস সার্ভিসে যাব।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ কেন "needs_full_control" চেক-টি ফাংশনের সবচেয়ে প্রথমে বসানো হলো, ট্রাফিক প্যাটার্নের আগে?
পূর্ণ OS নিয়ন্ত্রণের প্রয়োজন একটি "হার্ড কনস্ট্রেইন্ট" — এটি সত্য হলে অন্য কোনো ফ্যাক্টর (ট্রাফিক যত অনিয়মিতই হোক) গুরুত্বপূর্ণ থাকে না, কারণ সার্ভারলেস/PaaS-এ OS নিয়ন্ত্রণের অপশনই নেই। হার্ড কনস্ট্রেইন্টগুলো সবসময় সফট প্রেফারেন্সের (যেমন ট্রাফিক প্যাটার্ন) আগে চেক করা উচিত, নাহলে ফাংশন এমন সুপারিশ দিতে পারে যা আসলে বাস্তবায়নযোগ্যই নয়।
প্র ০২ "টিমের অপারেশনাল পরিপক্বতা" কেন একটি প্রযুক্তিগত সিদ্ধান্তের ফ্যাক্টর হওয়া উচিত?
Kubernetes প্রযুক্তিগতভাবে "সেরা" সমাধান মনে হলেও, যদি একটি ছোট টিমের কারো Kubernetes পরিচালনার অভিজ্ঞতা না থাকে, তাহলে এটি বেছে নেওয়া একটি অপারেশনাল ঝুঁকি তৈরি করে (misconfiguration, ধীর ইনসিডেন্ট-রেসপন্স)। প্রযুক্তিগত "সেরা" সমাধান আর টিমের জন্য "সঠিক" সমাধান সবসময় একই নয় — এই বাস্তবতা স্বীকার করা পরিপক্ব ইঞ্জিনিয়ারিং সিদ্ধান্তের অংশ।
প্র ০৩ একটি অ্যাপ্লিকেশন কি সময়ের সাথে একাধিক কম্পিউট মডেল ব্যবহার করতে পারে, নাকি একটিমাত্র বেছে নিতেই হয়?
বাস্তব সিস্টেমে প্রায়ই মিশ্রণ দেখা যায় — মূল অ্যাপ্লিকেশন হয়তো কন্টেইনার/Kubernetes-এ চলে, কিছু বিক্ষিপ্ত ব্যাকগ্রাউন্ড টাস্ক সার্ভারলেস ফাংশনে হ্যান্ডেল হয়, আর একটি লিগ্যাসি উপাদান এখনও একটি VM-এ থেকে যায়। এই সিদ্ধান্ত-কাঠামো একটিমাত্র বৈশ্বিক পছন্দ নয়, বরং প্রতিটি পৃথক ওয়ার্কলোডের জন্য আলাদাভাবে প্রয়োগযোগ্য একটি বিশ্লেষণ পদ্ধতি।
অনুশীলন
-
চিন্তা করুন: একটি রাত ৩টায় শিডিউল হয়ে চলা "ডেটাবেস ব্যাকআপ ক্লিনআপ" স্ক্রিপ্ট — যা
চলতে ২ মিনিট সময় নেয় এবং দিনে একবারই চলে — এই কাজের জন্য উপরের ফাংশনে কী প্যারামিটার দেবেন এবং ফলাফল
কী হবে?
এটি স্পষ্টভাবে "spiky" (দিনে একবার মাত্র চলে, বাকি সময় সম্পূর্ণ আইডল), এক্সিকিউশন সময় ২ মিনিট (১২০ সেকেন্ড, ৯০০ সেকেন্ডের সীমার অনেক নিচে), এবং পূর্ণ OS নিয়ন্ত্রণের কোনো প্রয়োজন নেই — তাই
recommend_compute_service("spiky", 120, False)কল করলে ফাংশন "সার্ভারলেস / FaaS" সুপারিশ করবে, যা এই ধরনের শিডিউলড, স্বল্প-সময়ের ব্যাকগ্রাউন্ড কাজের জন্য যথাযথ। -
পরীক্ষা করুন:
workloadsতালিকায় একটি পঞ্চম এন্ট্রি যোগ করুন —{"name": "রিয়েল-টাইম ভিডিও ট্রান্সকোডিং", "traffic_pattern": "steady", "max_duration_sec": 7200, "needs_full_control": False}— এবং দেখুন এটি কোন সুপারিশ পায়।এটি "steady" ট্রাফিক এবং ৭২০০ সেকেন্ড (৯০০ সেকেন্ডের সীমার অনেক উপরে) এক্সিকিউশন সময় — তাই দ্বিতীয় শর্তে (steady + duration > 900) মিলে যাবে এবং ফাংশন "VM / কন্টেইনার" সুপারিশ করবে, কারণ দীর্ঘস্থায়ী, স্থির-ভলিউম ট্রান্সকোডিং কাজ সার্ভারলেসের কস্ট-ক্রসওভার সীমার (L07) বাইরে চলে যায়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ পরবর্তী মডিউল — স্টোরেজ ও ডেটাবেস সার্ভিসেস — শীঘ্রই যুক্ত হবে।
- System Design & Software Architecture কোর্স সঙ্গী কোর্স মাইক্রোসার্ভিস আর্কিটেকচার ও সিস্টেম ডিজাইনের গভীর ধারণা শিখতে দেখুন।
- Cybersecurity & Ethical Hacking কোর্স সঙ্গী কোর্স প্রতিটি কম্পিউট মডেলের নিরাপত্তা বিবেচনা শিখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity ও Cloud Computing & DevOps — সব এক জায়গায়।