GUI युग का अंत

हमें GUIs और systems administration की दुनिया में उनकी भूमिका के बारे में कुछ ऐतिहासिक संदर्भ को देखकर मंच तैयार करना चाहिए।

“पुराने दिनों” में हमारे पास किसी भी computer पर graphical user interfaces नहीं थे, servers तो बिल्कुल भी नहीं। GUIs के end user equipment पर लोकप्रिय होने के बाद भी, servers के पास लंबे समय तक ये नहीं थे। 1980 और 1990 के दशक में GUI बनाने के लिए आवश्यक computational overhead एक machine की कुल computing क्षमता के संदर्भ में महत्वपूर्ण था और जो थोड़ा था उसे GUI बनाने के लिए उपयोग करना काफी अव्यावहारिक था, यदि अक्सर पूरी तरह असंभव नहीं था। Systems administration की दुनिया इसी संदर्भ में बड़ी हुई, command lines से काम करते हुए क्योंकि कोई अन्य विकल्प उपलब्ध नहीं था। लोगों के लिए systems administration के लिए GUIs की इच्छा करना सामान्य नहीं था, शायद इसलिए क्योंकि यह विचार अभी तक लोगों को नहीं आया था।

1990 के दशक के मध्य में Microsoft ने, कुछ अन्य लोगों के साथ, entry level server market के लिए GUI-driven systems administration का विचार पेश करना शुरू किया। पहले यह दृष्टिकोण उतना लोकप्रिय नहीं था क्योंकि यह उन अनुभवी administrators के काम करने के तरीके से मेल नहीं खाता था। लेकिन धीरे-धीरे, जैसे-जैसे नए Windows administrators और कुछ हद तक Novell Netware administrators GUI-based administration tools के साथ “बड़े होने” लगे, server market में इन systems के लिए एक स्वीकृत जगह बनने लगी। 1990 के दशक के मध्य से अंत तक UNIX और अन्य non-Windows servers ने बाज़ार पर पूरी तरह से हावी था। VMS भी एक प्रमुख player था और small business और commodity server की तरफ Novell Netware दशक के मध्य में dominant player था और अंत में भी एक बहुत गंभीर प्रतियोगी था। Netware एक GUI अनुभव प्रदान करता था लेकिन एक जो बहुत हल्का था और शायद केवल “semi-GUI” माना जाना चाहिए, Windows NT के समृद्ध GUI अनुभव की तुलना में जो कम से कम 1996 तक और कुछ हद तक NT 3.x family के साथ पहले से पेश किया जा रहा था, हालांकि Windows NT NT 4 की release से पहले दुनिया में अपनी जगह ढूंढ ही रहा था।

उस समय भी, GUI-driven administration market मुख्य रूप से एक पिछड़ा क्षेत्र बना रहा। Microsoft और Windows का अभी भी server की तरफ कोई प्रमुख स्थान नहीं था लेकिन small business market के माध्यम से प्रवेश करना शुरू कर रहा था जहां उनके कम लागत और उपयोग में आसान products बहुत समझ में आते थे। लेकिन यह वास्तव में 1990 के दशक के अंत की Y2K दहशत, dotcom market bubble और Microsoft द्वारा उत्कृष्ट product development और marketing का संयोजन था जिसने GUI-driven administration market में महत्वपूर्ण वृद्धि और बदलाव को जन्म दिया।

1990 के दशक के अंत में IT market के विशाल विस्तार का मतलब था कि IT में प्रवेश कर रहे नए लोगों को प्रशिक्षित करने के लिए पर्याप्त समय या संसाधन नहीं थे। Solaris और Netware सहित कई systems के लिए सीखने की अवस्था बहुत खड़ी थी और उद्योग को मौजूदा platforms के साथ जितना संभव था उससे कहीं अधिक तेज़ी से शून्य से “सक्षम IT professional” तक जाने के लिए अत्यधिक संख्या में लोगों की ज़रूरत थी। Market की वृद्धि विस्फोटक थी और IT में काम करके इतना पैसा कमाया जा सकता था कि शिक्षा में काम करने की बजाय उद्योग में काम करने में अधिक कमाई थी, इसलिए नए लोगों को प्रशिक्षित करने के लिए प्रभावी रूप से कोई उपलब्ध संसाधन नहीं थे। जैसे-जैसे market बढ़ता गया, परिपक्व, अनुभवी professionals का मूल्य बेहद उच्च हो गया, क्योंकि वे हमेशा बढ़ते हुए क्षेत्र में कम और कम दुर्लभ होते जा रहे थे।

Market ने इस ज़रूरत का कई तरीकों से जवाब दिया लेकिन सबसे बड़े तरीकों में से एक था IT के approach को मौलिक रूप से बदलना। IT professionals को पारंपरिक सीखने की अवस्थाओं को पार करने और उस समय बाज़ार में मौजूद systems को प्रभावी ढंग से प्रबंधित करने के लिए आवश्यक skills विकसित करने के लिए प्रेरित करने की बजाय, market ने उन tools को बदल दिया जो वे कम अनुभवी और कम जानकार IT staff को accommodate करने के लिए उपयोग कर रहे थे। GUI interfaces वाले सरल और अक्सर अधिक महंगे tools market में आने लगे जिससे कम training और अनुभव वाले लोग लगभग तुरंत उपयोगी और उत्पादक बनने लगे, भले ही उन्होंने पहले कभी कोई product नहीं देखा हो।

यह बदलाव computer hardware के performance की स्वाभाविक उन्नति के साथ मेल खाया। यह उस युग के दौरान था जब पहली बार कई systems की power ऐसी थी कि हालांकि GUI ने performance पर काफी महत्वपूर्ण प्रभाव डाला, support staff की कम लागत और वह गति जिससे systems को deploy और manage किया जा सकता था, आमतौर पर GUI द्वारा ली गई इस computing क्षमता के नुकसान की भरपाई कर देती थी। GUI तेज़ी से उन systems में एक मानक addition बन गया जिन पर कुछ साल पहले कभी नहीं होता।

इन नए IT professionals की क्षमताओं को बेहतर बनाने और उन्हें marketplace में rush करने के लिए उद्योग ने certifications की ओर भी भारी रुझान किया, जो उस समय एक नई innovation थी, जिसने नए IT pros को, जिनके पास अक्सर किसी भी प्रकार का कोई hands on अनुभव नहीं था, कुछ हद तक competence स्थापित करने और आमतौर पर मौजूदा IT professionals से किसी महत्वपूर्ण interaction या investment के बिना ऐसा करने की सुविधा दी जैसा university programs में ज़रूरी होता। GUI-based administration market और certification उद्योग दोनों फले-फूले; और IT का चेहरा बदल गया।

परिणाम निश्चित रूप से नए, untrained या हल्के प्रशिक्षित IT professionals की एक बाढ़ थी जो record गति से market में प्रवेश कर रहे थे। अल्पावधि में यह बदलाव उद्योग के लिए काम किया। क्षेत्र नाटकीय रूप से understaffed से अपेक्षाकृत well staffed हो गया जितना अन्यथा संभव होता उससे वर्षों तेज़ी से। लेकिन नए लोगों के इस तीव्र uptake के दंड दिखाई देने में देर नहीं लगी।

उद्योग पर सबसे बड़े प्रभावों में से एक था कि एक industry-wide “baby boom” हुआ जो उससे जुड़ी सभी growing pains के साथ था। IT professionals की एक पूरी पीढ़ी 1990 के दशक के अंत के boot camps और तेज़ “certification training” programs में बड़ी हुई। इसके परिणामस्वरूप उस युग में सामान्य thumb rules और general approaches का एक दीर्घकालिक प्रभाव हुआ जो अक्सर इस हद तक codified हो गए कि वे लगभग धार्मिक विश्वास का रूप ले लिया जिस तरह से पूर्ववर्ती और बाद के दृष्टिकोण नहीं ले पाते। अक्सर, क्योंकि शिक्षा जल्दी और उथली थी, कई अवधारणाओं को उनके पीछे के fundamentals की समझ के बिना rote में सीखना पड़ा। जैसे-जैसे “Class of 1998” समय के साथ अपनी companies में senior IT professionals बनती गई, वे नई पीढ़ियों के mentor बन गए और वह पुरानी rote learning बाद के वर्षों में इसी तरह के approaches के माध्यम से बहुत स्पष्ट रूप से trickling down हुई, यहां तक कि तब भी जब knowledge पुरानी या अव्यावहारिक हो गई और कई मामलों में इसे गलत तरीके से interpret किया गया है और उस युग के लिए भी predictable तरीकों से गलत है जहां से यह उभरी।

उस युग की इस learning का एक हिस्सा यह सामान्य स्वीकृति थी कि GUIs न केवल स्वीकार्य थे बल्कि वे व्यावहारिक और अपेक्षित थे। Baby boom effect का मतलब था कि पूर्व युग से बहुत कम mentorship था और पहले से स्थापित practices और norms को अक्सर हटा दिया गया। Baby boom effect का मतलब था कि उद्योग ने उतना खुद को फिर से reinvent नहीं किया जितना कि उसने खुद को simply invest किया। यहां तक कि Information Technology की अवधारणा एक विशिष्ट उद्योग के रूप में अपने वर्तमान रूप में इस guards के बदलाव के दौरान सार्वजनिक चेतना में आई। IT के अन्य departments या disciplines का अवशेष होने की बजाय IT अपने आप में आई; लेकिन यह उन practices की परिपक्वता और निरंतरता के बिना हुई जो अधिक organic विकास के साथ मौजूद होती, जो उद्योग को शायद उससे भी खराब स्थिति में छोड़ गई जितनी वह होती यदि यह निरंतर रूप से विकसित हुई होती।

1990 के दशक के अंत के IT boom का लंबे समय तक चलने वाला प्रभाव बहुत लंबे समय तक महसूस किया जाएगा क्योंकि उस समय की प्रवृत्तियों, विश्वासों और assumptions को अंततः हटाने में कई पीढ़ियां लगेंगी। धीरे-धीरे, नई अवधारणाएं और approaches पकड़ बना रही हैं, अक्सर केवल तभी जब पुरानी technologies गायब हो जाती हैं और नई पेश की जाती हैं जो परंपरा की पकड़ तोड़ती हैं। इनमें से एक है GUI का वह धारणा जो systems administration को accomplish करने का प्रमुख तरीका है।

जैसा कि हमने पहले बताया, GUI अपनी शुरुआत में पुराने systems और 1990 के दशक के अंत की नई दुनिया के बीच अंतर का बिंदु था। लेकिन तब से GUI administration tools उनकी उपलब्धता में सर्वव्यापी हो गए हैं। हर महत्वपूर्ण platform के पास graphical administration options हैं और लंबे समय से हैं, इसलिए GUI अब किसी भी platform को महत्वपूर्ण तरीके से अलग नहीं करता। इसका मतलब है कि अब कोई vendor नहीं है जिसके पास GUI की अवधारणा को push करने की स्पष्ट agenda हो। GUI का marketing value प्रभावी रूप से चला गया है। इसी तरह, न केवल वे systems जिनके पास पहले strong GUI नहीं था, उनमें से लगभग सभी ने एक (या अधिक) develop किए बल्कि GUI-based systems जिनके पास strong command line tools नहीं थे वे भी वापस गए और उन्हें develop किया और उनके आसपास नए professional ecosystems विकसित किए। ज्वार निश्चित रूप से पलट गया।

इसके अलावा, पिछले लगभग दो दशकों में non-GUI दुनिया की rhetoric पकड़ बनाने लगी है। किसी भी platform पर command line में महारत की स्थिति से काम करने वाले system administrators आमतौर पर अपने counterparts से बेहतर प्रदर्शन करते हैं जिससे अधिक career opportunities, अधिक चुनौतीपूर्ण roles और उच्च income होती है। Command line administration पर focused companies अपने आप को अधिक skilled workers और उच्च administration density के साथ पाती हैं जो बदले में overall cost को कम करती है।

यह अकेला GUI की स्थिति को डगमगाने लगाने के लिए पर्याप्त था। लेकिन हमेशा पुरानी दलील थी कि GUIs, 1990 के दशक के अंत में भी, बहुत कम system resources उपयोग करते थे और केवल बहुत कम additional attack surface जोड़ते थे। भले ही उनका उपयोग नहीं किया जाना था, उन्हें “just in case” install क्यों न रखा जाए। जैसे-जैसे CPUs तेज़ हुए, memory बड़ी हुई, storage सस्ता हुआ और system design में सुधार हुआ, GUI का प्रभाव कम और कम होता गया इसलिए GUIs उपलब्ध रखने का यह तर्क मज़बूत होता गया। विशेष रूप से मज़बूत यह प्रस्ताव था कि GUIs ने junior staff को भी काम करने में सक्षम बनाया जिससे वे अधिक उपयोगी बने। लेकिन इन परिस्थितियों में senior staff के लिए GUI को एक बैसाखी के रूप में बनाए रखना बहुत आम था।

Commodity server space में वर्चुअलाइज़ेशन के आगमन के साथ यह सब बदलने लगा। GUI की लागत अचानक फिर से ध्यान देने योग्य हो गई। बीस virtual machines चलाने वाला एक system अचानक एक single GUI instance की CPU resources, memory और storage capacity का बीस गुना उपयोग करेगा। GUI का footprint फिर से ध्यान देने योग्य था। जैसे-जैसे virtual machine densities बढ़ने लगीं, GUI का सापेक्ष प्रभाव भी बढ़ा।

वर्चुअलाइज़ेशन ने cloud computing को जन्म दिया। Cloud computing ने virtual machine deployment densities बढ़ाईं और GUIs के अन्य performance प्रभावों को उजागर किया, ज़्यादातर लंबे instance build times और अधिक जटिल remote console access के संदर्भ में। GUI की ज़रूरत वाले systems अपने GUI-less counterparts की तुलना में adoption और capabilities में ध्यान देने योग्य रूप से पीछे रहने लगे।

लेकिन कहीं बड़ा कारक cloud computing के standard billing methodologies का artifact था। क्योंकि cloud computing आमतौर पर per-instance costs को raw, पूरी तरह दृश्यमान तरीके से expose करता है, IT departments के पास GUI deployments की लागत को छिपाने या नज़रअंदाज़ करने का कोई तरीका नहीं था, जिनका additional overhead अक्सर एक single cloud instance की लागत को दोगुना कर देता था। Accounting बहुत स्पष्ट रूप से GUI systems के बिल देखती जो उनके GUI-less counterparts की तुलना में कहीं अधिक थे। यहां तक कि non-technical teams भी देख सकती थीं कि management की लागत पर विचार करने से पहले भी GUIs की लागत जुड़ती जा रही थी।

यह लागत बढ़ती जाती है जैसे-जैसे हम container technologies की ओर बढ़ते हैं जहां individual instances का scale छोटा और छोटा होता जाता है इसका मतलब है कि GUI का सापेक्ष overhead अधिक महत्वपूर्ण हो जाता है।

लेकिन असली प्रभाव, संभवतः GUI-driven systems के आसपास के मुद्दों का सबसे बड़ा exposure, DevOps system automation models की ओर उद्योग का कदम है। आज केवल कंपनियों का अपेक्षाकृत कम प्रतिशत पूरी तरह cloud-enabled, elastically scalable DevOps model of system management की ओर सक्रिय रूप से बढ़ रहा है लेकिन रुझान वहां है और model GUI administrators और उनके systems को पूरी तरह पीछे छोड़ देता है। DevOps models के साथ machines तक direct access अब प्रबंधन का एक मानक तरीका नहीं है और systems command line से केवल काम करने से भी आगे जाकर पूरी तरह code में बनाए जाने तक पहुंच गए हैं जिसका मतलब है कि न केवल DevOps दुनिया में काम करने वाले system administrators को command line पर अपने systems के साथ interact करना होगा बल्कि उन्हें programmatically ऐसा करना होगा।

Market तेज़ी से कम, अधिक highly skilled systems administrators की ओर बढ़ रही है जो किसी भी पिछले युग की तुलना में “per admin” कहीं अधिक servers के साथ काम कर रहे हैं। यह विचार कि एक single systems administrator केवल कुछ दर्जन servers ही manage कर सकता है, GUI दुनिया में एक सामान्य विश्वास, पारंपरिक “snowflake” command line systems administration में भी लंबे समय से challenged रहा है जहां संख्याएं आसानी से कुछ सौ तक पहुंच जाती हैं। लेकिन DevOps model या similar automation models वे संख्याएं administrator के हज़ारों servers तक ले जाते हैं। GUIs का overhead अधिक से अधिक स्पष्ट हो रहा है।

जैसे-जैसे cloud, containers और DevOps automation models जैसी नई technologies व्यापक होती जाती हैं, workloads का स्वाभाविक “sprawl” भी होता है। इसका मतलब है कि सभी आकारों की कंपनियां manage किए जाने वाले workloads की संख्या में वृद्धि देख रही हैं। जिन कंपनियों के पास परंपरागत रूप से केवल दो या तीन servers थे आज उनके पास दस या बीस virtual instances हो सकते हैं! केवल एक या दो virtual machines की ज़रूरत वाली कंपनियों की संख्या कम होती जा रही है।

इन सब का मतलब यह नहीं है कि GUI administration निकट, या यहां तक कि दूर के भविष्य में भी गायब हो जाएगा। “One off” systems administration की ज़रूरत बनी रहेगी। लेकिन GUI administration “one off” mode में काम करने में सक्षम administrators और command line के माध्यम से और विशेष रूप से scripted या यहां तक कि पूरी तरह automated systems (Puppet, Chef, Ansible जैसे) के माध्यम से काम करने वाले administrators का अनुपात पहले से ही non-GUI system administration और DevOps practices की ओर अविश्वसनीय रूप से तेज़ी से झुक रहा है।

इन सब का हमारे लिए वास्तविक दुनिया की खाइयों में क्या मतलब है? इसका मतलब यह है कि ऐसी roles भी, जैसे small business Windows administration, जिन्हें परंपरागत रूप से command line पर काम करने की बहुत कम या कोई ज़रूरत नहीं थी, उन्हें हमारे काम के लिए local server GUI पर निर्भरता पर पुनर्विचार करना होगा। Command line tools और processes अधिक से अधिक powerful, well known और हम जिस तरह से काम करने की उम्मीद रखते हैं वैसा होते जा रहे हैं। UNIX दुनिया में command line हमेशा बनी रही है और GUI tools पर निर्भर रहने की ज़रूरत को लगभग हमेशा एक बड़ी handicap के रूप में देखा जाएगा। यही impression Windows दुनिया पर भी लागू होने लगी है। धीरे-धीरे जो लोग exclusively GUI tools पर निर्भर हैं उन्हें second class citizens के रूप में देखा जाने लगा है और वे तेज़ी से अधिक junior roles और छोटे organizations तक सीमित होते जा रहे हैं।

Scripting और automation tools में सुधार का मतलब यह भी है कि scale का मूल्य बेहतर हो रहा है ताकि servers की छोटी संख्या को administer करने की लागत per workload basis पर बहुत अधिक हो रही है जिसका मतलब है कि छोटी companies के लिए बाहरी vendors का उपयोग करके management consolidation की ओर देखने के लिए एक बहुत भारी प्रोत्साहन है जो बड़े पैमाने पर systems management में specialize करने में सक्षम हैं और scripting और automation techniques का लाभ उठाकर अपनी लागत को बड़े businesses की लागत के अनुरूप ला सकते हैं। बाहरी vendors का उपयोग करके scale या उसके एक approximation को establish करने की क्षमता समय के साथ छोटे businesses के लिए IT ज़रूरतों में cost competitive रहने के लिए बहुत महत्वपूर्ण होगी, जबकि आज बड़े businesses जिस तरह के computing advantages का अनुभव करने लगे हैं वही style प्राप्त करने के लिए।

यह नोट किया जाना चाहिए कि command line और automation tools की ओर इस industry shift के साथ-साथ अधिक आधुनिक, powerful और principally remote GUIs की ओर भी कदम हो रहा है। यह एक बहुत कम नाटकीय बदलाव है लेकिन एक जिसे नज़रअंदाज़ नहीं किया जाना चाहिए। Microsoft के RSAT और Server Administrator जैसे tools एक GUI view प्रदान करते हैं जो hood के नीचे command line और API interfaces का लाभ उठा रहे हैं। इसी तरह Canonical की Ubuntu दुनिया में अब Landscape है। ये tools enterprise में कम popular हैं लेकिन बड़े SMB market को server instances के बड़े set को manage करते हुए GUI dependency बनाए रखने में सक्षम बनाने लगे हैं। इस प्रकार के GUI tools में advancement बोर्ड भर में command line tools के adoption को धीमा करने वाली सबसे मज़बूत शक्ति हो सकती है।

चाहे हम command line से GUIs की ओर और वापस command line की ओर जाने में Information Technology के उद्योग के इतिहास के एक दिलचस्प artifact के रूप में रुचि रखते हों या यदि हम इसे इस रूप में देख रहे हों कि systems administration हमारे अपने उपयोगों के लिए एक career path या business approach के रूप में कैसे evolve हो रहा है, यह हमारे लिए उन कारकों की सराहना करना अच्छा है जो इसे होने का कारण बने और क्यों उद्योग का ebb और flow अब हमें एक बार फिर command line के समंदर में वापस ले जा रहा है। इन शक्तियों को समझकर हम अधिक व्यावहारिक रूप से यह आकलन कर सकते हैं कि भविष्य हमें कहां ले जाएगा, ज्वार फिर कब बदल सकता है, अपने करियर के लिए सबसे अच्छे तरीके से कैसे approach करें या अपने organizations के लिए technology और human talent दोनों पर निर्णय कैसे लें।