আজকাল, আমাদের DevOps সংজ্ঞায়িত করা এত কঠিন সময় কারণ এটি প্রাথমিকভাবে যে সমস্যাটি সমাধান করে তা অনেক আগেই চলে গেছে।

কিছু সাম্প্রতিক কোম্পানীর জন্য, সমস্যা আসলে বিদ্যমান ছিল না! তারা সবকিছু সঠিকভাবে করছে, কিন্তু পরিবর্তে, সফ্টওয়্যার ইঞ্জিনিয়ারিং ল্যান্ডস্কেপ এত দ্রুত বিকশিত হয়েছে যে ফাঁকটি টুলিং এবং ক্লাউড ইঞ্জিনিয়ারিং দ্বারা পূরণ করা হয়েছে।

আমরা DevOps-এর আসল দিন থেকে অনেক দূরে এবং এর সংস্কৃতি পরিবর্তনের লক্ষ্যে Dev এবং Ops-এর মধ্যে সাইলো ভেঙ্গে ফেলা।

দেব এবং অপস সাইলোস

ফিরে 2008, যখন প্যাট্রিক ডুবইস DevOps সম্পর্কে প্রথমে চিন্তা করেছিলেন, তিনি এমন একটি প্রেক্ষাপটে উন্নয়ন এবং ক্রিয়াকলাপের মধ্যে অকার্যকর সহযোগিতার দিকে তাকিয়েছিলেন যেখানে প্রকল্প ব্যবস্থাপনা সবেমাত্র জলপ্রপাত থেকে চটপটে চলে গেছে।

সেই সময়ে অপারেশন দলগুলি নেটওয়ার্কিং, সার্ভার, ভার্চুয়াল মেশিন, ওএস এবং সফ্টওয়্যার আপডেট থেকে সবকিছু পরিচালনা করেছিল। এটি কার্যকরভাবে অনেক ম্যানুয়াল অপারেশন লুকিয়ে রাখে। সবকিছু ম্যানুয়াল ছিল না, তবে এটি পুতুল, শেফ এবং অ্যানসিবলের আগে ছিল - এমনকি টেরাফর্মের অস্তিত্ব ছিল।

সার্ভার এবং সফ্টওয়্যার রিলিজ পরিচালনা করা সহজ ছিল না এবং অনেক দক্ষতার প্রয়োজন ছিল। এমন কিছু যা নতুন সফ্টওয়্যার রিলিজের দ্রুত এবং নির্ভরযোগ্য ডেলিভারি প্রতিরোধ করবে।

মেঘ, বিবর্ণ সিলোসের প্রথম চিহ্ন

2006 সালে জন্মগ্রহণকারী AWS, প্রথম প্রধান ক্লাউড প্রদানকারী। DevOps 2008 সালে তৈরি করা হয়েছিল এবং এটি একটি ক্লাউড-ব্যবস্থাপনা সমস্যার সমাধান করার উদ্দেশ্যে নয় বরং অন-প্রিমিস অবকাঠামোর অপারেশনের মধ্যে আসল সাইলোস। DevOps কী তা নিয়ে বিভ্রান্তির মূল এটি। সফ্টওয়্যার ইঞ্জিনিয়ারিং ল্যান্ডস্কেপে দুটি বড় পরিবর্তন একই সময়ে শুরু হয়েছিল।

ক্লাউড কম্পিউটিংয়ের ক্ষেত্রে, আমরা তিনটি প্রধান মডেল ব্যবহার করি: একটি পরিষেবা হিসাবে সফ্টওয়্যার (SaaS), একটি পরিষেবা হিসাবে প্ল্যাটফর্ম (PaaS), এবং পরিষেবা হিসাবে পরিকাঠামো (IaaS)। যেহেতু আমরা সেই উচ্চ-স্তরের নির্মাণগুলি ব্যবহার করছি, ওপিএস (সিস্টেম প্রশাসন) প্রায় অদৃশ্য হয়ে গেছে। এটি যেন DevOps এর পিতাদের দ্বারা চিহ্নিত মূল সংস্কৃতি সমস্যাটি আর বিদ্যমান নেই।

প্রতিটি মডেল অন্তর্নিহিত অবকাঠামোর বিভিন্ন নিয়ন্ত্রণ, নমনীয়তা এবং পরিচালনার স্তর সরবরাহ করে এবং খুব কম কোম্পানিই অন-প্রিমিস অবকাঠামো বজায় রাখবে।

সুতরাং, যখন DevOps আন্দোলন Dev এবং Ops-এর মধ্যে "সিলট" সমস্যাগুলি সমাধান করার চেষ্টা করছিল, তখন ক্লাউড অবকাঠামো ইতিমধ্যে অপসকে অপ্রচলিত করে সমস্যার একটি অংশ ম্লান করে দিয়েছিল৷

কোন অপ্স, নো সাইলোস

DevOps-এর মূল উদ্দেশ্যগুলি হল "বামে স্থানান্তর করুন" এবং "আপনি এটি তৈরি করেন, আপনি এটি চালান", যা শুধুমাত্র একটি অপস টাস্ক(গুলি) Devs-এ স্থানান্তর করতে পারে৷ ক্লাউড আইএএএস মডেল অফার করে সিস্টেম অ্যাডমিনিস্ট্রেটরদের (অপস) প্রয়োজনীয়তা কমিয়েছে, ডেভেলপারদের নিজেরাই অ্যাপ্লিকেশন পরিচালনা এবং স্থাপন করার প্রচেষ্টা কমিয়েছে।

আমরা এটিকে আরও ভাল করে শোনাতে এটিকে পুনরায় শব্দবন্ধ করতে পারি! অপস সফ্টওয়্যার একীকরণ এবং স্থাপনাকে সহজ করার জন্য সরঞ্জামগুলি সরবরাহ করে Devsকে ক্ষমতায়ন করছিল, এইভাবে, পরিকাঠামো বজায় রাখার জন্য অপারেশন দলগুলির দ্বারা প্রয়োজনীয় ভারী উত্তোলন হ্রাস করা হয়েছিল। ফলস্বরূপ, আমরা এমন একটি পরিস্থিতিতে পড়েছিলাম যেখানে আমাদের সিস্টেম অ্যাডমিনিস্ট্রেশনের (অপস) প্রয়োজন ছিল না।

যাইহোক, "সফ্টওয়্যার ইন্টিগ্রেশন এবং স্থাপনাকে সহজ করার জন্য সরঞ্জামগুলি" বজায় রাখার জন্য আমাদের কাউকে দরকার।

এই নতুন উদীয়মান ভূমিকার এখনও কোনও নাম নেই যেহেতু এটি আপনার কাছে প্রাক্তন Ops দ্বারা আনা হয়েছিল, যারা এটিকে "DevOps guys" হিসাবে পুনরায় ব্র্যান্ড করেছে৷ এর ডেভঅপস ইঞ্জিনিয়ার বলা যাক। কেউ সম্ভবত এটি এক পর্যায়ে বলেছে, এবং এটি আটকে গেছে।

DevOps নিজেকে পুনরায় সংজ্ঞায়িত করেছে

DevOps টুলস সম্পর্কে ছিল না; এটা সংস্কৃতি সম্পর্কে ছিল. ধারণাটি হল যে সফ্টওয়্যার ইঞ্জিনিয়ারিংও আরও "ঝুঁকিপূর্ণ" হয়ে উঠতে পারে এবং সেই সফ্টওয়্যার বিতরণ ঠিক সময়ে করা যেতে পারে। DevOps-এর প্রাথমিক সমস্যা অনেক আগেই চলে যেতে পারে, কিন্তু এটি সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের সবচেয়ে গুরুত্বপূর্ণ ধারণার জন্ম দিয়েছে: ক্রমাগত বিতরণ।

আমি দীর্ঘদিন ধরে তাদের সমর্থন করেছি যারা দাবি করে যে DevOps একটি ভূমিকা বা একটি দল নয়, এবং আপনি যদি এটিকে কল করেন তবে আপনি এটি ভুল করছেন। পরে, আমি বুঝতে পেরেছিলাম যে, ভাল, জিনিসগুলি আরও জটিল ছিল। আমরা অসঙ্গতভাবে একটি ভূমিকা তৈরি করেছি, "লোক(গুলি) যেটি সফ্টওয়্যার ইন্টিগ্রেশন এবং স্থাপনাকে সহজ করার জন্য সরঞ্জামগুলি বজায় রাখে," কিন্তু আমাদের কাছে এটির জন্য একটি নাম ছিল না।

আপনি যখন এটি সম্পর্কে চিন্তা করেন, আপনার কি সত্যিই "ব্যক্তি(গুলি) প্রয়োজন যেটি সফ্টওয়্যার সংহতকরণ এবং স্থাপনাকে সহজ করার জন্য সরঞ্জামগুলি বজায় রাখে" যদি সবকিছুই ক্লাউড অফার হয়? সম্পূর্ণরূপে পরিচালিত? একটি বোতাম ক্লিক করে কাজ করে?

এটি বেশিরভাগ ক্লাউড সরবরাহকারীদের এবং অনেক DevOps SaaS পণ্যের স্বপ্ন (উদাহরণস্বরূপ, গিটল্যাব সম্পর্কে চিন্তা করুন)। সত্য এত সহজ নয়। তাত্ত্বিকভাবে, জিনিসগুলি সহজ হতে পারে, এবং অপস কাজগুলি স্বয়ংক্রিয় হতে পারে, পরিষেবা সম্পূর্ণরূপে পরিচালিত হতে পারে, ইত্যাদি৷ বাস্তবে, আমরা একটি দানব তৈরি করেছি৷

ফলস্বরূপ, বেশিরভাগ অপারেশন/অনফ্রাস্ট্রাকচার টিমের (ওরফে। অপস) চ্যালেঞ্জ হল অগণিত সরঞ্জাম এবং পরিষেবার মানচিত্র নেভিগেট করা, সেই টুলগুলিকে বোঝা, স্থাপন করা এবং একটি সুসংগত অবকাঠামো এবং টুলিংয়ের সাথে সংযোগ করা যা বিকাশকারীরা ব্যবহার করতে পারে।

DevOps আটকে গেছে সেই মূল বাজওয়ার্ড, যা থেকে বের করা সহজ: DevSecOps, FinOps, GitOps, MlOps, ইত্যাদি।

কিন্তু যদি আপনি লক্ষ্য করেন, যে সুগন্ধি থাকে তা সর্বদা অপস। মজার অংশ হল যে প্রতিটি পদ্ধতির লক্ষ্য সমীকরণের অপস অপসারণ করা। The Ops, ওরফে "ব্যক্তি(গুলি) যে সিস্টেমে লগ ইন করে এবং এটিকে কার্যকর করার জন্য কিছু করে।"

টিএল; ডিআর

ক্লাউড অবকাঠামোর উত্থানের কারণে DevOps যে মূল সমস্যাটি সমাধান করতে শুরু করেছে তা আর বিদ্যমান নাও থাকতে পারে। যাইহোক, DevOps ক্রমাগত বিতরণের গুরুত্বপূর্ণ ধারণার জন্ম দিয়েছে এবং সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ে একটি সংস্কৃতি পরিবর্তন এনেছে।

যদিও "DevOps" শব্দটি একটি গুঞ্জন শব্দ হিসাবে চারপাশে আটকে থাকতে পারে, এটি DevSecOps, FinOps এবং GitOps-এর মতো নতুন পদ্ধতির বিকাশের দিকে পরিচালিত করেছে, যার সবকটিই প্রথাগত Ops কাজের প্রয়োজনীয়তা দূর করা।

শেষ পর্যন্ত, DevOps এবং ক্লাউড অবকাঠামোর ল্যান্ডস্কেপ ক্রমাগত বিকশিত হয়, এবং বর্তমান থাকা এবং সঠিক টুল নির্বাচন করা কঠিন। হাস্যকরভাবে, DevOps প্রাথমিকভাবে Dev এবং Ops-এর মধ্যে সহযোগিতা বোঝায়, কিন্তু এটি সমীকরণ থেকে Ops বাদ দেওয়ার দিকে চলে গেছে।