आधुनिक पायाभूत सुविधा: समस्या आणि संभावना

मे शेवटी आम्ही आहोत या विषयावर ऑनलाइन बैठक घेतली "आधुनिक पायाभूत सुविधा आणि कंटेनर: समस्या आणि संभावना". आम्ही कंटेनर, कुबर्नेट्स आणि ऑर्केस्ट्रेशन तत्त्वतः, पायाभूत सुविधा निवडण्याचे निकष आणि बरेच काही याबद्दल बोललो. सहभागींनी त्यांच्या स्वतःच्या सरावातून प्रकरणे सामायिक केली.

सहभागी:

• इव्हगेनी पोटापोव्ह, ITSumma चे CEO. त्याचे अर्ध्याहून अधिक ग्राहक एकतर आधीच स्थलांतरित झाले आहेत किंवा कुबर्नेट्सवर स्विच करू इच्छित आहेत.
• दिमित्री स्टोल्यारोव्ह, सीटीओ "फ्लांट". कंटेनर सिस्टमसह काम करण्याचा 10+ वर्षांचा अनुभव आहे.
• डेनिस रेमचुकोव्ह (उर्फ एरिक ओल्डमन), सीओओ argotech.io, माजी RAO UES. त्याने “रक्तरंजित” एंटरप्राइझमधील प्रकरणांबद्दल बोलण्याचे वचन दिले.
• आंद्रे फेडोरोव्स्की, CTO “News360.com”दुसर्‍या खेळाडूने कंपनी खरेदी केल्यानंतर, तो अनेक ML आणि AI प्रकल्प आणि पायाभूत सुविधांसाठी जबाबदार आहे.
• इव्हान क्रुग्लोव्ह, सिस्टम इंजिनियर, माजी बुकिंग डॉट कॉम.तीच व्यक्ती ज्याने स्वतःच्या हातांनी कुबर्नेट्ससह बरेच काही केले.

थीम:

• कंटेनर आणि ऑर्केस्ट्रेशन (डॉकर, कुबर्नेट्स इ.) बद्दल सहभागींचे अंतर्दृष्टी; सराव किंवा विश्लेषणात काय प्रयत्न केले गेले.
• प्रकरण: कंपनी अनेक वर्षांपासून पायाभूत सुविधा विकास योजना तयार करत आहे. कंटेनर आणि कुबेर यांच्यासाठी पायाभूत सुविधा तयार करायच्या (किंवा सध्याचे स्थलांतरित) करायचे की नाही हा निर्णय कसा घेतला जातो?
• क्लाउड-नेटिव्ह जगात समस्या, काय गहाळ आहे, उद्या काय होईल याची कल्पना करूया.

एक मनोरंजक चर्चा झाली, सहभागींची मते इतकी भिन्न होती आणि त्यामुळे अनेक टिप्पण्या झाल्या की मला त्या तुमच्यासोबत सामायिक करायच्या आहेत. खा तीन तासांचा व्हिडिओ, आणि खाली चर्चेचा सारांश आहे.

Kubernetes आधीच एक मानक किंवा उत्तम विपणन आहे?

“आम्ही त्याच्याकडे आलो (कुबर्नेट्स. - एड.) जेव्हा कोणालाही याबद्दल माहिती नव्हती. तो नसतानाही आम्ही त्याच्याकडे आलो. आम्हाला ते आधी हवे होते" - दिमित्री स्टोल्यारोव्ह

Reddit.com वरून फोटो

5-10 वर्षांपूर्वी तेथे मोठ्या संख्येने साधने होती आणि कोणतेही एक मानक नव्हते. दर सहा महिन्यांनी एक नवीन उत्पादन दिसले, किंवा एकापेक्षा जास्त. प्रथम व्हॅग्रंट, नंतर सॉल्ट, शेफ, पपेट,... “आणि तुम्ही दर सहा महिन्यांनी तुमची पायाभूत सुविधा पुन्हा तयार करता. तुमच्याकडे पाच प्रशासक आहेत जे कॉन्फिगचे पुनर्लेखन करण्यात सतत व्यस्त असतात,” आंद्रे फेडोरोव्स्की आठवते. त्याचा असा विश्वास आहे की डॉकर आणि कुबर्नेट्सने उर्वरित "गर्दी" केली आहे. डॉकर गेल्या पाच वर्षांत, कुबर्नेट्स गेल्या दोन वर्षांत एक मानक बनले आहे. आणि ते उद्योगासाठी चांगले आहे..

दिमित्री स्टोल्यारोव्ह आणि त्याची टीम कुबेरवर प्रेम करते. ते दिसण्यापूर्वी त्यांना असे साधन हवे होते आणि कोणालाही त्याबद्दल माहिती नसताना ते आले. सध्या, सोयीच्या कारणास्तव, ते एखाद्या क्लायंटला समजत नाहीत की ते त्याच्यासोबत कुबर्नेट्सची अंमलबजावणी करणार नाहीत. त्याच वेळी, दिमित्रीच्या म्हणण्यानुसार, कंपनीकडे "भयंकर वारसा पुन्हा तयार करण्याबद्दल अनेक अवाढव्य यशोगाथा आहेत."

Kubernetes हे केवळ कंटेनर ऑर्केस्ट्रेशन नाही, तर ती विकसित API, नेटवर्किंग घटक, L3 बॅलन्सिंग आणि इंग्रेस कंट्रोलर्स असलेली कॉन्फिगरेशन व्यवस्थापन प्रणाली आहे, ज्यामुळे पायाभूत सुविधांच्या खालच्या स्तरांवरून संसाधने, स्केल आणि अमूर्त व्यवस्थापित करणे तुलनेने सोपे होते.

दुर्दैवाने, आपल्या आयुष्यात आपल्याला प्रत्येक गोष्टीची किंमत मोजावी लागते. आणि हा कर मोठा आहे, विशेषत: जर आपण विकसित पायाभूत सुविधा असलेल्या कंपनीच्या कुबर्नेट्समध्ये संक्रमणाबद्दल बोललो तर, इव्हान क्रुग्लोव्हच्या मते. पारंपारिक पायाभूत सुविधा असलेल्या कंपनीत आणि कुबेर यांच्यासोबतही तो मुक्तपणे काम करू शकत होता. मुख्य गोष्ट म्हणजे कंपनी आणि बाजाराची वैशिष्ट्ये समजून घेणे. परंतु, उदाहरणार्थ, एव्हगेनी पोटापोव्हसाठी, जो कुबर्नेट्सला कोणत्याही कंटेनर ऑर्केस्ट्रेशन साधनासाठी सामान्यीकृत करेल, असा प्रश्न उद्भवत नाही.

इव्हगेनीने 1990 च्या दशकातील परिस्थितीशी साधर्म्य साधले, जेव्हा ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग प्रोग्रामिंग कॉम्प्लेक्स ऍप्लिकेशन्सचा एक मार्ग म्हणून प्रकट झाला. त्या वेळी, वादविवाद चालूच राहिला आणि OOP चे समर्थन करण्यासाठी नवीन साधने दिसू लागली. मग अखंड संकल्पनेपासून दूर जाण्याचा मार्ग म्हणून मायक्रोसर्व्हिसेसचा उदय झाला. यामुळे, कंटेनर आणि कंटेनर व्यवस्थापन साधने उदयास आली. "मला वाटते की आम्ही लवकरच अशी वेळ येऊ शकतो जेव्हा लहान मायक्रोसर्व्हिस ऍप्लिकेशन लिहिणे योग्य आहे की नाही असा प्रश्नच उद्भवणार नाही, ते डीफॉल्टनुसार मायक्रोसर्व्हिस म्हणून लिहिले जाईल," तो विश्वास करतो. त्याचप्रमाणे, डॉकर आणि कुबर्नेट्स अखेरीस निवडीची आवश्यकता न घेता मानक समाधान बनतील.

स्टेटलेसमधील डेटाबेसची समस्या

द्वारे फोटो Twitter: @jankolario अनस्प्लॅश वर

आजकाल, Kubernetes मध्ये डेटाबेस चालविण्यासाठी अनेक पाककृती आहेत. डेटाबेसच्या ऍप्लिकेशन भागापासून सशर्त, I/O डिस्कसह कार्य करणारा भाग कसा वेगळा करायचा. हे शक्य आहे की भविष्यात डेटाबेस इतके बदलतील की ते एका बॉक्समध्ये वितरित केले जातील, जिथे एक भाग डॉकर आणि कुबर्नेट्सच्या माध्यमातून मांडला जाईल आणि पायाभूत सुविधांच्या दुसर्या भागात, वेगळ्या सॉफ्टवेअरद्वारे, स्टोरेज भाग प्रदान केला जाईल. ? उत्पादन म्हणून बेस बदलतील का?

हे वर्णन रांग व्यवस्थापनासारखेच आहे, परंतु पारंपारिक डेटाबेसमधील माहितीची विश्वासार्हता आणि सिंक्रोनाइझेशनची आवश्यकता जास्त आहे, आंद्रेचा विश्वास आहे. सामान्य डेटाबेसमध्ये कॅशे हिटचे प्रमाण 99% वर राहते. कामगार खाली गेल्यास, एक नवीन लॉन्च केला जातो आणि कॅशे सुरवातीपासून "वॉर्म अप" होतो. कॅशे गरम होईपर्यंत, कार्यकर्ता हळूहळू कार्य करतो, याचा अर्थ वापरकर्त्याच्या लोडसह ते लोड केले जाऊ शकत नाही. वापरकर्ता लोड नसताना, कॅशे गरम होत नाही. हे एक दुष्ट वर्तुळ आहे.

दिमित्री मूलभूतपणे असहमत - कोरम आणि शार्डिंग समस्येचे निराकरण करतात. परंतु आंद्रे आग्रह करतात की उपाय प्रत्येकासाठी योग्य नाही. काही परिस्थितींमध्ये, कोरम योग्य आहे, परंतु ते नेटवर्कवर अतिरिक्त भार टाकते. NoSQL डेटाबेस सर्व प्रकरणांमध्ये योग्य नाही.

संमेलनातील सहभागी दोन शिबिरांमध्ये विभागले गेले.

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

अगदी आधुनिक क्लाउड नेटिव्ह डेटाबेस जसे की MongoDB आणि Cassandra, किंवा Kafka किंवा RabbitMQ सारख्या मेसेज रांगांना, Kubernetes च्या बाहेर सतत डेटा स्टोअरची आवश्यकता असते.

इव्हगेनीचे म्हणणे आहे: "कुबेरातील तळ जवळच्या-रशियन किंवा जवळच्या-एंटरप्राइझ इजा आहेत, जे रशियामध्ये क्लाउड अॅडॉप्शन नाही या वस्तुस्थितीशी संबंधित आहे." पश्चिमेकडील लहान किंवा मध्यम आकाराच्या कंपन्या क्लाउड आहेत. Amazon RDS डेटाबेसेस स्वतः कुबर्नेट्सशी छेडछाड करण्यापेक्षा वापरणे सोपे आहे. रशियामध्ये ते कुबेर “ऑन-प्रिमाइस” वापरतात आणि जेव्हा ते प्राणीसंग्रहालयातून मुक्त होण्याचा प्रयत्न करत असतात तेव्हा त्यात तळ हस्तांतरित करतात.

कुबर्नेट्समध्ये कोणताही डेटाबेस ठेवता येणार नाही या विधानाशी दिमित्री देखील असहमत: “बेस बेसपेक्षा वेगळा आहे. आणि जर तुम्ही मोठा रिलेशनल डेटाबेस पुश केला तर कोणत्याही परिस्थितीत नाही. जर तुम्ही लहान आणि क्लाउड नेटिव्ह काहीतरी ढकलले, जे अर्ध-तात्कालिक जीवनासाठी मानसिकदृष्ट्या तयार असेल तर सर्व काही ठीक होईल. दिमित्रीने असेही नमूद केले की डेटाबेस व्यवस्थापन साधने डॉकर किंवा कुबेरसाठी तयार नाहीत, त्यामुळे मोठ्या अडचणी उद्भवतात.

इव्हान, याउलट, खात्री आहे की जरी आपण स्टेटफुल आणि स्टेटलेसच्या संकल्पनांपासून अमूर्त असलो तरी कुबर्नेट्समधील एंटरप्राइझ सोल्यूशन्सची इकोसिस्टम अद्याप तयार नाही. कुबेर सह, विधायी आणि नियामक आवश्यकता राखणे कठीण आहे. उदाहरणार्थ, सर्व्हरमध्ये घातलेल्या हार्डवेअरपर्यंत कठोर सर्व्हर आयडेंटिफिकेशन हमी आवश्यक असल्यास ओळख तरतूद समाधान करणे अशक्य आहे. या भागाचा विकास होत आहे, मात्र त्यावर अद्याप तोडगा निघालेला नाही.
सहभागी सहमत होऊ शकले नाहीत, त्यामुळे या भागात कोणतेही निष्कर्ष काढले जाणार नाहीत. चला काही व्यावहारिक उदाहरणे देऊ.

केस 1. कुबेराच्या बाहेर तळ असलेल्या "मेगा-रेग्युलेटर" ची सायबर सुरक्षा

विकसित सायबरसुरक्षा प्रणालीच्या बाबतीत, कंटेनर आणि ऑर्केस्ट्रेशनचा वापर हल्ले आणि घुसखोरीशी लढा देणे शक्य करते. उदाहरणार्थ, एका मेगा-रेग्युलेटरमध्ये, डेनिस आणि त्याच्या टीमने प्रशिक्षित SIEM सेवेसह ऑर्केस्ट्रेटरचे संयोजन लागू केले जे रिअल टाइममध्ये लॉगचे विश्लेषण करते आणि आक्रमण, हॅकिंग किंवा अपयशाची प्रक्रिया निर्धारित करते. हल्ला झाल्यास, एखादी गोष्ट ठेवण्याचा प्रयत्न केल्यास किंवा रॅन्समवेअर व्हायरसचे आक्रमण झाल्यास, ते, ऑर्केस्ट्रेटरद्वारे, ऍप्लिकेशन्स असलेले कंटेनर संक्रमित होण्यापेक्षा किंवा हल्लेखोर हल्ला करण्यापेक्षा वेगाने उचलतात.

प्रकरण 2. Booking.com डेटाबेसचे Kubernetes वर आंशिक स्थलांतर

Booking.com मध्ये, मुख्य डेटाबेस एसिंक्रोनस प्रतिकृतीसह MySQL आहे - तेथे एक मास्टर आणि गुलामांची संपूर्ण पदानुक्रम आहे. इव्हानने कंपनी सोडल्यापर्यंत, गुलामांच्या हस्तांतरणासाठी एक प्रकल्प सुरू करण्यात आला होता ज्याला विशिष्ट नुकसानासह "शॉट" केले जाऊ शकते.

मुख्य तळाव्यतिरिक्त, स्व-लिखित ऑर्केस्ट्रेशनसह कॅसॅन्ड्रा स्थापना आहे, जी कुबेर मुख्य प्रवाहात येण्यापूर्वीच लिहिली गेली होती. या संदर्भात कोणतीही समस्या नाही, परंतु स्थानिक SSDs वर ती कायम आहे. रिमोट स्टोरेज, अगदी त्याच डेटा सेंटरमध्ये, उच्च लेटन्सीच्या समस्येमुळे वापरले जात नाही.

डेटाबेसचा तिसरा वर्ग Booking.com शोध सेवा आहे, जिथे प्रत्येक सेवा नोड एक डेटाबेस आहे. कुबेरकडे शोध सेवा हस्तांतरित करण्याचा प्रयत्न अयशस्वी झाला, कारण प्रत्येक नोड 60-80 GB स्थानिक स्टोरेज आहे, ज्याला “उचल” आणि “वॉर्म अप” करणे कठीण आहे.

परिणामी, शोध इंजिन कुबर्नेट्सकडे हस्तांतरित केले गेले नाही आणि इव्हानला असे वाटत नाही की नजीकच्या भविष्यात नवीन प्रयत्न होतील. MySQL डेटाबेस अर्ध्यामध्ये हस्तांतरित केला गेला: फक्त गुलाम, ज्यांना "शॉट" होण्याची भीती वाटत नाही. कॅसँड्रा उत्तम प्रकारे स्थायिक झाली आहे.

पायाभूत सुविधांची निवड सामान्य समाधानाशिवाय कार्य म्हणून

द्वारे फोटो Pexels मधील मॅन्युअल गीसिंजर

समजा आमच्याकडे एक नवीन कंपनी आहे किंवा एखादी कंपनी आहे जिथे पायाभूत सुविधांचा काही भाग जुन्या पद्धतीने बांधला गेला आहे. तो वर्षानुवर्षे पायाभूत सुविधांच्या विकासाचा आराखडा तयार करतो. कंटेनर आणि कुबेर यांच्यावर पायाभूत सुविधा निर्माण करायच्या की नाही हा निर्णय कसा घेतला जातो?

नॅनोसेकंदसाठी लढणाऱ्या कंपन्यांना चर्चेतून वगळण्यात आले आहे. विश्वासार्हतेच्या बाबतीत निरोगी पुराणमतवाद पैसे देतो, परंतु तरीही अशा कंपन्या आहेत ज्यांनी नवीन पध्दतींचा विचार केला पाहिजे.

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

असे इव्हानचे मत आहे सध्याच्या पायाभूत सुविधांचा विकास हा निवड निकष आहे. जर पूर्वी एखादी गंभीर गुंतवणूक झाली असेल आणि ती कार्य करत असेल तर ती पुन्हा करण्यात काही अर्थ नाही. जर पायाभूत सुविधा विकसित केल्या नसतील आणि साधने, सुरक्षा आणि देखरेखीमध्ये समस्या असतील, तर वितरित पायाभूत सुविधांकडे पाहण्यात अर्थ आहे.

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

दोन सर्व्हर असलेल्या छोट्या कंपनीसाठी, कुबेरला काही अर्थ नाही,” आंद्रे म्हणतात. परंतु जर ते शेकडो किंवा त्याहून अधिक सर्व्हरपर्यंत वाढण्याची योजना आखत असेल तर त्याला ऑटोमेशन आणि संसाधन व्यवस्थापन प्रणाली आवश्यक आहे. 90% प्रकरणे किंमतीची आहेत. शिवाय, लोड आणि संसाधनांची पातळी विचारात न घेता. स्टार्टअप्सपासून लाखो प्रेक्षक असलेल्या मोठ्या कंपन्यांपर्यंत प्रत्येकासाठी हळूहळू कंटेनर ऑर्केस्ट्रेशन उत्पादनांकडे लक्ष देणे अर्थपूर्ण आहे. "होय, हे खरोखरच भविष्य आहे," आंद्रेला खात्री आहे.

डेनिसने दोन मुख्य निकष सांगितले - स्केलेबिलिटी आणि ऑपरेशनची स्थिरता. तो कार्यासाठी सर्वात योग्य असलेली साधने निवडेल. “हे तुमच्या गुडघ्यावर जमलेले नाव असू शकते आणि त्यावर नुटॅनिक्स कम्युनिटी एडिशन आहे. बॅकएंडवरील डेटाबेससह कुबेरवरील अनुप्रयोगाच्या स्वरूपात ही दुसरी ओळ असू शकते, ज्याची प्रतिकृती तयार केली गेली आहे आणि आरटीओ आणि आरपीओ पॅरामीटर्स निर्दिष्ट केले आहेत" (पुनर्प्राप्ती वेळ/बिंदू उद्दिष्टे - अंदाजे).

इव्हगेनीने कर्मचार्‍यांसह संभाव्य समस्या ओळखल्या. याक्षणी, मार्केटमध्ये "हिम्मत" समजणारे बरेच उच्च पात्र तज्ञ नाहीत. खरंच, जर निवडलेले तंत्रज्ञान जुने असेल, तर जीवनाला कंटाळलेल्या आणि कंटाळलेल्या मध्यमवयीन लोकांशिवाय इतर कोणालाही कामावर घेणे कठीण आहे. जरी इतर सहभागींचा असा विश्वास आहे की ही कर्मचारी प्रशिक्षणाची बाब आहे.
जर आम्ही निवडीचा प्रश्न ठेवला: Amazon RDS मधील डेटाबेससह सार्वजनिक क्लाउडमध्ये एक छोटी कंपनी लॉन्च करण्यासाठी किंवा Kubernetes मधील डेटाबेससह "ऑन प्रिमिस" लाँच करण्यासाठी, काही कमतरता असूनही, सहभागींची निवड Amazon RDS होती.

भेटणारे बहुसंख्य श्रोते "रक्तरंजित" एंटरप्राइझचे नसल्यामुळे वितरीत उपाय म्हणजे आपण ज्यासाठी प्रयत्न केले पाहिजेत. डेटा स्टोरेज सिस्टम वितरित, विश्वासार्ह आणि मिलिसेकंदांच्या युनिट्समध्ये मोजले जाणारे विलंब तयार करणे आवश्यक आहे, जास्तीत जास्त दहा", आंद्रेने सारांश दिला.

कुबर्नेट्सच्या वापराचे मूल्यांकन करणे

श्रोता अँटोन झबँकोव्ह यांनी कुबर्नेट्स माफीशास्त्रज्ञांना एक ट्रॅप प्रश्न विचारला: तुम्ही व्यवहार्यता अभ्यास कसा निवडला आणि कसा केला? कुबर्नेट्स का, उदाहरणार्थ आभासी मशीन का नाही?

द्वारे फोटो अनस्प्लॅशवर तात्याना एरेमिना

दिमित्री आणि इव्हान यांनी उत्तर दिले. दोन्ही प्रकरणांमध्ये, चाचणी आणि त्रुटीद्वारे, निर्णयांचा एक क्रम तयार केला गेला, परिणामी दोन्ही सहभागी कुबर्नेट्स येथे पोहोचले. आता व्यवसाय स्वतंत्रपणे सॉफ्टवेअर विकसित करू लागले आहेत जे कुबेरला हस्तांतरित करण्यास अर्थपूर्ण आहे. आम्ही क्लासिक तृतीय-पक्ष प्रणालींबद्दल बोलत नाही, जसे की 1C. नॉन-स्टॉप कंटिन्युअस इम्प्रूव्हमेंटसह, डेव्हलपर्सना त्वरीत रिलीझ करणे आवश्यक असते तेव्हा Kubernetes मदत करते.

अँड्रीच्या टीमने व्हर्च्युअल मशिन्सवर आधारित स्केलेबल क्लस्टर तयार करण्याचा प्रयत्न केला. नोड्स डोमिनोजसारखे पडले, ज्यामुळे कधीकधी क्लस्टर कोसळले. “सैद्धांतिकदृष्ट्या, आपण ते पूर्ण करू शकता आणि आपल्या हातांनी त्याचे समर्थन करू शकता, परंतु ते कंटाळवाणे आहे. आणि जर बाजारात एखादे समाधान असेल जे तुम्हाला बॉक्सच्या बाहेर काम करण्यास अनुमती देते, तर आम्हाला ते करण्यास आनंद होतो. आणि परिणामी आम्ही स्विच केले," आंद्रे म्हणतात.

अशा विश्लेषणासाठी आणि गणनेसाठी मानके आहेत, परंतु ते कार्यरत असलेल्या वास्तविक हार्डवेअरवर किती अचूक आहेत हे कोणीही सांगू शकत नाही. गणनेसाठी, प्रत्येक साधन आणि परिसंस्था समजून घेणे देखील महत्त्वाचे आहे, परंतु हे शक्य नाही.

आम्हाला काय वाट पाहत आहे

द्वारे फोटो अनस्प्लॅशवर ड्र्यू बीमर

जसजसे तंत्रज्ञान विकसित होत जाते, तसतसे अधिकाधिक विषम तुकडे दिसतात, आणि नंतर एक फेज संक्रमण होते, एक विक्रेता दिसून येतो ज्याने एकाच साधनात सर्वकाही एकत्र येण्यासाठी पुरेसे पीठ मारले आहे.

तुम्हाला असे वाटते का की अशी वेळ येईल जेव्हा लिनक्स जगासाठी उबंटू सारखे साधन असेल? कदाचित एकाच कंटेनरायझेशन आणि ऑर्केस्ट्रेशन टूलमध्ये कुबेरचा समावेश असेल. हे ऑन-प्रिमाइस क्लाउड तयार करणे सोपे करेल.

इव्हानने उत्तर दिले: "Google आता अँथॉस तयार करत आहे - ही त्यांची पॅकेज केलेली ऑफर आहे जी क्लाउड तैनात करते आणि त्यात कुबेर, सर्व्हिस मेश, मॉनिटरिंग - ऑन-प्रिमाइस मायक्रो सर्व्हिसेससाठी आवश्यक असलेले सर्व हार्डवेअर समाविष्ट आहेत." आम्ही जवळजवळ भविष्यात आहोत."

डेनिसने vRealize Suite उत्पादनासह Nutanix आणि VMWare चा देखील उल्लेख केला आहे, जे कंटेनरायझेशनशिवाय समान कार्यास सामोरे जाऊ शकतात.

दिमित्रीने आपले मत व्यक्त केले की "वेदना" कमी करणे आणि कर कमी करणे ही दोन क्षेत्रे आहेत जिथे आपण सुधारणांची अपेक्षा करू शकतो.

चर्चेचा सारांश देण्यासाठी, आम्ही आधुनिक पायाभूत सुविधांच्या खालील समस्यांवर प्रकाश टाकतो:

• तीन सहभागींनी ताबडतोब स्टेटफुलची समस्या ओळखली.
• डॉकर पायथन, ऍप्लिकेशन सर्व्हर आणि घटकांच्या एकाधिक आवृत्त्यांसह समाप्त होईल या शक्यतेसह विविध सुरक्षा समर्थन समस्या.
  जास्त खर्च करणे, ज्यावर वेगळ्या बैठकीत चर्चा करणे चांगले आहे.
  ऑर्केस्ट्रेशन म्हणून शिकण्याचे आव्हान एक जटिल परिसंस्था आहे.
  उद्योगातील एक सामान्य समस्या म्हणजे साधनांचा गैरवापर.

  बाकीचे निष्कर्ष तुमच्यावर अवलंबून आहेत. अजूनही अशी भावना आहे की डॉकर + कुबर्नेट्स संयोजन प्रणालीचा "मध्य" भाग बनणे सोपे नाही. उदाहरणार्थ, ऑपरेटिंग सिस्टम प्रथम हार्डवेअरवर स्थापित केले जातात, जे कंटेनर आणि ऑर्केस्ट्रेशनबद्दल सांगितले जाऊ शकत नाही. कदाचित भविष्यात, ऑपरेटिंग सिस्टम आणि कंटेनर क्लाउड व्यवस्थापन सॉफ्टवेअरमध्ये विलीन होतील.

  
  द्वारे फोटो पेक्सेल्स मधील गॅब्रिएल सॅंटोस फोटोग्राफिया

  मला माझ्या आईला नमस्कार सांगण्याची आणि आमचा फेसबुक ग्रुप आहे याची आठवण करून देण्याची मला ही संधी आवडेल "मोठ्या आयटी प्रकल्पांचे व्यवस्थापन आणि विकास", चॅनल @feedmeto विविध टेक ब्लॉगवरील मनोरंजक प्रकाशनांसह. आणि माझे चॅनेल @rybakalexey, जिथे मी उत्पादन कंपन्यांमधील विकास व्यवस्थापित करण्याबद्दल बोलतो.

स्त्रोत: www.habr.com