মেজর ক্লাউড প্রোভাইডার ওভারভিউ
এই পাঠে যা শিখবেন
- AWS, Azure ও GCP-এর সংক্ষিপ্ত, নিরপেক্ষ পরিচয় ও প্রতিটির আলাদা শক্তির জায়গা
- কেন এই কোর্সের বাকি অংশ প্রোভাইডার-নিরপেক্ষভাবে ধারণা শেখায়
- কীভাবে একই ধারণা (কম্পিউট, স্টোরেজ, ম্যানেজড Kubernetes) তিনটি প্রোভাইডারে ভিন্ন নামে পরিচিত
- Python দিয়ে একটি ক্রস-প্রোভাইডার পরিভাষা ম্যাপিং টেবিল তৈরি ও প্রিন্ট করা
১ · "বিগ থ্রি" — সংক্ষিপ্ত, নিরপেক্ষ পরিচয়
বিশ্বব্যাপী ক্লাউড মার্কেটে তিনটি প্রোভাইডার সবচেয়ে বেশি প্রভাবশালী — একে প্রায়ই "বিগ থ্রি" বলা হয়। এই পাঠে আমরা তাদের সংক্ষিপ্ত, নিরপেক্ষ পরিচয় দেখব — লক্ষ্য কোনো একটি প্রোভাইডার শেখানো নয়, বরং বোঝানো যে এই কোর্সের ধারণাগুলো তিনটির যেকোনোটির উপরই প্রযোজ্য।
সবচেয়ে বড় মার্কেট শেয়ার ও সবচেয়ে বিস্তৃত সার্ভিস ক্যাটালগ, ২০০৬ সালে চালু — ক্লাউড ইন্ডাস্ট্রির প্রথম মুভার।
Microsoft ইকোসিস্টেম (Windows Server, Active Directory, Office 365)-এর সাথে গভীর ইন্টিগ্রেশন — শক্তিশালী এন্টারপ্রাইজ উপস্থিতি।
শক্তিশালী ডেটা/ML টুলিং এবং Kubernetes-এর জন্মস্থান — Google-ই মূলত Kubernetes তৈরি ও ওপেন-সোর্স করেছিল।
বাস্তব চাকরির বাজারে আপনি যেকোনো একটি (বা একাধিক) প্রোভাইডারের সাথে কাজ করতে পারেন — সিদ্ধান্ত প্রায়ই আপনার প্রতিষ্ঠান, টিমের বিদ্যমান দক্ষতা বা নির্দিষ্ট প্রয়োজনের উপর নির্ভর করে, আপনার ব্যক্তিগত পছন্দের উপর নয়। তাই এই কোর্স ইচ্ছাকৃতভাবে ধারণা শেখায় (VM কী, লোড ব্যালেন্সিং কীভাবে কাজ করে, IaC-এর নীতি কী) — একবার ধারণা পরিষ্কার হয়ে গেলে, যেকোনো প্রোভাইডারের নির্দিষ্ট ডকুমেন্টেশন পড়ে দ্রুত মানিয়ে নেওয়া সম্ভব।
২ · একই ধারণা, ভিন্ন নাম
একটি গুরুত্বপূর্ণ পর্যবেক্ষণ — তিনটি প্রোভাইডারই একই মৌলিক ধারণাগুলো অফার করে, শুধু সার্ভিসের নাম আলাদা। উদাহরণস্বরূপ, "একটি ভার্চুয়াল মেশিন চালানো" (L05) AWS-এ EC2, Azure-এ Azure VMs, আর GCP-তে Compute Engine নামে পরিচিত — কিন্তু আন্ডারলাইং ধারণা (হাইপারভাইজার-ভিত্তিক ভার্চুয়ালাইজেশন, ইনস্ট্যান্স টাইপ, ঘণ্টাপ্রতি বিলিং) একই।
৩ · ক্রস-প্রোভাইডার পরিভাষা ম্যাপিং — Python উদাহরণ
নিচের কোড সেলে আমরা কয়েকটি মূল ধারণার জন্য তিনটি প্রোভাইডারের সার্ভিস নাম ম্যাপ করব — এই টেবিলের গুরুত্বপূর্ণ বিষয়টি হলো নাম নয়, বরং এটি প্রমাণ করা যে ধারণা (এই কোর্স যা শেখায়) স্থানান্তরযোগ্য, এমনকি সার্ভিস নাম আলাদা হলেও।
# ক্রস-প্রোভাইডার পরিভাষা ম্যাপিং টেবিল (illustrative, সংক্ষিপ্ত — সম্পূর্ণ তালিকা নয়)
concept_mapping = {
"ভার্চুয়াল মেশিন (কম্পিউট)": {
"aws_name": "EC2",
"azure_name": "Azure VMs",
"gcp_name": "Compute Engine",
},
"অবজেক্ট স্টোরেজ": {
"aws_name": "S3",
"azure_name": "Blob Storage",
"gcp_name": "Cloud Storage",
},
"ম্যানেজড Kubernetes": {
"aws_name": "EKS",
"azure_name": "AKS",
"gcp_name": "GKE",
},
}
print(f"{'ধারণা':28}{'AWS':12}{'Azure':14}{'GCP'}")
for concept, names in concept_mapping.items():
print(f"{concept:28}{names['aws_name']:12}{names['azure_name']:14}{names['gcp_name']}")প্রোভাইডার বেছে নেওয়া একটি বাস্তব-জগতের সিদ্ধান্ত (চাকরি, প্রতিষ্ঠান, নির্দিষ্ট প্রয়োজনের উপর ভিত্তি করে), কিন্তু এই কোর্সের লক্ষ্য আপনাকে সেই ধারণাগুলো শেখানো যা যেকোনো প্রোভাইডারেই প্রযোজ্য। M2 থেকে শুরু করে (কম্পিউট সার্ভিসেস) আমরা এই ধারণাগুলোর গভীরে যাব — সবসময় প্রোভাইডার-নিরপেক্ষভাবে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটি ইঞ্জিনিয়ার শুধু একটি নির্দিষ্ট প্রোভাইডারের টুল শিখলে দীর্ঘমেয়াদে কেন সীমাবদ্ধ হয়ে যেতে পারেন?
যদি কেউ শুধু নির্দিষ্ট সার্ভিস নাম ও সেই প্রোভাইডারের কনসোলের বাটন-ক্লিক মুখস্থ করে, কিন্তু আন্ডারলাইং ধারণা (VM কী, কেন লোড ব্যালেন্সিং দরকার) বোঝেন না, তাহলে চাকরি পরিবর্তন করে ভিন্ন প্রোভাইডার ব্যবহার করা প্রতিষ্ঠানে গেলে তাকে আবার নতুন করে শিখতে হবে। যিনি ধারণা বোঝেন, তার জন্য নতুন প্রোভাইডার মানানো শুধু নতুন নাম শেখা — মৌলিক চিন্তাভাবনা একই থাকে।
প্র ০২ একটি প্রতিষ্ঠান কেন সচেতনভাবে একাধিক ক্লাউড প্রোভাইডার (মাল্টি-ক্লাউড) ব্যবহার করার সিদ্ধান্ত নিতে পারে?
কিছু কারণ হতে পারে — একটি নির্দিষ্ট প্রোভাইডারের উপর সম্পূর্ণ নির্ভরশীলতা এড়ানো ("ভেন্ডর লক-ইন" ঝুঁকি কমানো), বিভিন্ন প্রোভাইডারের ভিন্ন শক্তির জায়গা কাজে লাগানো (যেমন GCP-এর ML টুলিং এবং AWS-এর ব্যাপক সার্ভিস ক্যাটালগ একসাথে ব্যবহার), অথবা একটি অঞ্চলে একটি প্রোভাইডারের ভালো উপস্থিতি না থাকলে সেই অঞ্চলের জন্য ভিন্ন প্রোভাইডার বেছে নেওয়া। এই কৌশলগুলো L52-এ বিস্তারিত আসবে।
প্র ০৩ Kubernetes মূলত Google তৈরি করেছিল এই তথ্যটি কীভাবে GCP-এর "শক্তিশালী Kubernetes অরিজিন" দাবিকে ব্যাখ্যা করে?
Google অভ্যন্তরীণভাবে বছরের পর বছর ধরে "Borg" নামে একটি বিশাল-স্কেল কন্টেইনার অর্কেস্ট্রেশন সিস্টেম চালিয়ে অভিজ্ঞতা অর্জন করেছিল, এবং সেই অভিজ্ঞতা থেকে Kubernetes ডিজাইন ও ওপেন-সোর্স করেছিল। ফলে GCP-এর নিজস্ব ম্যানেজড Kubernetes সার্ভিস (GKE) প্রায়ই সবচেয়ে পরিপক্ব ও গভীরভাবে ইন্টিগ্রেটেড বলে বিবেচিত হয় — যদিও AWS-এর EKS ও Azure-এর AKS একই মূল ওপেন-সোর্স Kubernetes ব্যবহার করে, তাই মৌলিক ধারণাগুলো (M7) সব জায়গাতেই একই থাকে।
অনুশীলন
-
চিন্তা করুন: "ভেন্ডর লক-ইন" শব্দটি আপনি কীভাবে ব্যাখ্যা করবেন — কেন একটি প্রোভাইডারের নির্দিষ্ট (নন-স্ট্যান্ডার্ড) ফিচার বেশি ব্যবহার করলে এই ঝুঁকি বাড়ে?
ভেন্ডর লক-ইন মানে একটি প্রোভাইডার থেকে অন্যটিতে সরে যাওয়া এত ব্যয়বহুল বা জটিল হয়ে ওঠে যে বাস্তবে আটকে থাকতে হয়। যদি আপনার অ্যাপ্লিকেশন একটি প্রোভাইডারের অনন্য, নন-স্ট্যান্ডার্ড ফিচারের উপর ভারীভাবে নির্ভর করে (যা অন্য কোনো প্রোভাইডারে নেই), তাহলে ভবিষ্যতে সরে যেতে চাইলে সেই অংশ পুরোপুরি নতুন করে ডিজাইন করতে হবে — এই ঝুঁকিই L52-এর মূল বিষয়।
-
পরীক্ষা করুন: উপরের কোড সেলে "সার্ভারলেস ফাংশন" নামে একটি নতুন এন্ট্রি যোগ করুন (aws_name="Lambda", azure_name="Azure Functions", gcp_name="Cloud Functions") এবং টেবিলে দেখুন।
dict-এ নতুন এন্ট্রি যোগ করলে লুপ স্বয়ংক্রিয়ভাবে সেটিও প্রিন্ট করবে — এটি দেখায় সার্ভারলেস কম্পিউট (L07-এ বিস্তারিত) ধারণাটিও তিনটি প্রোভাইডারেই একইভাবে বিদ্যমান, শুধু নাম আলাদা।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ পরবর্তী পাঠ — ভার্চুয়াল মেশিন ও ইনস্ট্যান্স টাইপ (মডিউল ২ শুরু) — শীঘ্রই যুক্ত হবে।
- System Design & Software Architecture কোর্স সঙ্গী কোর্স যে সিস্টেম আপনি ক্লাউডে ডিপ্লয় করবেন তার আর্কিটেকচার ডিজাইন শিখতে দেখুন।
- Cybersecurity & Ethical Hacking কোর্স সঙ্গী কোর্স ক্লাউড ও DevOps পাইপলাইন নিরাপদ রাখার কৌশল শিখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity ও Cloud Computing & DevOps — সব এক জায়গায়।