माइक्रोसर्विसेज

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

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


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

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

इतिहास
माइक्रोसर्विसेज शब्द की उत्पत्ति के संबंध में कई दावे हैं। 2004 में विचार काम करता है  के उपाध्यक्ष रहते हुए,  फ्रेड जॉर्ज  ने प्रोटोटाइप आर्किटेक्चर पर काम करना शुरू किया, जिसे उन्होंने जेफ बे के नाम पर बेसियन सिद्धांत कहा। 2005 की शुरुआत में, पीटर रॉजर्स ने वेब सेवा  एज सम्मेलन में एक प्रस्तुति के दौरान माइक्रो-वेब सेवा | वेब-सेवा शब्द की शुरुआत की। पारंपरिक सोच के खिलाफ और  SOAP  SOA आर्किटेक्चर प्रचार वक्र की ऊंचाई पर उन्होंने प्रतिनिधि राज्य हस्तांतरण-सेवाओं के लिए तर्क दिया और सम्मेलन प्रस्तुति की स्लाइड #4 पर, उन्होंने चर्चा की कि  सॉफ्टवेयर घटक  माइक्रो-वेब-सर्विसेज हैं। उन्होंने कहा कि माइक्रो-सर्विसेज  पाइपलाइन (यूनिक्स)  | यूनिक्स जैसी पाइपलाइनों ( डब्ल्यूडब्ल्यूडब्ल्यू  यूनिक्स = ट्रू लूज कपलिंग | लूज-कपलिंग से मिलती है) का उपयोग करके बनाई गई हैं। सेवाएं सेवाओं को कॉल कर सकती हैं (+ एकाधिक भाषा रन-टाइम)। कॉम्प्लेक्स सर्विस असेंबली सरल यूआरआई इंटरफेस के पीछे अमूर्त हैं। कोई भी सेवा, किसी भी ग्रैन्युलैरिटी पर, प्रदर्शित की जा सकती है। उन्होंने वर्णन किया कि कैसे एक अच्छी तरह से डिज़ाइन किया गया माइक्रोसर्विसेज प्लेटफ़ॉर्म WWW और REST सेवाओं के अंतर्निहित वास्तु सिद्धांतों को यूनिक्स जैसी शेड्यूलिंग और पाइपलाइनों के साथ लागू करता है ताकि सेवा-उन्मुख आर्किटेक्चर में कट्टरपंथी लचीलापन और बेहतर सादगी प्रदान की जा सके। रॉजर्स का काम 1999 में हेवलेट पैकर्ड लैब्स  में डेक्सटर रिसर्च प्रोजेक्ट के साथ शुरू हुआ, जिसका उद्देश्य कोड को कम भंगुर बनाना और बड़े पैमाने पर जटिल सॉफ्टवेयर सिस्टम रोबस्टनेस (कंप्यूटर साइंस) को बदलने के लिए बनाना था। अंतत: शोध के इस मार्ग ने  संसाधन-उन्मुख कंप्यूटिंग  (आरओसी) के विकास का मार्ग प्रशस्त किया, एक सामान्यीकृत संगणना अमूर्तता जिसमें REST एक विशेष उपसमुच्चय है।

2007 में, जुवल लोवी ने अपने लेखन में और बोल रहा हूँ उन प्रणालियों के निर्माण का आह्वान किया जिनमें प्रत्येक वर्ग एक सेवा थी। लोवी ने महसूस किया कि इसके लिए एक ऐसी तकनीक के उपयोग की आवश्यकता है जो सेवाओं के इस तरह के व्यापक उपयोग का समर्थन कर सके, और उन्होंने ऐसा करने के लिए  विंडोज संचार फाउंडेशन  | विंडोज कम्युनिकेशन फाउंडेशन (डब्ल्यूसीएफ) का विस्तार किया।  कक्षाओं के पारंपरिक प्रोग्रामिंग मॉडल को बनाए रखते हुए हर वर्ग को लेना और इसे एक सेवा के रूप में मानना।

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

मई 2011 में वेनिस के पास आयोजित सॉफ्टवेयर आर्किटेक्ट्स की एक कार्यशाला ने माइक्रोसर्विस शब्द का उपयोग यह वर्णन करने के लिए किया कि प्रतिभागियों ने एक सामान्य वास्तुशिल्प शैली के रूप में क्या देखा जो उनमें से कई हाल ही में खोज रहे थे। मई 2012 में, उसी समूह ने सबसे उपयुक्त नाम के रूप में माइक्रोसर्विसेज पर निर्णय लिया। जेम्स लुईस ने उन कुछ विचारों को मार्च 2012 में माइक्रोसर्विसेज - जावा, यूनिक्स वे में क्राको में 33वीं डिग्री में मामले का अध्ययन  के रूप में प्रस्तुत किया। जैसा कि फ्रेड जॉर्ज ने किया था उसी समय के बारे में।  एड्रियन कॉक्रॉफ्ट, नेटफ्लिक्स में क्लाउड सिस्टम्स के पूर्व निदेशक, इस दृष्टिकोण को सुक्ष्म SOA के रूप में वर्णित किया, वेब-स्केल पर शैली का नेतृत्व किया, जैसा कि इस लेख में उल्लिखित कई अन्य - जो वाल्नेस, डैन नॉर्थ, इवान बॉटचर और ग्राहम टैक्ले ने किया। माइक्रोसर्विसेज सेवा-उन्मुख आर्किटेक्चर (SOA) के लिए एक कार्यान्वयन दृष्टिकोण का एक विशेषज्ञता है जिसका उपयोग लचीला, स्वतंत्र रूप से तैनात करने योग्य वितरित सॉफ़्टवेयर बनाने के लिए किया जाता है। माइक्रोसर्विसेज दृष्टिकोण SOA का पहला अहसास है जिसने DevOps की शुरुआत का अनुसरण किया और निरंतर परिनियोजन प्रणाली के निर्माण के लिए अधिक लोकप्रिय हो रहा है। फरवरी 2020 में, क्लाउड माइक्रोसर्विसेज मार्केट रिसर्च रिपोर्ट ने भविष्यवाणी की थी कि वैश्विक माइक्रोसर्विस आर्किटेक्चर बाजार का आकार 2019 से 2026 तक 21.37% की चक्रवृद्धि वार्षिक वृद्धि दर  से बढ़ेगा और 2026 तक 3.1 बिलियन डॉलर तक पहुंच जाएगा।

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

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

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

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

रेफरी> 
 * मापनीयता: चूंकि माइक्रोसर्विसेज एक दूसरे से स्वतंत्र रूप से कार्यान्वित और तैनात किए जाते हैं, यानी वे स्वतंत्र प्रक्रियाओं के भीतर चलते हैं, उन्हें स्वतंत्र रूप से मॉनिटर और स्केल किया जा सकता है।

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

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

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

टेक्नोलॉजीज
कंप्यूटर माइक्रोसर्विसेज को विभिन्न प्रोग्रामिंग भाषाओं में लागू किया जा सकता है और विभिन्न इन्फ्रास्ट्रक्चर का उपयोग कर सकता है। इसलिए, सबसे महत्वपूर्ण प्रौद्योगिकी विकल्प हैं जिस तरह से माइक्रोसर्विसेज एक दूसरे के साथ संवाद करते हैं (सिंक्रोनस, एसिंक्रोनस, यूआई इंटीग्रेशन) और संचार के लिए उपयोग किए जाने वाले प्रोटोकॉल (RESTful HTTP, मैसेजिंग, ग्राफक्यूएल ाइन ...)। एक पारंपरिक प्रणाली में, प्रोग्रामिंग भाषा जैसे अधिकांश तकनीकी विकल्प पूरे सिस्टम को प्रभावित करते हैं। इसलिए, प्रौद्योगिकियों को चुनने का दृष्टिकोण काफी अलग है। ग्रहण फाउंडेशन ने माइक्रोसर्विसेज, एक्लिप्स माइक्रोप्रोफाइल के विकास के लिए एक विनिर्देश प्रकाशित किया है।

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

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

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

यह भी देखें

 * कॉनवे का नियम
 * क्रॉस-कटिंग चिंता
 * डेटा मेश, एक डोमेन-ओरिएंटेड डेटा आर्किटेक्चर
 * DevOps
 * वितरित कंप्यूटिंग की भ्रांतियां
 * ग्राफक्यूएल
 * जीआरपीसी
 * प्रतिनिधित्वात्मक राज्य स्थानांतरण (REST)
 * सेवा-उन्मुख वास्तुकला (SOA)
 * सॉफ्टवेयर आधुनिकीकरण
 * यूनिक्स दर्शन
 * स्व-निहित प्रणाली (सॉफ्टवेयर)
 * सर्वर रहित कंप्यूटिंग
 * वेब-उन्मुख वास्तुकला (WOA)

आगे की पढाई

 * Special theme issue on microservices, IEEE Software 35(3), May/June 2018, https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=8354413
 * I. Nadareishvili et al., Microservices Architecture – Aligning Principles, Practices and Culture, O'Reilly, 2016,  ISBN 978-1-491-95979-4
 * S. Newman, Building Microservices – Designing Fine-Grained Systems, O'Reilly, 2015 ISBN 978-1491950357
 * Wijesuriya, Viraj Brian (2016-08-29) Microservice Architecture, Lecture Notes - University of Colombo School of Computing, Sri Lanka
 * Christudas Binildas (June 27, 2019). Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud. Apress. ISBN 978-1484245002.