DevOps और Snowflakes पर

IT में आजकल मुश्किल से ही कोई ऐसा दिन जाता है जब लोग DevOps के बारे में बात न कर रहे हों। DevOps उद्योग में नया गर्म विषय है जो cloud की बातों से आगे बढ़ा है और लोगों को इसके बारे में बात करते सुनकर कोई यह मान सकता है कि पारंपरिक systems administration पहले ही मृत और दफन हो चुका है।

सबसे पहले हमें DevOps का क्या अर्थ है इसके बारे में बात करनी होगी। यह भ्रामक हो सकता है क्योंकि, cloud की तरह, एक पुराने शब्द को अक्सर कुछ अलग अर्थ देने के लिए उठाया जा रहा है या, सबसे अच्छे तरीके से, किसी ऐसी चीज़ से संबंधित जो पहले से ही मौजूद थी। पारंपरिक DevOps developer और operational roles का विलय था। 1960 के दशक से 1990 के दशक तक, systems चलाने का यह मानक तरीका था। इस दुनिया में जो लोग software लिखते थे वे आमतौर पर वही थे जो इसे deploy और maintain करते थे। इसलिए “developer” और “operations” का विलय, operations system administrator की भूमिका के लिए एक अर्ध-मानक शब्द है। 1990 के दशक में “IT Department” के उदय तक ये roles आमतौर पर अलग नहीं थे। तब से, दो roles के विलय की वापसी लोकप्रियता में बढ़ने लगी है, मुख्यतः इसलिए कि आधुनिक, hosted web application स्थितियों में दोनों मिलकर बड़े मूल्य के साथ काम कर सकते हैं।

जहाँ DevOps के बारे में आज अक्सर बात की जाती है वह developers और operations staff के सख्त विलय के रूप में नहीं बल्कि operations staff में एक संशोधन के रूप में है जो application infrastructure को code के रूप में cloud architecture के प्राकृतिक विस्तार के रूप में परिभाषित करने पर बहुत अधिक ध्यान केंद्रित करता है। यह पहली बार में काफी भ्रामक हो सकता है। जो महत्वपूर्ण है वह यह है कि पारंपरिक DevOps वह नहीं है जो आमतौर पर आज हो रहा है बल्कि एक नया “नकली” DevOps है जहाँ developers developer रहते हैं और operations, operations रहता है लेकिन operations एक नए “code-heavy” role में विकसित हो गया है जो developers द्वारा प्रदान किए गए code को चलाने वाले servers को manage करना जारी रखता है।

जो आज महत्वपूर्ण है वह यह है कि system administrator की role दो संबंधित, लेकिन काफी भिन्न roles में विभाजित होने लगी है, जिनमें से एक को आज उद्योग के अधिकांश लोग गलत तरीके से DevOps कहते हैं (अधिकांश उद्योग इतना युवा है कि DevOps के आदर्श होने का समय याद नहीं है, न कि अपवाद और निश्चित रूप से कुछ नया और उपन्यास नहीं।) मैं यहाँ system administrator role के इन दो पहलुओं को DevOps और Snowflake दृष्टिकोण के रूप में संदर्भित करता हूँ।

मैं systems के पारंपरिक architectures को संदर्भित करने के लिए Snowflake शब्द का उपयोग करता हूँ क्योंकि प्रत्येक individual server को एक “unique Snowflake” के रूप में देखा जा सकता है। वे सभी अलग हैं, कम से कम जहाँ तक वे किसी तरह से identical रखने के लिए managed नहीं होते। इसका मतलब यह नहीं है कि उन्हें सभी अनूठे होने की जरूरत है, बस यह है कि वे होने की क्षमता बनाए रखते हैं। पारंपरिक वातावरण में एक system administrator प्रत्येक server में individually log in करके उन पर काम करेगा।

Snowflake architectures के administration को आसान बनाने में अक्सर उचित तरीकों से systems के बीच अंतरों को कम करने के प्रयास शामिल होते हैं। यह आम तौर पर एकल मानक operating system और version (Windows 2012 R2 या Red Hat Enterprise Linux 7) चुनने जैसी चीजों से शुरू होता है, बजाय हर server installation को एक अलग OS या version होने देने के।

एक अगला कदम आमतौर पर एक मानक deployment methodology या gold master image बनाना है जिसका उपयोग सभी systems बनाने के लिए किया जाता है ताकि base operating system और सभी base packages, जिसमें अक्सर system customization, monitoring packages, security packages, authentication configuration और समान modifications शामिल हैं, मानक हों और uniformly deploy किए जाएं। यह सभी systems के लिए एक सामान्य शुरुआती बिंदु प्रदान करता है।

इन कदमों से परे, Snowflake वातावरण आमतौर पर समय के साथ systems के बीच कुछ मानकीकरण बनाए रखने के लिए custom, bespoke administration scripts या management tools का उपयोग करते हैं। Systems के बीच जितनी अधिक समानताएं होती हैं, उन्हें maintain और troubleshoot करना उतना ही आसान होता है और administration staff द्वारा कम ज्ञान की आवश्यकता होती है।

DevOps दृष्टिकोण cloud architecture model से organically बढ़ता है। Cloud architecture automatically बनाए और automatically नष्ट किए गए, व्यापक रूप से identical systems (कम से कम groups में) के आसपास design किया गया है जो एक programmatic interface या API के माध्यम से नियंत्रित होते हैं। यह model, काफी स्पष्ट रूप से, एक system administrator के manual प्रयासों के माध्यम से नहीं बल्कि एक management system के माध्यम से केंद्रीय रूप से नियंत्रित होने के लिए उधार देता है।

cloud architecture दुनिया से जो विचार उभरा है वह यह है कि systems architecture को servers पर नहीं बल्कि केंद्रीय रूप से “code में” परिभाषित किया जाना चाहिए। यह पहली बार में भ्रामक लगता है लेकिन जब हम इसे अधिक गहराई से देखते हैं तो बहुत समझ में आता है। इस model का समर्थन करने के लिए एक नए प्रकार का systems management tool जिसने अभी तक कोई वास्तव में मानक नाम नहीं लिया है, लेकिन जिसे अक्सर systems automation tool, DevOps framework, IT automation tool या बस “infrastructure as code” tool कहा जाता है, उभरने लगा है। इस क्षेत्र में सामान्य toolsets में Puppet, Chef, CFEngine और SaltStack शामिल हैं।

इन automation toolsets के पीछे का विचार यह है कि सभी systems को manage और control करने के लिए एक central service का उपयोग किया जाता है। यह central authority individual servers को code-based descriptions के माध्यम से manage करती है कि system कैसा दिखना चाहिए और कैसे behave करना चाहिए। Chef की दुनिया में, इन्हें cute तरीके से “recipes” कहा जाता है लेकिन analogy अच्छी तरह से काम करता है। प्रत्येक system के code में ऐसी जानकारी शामिल हो सकती है जैसे कि कौन से packages और package versions install होने चाहिए, कौन से system configurations को modified किया जाना चाहिए और files को box पर copy किया जाना चाहिए।

ये मानक definitions का मतलब है कि systems, एक बार एक role या किसी अन्य से संबंधित होने के रूप में नामित होने पर, automatically “खुद को build” कर सकते हैं। एक नया system एक administrator द्वारा system का अनुरोध करने पर बनाया जा सकता है या एक capacity monitoring system यह तय कर सकता है कि एक role के लिए अतिरिक्त capacity की आवश्यकता है और बिना किसी human intervention के नए server instances spawn कर सकता है।

Code में systems को परिभाषित करने के कुछ गैर-स्पष्ट परिणाम हैं। एक यह है कि complete systems के backups की अब आवश्यकता नहीं है। एक ऐसे system का backup क्यों करें जिसे आप minimum प्रयास के साथ लगभग तुरंत recreate कर सकते हैं? Database systems से local data को backup करने की आवश्यकता होगी लेकिन केवल database data, पूरे system की नहीं।

Code में पहले से परिभाषित systems के लिए आवश्यक documentation की मात्रा बहुत कम है। Snowflake वातावरण में system administrator को प्रत्येक host के specific documentation को manually maintain करना होता है। यह बहुत समय लेने वाला और error prone है। Central code के माध्यम से परिभाषित systems को बहुत कम या कोई documentation की आवश्यकता नहीं होती।

Code में परिभाषित systems का testing करना भी आसान है। आप code के माध्यम से एक system बना सकते हैं, उसे test कर सकते हैं और जान सकते हैं कि जब आप उस definition को production में ले जाते हैं तो production system ठीक उसी तरह बनाया जाएगा जैसा testing में बनाया गया था।

Cloud architectures में DevOps की दुनिया में automation के सबसे extreme level को enable करने के लिए बड़ा मूल्य है लेकिन इन प्रकार के tools का लाभ उठाने के लिए cloud architectures का उपयोग करना अनावश्यक है। और निश्चित रूप से, एक code defined architecture का उपयोग आंशिक रूप से किया जा सकता है जबकि manual administration को एक hybrid दृष्टिकोण के लिए भी implement किया जा सकता है।

DevOps दृष्टिकोण, हालांकि, प्रमुख caveats के साथ भी आता है। इस तरह से एक system को manage करने के लिए आवश्यक skill sets पारंपरिक systems administration के लिए आवश्यक से कहीं अधिक हैं क्योंकि, कम से कम, सभी पारंपरिक systems administration ज्ञान अभी भी आवश्यक है और साथ में आधुनिक languages जैसे Python और Ruby का ठोस programming ज्ञान और specific frameworks का ज्ञान भी। यह extended knowledge base की आवश्यकता का मतलब है कि DevOps practitioners न केवल दुर्लभ हैं बल्कि महंगे भी हैं।

इन दो camps में काम करने वाले system administrators की प्रवृत्ति होती है कि सभी systems को अपने mold में फिट होने की जरूरत देखें। नए DevOps practitioners अक्सर मानते हैं कि Snowflake systems legacy हैं और उन्हें update करने की जरूरत है। Snowflake (पारंपरिक) admins “infrastructure as code” आंदोलन को silly, अनावश्यक overhead से भरा, अधिक जटिल और बहुत niche के रूप में देखते हैं।

वास्तविकता यह है कि दोनों दृष्टिकोणों में भारी मात्रा में merit है और दोनों अत्यंत viable रहने वाले हैं। दोनों बहुत अलग-अलग workloads के लिए समझ में आते हैं और बड़े organizations, मेरा अनुमान है, सामान्यतः किसी न किसी form of hybridization के माध्यम से दोनों को place में देखेंगे। SMB बाजार में जहाँ आमतौर पर केवल बहुत कम servers होते हैं, cloud architectures को justify करने के लिए कोई scaling leverage नहीं होता और systems के बीच उच्च विषमता होती है, मेरा अनुमान है कि DevOps लगभग indefinitely norm के बाहर रहेगा क्योंकि overhead और इसे काम करने के लिए आवश्यक additional skills अव्यावहारिक या प्राप्त करने में असंभव भी हैं।

दृष्टिकोण में यह अंतर का मतलब है कि, उदाहरण के लिए United States में, अधिकांश US में ऐसी कंपनियां हैं जो Snowflake management model पर focused रहेंगी जबकि कुछ east coast कंपनियां DevOps model का effectively मूल्यांकन कर सकती हैं और उस दिशा में आगे बढ़ना शुरू कर सकती हैं। लेकिन west coast पर जहाँ अधिक आधुनिक architectures और बाहरी उपभोग के लिए hosted applications और applications पर बहुत अधिक focus driving economic factors हैं, DevOps पहले से ही newcomer से mature, established normalcy में move कर रहा है।

कोई भी दृष्टिकोण बेहतर या बदतर नहीं है, ये दो अलग-अलग दृष्टिकोण हैं जो systems को provision करने के दो बहुत अलग-अलग तरीकों और उन systems की दो अलग-अलग fundamental जरूरतों की सेवा करते हैं। Cloud architectures और DevOps model के उदय के साथ, हालांकि, यह critically important है कि मौजूदा system administrators समझें कि DevOps model का क्या मतलब है और यह कब लागू होता है ताकि वे अपने खुद के workloads और unique जरूरतों का सही तरीके से मूल्यांकन कर सकें।

मूल रूप से StorageCraft Blog पर प्रकाशित।