🧑🏿‍🤝‍🧑🏼 🧖🏽 🙌🏾 सॉफ्टवेयर आर्किटेक्चर के प्रकारों के बारे में संक्षेप में, और जो हमने IaaS प्रदाता के लिए चुना ☸️ 👞 👩🏼‍🎨

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

/ लाइब्रेशॉट / पीडी

सॉफ्टवेयर आर्किटेक्चर के प्रकार

स्तरित वास्तुकला

यह सबसे आम आर्किटेक्चर में से एक है। इसके आधार पर, कई बड़े ढांचे का निर्माण किया जाता है - जावा ईई, द्रुपाल, एक्सप्रेस। शायद इस वास्तुकला का सबसे प्रसिद्ध उदाहरण OSI नेटवर्क मॉडल है।

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

वास्तुकला में स्तरों की कोई अनिवार्य संख्या नहीं है - तीन, चार, पांच या अधिक हो सकते हैं। सबसे अधिक, तीन स्तरीय प्रणाली का उपयोग किया जाता है: एक प्रस्तुति स्तर (क्लाइंट), एक तर्क स्तर और एक डेटा स्तर के साथ।

बहुस्तरीय वास्तुकला के बारे में अनगिनत किताबें और लेख लिखे गए हैं। और इसके फायदे और नुकसान के बारे में अलग-अलग राय थी।

पेशेवरों:

इस वास्तुकला का प्रत्येक स्तर कार्य का एक सीमित सीमित प्रदर्शन करता है (जो परत से परत तक दोहराया नहीं जाता है) और यह नहीं जानता कि अन्य स्तरों की व्यवस्था कैसे की जाती है। इसलिए, परतों के बीच वैश्विक संघर्ष के जोखिम के बिना स्तरों की "सामग्री" को बदला जा सकता है।

सामान्य तौर पर, बहुस्तरीय अनुप्रयोग इतने व्यापक होते हैं कि उनके विकास के लिए विशेष टेम्पलेट जनरेटर बनाए जाते हैं। उदाहरण के लिए, Visual Studio के लिए LASG कई कोड जनरेशन विधियाँ प्रदान करता है जो नियमित कार्यों को स्वचालित करता है और एप्लिकेशन टियर बनाने में मदद करता है।

नुकसान:

प्रोग्रामिंग में, एक कहावत है कि किसी भी समस्या को दूसरे स्तर के अमूर्त जोड़कर हल किया जा सकता है। हालांकि, यह दृष्टिकोण अंततः कोड के खराब संगठन और डेवलपर्स को भ्रमित कर सकता है।

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

मल्टी-टियर सिस्टम पर बग ढूंढना भी मुश्किल हो सकता है । डेटाबेस में प्रवेश करने से पहले, जानकारी सभी स्तरों से गुजरती है (क्योंकि डेटाबेस अंतिम घटक है)। यदि किसी कारण से यह जानकारी क्षतिग्रस्त हो जाती है (या रास्ते में खो जाती है), तो एक त्रुटि खोजने के लिए, आपको प्रत्येक स्तर का अलग-अलग विश्लेषण करना होगा।

अच्छा फिट:

नए एप्लिकेशन बनाने के लिए जिन्हें जल्दी से तैनात करने की आवश्यकता है। यह एक तरह का "सामान्य उद्देश्य का टेम्पलेट" है।

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

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

संगठन की संरचना और अनुप्रयोग विकास दृष्टिकोणों के बीच एक समान संबंध कोनवे के नियम द्वारा भी निर्धारित किया गया है , जो 1967 में बनाया गया था। यह पढ़ता है: "जब एक प्रणाली विकसित कर रहे हैं, तो संगठनों को एक ऐसी योजना का पालन करने के लिए मजबूर किया जाता है जो कंपनी के भीतर संचार की संरचना को दोहराता है।"

इवेंट ओरिएंटेड आर्किटेक्चर

इस मामले में, डेवलपर किसी भी घटना के होने पर कार्यक्रम के लिए व्यवहार (प्रतिक्रियाओं) को निर्धारित करता है। सिस्टम में एक घटना को उसके राज्य में एक महत्वपूर्ण बदलाव माना जाता है।

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

ईवेंट-चालित प्रणाली में आम तौर पर दो घटक होते हैं: ईवेंट स्रोत (एजेंट) और उनके उपभोक्ता (सिंक)। आमतौर पर दो प्रकार के कार्यक्रम भी होते हैं: एक आरंभ करने वाली घटना और एक ऐसी घटना जिसका उपभोक्ता जवाब देते हैं।

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

इस तंत्र के लिए निम्नलिखित कार्यान्वयन कोड विकी पर प्रदान किया गया है:

public class FooPanel extends JPanel implements ActionListener { public FooPanel() { super(); JButton btn = new JButton("Click Me!"); btn.addActionListener(this); this.add(btn); } @Override public void actionPerformed(ActionEvent ae) { System.out.println("Button has been clicked!"); } }

वास्तुकला के लाभ:

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

नुकसान:

ऐसे अनुप्रयोगों की अतुल्यकालिक प्रकृति डीबगिंग को जटिल करती है। एक घटना एक ही बार में कई श्रृंखलाओं को ट्रिगर कर सकती है। यदि ऐसी बहुत सी श्रृंखलाएं हैं, तो यह समझना मुश्किल हो सकता है कि वास्तव में विफलता का कारण क्या था। समस्या को हल करने के लिए, हमें त्रुटि से निपटने के लिए कठिन परिस्थितियों को हल करना होगा। यहां से लॉगिंग समस्या के साथ समस्या है - लॉग संरचना के लिए कठिन हैं।

के लिए उपयुक्त:

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

माइक्रोकर्नल आर्किटेक्चर

इस प्रकार की वास्तुकला में दो घटक होते हैं: सिस्टम और प्लगइन्स का मूल। प्लगइन्स व्यावसायिक तर्क के लिए जिम्मेदार हैं, और कर्नेल उनके लोडिंग और अनलोडिंग का प्रबंधन करता है।

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

एक समय में माइक्रोकबर्न आर्किटेक्चर ने मोबाइल उपकरणों के लिए सिम्बियन ऑपरेटिंग सिस्टम का उपयोग किया था (2012 में विकास रोक दिया गया था)। उसके माइक्रोकर्नेल में एक कार्य अनुसूचक, स्मृति प्रबंधन प्रणाली और ड्राइवर थे, और फ़ाइल सिस्टम और टेलीफोन संचार के लिए जिम्मेदार घटक प्लग-इन के रूप में कार्य करते थे।

वास्तुकला के लाभ:

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

नुकसान:

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

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

इसके लिए अच्छा:

एक्स्टेंसिबल एप्लिकेशन बनाएं जो बड़ी संख्या में लोगों द्वारा उपयोग किए जाते हैं। उदाहरण के लिए, iPhone OS में "माइक्रोकर्नल" जड़ें होती हैं - इसके डेवलपर्स ने Mach से प्रेरणा ली (यह एक माइक्रोकर्ल के पहले उदाहरणों में से एक है)।
बुनियादी विधियों और उच्च-स्तरीय नियमों के स्पष्ट पृथक्करण के साथ अनुप्रयोगों का निर्माण।
नियमों के एक गतिशील रूप से बदलते सेट के साथ सिस्टम का विकास जिसे अक्सर अद्यतन करना पड़ता है।

Mikroservisy

घटना-संचालित वास्तुकला और माइक्रोकर्नेल के समान। लेकिन उनका उपयोग तब किया जाता है जब व्यक्तिगत अनुप्रयोग कार्यों को आसानी से छोटे कार्यों - स्वतंत्र सेवाओं में विभाजित किया जा सकता है। इन सेवाओं को विभिन्न प्रोग्रामिंग भाषाओं में लिखा जा सकता है क्योंकि वे REST API (उदाहरण के लिए, JSON या थ्रिफ्ट का उपयोग करके) एक दूसरे के साथ संवाद करते हैं।

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

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

लाभ:

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

मार्टिन एल। एबॉट, द आर्ट ऑफ़ स्केलेबिलिटी द्वारा पुस्तक में माइक्रोसॉर्स्ट सिस्टम के स्केलिंग तंत्र के बारे में अधिक पढ़ें।

नुकसान:

त्रुटियों की तलाश करना कठिन है। अखंड प्रणालियों के विपरीत (जब सभी कार्य एक ही कर्नेल में होते हैं), यह निर्धारित करना मुश्किल हो सकता है कि अनुरोध "गिर गया" क्यों है। विवरण के लिए, आपको "दोषी" प्रक्रिया के लॉग पर जाना होगा (यदि कई हैं, तो समस्या बढ़ जाती है)।

यह माइक्रोसर्विसेज के बीच संदेशों के प्रसारण के लिए अतिरिक्त ओवरहेड बनाता है। हमारे अनुमानों के अनुसार, नेटवर्क लागत की वृद्धि 25% तक पहुंच सकती है।

एक और दोष यह है कि अंततः सुसंगतता ( लंबे समय में सुसंगतता ) की अवधारणा के साथ रखा जाना चाहिए । माइक्रोसर्विसेस के पास अपने स्वयं के डेटा वेयरहाउस होते हैं, जो अन्य माइक्रोसिस्टर्स द्वारा एक्सेस किए जाते हैं। इस डेटा में बदलाव की जानकारी सिस्टम के माध्यम से तुरंत वितरित नहीं की जाती है। इसलिए, ऐसी स्थितियाँ उत्पन्न होती हैं जब कुछ माइक्रोसर्विस (अत्यंत कम समय के लिए) के पास पुराना डेटा होता है।

उपयोग कहाँ करें:

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

हम 1cloud में माइक्रोसर्विसेज पर क्यों स्विच कर रहे हैं

जैसा कि हमने पहले ही कहा था, हमारे द्वारा प्रदान की जाने वाली सेवाओं का आधार ( निजी क्लाउड , वर्चुअल सर्वर , ऑब्जेक्ट क्लाउड स्टोरेज , आदि) एक बहु-स्तरीय वास्तुकला पर आधारित है। उसने खुद को अच्छे पक्ष में दिखाया, लेकिन अब उसकी पैमाने पर क्षमता खत्म होने लगी।

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

मौजूदा फ़ंक्शंस को स्केल करना और नई सुविधाओं को पेश करना आसान बनाने के लिए, हम 1cloud में अपने पूरे बुनियादी ढांचे को माइक्रो-सर्विसेज में स्थानांतरित करते हैं ।

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

हम कई डेवलपर्स के बीच सेवाओं पर काम को विभाजित करने में सक्षम होंगे (कंपनी में विशेषज्ञता को हाइलाइट करें) और पैमाने को प्रभावी ढंग से क्षैतिज रूप से - जब आवश्यक हो, हम सिर्फ नए माइक्रोसेवा कनेक्ट करते हैं।

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

कजाखस्तान और बेलारूस (और अन्य देश जहां हम प्रतिनिधि कार्यालय खोलेंगे) के ग्राहक इंटरफेस की गति और जवाबदेही में उल्लेखनीय वृद्धि देखेंगे, क्योंकि नियंत्रण कक्ष स्थानीय स्तर पर स्थित होंगे।

जो पहले ही किया जा चुका है

अब तक हमने केवल पहला पायलट लागू किया है: "निगरानी सेवा"। शेष सेवाओं को 2018 के अंत में एक नए ट्रैक पर स्थानांतरित किया जाएगा - 2019 की शुरुआत।

इसी समय, नया आर्किटेक्चर अगले चरण के लिए तकनीकी नींव देता है - कंटेनरों में प्रवास। अब हम विंडोज इन्फ्रास्ट्रक्चर का उपयोग करते हैं, और कंटेनरों में जाने के लिए, हमें .NetCore पर सभी संचित कोड को फिर से लिखना होगा और इसे लिनक्स में स्थानांतरित करना होगा।

हमने 2019 की शुरुआत में एक नया संक्रमण शुरू करने और अगले साल के अंत में इसे समाप्त करने की योजना बनाई है।

वास्तुकला के बारे में याद रखने योग्य बात के बारे में सरल शब्दों में

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

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

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

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

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

सॉफ्टवेयर आर्किटेक्चर के प्रकारों के बारे में संक्षेप में, और जो हमने IaaS प्रदाता के लिए चुना