मैं इस बारे में बात करने का प्रस्ताव करता हूं कि माइक्रोसर्विस की आवश्यकता कब है, और कब नहीं। स्पॉयलर: यह परियोजना पर निर्भर करता है।

हम, सॉफ्टवेयर डेवलपर्स, बल्कि एक दिलचस्प पेशा है। हम सुरक्षित रूप से दिनों के लिए कोड कर सकते हैं, और फिर कुछ के बारे में एक लेख पढ़ सकते हैं - और यह हमारे पूरे काम पर सवाल उठाता है, क्योंकि कुछ नेटफ्लिक्स ने एक्सवाईजेड को बताया।

ठीक उसी तरह, जैसे किसी एक व्यक्ति या कंपनी की राय के कारण, आप उन सभी चीजों पर संदेह करना शुरू कर देते हैं जो आप कई वर्षों से कर रहे हैं, भले ही वह सब कुछ पूरी तरह से हो।

आप Google नहीं हैं (जब तक आप Google नहीं हैं)

जब हम HackerNews और अन्य समाचार साइटों को पढ़ते हैं, तो हम अक्सर Google, नेटफ्लिक्स, अमेज़ॅन और फेसबुक से तकनीकी संदेश देखते हैं, और वे इस बारे में बात करना पसंद करते हैं कि वे कितनी सैकड़ों या हजारों सेवाएं लॉन्च करते हैं। वे चीजों को अपने तरीके से करने के लाभों के बारे में बात करते हैं। यह पिछले कुछ सालों का एक ट्रेंड है।

लेकिन इसका सामना करते हैं। यह संभावना नहीं है कि आपके पास 1000 डेवलपर्स हैं जो 10 से अधिक वर्षों के इतिहास के साथ एक बड़े पैमाने पर परियोजना पर काम कर रहे हैं।

सिर्फ इसलिए कि Google का यह मतलब नहीं है कि आपको ऐसा करना चाहिए।

हम पूरी तरह से अलग आकाशगंगा में काम करते हैं। Google को उन समस्याओं का सामना करना पड़ रहा है जिनका हम कभी सामना नहीं करेंगे, लेकिन साथ ही हम उन चीजों को भी कर सकते हैं जो Google नहीं कर सकता।

अधिकांश सॉफ्टवेयर प्रोजेक्ट कैसे शुरू होते हैं?

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

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

नरक नं। मैं Shopify के पहले संस्करण को विकसित करते समय मौजूद नहीं था, जो मूल रूप से स्नोबोर्डिंग के लिए सिर्फ एक ऑनलाइन स्टोर था, लेकिन अगर टोबियास मुझे (एक विशिष्ट डेवलपर) दिखता है, तो प्रक्रिया कुछ इस तरह दिखती है:

1. मूल उत्पाद लिखते समय नई तकनीक सीखें।
2. एक गैर-मानक (बुरा) लिखें, लेकिन पूरी तरह से काम करने वाला कोड।
3. देखें कि कैसे सब कुछ एक साथ काम करता है और उत्तेजित हो जाता है।
4. रिफैक्टर जैसे "आग से जलना" और समस्या होने पर कोड में सुधार करना।
5. नई सुविधाओं को जोड़ने और एक उत्पादन वातावरण में शुरू होने पर इस चक्र को दोहराएं।

यह एक बहुत ही सरल चक्र की तरह लग सकता है, लेकिन मुझे प्रोग्रामिंग के बारे में 20 साल लग गए कि यह कितना गहरा है।

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

आपके द्वारा प्रतिस्थापित मूल कोड समय या प्रयास व्यर्थ नहीं है। समय के साथ, यह आपके स्तर को बेहतर बनाने में आपकी बहुत मदद करता है। यह एक गुप्त घटक है।

कोड सार के बारे में बात करें

डेवलपर्स के रूप में, हम सभी ने "DRY: खुद को दोहराएं नहीं" वाक्यांश सुना है , और कुल मिलाकर यह उचित सलाह है कि फिर से काम न करें। लेकिन अक्सर यह करने योग्य है।

जब आप पूरी समझ के बिना किसी चीज को अमूर्त करने की कोशिश करते हैं और जो एक टपका हुआ अमूर्त कहलाता है, उसे बनाने की कोशिश करता है।

मैं आमतौर पर तीन बार काम करने से पहले कुछ कोड को फिर से भरने और डुप्लिकेट को हटाने के बारे में सोचता हूं। अक्सर, केवल 4 या 5 वीं बार के बाद ही मैं कुछ उपाय करता हूं।

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

एब्स्ट्रक्शन का स्तर, एम्बेडेड कोड से बाहरी पुस्तकालयों तक:

1. इनलाइन कोड लिखें।
2. कई अलग-अलग स्थानों में कोड को डुप्लिकेट करें।
3. फंक्शन में डुप्लिकेट कोड निकालें, आदि।
4. थोड़ी देर के लिए इन अमूर्त का उपयोग करें।
5. देखें कि यह कोड अन्य कोड के साथ कैसे इंटरैक्ट करता है।
6. आंतरिक लाइब्रेरी में सामान्य कार्यक्षमता निकालें।
7. लंबे समय तक आंतरिक पुस्तकालय का उपयोग करें।
8. वास्तव में समझते हैं कि सभी टुकड़े एक साथ कैसे आते हैं।
9. एक बाहरी पुस्तकालय (खुला स्रोत, आदि) बनाएं, अगर यह समझ में आता है।

मुद्दा यह है कि आप एक अच्छे पुस्तकालय या ढांचे का "आविष्कार" नहीं कर सकते। लगभग सभी बहुत सफल उपकरण जो आज हम उपयोग करते हैं वे वास्तविक दुनिया की परियोजनाओं से आते हैं। वहां, हमारे पसंदीदा उपकरण को आंतरिक उपयोग के वास्तविक मामलों से निकाला जाता है।

रेल एक महान उदाहरण है। डीएचएच (रेल्स के लेखक) एक दिन भी नहीं उठे और कहा: “ओह! यह मॉडल /, नियंत्रक / और विचार / निर्देशिका बनाने का समय है। "

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

यह बहुत अच्छी तरह से चलने का एक आदर्श तूफान है (पढ़ें: सैद्धांतिक रूप से विकसित नहीं) सार एक प्रोग्रामिंग भाषा के साथ संयुक्त है जो आपको आकर्षक कोड लिखने की अनुमति देता है। यह भी बताता है कि "RY में केवल" रेल जैसे लगभग सभी ढांचे क्यों काम नहीं करते हैं। वे अमूर्त श्रृंखला के प्रमुख घटकों को छोड़ देते हैं और सोचते हैं कि वे बस रेल की नकल कर सकते हैं।

अमूर्तता से लेकर माइक्रोसेवा तक

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

माइक्रोसेर्विस वह नहीं है जहां आप शुरू करते हैं, ठीक वैसे ही जैसे आप कम से कम कोड की एक पंक्ति लिखने से पहले एकदम सही बाहरी ओपन सोर्स लाइब्रेरी बनाने की कोशिश नहीं करेंगे। इस समय, आप यह भी नहीं जानते हैं कि आप क्या विकसित कर रहे हैं।

जब आप वास्तविक समस्याओं में भाग लेते हैं, तो एक माइक्रो-सर्विस आधारित वास्तुकला एक परियोजना समय के साथ बदल सकती है।

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

मुझे नहीं लगता कि कोई भी उन्हें छोटा कहेगा, हालांकि वे Google पैमाने पर काम नहीं करते हैं।

Shopify मोनोलिथ पर प्रति माह $ 17 मिलियन कमाता है

2018 के मध्य तक, Shopify ने सार्वजनिक रूप से घोषणा की है कि उनके प्लेटफ़ॉर्म पर 600,000 से अधिक ऑनलाइन स्टोर संचालित हैं।

Shopify एक SaaS एप्लिकेशन है जिसमें प्रति माह $ 29 की सबसे सस्ती दर है, और मुझे यह महसूस होता है कि कई कंपनियां प्रति माह $ 79 की दर का चयन करती हैं। किसी भी मामले में, भले ही 600,000 ग्राहकों ने $ 29 के लिए सबसे सस्ती योजना का उपयोग किया हो, यह केवल उनके व्यवसाय की सास लाइन से प्रति माह $ 17.4 मिलियन की आय है।

बेसकैंप ऐप एक और बेहतरीन मोनोलिथिक ऐप है। बेसकैंप के बारे में जो दिलचस्प है वह यह है कि उनके पास केवल लगभग 50 कर्मचारी हैं, और उनमें से कुछ ही सॉफ्टवेयर डेवलपर हैं जो मुख्य उत्पाद पर काम कर रहे हैं।

मैं यह कहना चाहता हूं कि आप बहुत दूर जा सकते हैं बिना खरगोशों के सूक्ष्मदर्शी के छेद के नीचे। माइक्रोसर्विस को ऐसे ही न बनाएं।

माइक्रोसर्विस का उपयोग कब किया जाना चाहिए?

यह सब आपके निर्णय पर निर्भर करता है। यह सिर्फ उन चीजों में से एक है, जहां आप "मोनोलिथ के खिलाफ माइक्रोसॉर्क्स" को Google नहीं करेंगे। यदि आपको वास्तव में माइक्रोसर्विस की आवश्यकता है, तो आपको इसके बारे में पहले से ही पता होगा।

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

ध्यान रखें कि यदि आपके पास एक छोटी टीम है जो समय के साथ धीरे-धीरे बढ़ती है, तो आप एक या दो माइक्रोसर्विसेज के साथ शुरू कर सकते हैं। ऐसी स्थिति में, आपको शायद खदान से शुरू होकर, 100 माइक्रोसेरो में एक बार मोनोलिथ को नहीं तोड़ना चाहिए।

खेल मोमबत्ती के लायक है?

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

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

यह एक मुश्किल काम है, क्योंकि आदर्श रूप से हम चाहेंगे कि सभी माइक्रोसर्विसेज एक ही निगरानी सेवा का उपयोग करें।

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

उनका उत्पाद बड़े पैमाने पर अनुप्रयोगों पर केंद्रित है (यह समझ में क्यों आता है), लेकिन यह छोटी परियोजनाओं के लिए भी काम करता है। मैंने हाल ही में उनके बारे में सुना क्योंकि उन्हें क्लाउड फील्ड डे 4 पर प्रस्तुत किया गया था।

किसी भी मामले में, निगरानी केवल कई कठिनाइयों में से एक है, लेकिन मैंने इसका उल्लेख करने का फैसला किया क्योंकि यह सबसे दर्दनाक समस्याओं में से एक है।

अंतिम विचार

असल में, मैंने इस लेख को दो कारणों से लिखा है:

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

दूसरे , ऑनलाइन पाठ्यक्रमों के लेखक के रूप में, मुझे अपने स्वयं के एप्लिकेशन बनाने के तरीके के बारे में बहुत सारे प्रश्न मिलते हैं।

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

यह क्षण उन्हें आगे बढ़ने से रोकता है, और एक विकास सहयोगी के रूप में, मुझे पता है कि अनिर्णय में फंसना कितना कठिन है (मेरे पास था!)।

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

मैं इस परियोजना को पूरी तरह से अखंड अनुप्रयोग के रूप में सहेजने जा रहा हूं, जब तक कि यह माइक्रोसेवाओं को लागू करने के लिए समझ में नहीं आता है, लेकिन मेरी वृत्ति मुझे बताती है कि ऐसा क्षण कभी नहीं आएगा।

आप इस बारे में क्या सोचते हैं? मुझे टिप्पणियों में बताएं।