DevOps के लिए एक श्रद्धांजलि

DevOps की अवधारणा और इतिहास

• DevOps लगभग 2007 के आसपास शुरू हुई एक अवधारणा थी, जिसका लक्ष्य हार्डवेयर मैनेज करने वाले लोगों और software लिखने वाले लोगों के बीच की दूरी को खत्म करना था
• शुरुआत में यह NASA की प्रक्रियाओं और विचारों की नकल करते हुए code deployment की सुरक्षा बढ़ाने का प्रयास था
• उस समय software deployment प्रक्रिया कुछ इस प्रकार थी:
  • development team server software की release तैयार करती थी, QA team उसे test करती थी, और फिर उसे customer तक deploy किया जाता था
  • operations team को एक playbook मिलता था, जिसमें software changes और समस्या आने पर उससे निपटने के तरीके शामिल होते थे
  • data center के भीतर धीरे-धीरे updates rollout किए जाते थे और उनकी monitoring की जाती थी
  • deployment day तय किया जाता था, और deployment के बाद monitoring की जाती थी

DevOps की समस्याएँ

• DevOps बहुत अधिक श्रम-प्रधान था
• इसमें development team, QA team, technical writers और operations team के बीच सहयोग की आवश्यकता थी
• feature deployment धीमा था, और महत्वपूर्ण updates को प्राथमिकता दी जाती थी
• कई संगठनों ने DevOps अपनाने के कारण ये थे:
  • skilled tech staff को आसानी से replace नहीं किया जा सकता था
  • hiring कठिन और महँगी थी
  • SaaS vendors ने complexity कम कर दी थी
  • cloud platforms के फायदे जोर देकर बताए गए
  • developers इस बात से नाराज़ थे कि छोटे changes deploy होने में भी बहुत समय लग रहा था

DevOps का वास्तविक रूप

• DevOps का लक्ष्य development team और operations team को एक ही team में मिलाना था
• QA team को हटा दिया गया, और तेज deployment व feedback के कारण internal testing अवधि कम हो गई
• DevOps को कभी-कभी Google के SRE के साथ भ्रमित किया जाता है, लेकिन SRE अधिक structured और strict approach रखता है
• DevOps की वास्तविक प्रक्रिया कुछ इस तरह थी:
  • developer git में branch बनाता है और feature जोड़ता है
  • PR खोला जाता है, team members review करते हैं, फिर उसे main में merge किया जाता है
  • CI/CD system build शुरू करता है और container को registry में push करता है
  • CD system servers को नई release की सूचना देता है और deployment की सफलता की monitoring करता है
  • release-aware metrics के माध्यम से deployment के बाद होने वाले बदलावों की monitoring की जाती है

DevOps की विफलता के कारण

• developers local environment में test करते थे और Linux servers पर deploy करते समय छोटे-छोटे फर्क सामने आते थे
• operations team deployment की monitoring नहीं करती थी, जिससे समस्या सुलझाना मुश्किल हो जाता था
• developers के पास system operations का पर्याप्त ज्ञान नहीं था
• containers के आने से कुछ समस्याएँ हल हुईं, लेकिन operations की complexity फिर भी बनी रही

Containers का आगमन और सीमाएँ

• containers ने "मेरे कंप्यूटर पर तो यह ठीक चल रहा था" वाली समस्या को हल किया
• इसने Linux server components को सरल बनाया
• फिर भी कुछ समस्याएँ बाकी रहीं
  • Operate: infrastructure maintenance, upgrades आदि के लिए विशेषज्ञता की आवश्यकता
  • Observe: जटिल monitoring systems बनाने और manage करने में कठिनाई
  • निरंतर feedback: internal feedback को संभालने में कमी
  • Discover: teams के बीच knowledge sharing की कमी
  • Plan: centralized planning बनाने में कठिनाई

Platform Engineering का उदय

• Platform Engineering, DevOps के बाद उभरी अवधारणा है, जिसमें development team के platform operations को समझने और समस्याएँ हल करने के बजाय platform team यह जिम्मेदारी संभालती है
• यह approach development team और platform operations की जिम्मेदारियों को स्पष्ट रूप से अलग करती है, जिससे role division साफ होता है, लेकिन फिर भी बहुत अधिक तकनीकी क्षमता की मांग करती है
• developers और operations team दोनों को और अधिक काम करना पड़ता है

निष्कर्ष

• infrastructure क्षेत्र में सरल और platform-independent tools खोजने की प्रवृत्ति बढ़ रही है
• कई संगठन Kubernetes जैसी जटिल technologies को छोड़कर, सरल workflows की ओर लौट रहे हैं
• Platform Engineering कोई जादुई समाधान नहीं है, और संगठनों को यह अलग करना चाहिए कि वास्तव में क्या आवश्यक है और क्या नहीं
• DevOps approach के फायदों को बनाए रखते हुए simplification और stability पर ध्यान केंद्रित करना चाहिए

GN⁺ की राय

1. DevOps का विकास और उसकी वर्तमान स्थिति तकनीकी उद्योग में बदलते trends का अच्छा उदाहरण है। शुरुआती आदर्श लक्ष्यों और वास्तविकता के बीच की दूरी को समझते हुए व्यावहारिक approach खोजने की प्रक्रिया दिलचस्प है

2. Platform Engineering की ओर बदलाव DevOps की सीमाओं को स्वीकार करने और नए समाधान खोजने का प्रयास लगता है। लेकिन यह भी कोई पूर्ण समाधान नहीं है, और संगठन के आकार व प्रकृति के अनुरूप customized approach की आवश्यकता होगी

3. cloud-native technologies और microservice architecture की complexity बढ़ने के साथ, simplicity और stability का पुनर्मूल्यांकन हो रहा है। यह संकेत देता है कि technology selection में business value और operational efficiency को और अधिक महत्व देना चाहिए

4. DevOps और Platform Engineering में हो रहे बदलाव software development और operations क्षेत्र में निरंतर learning और adaptation के महत्व को रेखांकित करते हैं। तकनीकी पेशेवरों को नए tools और methodologies सीखने के साथ-साथ business requirements और technical complexity के बीच संतुलन बनाने की क्षमता भी विकसित करनी होगी

5. भविष्य में software development और operations के तरीके अधिक flexible और context-specific approaches अपनाएँगे। बड़े संगठनों और छोटे startups के लिए एक ही तरीका उपयुक्त नहीं होगा; इसके बजाय, अपनी-अपनी परिस्थितियों के अनुरूप सर्वोत्तम process और tools चुनने की प्रवृत्ति और मजबूत होगी

[kaydash]

काफी बार
मैनेजर
यह उम्मीद करते हैं कि सिर्फ DevOps की अवधारणा अपनाते ही
बिना किसी मेहनत के बड़ा बदलाव आ जाएगा
और यह (बड़ी कंपनियों और छोटी-मध्यम कंपनियों, दोनों में)
पुरानी कंपनियों की एक गलत सोच है

[GN⁺]

Hacker News राय

• "devops cycle" डायग्राम में "build, test, deploy" पर फ़ोकस करना ही मुख्य बात है

  • ज़ोर गति पर था, engineering excellence पर विचार नहीं किया गया
  • operations टीम को हटा दिया गया और QA को फिर से संगठित किया गया
  • हर टीम के पास on-call roster आ गया
  • अल्पकालिक लाभ के लिए सिस्टम में अव्यवस्थित बदलाव किए गए
  • कुछ महीनों बाद हर बदलाव पर समस्याएँ होने लगीं
  • devops tools उपयोगी थे, लेकिन महंगे और निराशाजनक भी थे
  • नए developers devops नहीं जानते, लेकिन containers जानते हैं

• यह devops टीम द्वारा झेली गई समस्याओं पर आधारित राय है

  • नई services जोड़ना और infrastructure को सुरक्षित रूप से मैनेज करना संभव होना चाहिए
  • devops एक standard बन गया है, और manual system administrator काम की ज़रूरत नहीं है

• Kubernetes पर की गई आलोचना गलत है

  • Kubernetes शानदार software engineering का उदाहरण है, अच्छी तरह supported है और हर जगह चलता है
  • random bash scripts इस्तेमाल करने के बजाय Kubernetes सीखना बेहतर है

• devops का मतलब software deployment को आसान बनाने के लिए रुकावटें हटाना है

  • daily deployments, higher quality code deploy करने में मदद करते हैं
  • जब code तैयार हो तभी deploy करने का option महत्वपूर्ण है
  • monthly releases दबाव बनाते हैं और inefficient choices तक ले जा सकते हैं

• devops एक philosophy है, methodology नहीं

  • operations को SDLC में integrate करना इसका उद्देश्य है
  • cloud ने इसे और आसान बना दिया
  • "DevOps" टीमों के बनने से मूल philosophy विकृत हो गई

• leadership का "silos तोड़ना" लगभग औपचारिकता भर है

  • ज़िम्मेदारी के बिना authority प्रभावी नहीं होती
  • सबसे अच्छे devops talent खुद को code से replace करना पसंद करते हैं
  • devops tools mature हैं और अच्छी तरह documented हैं
  • जो developer Kubernetes नहीं सीखता, वह उस developer जैसा है जिसे Linux commands नहीं आते

• अगर users tester बन सकते हैं, तो उन्हें बनना चाहिए

  • समस्या सिर्फ़ आर्थिक है
  • अगर customers बहुत हैं, तो users से test कराना चाहिए; अगर customers कम हैं, तो खुद test करना चाहिए

• platform teams सिर्फ़ बड़ी कंपनियों में संभव हैं

  • छोटे और मझोले व्यवसायों को devops लोगों की कमी के कारण stress और risk उठाना पड़ता है
  • platform team की अनुपस्थिति कई समस्याएँ पैदा करती है

• devops एक philosophy है, methodology नहीं

  • silo teams में अनुभव devops की ज़रूरत को साबित करता है
  • devops टीमों को project को पूरी तरह समझने और deploy करने में सक्षम बनाता है

• devops की मंशा अच्छी है

  • तेज़ feedback loop विकास की गति के लिए महत्वपूर्ण है
  • संगठन और product के अनुरूप सबसे अच्छा solution खोजना चाहिए