नोडर डेनेलिया, शटल के सीईओ और सह-संस्थापक – साक्षात्कार श्रृंखला

नोडर डेनेलिया, शटल के सीईओ और सह-संस्थापक – साक्षात्कार श्रृंखला: नोडर डेनेलिया ने 2019 में कंपनी की स्थापना के बाद से शटल के सह-संस्थापक और सीईओ के रूप में कार्य किया है, इसकी वृद्धि का नेतृत्व एक प्रारंभिक वाईसी समर 2020 स्टार्टअप से एक डेवलपर-केंद्रित प्लेटफ़ॉर्म इंजीनियरिंग कंपनी में किया है; शटल से पहले उन्होंने प्रोवेनेंस टेक्नोलॉजीज़ लिमिटेड में चीफ रिस्क ऑफिसर सहित भूमिकाएं निभाईं, जहां उन्होंने सांख्यिकीय हेज फंड रणनीतियों पर काम किया, और पहले लंदन और गूगल में तकनीकी और डेटा भूमिकाएं निभाईं।

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

आपको शटल को सह-संस्थापक बनाने के लिए कौन सा क्षण या निराशा थी, और आप शुरुआत में किस समस्या का समाधान करने की कोशिश कर रहे थे?

मोड़ का बिंदु मेरे समय के दौरान एक सांख्यिकीय हेज फंड में व्यापार का नेतृत्व करने के दौरान आया। हमारे पास असाधारण इंजीनियर थे – पीएचडी, वरिष्ठ प्लेटफ़ॉर्म लोग, एमएल शोधकर्ता – लेकिन फिर भी क्लाउड इंफ्रास्ट्रक्चर हमेशा बोतलनेक था। एक ट्रेडिंग मॉडल या बैकेंड सेवा बनाना मुश्किल नहीं था। समस्या तैनाती थी: इसे सुरक्षित रूप से लाइव प्राप्त करना, इसे स्केल करना, क्लाउड सेवाओं को एक साथ जोड़ना। यह वह जगह थी जहां सब कुछ धीमा हो गया। एक बिंदु पर, हमारी इंजीनियरिंग टीम के अधिकांश डेवओप्स कार्य कर रहे थे, बस सिस्टम को चलाने के लिए।

जो बात मुझे याद रही वह कोड या गणित की जटिलता नहीं थी। यह देख रहा था कि कितने सक्षम लोग अपना अधिकांश समय वास्तव में महत्वपूर्ण चीज़ें बनाने के बजाय क्लाउड से जूझने में बर्बाद कर रहे थे। कोई भी उस काम को करना नहीं चाहता था, लेकिन यह अपरिहार्य था। वह घर्षण – “मैंने कुछ बनाया” और “यह विश्वसनीय रूप से चल रहा है” के बीच का अंतर – यह वह समस्या है जिसे शटल हल करने के लिए बनाया गया था।

शटल की स्थापना 2019 में हुई थी, आज के एआई कोडिंग टूल्स की लहर से पहले। एआई-सहायता प्राप्त विकास के मुख्यधारा बनने के साथ आपकी मूल दृष्टि कैसे विकसित हुई है?

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

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

दृष्टि «डेवलपर के लिए इंफ्रास्ट्रक्चर आसान बनाना» से बदलकर «निर्माताओं की एक पूरी नई पीढ़ी के लिए इंफ्रास्ट्रक्चर काम करने योग्य बनाना» हो गई। इसमें एकल संस्थापक, छोटी टीमें और ऐसे एआई एजेंट हैं जो बैकेंड कोड बना सकते हैं लेकिन क्लाउड कॉन्फ़िगरेशन से जूझना नहीं चाहते। अब हम केवल पारंपरिक इंजीनियरों की सेवा नहीं करते। उपयोगकर्ताओं का दायरा बहुत बढ़ गया है।

एआई टूल्स जैसे कर्सर और गिटहब कोपिलॉट ने कोड लिखने के तरीके को बदल दिया है। आपके दृष्टिकोण से, सॉफ्टवेयर जीवन चक्र के कौन से हिस्से सबसे अधिक सुधार करते हैं, और टीमें अभी भी कहां संघर्ष करती हैं?

कोड जनरेशन ने छलांग लगाई है। वह हिस्सा लगभग हल हो गया है। आप एक विशेषता का वर्णन कर सकते हैं, और एआई उसकी शुरुआती संरचना तैयार कर देगा। फ्रंटएंड विशेष रूप से लाभान्वित हुआ है क्योंकि पैटर्न अच्छी तरह से समझे जाते हैं – घटक, शैलियों, लेआउट।

जहां टीमें संघर्ष करती हैं वह है सब कुछ जो उसके बाद आता है: तैनाती, इंफ्रास्ट्रक्चर, संचालन। एआई एक एपीआई एंडपॉइंट बना सकता है, लेकिन यह स्वचालित रूप से डेटाबेस, स्टोरेज, क्यू, नेटवर्किंग, अनुमतियों या तैनाती पाइपलाइन का निर्माण नहीं कर सकता है जो इसे वास्तविक बनाता है। बैकेंड इंफ्रास्ट्रक्चर कोड जनरेशन के साथ तालमेल नहीं रखा है।

परिणाम असमान प्रगति है। शुरू से अंत तक चीज़ें आसान होने के बजाय नए दबाव-बिंदु उभरते हैं। टीमें मिनटों में पूरा बैकेंड बनाती हैं, फिर उसे सुरक्षित रूप से तैनात करने में कई दिन अटक जाती हैं। कभी-कभी एआई इतना अधिक कोड बनाता है कि टीम उसे चला या बनाए नहीं रख सकती। असली बाधा अब यहीं है।

तैनाती अक्सर एआई-जनित अनुप्रयोगों के लिए सबसे बड़ा बोतलनेक के रूप में वर्णित किया जाता है। उत्पादनीकरण इन प्रणालियों को इतना चुनौतीपूर्ण बनाने वाली विशिष्ट क्या है, कोड स्वयं को उत्पन्न करने की तुलना में?

समस्या विश्वसनीयता और परिणाम है। कोड जनरेशन माफ़ करने योग्य है – यदि एआई एक गलती करता है, तो आप तुरंत इसे देखते हैं और इसे ठीक करते हैं। इंफ्रास्ट्रक्चर गलतियां अलग हैं। एक गलत अनुमति, एक गलत संसाधन, एक खराब धारणा लागत या सुरक्षा के बारे में और आप एक वास्तविक समस्या बना देते हैं जो बाद में तक नहीं दिखाई दे सकती है।

शुरुआत में हमने एआई को एप्लिकेशन कोड से स्वतंत्र रूप से इंफ्रास्ट्रक्चर का अनुमान लगाने दिया। डेमो में यह बहुत अच्छा लगा, लेकिन असली सिस्टम में विफल हो गया। एआई पूरे विश्वास से ऐसी व्यवस्थाएँ बनाता जो लगभग सही थीं, पर पूरी तरह नहीं: बहुत व्यापक अनुमतियाँ, संसाधनों के अजीब विकल्प और ऐसी कॉन्फ़िगरेशन जो चुपचाप महँगी होती जातीं।

इससे हमने महत्वपूर्ण बात सीखी: उत्पादन में सीमाओं के बिना बुद्धिमत्ता समस्याएँ पैदा करती है। एआई को अधिक स्वतंत्रता नहीं, बेहतर सुरक्षा सीमाएँ चाहिए। आपको ऐसे सिस्टम बनाने होंगे जिनमें एआई सुझाव दे और गति बढ़ाए, लेकिन बेलगाम न हो सके। यही तकनीकी चुनौती एआई-जनित ऐप को उत्पादन में लाना, कोड बनाने से कहीं अधिक कठिन बनाती है।

शटल ने हाल ही में नेपच्यून को अपने प्लेटफ़ॉर्म के अगले विकास के रूप में पेश किया। नेपच्यून को एक यूनिवर्सल एआई प्लेटफ़ॉर्म इंजीनियर के रूप में वर्णित किया गया है – इसका क्या अर्थ है व्यावहारिक रूप से डेवलपर्स के लिए जो एक प्रोटोटाइप से एक उत्पादन-तैयार बैकेंड में जा रहे हैं?

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

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

प्रोटोटाइप से उत्पादन की ओर जाने वाले व्यक्ति के लिए इसका अर्थ है कि अचानक DevOps सीखने की दीवार सामने नहीं आती। आपका बनाया एप्लिकेशन स्केल बढ़ने पर भी काम करता रहता है। नेपच्यून «मैंने कुछ बनाया है» और «यह उत्पादन में विश्वसनीय रूप से चल रहा है» के बीच का अंतर मिटाता है।

डेवलपर्स बैकेंड सिस्टम को उत्पन्न करने के लिए एआई पर अधिक भारी रूप से निर्भर करते हैं, तो आप गति और अमूर्तता की आवश्यकता के साथ नियंत्रण, सुरक्षा और दृश्यता की आवश्यकता को कैसे संतुलित करते हैं?

विश्वास उत्तर है। इंफ्रास्ट्रक्चर में, विश्वास क्षमता से अधिक मायने रखता है। एक बुरी आश्चर्य – एक सुरक्षा छेद, एक टूटी हुई तैनाती, एक बड़ा क्लाउड बिल – और आप लोगों को खो देते हैं।

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

हमने «एआई निर्णय करता है» से «एआई सीमाओं के भीतर प्रस्ताव रखता है» की ओर बदलाव किया। यही मज़ेदार डेमो और महत्वपूर्ण समय पर भरोसेमंद सिस्टम का अंतर है। डेवलपर निर्णय लेने में कम समय नहीं लगाते; वे टाइप करने में कम समय और यह तय करने में अधिक समय लगाते हैं कि क्या होना चाहिए, क्या स्वीकार्य है और कौन-से समझौते उचित हैं। सर्वश्रेष्ठ टीमें एआई को बहुत सक्षम जूनियर इंजीनियर मानती हैं: मददगार और उत्पादक, लेकिन नियंत्रण रखने वाला नहीं।

आज नेपच्यून से सबसे मजबूत मूल्य देख रहे टीमों के प्रकार क्या हैं, चाहे वह एकल डेवलपर, स्टार्टअप या बड़े इंजीनियरिंग संगठन हों?

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

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

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

तकनीकी दृष्टिकोण से, नेपच्यून पर्यावरण कॉन्फ़िगरेशन, सीक्रेट प्रबंधन और इंफ्रास्ट्रक्चर ऑर्केस्ट्रेशन को कैसे संभालता है जब यह एआई-जनित कोड को एक तैनाती योग्य उत्पादन बैकेंड में बदल देता है?

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

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

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

आगे देखते हुए, आप नेपच्यून की भूमिका को एक पारिस्थितिकी तंत्र में कैसे विकसित होते हुए देखते हैं जहां एआई सिस्टम बढ़ते हुए सॉफ्टवेयर सिस्टम का निर्माण, तैनाती और प्रबंधन करते हैं?

हम एक दुनिया की ओर बढ़ रहे हैं जहां एक विचार और एक काम करने वाले उत्पाद के बीच का अंतर लगभग शून्य है। जल्द ही, उत्पाद न केवल तेजी से बनाए जाएंगे, बल्कि वे वास्तविक उपयोगकर्ता फीडबैक के आधार पर स्वयं को लगातार बेहतर बनाएंगे।

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

हमारा दीर्घकालिक लक्ष्य एआई-सहायता प्राप्त डेवओप्स के लिए डिफ़ॉल्ट सिस्टम बनना है – मूल रूप से एआई प्लेटफ़ॉर्म इंजीनियर। चाहे कोड एक डेवलपर द्वारा कर्सर में लिखा गया हो या स्वचालित रूप से एक एआई एजेंट द्वारा उत्पन्न किया गया हो, नेपच्यून वह परत होनी चाहिए जो इसे कोड से एक पूरी तरह से चलने वाले, स्केलेबल, उत्पादन-ग्रेड सेवा में ले जाती है।

यदि रचनात्मकता अप्रतिबंधित हो जाती है, तो इंफ्रास्ट्रक्चर एक प्रतिबंध नहीं हो सकता। जैसे ही एआई एजेंट और स्वचालित रूप से विकसित होने वाले उत्पाद सामान्य हो जाते हैं, हमारा काम यह सुनिश्चित करना है कि क्लाउड इंफ्रास्ट्रक्चर के साथ बातचीत सहज, पूर्वानुमानित और सुरक्षित है। हम उसे अदृश्य बनाने पर ध्यान केंद्रित कर रहे हैं, ताकि डेवलपर, संस्थापक और कंपनियां मूल्य बनाने पर ध्यान केंद्रित कर सकें और इंफ्रास्ट्रक्चर से जूझने के बजाय।

धन्यवाद महान साक्षात्कार के लिए, पाठक जो अधिक जानना चाहते हैं उन्हें शटल पर जाना चाहिए।