इन दिनों, हमें DevOps को परिभाषित करने में बहुत कठिनाई हो रही है, क्योंकि यह जिस समस्या का आरंभिक समाधान करता है, वह बहुत पहले ही समाप्त हो चुकी है।

हाल ही में कुछ कंपनियों के लिए, समस्या वास्तव में कभी मौजूद ही नहीं थी! वे सब कुछ सही तरीके से कर रहे हैं, लेकिन इसके बजाय, सॉफ्टवेयर इंजीनियरिंग परिदृश्य इतनी तेजी से विकसित हुआ है कि टूलिंग और क्लाउड इंजीनियरिंग द्वारा अंतर को भर दिया गया है।

हम DevOps के मूल समय से बहुत दूर हैं और इसकी संस्कृति में बदलाव का उद्देश्य Dev और Ops के बीच की खाई को तोड़ना था।

देव और ऑप्स साइलो

सन् 2008 की बात है, जब पैट्रिक डुबोइस जब उन्होंने DevOps के बारे में पहली बार सोचा, तो वे विकास और परिचालन के बीच अप्रभावी सहयोग को देख रहे थे, ऐसे संदर्भ में जब परियोजना प्रबंधन अभी-अभी वॉटरफॉल से एजाइल में स्थानांतरित हुआ था।

उस समय ऑपरेशन टीमें नेटवर्किंग, सर्वर, वर्चुअल मशीन, ओएस और सॉफ्टवेयर अपडेट से लेकर हर काम को मैनेज करती थीं। इससे बहुत सारे मैनुअल ऑपरेशन छिप जाते थे। सब कुछ मैनुअल नहीं था, लेकिन यह पपेट, शेफ और एन्सिबल या यहां तक कि टेराफॉर्म के अस्तित्व में आने से पहले की बात है।

सर्वर और सॉफ्टवेयर रिलीज का प्रबंधन करना कोई आसान काम नहीं था और इसके लिए बहुत अधिक विशेषज्ञता की आवश्यकता थी। ऐसा कुछ जो नए सॉफ्टवेयर रिलीज की तेज़ और विश्वसनीय डिलीवरी को रोकता था।

बादल, लुप्त होते साइलो का पहला संकेत

2006 में जन्मा AWS पहला प्रमुख क्लाउड प्रदाता था। DevOps की शुरुआत 2008 में हुई थी और इसका उद्देश्य क्लाउड-प्रबंधन की समस्या को हल करना नहीं था, बल्कि ऑन-प्रिमाइसेस इंफ्रास्ट्रक्चर के संचालन के बीच वास्तविक सिलोस को हल करना था। DevOps क्या है, इस बारे में भ्रम की जड़ यही है। सॉफ़्टवेयर इंजीनियरिंग परिदृश्य में दो बड़े बदलाव लगभग एक ही समय में शुरू हुए।

जब क्लाउड कंप्यूटिंग की बात आती है, तो हम तीन मुख्य मॉडल का उपयोग करते हैं: सॉफ़्टवेयर ऐज़ ए सर्विस (SaaS), प्लेटफ़ॉर्म ऐज़ ए सर्विस (PaaS), और इंफ्रास्ट्रक्चर ऐज़ ए सर्विस (IaaS)। चूँकि हम उन उच्च-स्तरीय संरचनाओं का उपयोग कर रहे हैं, इसलिए OPS (सिस्टम एडमिनिस्ट्रेशन) लगभग गायब हो गया है। यह ऐसा है जैसे DevOps के जनक द्वारा पहचानी गई मूल संस्कृति समस्या अब मौजूद नहीं है।

प्रत्येक मॉडल अंतर्निहित बुनियादी ढांचे के विभिन्न नियंत्रण, लचीलेपन और प्रबंधन स्तर प्रदान करता है, और बहुत कम कंपनियां ऑन-प्रिमाइसेस बुनियादी ढांचे को बनाए रखती हैं।

इसलिए, जबकि DevOps आंदोलन Dev और Ops के बीच "साइलॉट" मुद्दों को हल करने की कोशिश कर रहा था, क्लाउड इन्फ्रास्ट्रक्चर पहले से ही Ops को अप्रचलित बनाकर समस्या का एक हिस्सा फीका कर रहा था।

कोई ऑप्स नहीं, कोई साइलो नहीं

DevOps के मुख्य मोटो हैं "शिफ्ट लेफ्ट" और "आप इसे बनाते हैं, आप इसे चलाते हैं", जो केवल ऑप्स कार्य को Devs को हस्तांतरित करने की ओर ले जा सकता है। क्लाउड ने IaaS मॉडल की पेशकश करके सिस्टम एडमिनिस्ट्रेटर (Ops) की आवश्यकता को कम कर दिया, जिससे डेवलपर्स के लिए खुद एप्लिकेशन को प्रबंधित और तैनात करने का प्रयास कम हो गया।

हम इसे बेहतर बनाने के लिए इसे फिर से लिख सकते हैं! ऑप्स सॉफ्टवेयर एकीकरण और परिनियोजन को सरल बनाने के लिए उपकरण प्रदान करके डेव्स को सशक्त बना रहे थे, इस प्रकार, बुनियादी ढांचे को बनाए रखने के लिए संचालन टीमों द्वारा आवश्यक भारी काम को कम कर रहे थे। नतीजतन, हम ऐसी स्थिति में आ गए जहाँ हमें सिस्टम एडमिनिस्ट्रेशन (ऑप्स) की आवश्यकता नहीं थी।

हालाँकि, हमें ऐसे किसी व्यक्ति की आवश्यकता है जो “सॉफ्टवेयर एकीकरण और परिनियोजन को सरल बनाने के लिए उन उपकरणों” का रखरखाव कर सके।

इस नई उभरती भूमिका का अभी तक कोई नाम नहीं है क्योंकि इसे भूतपूर्व ऑप्स द्वारा आपके सामने लाया गया था, जिन्होंने इसे "डेवऑप्स लोग" के रूप में पुनः ब्रांड किया था। चलिए इसे डेवऑप्स इंजीनियर कहते हैं। किसी ने शायद किसी समय यह कहा होगा, और यह अटक गया।

DevOps ने खुद को पुनर्परिभाषित किया

DevOps कभी भी उपकरणों के बारे में नहीं था; यह संस्कृति के बारे में था। विचार यह है कि सॉफ्टवेयर इंजीनियरिंग भी अधिक "लीन" बन सकती है और सॉफ्टवेयर डिलीवरी सही समय पर की जा सकती है। DevOps की शुरुआती समस्या भले ही बहुत पहले दूर हो गई हो, लेकिन इसने सॉफ्टवेयर इंजीनियरिंग में सबसे महत्वपूर्ण विचार को जन्म दिया: निरंतर डिलीवरी।

मैं लंबे समय से उन लोगों का समर्थन करता रहा हूं जो दावा करते हैं कि DevOps कोई भूमिका या टीम नहीं है, और अगर आप इसे ऐसा कहते हैं, तो आप गलत कर रहे हैं। बाद में, मुझे एहसास हुआ कि, ठीक है, चीजें अधिक जटिल थीं। हमने असंगत रूप से एक भूमिका बनाई, "वह व्यक्ति जो सॉफ़्टवेयर एकीकरण और परिनियोजन को सरल बनाने के लिए उपकरणों का रखरखाव करता है," लेकिन हमारे पास इसका कोई नाम नहीं था।

जब आप इसके बारे में सोचते हैं, तो क्या आपको वास्तव में "ऐसे व्यक्ति की ज़रूरत है जो सॉफ़्टवेयर एकीकरण और परिनियोजन को सरल बनाने के लिए उपकरणों का रखरखाव करता है" अगर सब कुछ क्लाउड ऑफ़रिंग था? पूरी तरह से प्रबंधित? एक बटन के क्लिक से काम करता है?

यह अधिकांश क्लाउड प्रदाताओं और कई DevOps SaaS उत्पादों (उदाहरण के लिए, GitLab के बारे में सोचें) का सपना है। सच्चाई इतनी सरल नहीं है। जबकि सिद्धांत रूप में, चीजें सरल हो सकती थीं, और ऑप्स कार्यों को स्वचालित किया जा सकता था, सेवा पूरी तरह से प्रबंधित की जा सकती थी, आदि। वास्तव में, हमने एक राक्षस बनाया।

परिणामस्वरूप, अधिकांश परिचालन/बुनियादी ढांचा टीमों (जिन्हें ऑप्स भी कहा जाता है) के लिए चुनौती अनगिनत उपकरणों और सेवाओं के मानचित्र को नेविगेट करना, समझना, तैनात करना, और उन उपकरणों को एक सुसंगत बुनियादी ढांचे और टूलिंग में जोड़ना है, जिसका उपयोग डेवलपर्स कर सकें।

DevOps अटक गया वह प्रमुख शब्द है, जिसे आसानी से समझा जा सकता है: DevSecOps, FinOps, GitOps, MlOps, आदि।

लेकिन अगर आप गौर करें, तो जो खुशबू बची रहती है वह हमेशा ऑप्स होती है। मजेदार बात यह है कि हर दृष्टिकोण का उद्देश्य समीकरणों से ऑप्स को हटाना होता है। ऑप्स, उर्फ़ "वह व्यक्ति(या व्यक्ति) जो सिस्टम में लॉग इन करता है और इसे काम करने के लिए कुछ करता है।"

संक्षेप में

DevOps ने जिस मूल समस्या को हल करने का लक्ष्य रखा था, वह अब क्लाउड इंफ्रास्ट्रक्चर के उदय के कारण मौजूद नहीं हो सकती है। हालाँकि, DevOps ने निरंतर डिलीवरी के महत्वपूर्ण विचार को जन्म दिया है और सॉफ्टवेयर इंजीनियरिंग में एक सांस्कृतिक बदलाव लाया है।

यद्यपि "डेवऑप्स" शब्द एक प्रचलित शब्द के रूप में प्रचलित हो गया है, लेकिन इसने डेवसेकऑप्स, फिनऑप्स और गिटऑप्स जैसे नए तरीकों के विकास को जन्म दिया है, जिनका उद्देश्य पारंपरिक ऑप्स कार्यों की आवश्यकता को खत्म करना है।

आखिरकार, DevOps और क्लाउड इंफ्रास्ट्रक्चर का परिदृश्य लगातार विकसित होता रहता है, और वर्तमान में बने रहना और सही उपकरण चुनना कठिन है। विडंबना यह है कि DevOps का मतलब शुरू में Dev और Ops के बीच सहयोग था, लेकिन यह समीकरण से Ops को बाहर करने की ओर बढ़ गया है।