পাঠ ০১ · ৫৭-এর মধ্যে · মডিউল ১
Home / Courses / Cloud Computing & DevOps / পরিচিতি

ক্লাউড কম্পিউটিং কী ও DevOps পরিচিতি

What is cloud computing & DevOps
৯ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

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

  • ক্লাউড কম্পিউটিং-এর পাঁচটি মূল বৈশিষ্ট্য এবং কেন এটি ঐতিহ্যবাহী অন-প্রিমাইজ ইনফ্রাস্ট্রাকচার থেকে আলাদা
  • IaaS, PaaS ও SaaS-এর পার্থক্য এবং প্রতিটিতে আপনার দায়িত্ব কতটা
  • DevOps আসলে কী — একটি টুলসেট নয়, বরং একটি কালচার ও প্র্যাকটিস
  • DORA মেট্রিক্স দিয়ে DevOps পারফরম্যান্স কীভাবে পরিমাপ করা হয় — Python দিয়ে একটি ছোট্ট তুলনামূলক উদাহরণ

১ · ক্লাউড কম্পিউটিং কী

ক্লাউড কম্পিউটিংCloud Computingইন্টারনেটের মাধ্যমে কম্পিউটিং রিসোর্স (সার্ভার, স্টোরেজ, ডেটাবেস, নেটওয়ার্কিং) অন-ডিমান্ড ভাড়া নেওয়ার মডেল — নিজে হার্ডওয়্যার কিনে বসাতে হয় না। -এর একটি ব্যাপকভাবে গৃহীত সংজ্ঞা (NIST-এর মতো মানসম্মত সংস্থা অনুযায়ী) পাঁচটি মূল বৈশিষ্ট্যের উপর ভিত্তি করে —

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

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

২ · IaaS, PaaS ও SaaS — দায়িত্বের স্পেকট্রাম

ক্লাউড সার্ভিসগুলো কতটা "রেডিমেড" তার উপর ভিত্তি করে তিনটি স্তরে ভাগ করা হয় — প্রতিটি স্তরে আপনার নিজের ব্যবস্থাপনার দায়িত্ব কমতে থাকে, প্রোভাইডারের দায়িত্ব বাড়তে থাকে।

  • IaaSInfrastructure as a Serviceকাঁচা ভার্চুয়াল মেশিন, স্টোরেজ ও নেটওয়ার্ক ভাড়া — আপনি নিজে অপারেটিং সিস্টেম, রানটাইম ও অ্যাপ্লিকেশন ম্যানেজ করেন। উদাহরণ: AWS EC2। (Infrastructure as a Service) — কাঁচা ভার্চুয়াল মেশিন/স্টোরেজ/নেটওয়ার্ক পান, বাকি সব (OS, রানটাইম, অ্যাপ) আপনার দায়িত্ব। সর্বোচ্চ নিয়ন্ত্রণ, সর্বোচ্চ দায়িত্ব।
  • PaaSPlatform as a Serviceআপনি শুধু কোড ডিপ্লয় করেন — অপারেটিং সিস্টেম, রানটাইম, স্কেলিং প্ল্যাটফর্ম নিজে ম্যানেজ করে। উদাহরণ: Google App Engine, Heroku। (Platform as a Service) — আপনি শুধু কোড দেন, প্ল্যাটফর্ম OS/রানটাইম/স্কেলিং নিজে সামলায়। মাঝামাঝি নিয়ন্ত্রণ, মাঝামাঝি দায়িত্ব।
  • SaaSSoftware as a Serviceসম্পূর্ণ রেডিমেড অ্যাপ্লিকেশন ব্যবহার করেন, ইনফ্রাস্ট্রাকচারের কিছুই দেখতে বা ম্যানেজ করতে হয় না। উদাহরণ: Gmail, Google Docs। (Software as a Service) — সম্পূর্ণ রেডিমেড অ্যাপ ব্যবহার করেন, ইনফ্রাস্ট্রাকচার সম্পূর্ণ প্রোভাইডারের দায়িত্ব। ন্যূনতম নিয়ন্ত্রণ, ন্যূনতম দায়িত্ব।
IaaS আপনার দায়িত্ব বেশি PaaS দায়িত্ব ভাগাভাগি SaaS প্রোভাইডারের দায়িত্ব বেশি
IaaS → PaaS → SaaS — যত ডানে যাবেন, ইনফ্রাস্ট্রাকচার ব্যবস্থাপনার দায়িত্ব তত কমবে, কিন্তু নিয়ন্ত্রণও তত কমবে।

৩ · DevOps কী — একটি কালচার, শুধু টুল নয়

ঐতিহ্যবাহীভাবে Development (নতুন ফিচার দ্রুত শিপ করতে চায়) ও Operations (সিস্টেম স্থিতিশীল রাখতে চায়, তাই পরিবর্তন এড়িয়ে চলতে চায়) — এই দুই টিমের লক্ষ্য পরস্পরবিরোধী ছিল, যা ধীর, ঘর্ষণপূর্ণ রিলিজ প্রক্রিয়ার জন্ম দিত। DevOpsDevOpsDevelopment ও Operations টিমকে একত্র করার কালচার ও প্র্যাকটিস — স্বয়ংক্রিয়করণ ও দ্রুত ফিডব্যাক লুপের মাধ্যমে দ্রুত, নির্ভরযোগ্য সফটওয়্যার ডেলিভারি নিশ্চিত করা। এই বিভাজন দূর করে — উভয় টিম একসাথে দায়িত্ব নেয়, স্বয়ংক্রিয়করণের মাধ্যমে দ্রুত কিন্তু নিরাপদ রিলিজ সম্ভব করে।

C — Culture
সাইলো ভেঙে শেয়ার্ড দায়িত্ব ও সহযোগিতার সংস্কৃতি।
A — Automation
ম্যানুয়াল, ভুল-প্রবণ ধাপ (বিল্ড, টেস্ট, ডিপ্লয়) স্বয়ংক্রিয় করা।
L — Lean
ছোট, ঘনঘন পরিবর্তন — বড়, বিরল, ঝুঁকিপূর্ণ রিলিজের বদলে।
M — Measurement
প্রতিটি পরিবর্তনের প্রভাব ডেটা দিয়ে পরিমাপ করা (L41-এর মনিটরিং)।
S — Sharing
জ্ঞান, টুল ও শেখার অভিজ্ঞতা টিমগুলোর মধ্যে খোলাখুলি শেয়ার করা।
DevOps লাইফসাইকেল — একটি চক্র, একমুখী প্রক্রিয়া নয়

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor — এবং মনিটরিং থেকে পাওয়া ফিডব্যাক আবার Plan-এ ফিরে যায়। এটি একটি অবিচ্ছিন্ন চক্র (তাই একে প্রায়ই "ইনফিনিটি লুপ" হিসেবে আঁকা হয়) — প্রতিটি রিলিজের পর শেখা জিনিস পরবর্তী পরিকল্পনাকে প্রভাবিত করে। এই কোর্সের M5-M12 প্রতিটি এই চক্রের একটি নির্দিষ্ট অংশের হাতিয়ার শেখায় (IaC, Docker/Kubernetes, CI/CD, মনিটরিং)।

৪ · DORA মেট্রিক্স — DevOps পারফরম্যান্স পরিমাপ করা

DevOps "ভালো করছে কি না" তা অনুভূতির বদলে সংখ্যা দিয়ে বলা যায় — গবেষণায় সবচেয়ে বহুল-ব্যবহৃত চারটি মেট্রিক্স (DORA মেট্রিক্স নামে পরিচিত) হলো —

  • ডিপ্লয়মেন্ট ফ্রিকোয়েন্সি — কতবার প্রোডাকশনে ডিপ্লয় হয় (দিনে অনেকবার = "elite", মাসে একবারের কম = "low")।
  • লিড টাইম ফর চেঞ্জেস — কোড কমিট থেকে প্রোডাকশনে পৌঁছাতে কত সময় লাগে।
  • চেঞ্জ ফেইলিওর রেট — কত শতাংশ ডিপ্লয়মেন্ট প্রোডাকশনে সমস্যা তৈরি করে (রোলব্যাক/হটফিক্স লাগে)।
  • টাইম টু রিস্টোর সার্ভিস — একটি প্রোডাকশন ইনসিডেন্ট থেকে সার্ভিস পুরোপুরি সুস্থ হতে কত সময় লাগে।
Python
# উদাহরণস্বরূপ দুটি টিমের DORA মেট্রিক্স তুলনা (illustrative, বাস্তব কোনো টিমের ডেটা নয়)
teams = {
    "উচ্চ-পারফরম্যান্স টিম": {
        "deploys_per_day": 5,
        "lead_time_hours": 1,
        "change_failure_rate_pct": 10,
        "restore_time_hours": 1,
    },
    "নিম্ন-পারফরম্যান্স টিম": {
        "deploys_per_day": 0.03,   # প্রায় মাসে একবার
        "lead_time_hours": 720,     # ~১ মাস
        "change_failure_rate_pct": 50,
        "restore_time_hours": 168,  # ~১ সপ্তাহ
    },
}

print(f"{'মেট্রিক্স':32}{'উচ্চ-পারফরম্যান্স':20}{'নিম্ন-পারফরম্যান্স'}")
for metric in teams["উচ্চ-পারফরম্যান্স টিম"]:
    high = teams["উচ্চ-পারফরম্যান্স টিম"][metric]
    low = teams["নিম্ন-পারফরম্যান্স টিম"][metric]
    print(f"{metric:32}{high:<20}{low}")

    


    

      লক্ষ্য করুন পার্থক্যের মাত্রা — উচ্চ-পারফরম্যান্স টিম দিনে একাধিকবার ডিপ্লয় করে (লিড টাইম ঘণ্টায়), আর নিম্ন-পারফরম্যান্স
      টিম মাসে একবার (লিড টাইম মাসে) — প্রায় ১০০x পার্থক্য! এই সংখ্যাগুলো ইলাস্ট্রেটিভ উদাহরণ, কিন্তু এই ধরনের বিশাল
      ব্যবধান বাস্তব শিল্প-গবেষণায় (State of DevOps রিপোর্ট) বারবার পরিলক্ষিত হয়েছে — এই কোর্সের বাকি অংশ ঠিক এই
      ব্যবধান কমানোর হাতিয়ার শেখায়।
    


    
৫ · এই কোর্স ও System Design/Cybersecurity কোর্সের সম্পর্ক

    

      System Design কোর্স শেখায় কীভাবে একটি সিস্টেমের আর্কিটেকচার ডিজাইন
      করতে হয় (স্কেলেবিলিটি, ডেটাবেস, ক্যাশিং প্যাটার্ন), আর Cybersecurity
      কোর্স শেখায় কীভাবে সেই সিস্টেমকে নিরাপদ রাখতে হয়। এই কোর্স তৃতীয় স্তম্ভ যোগ করে — কীভাবে সেই ডিজাইন করা,
      নিরাপদ সিস্টেমকে বাস্তবে ক্লাউডে বিল্ড, ডিপ্লয় ও প্রতিদিন অপারেট করা যায়। তিনটি কোর্স একসাথে একজন
      ইঞ্জিনিয়ারকে ডিজাইন থেকে প্রোডাকশন পর্যন্ত সম্পূর্ণ পথ দেখায়।
    


    

      মূল কথা · Key takeaway
      

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

    


  


  

    
    
  


  

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

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


    

      
        প্র ০১
        একটি স্টার্টআপ কেন IaaS দিয়ে শুরু না করে সরাসরি PaaS বা SaaS বেছে নিতে পারে, এমনকি যদি তারা কিছু নিয়ন্ত্রণ হারায়?
      
      

        

          একটি ছোট টিমের জন্য OS প্যাচিং, স্কেলিং লজিক, সার্ভার ম্যানেজমেন্ট নিজে হাতে করা সময় ও দক্ষতার অপচয় হতে
          পারে — বিশেষ করে যখন তাদের মূল ফোকাস হওয়া উচিত প্রোডাক্ট/ফিচার বানানো। PaaS/SaaS বেছে নিলে তারা কম
          নিয়ন্ত্রণের বিনিময়ে দ্রুত গতি ও কম অপারেশনাল বোঝা পায় — একটি ইঞ্জিনিয়ারিং-রিসোর্স-সীমিত স্টার্টআপের জন্য
          প্রায়ই এটি সঠিক ট্রেড-অফ।
        

      

    


    

      
        প্র ০২
        DevOps-কে "শুধু একটা নতুন টুল কেনা" হিসেবে দেখলে একটি প্রতিষ্ঠান কেন ব্যর্থ হতে পারে?
      
      

        

          DevOps-এর মূল সমস্যাটি সাংগঠনিক/সাংস্কৃতিক — Dev ও Ops টিমের পরস্পরবিরোধী প্রণোদনা ও যোগাযোগের অভাব। শুধু
          একটি CI/CD টুল বসিয়ে দিলে সেই আন্ডারলাইং সাংস্কৃতিক সমস্যা (সাইলো, দোষারোপের সংস্কৃতি, শেয়ার্ড দায়িত্বের
          অভাব) সমাধান হয় না — টুল শুধু একটি ভালো কালচারকে আরও কার্যকর করে, খারাপ কালচারকে ঢেকে রাখতে পারে না।
        

      

    


    

      
        প্র ০৩
        "চেঞ্জ ফেইলিওর রেট" কম রাখা এবং "ডিপ্লয়মেন্ট ফ্রিকোয়েন্সি" বেশি রাখা — এই দুটো লক্ষ্য কি পরস্পরবিরোধী মনে হয়? বাস্তবে কেন নয়?
      
      

        

          সহজাতভাবে মনে হতে পারে বেশি ঘনঘন ডিপ্লয় করলে বেশি ভুল হবে। কিন্তু বাস্তবে বিপরীত সম্পর্ক পাওয়া যায় —
          ছোট, ঘনঘন পরিবর্তন প্রতিটি ডিপ্লয়মেন্টের ঝুঁকি ও জটিলতা কমায় (একবারে অনেক পরিবর্তনের বদলে অল্প কিছু
          পরিবর্তন, তাই সমস্যা হলে খুঁজে বের করা সহজ), এবং স্বয়ংক্রিয় টেস্টিং/CI-CD (M8) প্রতিটি ছোট পরিবর্তন দ্রুত
          যাচাই করে। এই কারণেই high-performing টিমগুলো একই সাথে বেশি ডিপ্লয় করে এবং কম ব্যর্থ হয় — দুটোই একসাথে
          অর্জনযোগ্য, বরং একে অপরকে শক্তিশালী করে।
        

      

    

  


  

    
 অনুশীলন

    
    
      
  1. 
        চিন্তা করুন: আপনার ব্যবহৃত একটি অ্যাপ বা সার্ভিস বেছে নিন এবং অনুমান করুন এটি IaaS, PaaS নাকি SaaS হিসেবে তৈরি হয়েছে বলে মনে হয় (অথবা এই তিনটির মিশ্রণ)।
        
    
          
          
    
            
    
              উদাহরণ: একটি ই-কমার্স স্টার্টআপ প্রায়ই একটি মিশ্রণ ব্যবহার করে — তাদের নিজস্ব ব্যাকএন্ড অ্যাপ্লিকেশন
              চালাতে PaaS/IaaS (যেমন কন্টেইনার হোস্টিং), পেমেন্ট প্রসেসিংয়ের জন্য একটি SaaS (যেমন একটি পেমেন্ট
              গেটওয়ে সার্ভিস), এবং ইমেইল পাঠানোর জন্য আরেকটি SaaS ব্যবহার করতে পারে — বেশিরভাগ বাস্তব সিস্টেম বিশুদ্ধ
              একটি স্তরে থাকে না।
            
    
          
    
        
    
      
    2. 
      
  2. 
        পরীক্ষা করুন: উপরের কোড সেলে একটি তৃতীয় "মাঝারি-পারফরম্যান্স টিম" যোগ করুন (deploys_per_day=0.5, lead_time_hours=24, change_failure_rate_pct=25, restore_time_hours=8) এবং তিনটি টিমের তুলনা দেখুন।
        
    
          
          
    
            
    
              টিম dict-এ নতুন একটি এন্ট্রি যোগ করলে এবং প্রিন্ট লুপে সেটিও দেখালে আপনি দেখবেন এই মাঝারি টিমের
              সংখ্যাগুলো ঠিক উচ্চ ও নিম্ন-পারফরম্যান্স টিমের মাঝামাঝি বসে — এটি দেখায় DORA মেট্রিক্স একটি ধারাবাহিক
              স্পেকট্রাম, শুধু দুটি বিচ্ছিন্ন বিভাগ নয়।
            
    
          
    
        
    
      
    3. 
    

  


  

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

    
  







  
  
     এই পাঠে ভুল পেয়েছেন? জানান
  





  
    
 কোর্সে ফিরে যান

    
Cloud Computing & DevOps — সব পাঠ