CTOcast # 0: रुस्लान सिनित्सकी (जेलस्टिक)

पेश है आईटी कंपनियों में तकनीक, प्रक्रियाओं, बुनियादी ढांचे और लोगों पर पॉडकास्ट के शून्य संस्करण का परिचय। आज, CTOcast पर जाने वाले रुस्लान सिनित्सकी, CTO और Jelastic के सह-संस्थापक हैं।

पॉडकास्ट सुनो



रुस्लान सिनित्सकी का जन्म 1978 में हुआ था। ज़ाइटॉमिर, यूक्रेन में रहता है और काम करता है। उन्हें बचपन से ही प्रोग्रामिंग का शौक था, उन्होंने ज़ाइटॉमिर मिलिट्री इंस्टीट्यूट ऑफ रेडियो इलेक्ट्रॉनिक्स से विशेष निगरानी उपकरणों की डिग्री के साथ स्नातक किया। 2001-2008 में यूक्रेन की राष्ट्रीय अंतरिक्ष एजेंसी में काम किया, जहां वह पृथ्वी की सतह पर भूकंप नियंत्रण के लिए सॉफ्टवेयर के विकास में लगे हुए थे। 2008-2011 में - iQueLab में वरिष्ठ UI वास्तुकार। उन्होंने विभिन्न आउटसोर्सिंग कंपनियों में फ्रीलांसर के रूप में भी काम किया।

Jelastic के बारे में कुछ शब्द:

2008 में, हेबर में, रुस्लान सिनित्स्की ने कोंस्टेंटिन एलेक्जेंड्रोव (वोरोनिश का एक प्रोग्रामर) से मुलाकात की, जिसके साथ वह जावा डेवलपर्स के लिए एक उपकरण के विचार के साथ आया, जो अनुप्रयोगों को विकसित करने और उन्हें स्केल करने की प्रक्रिया को सरल करता है। 2 वर्षों में एक व्यक्तिगत बैठक के बिना, रुस्लान और कॉन्स्टेंटिन ने एक प्रोटोटाइप बनाया।

2010 में, कंपनी Hivext Technologies, Inc. की स्थापना की गई, जो जेल्लास्टिक के पूर्वज बने। लगभग उसी समय, एलेक्सी स्कूटिन टीम में शामिल हो गए, संभावित निवेशकों की तलाश में और बाजार में जेलस्टिक को बढ़ावा दिया। दिसंबर 2010 में, बुवाई के दौर में रुना कैपिटल फंड से निवेश प्राप्त हुआ, जिसने सभी को एक शहर में इकट्ठा करने की अनुमति दी - ज़ाइटॉमिर और एक विकास टीम की भर्ती की।

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

सितंबर 2013 में, मैक्सफील्ड कैपिटल निवेशक टीम में शामिल हो गया, और जॉन डेरिक ने रुस्लान को सीईओ के रूप में सफलता दिलाई।

वर्तमान में, कंपनी के पास दुनिया भर में लगभग 80 हजार उपयोगकर्ता हैं - संयुक्त राज्य अमेरिका, यूरोप, एशिया और 24 भागीदारों में - एक होस्टिंग प्रदाता। Jelastic अपने आप में दुनिया में एकमात्र Platform-as-Infrastructure solution के रूप में है।

पॉडकास्ट सुनो

पॉडकास्ट का पाठ संस्करण (पहला भाग)

पावेल पावलोव: प्लेटफ़ॉर्म-एज़-इन्फ्रास्ट्रक्चर का विषय पहले से ही आज तक छू चुका है। मैं इस बारे में अधिक जानना चाहूंगा कि इस शब्द में आपकी कंपनी का क्या अर्थ है?

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

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

इसलिए, संक्षेप में, प्लेटफार्म-ए-इन्फ्रास्ट्रक्चर प्लेटफॉर्म-ए-ए-सर्विस और इन्फ्रास्ट्रक्चर-ए-सर्विस के हाइब्रिड है।

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

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

अलेक्जेंडर अस्टापेंको: प्रत्यक्ष ग्राहक और जो वास्तव में उत्पाद के लिए भुगतान करते हैं, वे बी 2 बी कंपनियां हैं, अर्थात् कुछ मध्य परत, और अंतिम उपयोगकर्ता नहीं हैं जो जेलस्टिक के साथ काम करेंगे। उदाहरण के लिए, ये होस्टिंग प्रदाता हैं। तो? आपके ग्राहक कौन हैं इसके बारे में कुछ शब्द?

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

अलेक्जेंडर अस्टापेंको: क्या मैं सही ढंग से समझता हूं कि उत्पाद का प्रचार दो दिशाओं में होता है: अंतिम उपयोगकर्ताओं के लिए जो परिणामों के साथ काम करेंगे, अर्थात्, खुद जेलेस्टिक उत्पाद, और जो अपने सर्वर पर जेलस्टिक स्थापित करेंगे?

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

पावेल पावलोव: यह उत्पाद, प्लेटफ़ॉर्म में रुचि का संदर्भ है, और आपने कंपनी के विकास की शुरुआत में और बड़े कॉर्पोरेट ग्राहकों के साथ काम करते समय आत्मविश्वास कैसे बनाया?

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

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

पावेल पावलोव: आप मंच की बहुमुखी प्रतिभा के बीच एक निश्चित समझौता हासिल करने में कामयाब रहे, जो उपयोगकर्ताओं के कई समूहों और लचीलेपन और ठीक-ट्यूनिंग के लिए जगह के अनुरूप होगा।

रुस्लान सिनित्सकी: हाँ, मुझे लगता है कि हम एक संतुलन खोजने में कामयाब रहे।

पावेल पावलोव: आप कितने समय के लिए आए हैं?

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

जब हमने अपने Hivext उत्पाद का पहला संस्करण बनाया, तो हमने 5,000 उपयोगकर्ताओं को एकत्रित किया, और यह Hivext Google App Engine - Backend-as-a-Serivce के समान था। इस दृष्टिकोण का नुकसान यह है कि उपयोगकर्ता एक मानक एप्लिकेशन को तैनात नहीं कर सकते हैं, वे संचित अनुभव का उपयोग नहीं कर सकते हैं - उन्हें फिर से आवेदन लिखना होगा। तदनुसार, एक छोटे से स्टार्टअप के लिए - यह कहीं भी सड़क नहीं है। बड़ी कंपनियां वहां नहीं जाएंगी, केवल छोटे स्टार्टअप, जो सिद्धांत रूप में प्रारंभिक चरण में पैसा देने में सक्षम नहीं हैं। इससे सीख लेने के बाद, हमने अपने मंच के अगले संस्करण में मुख्य लाभ को मुख्य लाभ बनाने का फैसला किया। हमने कहा कि हम एक ऐसा प्लेटफॉर्म बनाएंगे जिसमें आपके कोड को दोबारा लिखने की आवश्यकता न हो।

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

अलेक्जेंडर अस्टापेंको: यह लीन दृष्टिकोण के समान है।

रुस्लान Sinitsky: हाँ, यह लगभग लगता है। ईमानदारी से, उन्होंने इसे शुरू में नहीं पढ़ा, लेकिन फिर, जब समय बीत गया और मुझे एक पुस्तक मिली, पढ़ी और महसूस किया कि हम इसके बहुत करीब हैं।

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

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

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

अलेक्जेंडर अस्टापेंको: प्रक्रिया कैसे चल रही है? एकीकरण कौन करता है? मेजबान से विशेषज्ञ या आपकी तरफ से कोई? और होस्टर द्वारा नियंत्रित प्रक्रिया कितनी है? वे इसे कितना नियंत्रित करना चाहते हैं?

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

अलेक्जेंडर अस्टापेंको: यह देखा जा सकता है कि प्रक्रिया पहले से ही काम के वर्षों में तैयार की गई है। मैं समझता हूं कि शुरुआत में ऐसा बिल्कुल नहीं था। आप अपने स्वयं के अनुभव से गुजरे। है न?

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

अलेक्जेंडर अस्टापेंको: रूस में, 90 के दशक के अंत में, ऐसे व्यक्ति को देश पर शासन करने के लिए फेंक दिया गया था, हमने इसके बारे में सुना।

रुस्लान Sinitsky: ठीक है, हाँ)

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

रुस्लान सिनित्सकी: जब हम 5-7 लोग थे, यह सवाल आसान हल हो गया था, कम लोग और बड़ी चीजें अधिक स्पष्ट थीं। जब लोग अधिक से अधिक काम करने लगते हैं, तब सब कुछ अधिक जटिल हो जाता है। इसलिए, कुछ प्रक्रियाओं को लागू करना आवश्यक है। हमने उन विशेषज्ञों को आमंत्रित किया जो हमारी टीम में आए और प्रक्रियाओं की स्थापना की। यह एक विशेष कार्यात्मक की प्राथमिकता निर्धारित करने की प्रक्रिया का संबंध है। आज हम एजाइल का उपयोग करते हैं, हम बैकलॉग का उपयोग करते हैं।

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

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

अलेक्जेंडर अस्टापेंको:यही है, आप कह सकते हैं कि आप जेलेस्टिक उत्पाद बनाने वाले व्यक्ति हैं?

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

अलेक्जेंडर अस्टापेंको: ठीक है, सुविधाओं को इकट्ठा किया जाता है, प्राथमिकताओं को पंक्तिबद्ध किया जाता है, उन्होंने रिलीज और बाजार को मारा। आप कैसे निर्णय लेते हैं कि आपको जिस सुविधा की आवश्यकता है और वह उत्पाद से रहता है या उसे हटाता है? या क्या आप वहां मौजूद सुविधाओं को नहीं हटाते हैं?

रुस्लान सिनित्सकी:हम एमवीपी (न्यूनतम व्यवहार्य उत्पाद) करने की कोशिश करते हैं - ऐसा कुछ जो एक स्क्वाट में करना आसान है, जो मूल रूप से समाप्त हो गया है और एक विशिष्ट समस्या को हल करता है। हम इसे उपयोगकर्ताओं को समाप्त करने और उनकी प्रतिक्रिया को देखने के लिए देने की कोशिश करते हैं, अर्थात हम प्रतिक्रिया एकत्र करते हैं। यह देखने के लिए कि क्या हम सही दिशा में जा रहे हैं, यह विश्लेषण करने के लिए कि किसी अन्य की तुलना में एक दिलचस्प विशेषता है, क्या वास्तु समाधान को सही तरीके से चुना गया है। अगली रिलीज के लिए, हम पहले से ही कुछ बदलाव कर रहे हैं, विभिन्न विशेषताओं के लिए एकत्रित प्रतिक्रिया के अनुसार, हम प्राथमिकताएं निर्धारित करते हैं। हमने एक रिलीज़ में शुरू से लेकर अंत तक एक भी फीचर जारी नहीं किया। क्योंकि अन्यथा हम केवल इस सुविधा पर विशेष रूप से ध्यान केंद्रित करते हैं, और बहुत सारी दिशाएँ होती हैं। दूसरे, यदि आप कुछ गलत करते हैं जब आप गहरे जाते हैं और इसे अंतिम उपयोगकर्ताओं पर आज़माते हैं,रीमेकिंग बहुत कठिन और समस्याग्रस्त होगी। आप गलत दिशा में बहुत समय खो देंगे, जो कंपनी के लिए बहुत महंगा होगा। इसलिए, हम छोटे, पुनरावृत्त चरणों में जाने का प्रयास करते हैं। उदाहरण के लिए, हमने हाल ही में रूबी को एक निजी बीटा में जारी किया, होस्टर्स ने वापस नहीं लिया और एक सार्वजनिक बीटा में प्रकाशित किया। हमने प्रतिक्रिया एकत्र की और हम यह सुनिश्चित करने के लिए जानते हैं कि वर्तमान रूबी कार्यान्वयन में क्या कमी है। 100% जानते हैं कि सबसे महत्वपूर्ण क्या है, और हम अगले रिलीज में ऐसा करते हैं। हम इसे फिर से जारी करेंगे और देखेंगे: हाँ, हमने 80% कवर किया है, अब हम 90% मामलों को कवर करते हैं। 95% मामलों को कवर करने के लिए क्या करने की आवश्यकता है?हमने प्रतिक्रिया एकत्र की और हम यह सुनिश्चित करने के लिए जानते हैं कि वर्तमान रूबी कार्यान्वयन में क्या कमी है। 100% जानते हैं कि सबसे महत्वपूर्ण क्या है, और हम अगले रिलीज में ऐसा करते हैं। हम इसे फिर से जारी करेंगे और देखेंगे: हाँ, हमने 80% कवर किया है, अब हम 90% मामलों को कवर करते हैं। 95% मामलों को कवर करने के लिए क्या करने की आवश्यकता है?हमने प्रतिक्रिया एकत्र की और हम यह सुनिश्चित करने के लिए जानते हैं कि वर्तमान रूबी कार्यान्वयन में क्या कमी है। 100% जानते हैं कि सबसे महत्वपूर्ण क्या है, और हम अगले रिलीज में ऐसा करते हैं। हम इसे फिर से जारी करेंगे और देखेंगे: हाँ, हमने 80% कवर किया है, अब हम 90% मामलों को कवर करते हैं। 95% मामलों को कवर करने के लिए क्या करने की आवश्यकता है?

पावेल पावलोव: और PHP, रूबी के लिए नए प्लेटफार्मों के लिए इस तरह के एक संक्रमण का विचार कैसे आया? मंच की लोकप्रियता से प्रेरित या कुछ और?

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

पावेल पावलोव: रूबी के बारे में कैसे आया?

रुस्लान सिनित्सकी: हमने PHP जोड़ा, हमने वाणिज्यिक PHP लॉन्च किया है, यह ठीक काम करता है, संसाधन मुक्त हैं, और फिर हम रूबी के पास गए।

पावेल पावलोव: यानी, कदम से कदम?

रुस्लान सिनित्सकी:हां। .NET के बाद हमारा अगला नोड.जेएस है। मुझे लगता है कि अजगर को नोड के साथ जोड़ा जाएगा। कुछ ही दिन पहले, हमने रेड हैट के साथ एक साझेदारी की घोषणा की, सिद्धांत रूप में, हमारे प्रतियोगी, ओपनशिफ्ट (प्लेटफॉर्म-ए-ए-सर्विस) के साथ, कि हम एप्लिकेशन सर्वर, डेटाबेस के लिए प्रोग्रामिंग भाषाओं के ढेर के लिए एकीकृत टेम्पलेट प्रारूप का समर्थन करेंगे। । इन दोनों प्लेटफार्मों के बीच एकीकृत प्रारूप होगा। इसका मतलब यह है कि, उदाहरण के लिए, डेटाबेस, एप्लिकेशन सर्वर या बस अनुप्रयोगों के डेवलपर्स इस प्रारूप में अपने अनुप्रयोगों को पैक कर सकते हैं और एप्लिकेशन को आसानी से या तो OpenShift या Jelastic में तैनात किया जा सकता है और इसे एक विशिष्ट प्लेटफ़ॉर्म के लिए फिर से लिखने की आवश्यकता नहीं होगी। इस प्रकार, निकट भविष्य में पारिस्थितिकी तंत्र बहुत बढ़ जाएगा। यह एकीकरण के लिए एक बहुत ही गंभीर कदम है, जो बाजार के सभी खिलाड़ियों के लिए बहुत अच्छा है।

पॉडकास्ट का पाठ संस्करण आने वाले दिनों में भी जारी रहेगा।