आधुनिक पूर्वाधार: समस्या र सम्भावनाहरू

मेको अन्त्यमा हामी यस विषयमा अनलाइन बैठक गरे "आधुनिक पूर्वाधार र कन्टेनरहरू: समस्या र सम्भावनाहरू"। हामीले कन्टेनरहरू, कुबेरनेटहरू र सिद्धान्तमा अर्केस्ट्रेसनको बारेमा कुरा गर्यौं, पूर्वाधार छनौट गर्ने मापदण्ड र अधिक। सहभागीहरूले आफ्नै अभ्यासबाट केसहरू साझा गरे।

सहभागीहरु:

• Evgeniy Potapov, ITSumma को सीईओ। यसका आधाभन्दा बढी ग्राहकहरू या त पहिले नै सर्दै छन् वा कुबर्नेट्समा स्विच गर्न चाहन्छन्।
• दिमित्री Stolyarov, CTO "Flant"। कन्टेनर प्रणालीहरूसँग काम गर्ने 10+ वर्षको अनुभव छ।
• डेनिस रेमचुकोभ (उर्फ एरिक ओल्डम्यान), सीओओ argotech.io, भूतपूर्व RAO UES। उनले "रगती" उद्यममा केसहरूको बारेमा कुरा गर्ने वाचा गरे।
• Andrey Fedorovsky, CTO "News360.com"अर्को खेलाडीद्वारा कम्पनी खरिद गरेपछि, उहाँ धेरै ML र AI परियोजनाहरू र पूर्वाधारहरूको लागि जिम्मेवार हुनुहुन्छ।
• इभान क्रुग्लोभ, सिस्टम इन्जिनियर, ex-Booking.com।उही व्यक्ति जसले आफ्नै हातले Kubernetes संग धेरै गर्यो।

विषयहरु:

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

एक रोचक छलफल भयो, सहभागीहरूको विचार धेरै फरक थियो र यति धेरै टिप्पणीहरू उत्पन्न भयो कि म तपाईसँग साझा गर्न चाहन्छु। खानुहोस् तीन घण्टाको भिडियो, र तल छलफलको सारांश हो।

के Kubernetes पहिले नै मानक वा उत्कृष्ट मार्केटिङ हो?

"हामी यसमा आएका हौं (कुबर्नेट्स। - एड।) जब कसैलाई यसको बारेमा थाहा थिएन। उहाँ नहुँदा पनि हामी उहाँकहाँ आएका थियौं । हामीले यो पहिले नै चाहेका थियौं "- दिमित्री Stolyarov

Reddit.com बाट फोटो

5-10 वर्ष पहिले त्यहाँ उपकरणहरूको ठूलो संख्या थियो, र त्यहाँ कुनै एक मानक थिएन। प्रत्येक छ महिनामा नयाँ उत्पादन देखा पर्यो, वा एक भन्दा बढी। पहिले भ्याग्रन्ट, त्यसपछि साल्ट, शेफ, कठपुतली,... "र तपाइँ प्रत्येक छ महिनामा आफ्नो पूर्वाधार पुनर्निर्माण गर्नुहुन्छ। तपाईंसँग पाँच प्रशासकहरू छन् जो कन्फिगहरू पुन: लेख्न निरन्तर व्यस्त छन्, "आन्द्रे फेडोरोव्स्की सम्झन्छिन्। उनी विश्वास गर्छन् कि डकर र कुबर्नेट्सले बाँकीलाई "भीड आउट" गरेका छन्। डकर पछिल्लो पाँच वर्षमा मानक बनेको छ, पछिल्लो दुई वर्षमा Kubernetes। र यो उद्योग को लागी राम्रो छ.

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

Kubernetes कन्टेनर अर्केस्ट्रेसन मात्र होइन, यो एक विकसित एपीआई, नेटवर्किङ कम्पोनेन्ट, L3 ब्यालेन्सिङ र इन्ग्रेस कन्ट्रोलरहरू भएको कन्फिगरेसन व्यवस्थापन प्रणाली हो, जसले पूर्वाधारको तल्लो तहबाट स्रोतहरू, स्केल र सारहरू व्यवस्थापन गर्न अपेक्षाकृत सजिलो बनाउँछ।

दुर्भाग्यवश, हाम्रो जीवनमा हामीले सबै कुराको लागि तिर्नुपर्छ। र यो कर ठूलो छ, विशेष गरी यदि हामी इभान क्रुग्लोभले विश्वास गरे जस्तै विकसित पूर्वाधार भएको कम्पनीको कुबेरनेटमा संक्रमणको बारेमा कुरा गर्छौं। उसले परम्परागत पूर्वाधार भएको कम्पनी र कुबेर दुवैमा स्वतन्त्र रूपमा काम गर्न सक्छ। मुख्य कुरा कम्पनी र बजार को विशेषताहरु बुझ्न छ। तर, उदाहरणका लागि, Evgeny Potapov को लागि, जसले Kubernetes लाई कुनै पनि कन्टेनर अर्केस्ट्रेशन उपकरणमा सामान्यीकरण गर्नेछ, यस्तो प्रश्न उठ्दैन।

Evgeniy ले 1990s मा परिस्थिति संग एक समानता बनाए, जब वस्तु-उन्मुख प्रोग्रामिंग प्रोग्रामिंग जटिल अनुप्रयोग को एक तरिका को रूप मा देखा पर्यो। त्यस समयमा, बहस जारी रह्यो र OOP लाई समर्थन गर्न नयाँ उपकरणहरू देखा पर्यो। त्यसपछि सूक्ष्म सेवाहरू मोनोलिथिक अवधारणाबाट टाढा जानको लागि एक तरिकाको रूपमा देखा पर्यो। यसले, बारीमा, कन्टेनर र कन्टेनर व्यवस्थापन उपकरणहरूको उदयको नेतृत्व गर्‍यो। "मलाई लाग्छ कि हामी छिट्टै एउटा यस्तो समय आउनेछौं जब त्यहाँ सानो माइक्रोसर्भिस अनुप्रयोग लेख्न लायक छ कि छैन भन्ने बारे कुनै प्रश्न हुनेछैन, यसलाई पूर्वनिर्धारित रूपमा माइक्रोसर्भिसको रूपमा लेखिनेछ," उनी विश्वास गर्छन्। त्यस्तै गरी, डकर र कुबर्नेट्स अन्ततः छनौटको आवश्यकता बिना मानक समाधान बन्नेछ।

राज्यविहीन डाटाबेसको समस्या

फोटो द्वारा ट्विटर: @jankolario अनस्प्लासमा

आजकल, Kubernetes मा डाटाबेस चलाउन को लागी धेरै व्यञ्जनहरु छन्। सशर्त रूपमा, डाटाबेसको अनुप्रयोग भागबाट I/O डिस्कसँग काम गर्ने भागलाई कसरी अलग गर्ने। के यो सम्भव छ कि भविष्यमा डाटाबेसहरू यति धेरै परिवर्तन हुनेछ कि तिनीहरू बक्समा डेलिभर हुनेछन्, जहाँ एक भाग डकर र कुबर्नेट्स मार्फत अर्केस्ट्रेटेड हुनेछ, र पूर्वाधारको अर्को भागमा, अलग सफ्टवेयर मार्फत, भण्डारण भाग प्रदान गरिनेछ। ? के आधारहरू उत्पादनको रूपमा परिवर्तन हुनेछ?

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

दिमित्री मौलिक रूपमा असहमत छन् - कोरम र शार्डिंगले समस्या समाधान गर्दछ। तर एन्ड्रीले समाधान सबैको लागि उपयुक्त छैन भनेर जोड दिए। केही अवस्थामा, कोरम उपयुक्त छ, तर यसले नेटवर्कमा थप भार राख्छ। एक NoSQL डाटाबेस सबै अवस्थामा उपयुक्त छैन।

बैठकमा सहभागीहरूलाई दुईवटा क्याम्पमा विभाजन गरिएको थियो।

डेनिस र एन्ड्री तर्क गर्छन् कि डिस्कमा लेखिएका सबै कुरा - डाटाबेसहरू र यस्तै अन्य - वर्तमान कुबेर इकोसिस्टममा गर्न असम्भव छ। Kubernetes मा उत्पादन डाटाको अखण्डता र स्थिरता कायम राख्न असम्भव छ। यो एक मौलिक विशेषता हो। समाधान: हाइब्रिड पूर्वाधार।

आधुनिक क्लाउड नेटिभ डाटाबेसहरू जस्तै MongoDB र Cassandra, वा Kafka वा RabbitMQ जस्ता सन्देश लामहरू, Kubernetes बाहिर निरन्तर डाटा स्टोरहरू चाहिन्छ।

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

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

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

केस 1. कुबेर बाहिर आधारहरू भएको "मेगा-नियामक" को साइबर सुरक्षा

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

केस 2. Kubernetes मा Booking.com डाटाबेसको आंशिक माइग्रेसन

Booking.com मा, मुख्य डाटाबेस एसिंक्रोनस प्रतिकृतिको साथ MySQL हो - त्यहाँ एक मास्टर र दासहरूको सम्पूर्ण पदानुक्रम छ। इभानले कम्पनी छोड्दा, दासहरूलाई स्थानान्तरण गर्न एउटा परियोजना सुरु गरिएको थियो जुन निश्चित क्षतिको साथ "शट" हुन सक्छ।

मुख्य आधारको अतिरिक्त, त्यहाँ स्व-लिखित अर्केस्ट्रेशनको साथ क्यासान्ड्रा स्थापना छ, जुन कुबेर मूलधारमा प्रवेश गर्नु अघि नै लेखिएको थियो। यस सन्दर्भमा कुनै समस्याहरू छैनन्, तर यो स्थानीय SSD मा निरन्तर छ। रिमोट भण्डारण, एउटै डाटा केन्द्र भित्र पनि, उच्च विलम्बताको समस्याको कारण प्रयोग गरिएको छैन।

डाटाबेसको तेस्रो वर्ग Booking.com खोज सेवा हो, जहाँ प्रत्येक सेवा नोड डाटाबेस हो। खोज सेवा कुबेरमा स्थानान्तरण गर्ने प्रयास असफल भयो, किनभने प्रत्येक नोड 60-80 GB को स्थानीय भण्डारण छ, जसलाई "लिफ्ट" र "वार्म अप" गर्न गाह्रो छ।

नतिजाको रूपमा, खोज इन्जिन Kubernetes मा हस्तान्तरण गरिएको थिएन, र इभान निकट भविष्यमा नयाँ प्रयास हुनेछ भन्ने लाग्दैन। MySQL डाटाबेस आधामा स्थानान्तरण गरिएको थियो: केवल दासहरू, जो "शट" हुन डराउँदैनन्। क्यासान्ड्रा पूर्ण रूपमा बसेको छ।

पूर्वाधार चयन सामान्य समाधान बिना कार्यको रूपमा

फोटो द्वारा Pexels बाट Manuel Geissinger

मानौं हामीसँग नयाँ कम्पनी छ, वा एउटा कम्पनी जहाँ पूर्वाधारको अंश पुरानो तरिकाले निर्माण गरिएको छ। यसले वर्षौंको लागि पूर्वाधार विकास योजना बनाउँछ। कन्टेनर र कुबेरमा पूर्वाधार निर्माण गर्ने कि नगर्ने निर्णय कसरी हुन्छ ?

नानोसेकेन्डका लागि लड्ने कम्पनीहरू छलफलबाट बाहिर छन्। स्वस्थ रूढ़िवादले विश्वसनीयताको सर्तमा भुक्तान गर्दछ, तर त्यहाँ अझै पनि कम्पनीहरू छन् जसले नयाँ दृष्टिकोणहरू विचार गर्नुपर्छ।

इभान: "म पक्कै पनि अब क्लाउडमा कम्पनी सुरु गर्नेछु, किनभने यो छिटो छ," यद्यपि सस्तो छैन। उद्यम पुँजीवादको विकासको साथ, स्टार्टअपहरूसँग पैसाको साथ कुनै ठूलो समस्या छैन, र मुख्य कार्य बजारलाई जित्नु हो।

इभानको धारणा छ वर्तमान पूर्वाधारको विकास चयन मापदण्ड हो। यदि विगतमा गम्भीर लगानी थियो, र यसले काम गर्छ भने, त्यसलाई पुन: गर्नुको कुनै अर्थ छैन। यदि पूर्वाधारको विकास हुन सकेको छैन र उपकरण, सुरक्षा र अनुगमनमा समस्या छ भने, वितरण गरिएको पूर्वाधार हेर्नु उचित हुन्छ।

कर कुनै पनि अवस्थामा तिर्नुपर्नेछ, र इभानले भविष्यमा कम तिर्ने अनुमति दिनेछ। "किनभने अरूले चलिरहेको रेलमा म सवार छु भन्ने तथ्यको आधारमा, म अर्को रेलमा बस्दा भन्दा धेरै टाढाको यात्रा गर्नेछु, जसमा मैले आफैं इन्धन हाल्नु पर्छ।"इवान भन्छन्। जब कम्पनी नयाँ छ, र विलम्बता आवश्यकताहरू दशौं मिलिसेकेन्डहरू छन्, तब इभानले "अपरेटरहरू" तर्फ हेर्नेछन् जसमा आज शास्त्रीय डाटाबेसहरू "रेप" छन्। तिनीहरूले प्रतिकृति चेन खडा गर्छन्, जसले फेलओभर, इत्यादिको अवस्थामा आफैलाई स्विच गर्दछ।

दुईवटा सर्भर भएको सानो कम्पनीको लागि कुबेरले कुनै अर्थ राख्दैन,” एन्ड्री भन्छन्। तर यदि यसले सयौं सर्भरहरू वा बढीमा बढ्ने योजना बनाउँछ भने, यसलाई स्वचालन र स्रोत व्यवस्थापन प्रणाली चाहिन्छ। 90% केसहरू लागत लायक छन्। यसबाहेक, लोड र स्रोतहरूको स्तरको पर्वाह नगरी। यसले स्टार्टअपदेखि ठूला कम्पनीहरूसम्म लाखौं दर्शकहरूको साथमा, कन्टेनर अर्केस्ट्रेशन उत्पादनहरू तिर बिस्तारै हेर्नु अर्थपूर्ण हुन्छ। "हो, यो साँच्चै भविष्य हो," एन्ड्री निश्चित छ।

डेनिसले दुई मुख्य मापदण्डहरू उल्लेख गरे - स्केलेबिलिटी र सञ्चालन को स्थिरता। उसले कार्यको लागि सबैभन्दा उपयुक्त उपकरणहरू चयन गर्नेछ। "यो तपाईंको घुँडामा जम्मा भएको नाम हुन सक्छ, र यसमा Nutanix सामुदायिक संस्करण छ। यो ब्याकइन्डमा डाटाबेसको साथ कुबेरमा एप्लिकेसनको रूपमा दोस्रो लाइन हुन सक्छ, जुन नक्कल गरिएको छ र RTO र RPO प्यारामिटरहरू निर्दिष्ट गरिएको छ" (रिकभरी समय/बिन्दु उद्देश्यहरू - लगभग।).

Evgeniy कर्मचारी संग सम्भावित समस्या पहिचान। यस समयमा, बजारमा "हिम्मत" बुझ्ने धेरै उच्च योग्य विशेषज्ञहरू छैनन्। वास्तवमा, यदि छनोट गरिएको टेक्नोलोजी पुरानो छ भने, जीवनबाट थकित र थकित मध्यम-उमेरका मानिसहरू बाहेक अरू कसैलाई काममा राख्न गाह्रो छ। यद्यपि अन्य सहभागीहरूले विश्वास गर्छन् कि यो कर्मचारी प्रशिक्षणको कुरा हो।
यदि हामीले छनोटको प्रश्न राख्यौं: सार्वजनिक क्लाउडमा अमेजन RDS मा डाटाबेस वा "अन प्रिमिस" मा डाटाबेसको साथ एउटा सानो कम्पनी सुरू गर्न, त्यसपछि केही कमजोरीहरूको बावजुद, Amazon RDS सहभागीहरूको छनौट भयो।

धेरै जसो भेटघाट श्रोताहरू "रगती" उद्यमबाट होइनन् वितरित समाधानहरू हामीले प्रयास गर्नुपर्छ। डाटा भण्डारण प्रणालीहरू वितरित, भरपर्दो, र मिलिसेकेन्डको एकाइहरूमा मापन गरिएको विलम्बता सिर्जना गर्नुपर्दछ, धेरैमा दसौं।", एन्ड्रीले संक्षेप गरे।

Kubernetes उपयोग मूल्याङ्कन

श्रोता एन्टोन ज्बान्कोभले कुबर्नेट्स माफीविद्हरूलाई जाल प्रश्न सोधे: तपाईंले कसरी सम्भाव्यता अध्ययन छान्नुभयो र सञ्चालन गर्नुभयो? कुबर्नेट्स किन, उदाहरणका लागि भर्चुअल मेसिनहरू किन होइन?

फोटो द्वारा Unsplash मा Tatyana Eremina

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

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

त्यस्ता विश्लेषण र गणनाका लागि मापदण्डहरू छन्, तर तिनीहरू सञ्चालनमा रहेको वास्तविक हार्डवेयरमा कति सही छन् भनेर कसैले भन्न सक्दैन। गणनाको लागि, प्रत्येक उपकरण र इकोसिस्टम बुझ्न पनि महत्त्वपूर्ण छ, तर यो सम्भव छैन।

हामीलाई के पर्खिरहेको छ

फोटो द्वारा Unsplash मा Drew Beamer

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

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

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

डेनिसले vRealize Suite उत्पादनको साथ Nutanix र VMWare लाई पनि उल्लेख गरे, जसले कन्टेनराइजेसन बिना समान कार्यको सामना गर्न सक्छ।

दिमित्रीले आफ्नो विचार साझा गर्नुभयो कि "पीडा" कम गर्नु र करहरू घटाउनु दुईवटा क्षेत्रहरू हुन् जहाँ हामी सुधारको आशा गर्न सक्छौं।

छलफल संक्षेपमा, हामी आधुनिक पूर्वाधारका निम्न समस्याहरूलाई हाइलाइट गर्छौं:

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

  बाँकी निष्कर्ष तपाईं मा निर्भर छ। त्यहाँ अझै पनि एक भावना छ कि डकर + कुबर्नेट्स संयोजन प्रणालीको "केन्द्रीय" भाग बन्न सजिलो छैन। उदाहरणका लागि, अपरेटिङ सिस्टमहरू पहिले हार्डवेयरमा स्थापित हुन्छन्, जसलाई कन्टेनर र अर्केस्ट्रेसनको बारेमा भन्न सकिँदैन। सायद भविष्यमा, अपरेटिङ सिस्टम र कन्टेनरहरू क्लाउड व्यवस्थापन सफ्टवेयरसँग मर्ज हुनेछन्।

  
  फोटो द्वारा गेब्रियल सान्तोस फोटोग्राफिया Pexels बाट

  म मेरो आमालाई नमस्कार भन्न यो अवसर लिन चाहन्छु र हामीसँग फेसबुक समूह छ भनेर सम्झाउन चाहन्छु "ठूला आईटी परियोजनाहरूको व्यवस्थापन र विकास", च्यानल @feedmeto विभिन्न प्राविधिक ब्लगहरूबाट रोचक प्रकाशनहरूको साथ। र मेरो च्यानल @rybakalexey, जहाँ म उत्पादन कम्पनीहरूमा विकास व्यवस्थापनको बारेमा कुरा गर्छु।

स्रोत: www.habr.com