वर्चुअलाइज्ड पेशकशें काफी खराब प्रदर्शन करती हैं (मेरे 2019 प्रयोग देखें: httpsjan.rychter.com/enblog/cloud-server-cpu-performance और लागत अधिक है। अंतर यह है कि आप "मांग पर स्केल"कर सकते हैं, जो मुझे आवश्यक नहीं लगा, कम से कम मेरे मामले में। और अगर मुझे स्केल करने की आवश्यकता है, तो मैं अभी भी ऐसा कर सकता हूं, बात बस इतनी है कि नए सर्वर प्राप्त करने में सेकंड के बजाय घंटे लगते हैं। खैर, मुझे सेकंड में स्केल करने की आवश्यकता नहीं है

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

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

मुझे संदेह है कि वेंडरऑप्स और कुबेरनेट्स जैसे जटिल उपकरण जटिलता वाले व्यापारियों के पक्षधर हैं जो पिछले दशक में उत्पन्न हुए हैं। यह बायोडाटा में बहुत अच्छा लगता है और तकनीकी नेताओं को उपलब्धि का झूठा अहसास कराता है

इस बीच स्टैकओवरफ्लो, जो यकीनन अधिकांश स्टार्टअप्स से अधिक महत्वपूर्ण है, समर्पित मशीनों पर काम कर रहा है

1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..

ऐसा लगता है जैसे इस क्षेत्र में प्रवृत्ति सीधे अमूर्तता की उच्चतम परत पर कूदने की है। बुनियादी बातों को छोड़कर $buzzword टूल, लाइब्रेरी और उत्पादों की ओर इशारा करें

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

कॉर्बा वहीं का है. और शायद सिमेंटिक वेब सामग्री भी। निश्चित रूप से एक्सएमएल!
XML बढ़िया है - यदि आप इस पर विश्वास नहीं करते हैं, तो आपको JSON को पार्स करने की कठिनाइयों में रुचि हो सकती है: httpseriot.ch/projects/parsing_json.html
और मुझे YAML पर आरंभ न करें..

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

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

यदि आप अपने पर्यावरण कॉन्फ़िगरेशन को कोड के रूप में कर रहे हैं तो अंततः इससे कोई फर्क नहीं पड़ता कि आपका लक्ष्य एक समर्पित सर्वर, एक वीएम या एपीआई के माध्यम से कॉन्फ़िगर किया गया कुछ क्लाउड विशिष्ट सेटअप है

वास्तव में इससे कोई फर्क नहीं पड़ता कि कौन सा है, मुद्दा यह है कि आपके पास एक ऐसा बॉक्स है जो आपके लिए एक नया बॉक्स बना सकता है या बस एक कमांड चलाकर खराब व्यवहार वाले बॉक्स को अच्छी स्थिति में वापस ला सकता है।

निश्चित रूप से, इसे चलाने वाले गो(ओ) के वास्तविक ढेर में सुधार किया जा सकता है (और यह वास्तव में सुधार हो रहा है)

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

चारों तरफ अच्छी चीजें

Ansible अनिवार्य है, यह एक स्थिर स्थिति की ओर काम कर सकता है, और बस इतना ही। यदि इसमें कोई समस्या आती है तो यह अपना SSH कनेक्शन बंद कर देता है, और ढेरों पाइथॉन त्रुटियों का रोना रोता है, और हमेशा के लिए हार मान लेता है। यहां तक ​​कि अपनी सूची के साथ भी यह घोषणात्मक होने से बहुत दूर है
k8s एक नियंत्रण लूप है जो अपनी घोषित स्थिति की ओर प्रगति करने का प्रयास करता है। असफलता कोई समस्या नहीं है, पुनः प्रयास करेंगे। यह लगातार अपनी स्थिति की जांच करेगा, इसकी रिपोर्ट करने के लिए इसमें एक अच्छा एपीआई है, और कई संशोधित अवधारणाओं के लिए धन्यवाद, तैनात घटकों के बीच अजीब टकराव होना कठिन है। (जबकि Ansible के साथ एकाधिक प्लेबुक को एकीकृत करना मामूली बात नहीं है।)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
और भले ही k8s बहुत अधिक विरासत-पन रखता हो, मूल विचारों की आगामी पतली अभिव्यक्तियाँ होती हैं। (उदा. httpsgithub.com/aurae-runtime/aurae )
और अब आप सुझाव दे रहे हैं कि लोग सरल गैर मानक कार्यान्वयन का उपयोग करें?
तो निश्चित रूप से आप न्यूनतम जटिलता समाधान लागू कर सकते हैं या आप "शेल्फ से बाहर"कुछ का उपयोग कर सकते हैं

k8s जटिलता है और इसमें से कुछ निश्चित रूप से आपकी स्थिति के लिए अनावश्यक है, लेकिन यह सामान्य, लचीला, अच्छी तरह से समर्थित आदि भी है

>आप सुझाव दे रहे हैं कि लोग सरल गैर मानक कार्यान्वयन का उपयोग करें?
मैंने जो सुझाव दिया वह यह है कि यदि k8s प्रोजेक्ट/सॉफ़्टवेयर विफल होने के लिए बहुत बड़ा हो जाता है, तो लोग किसी विकल्प पर स्विच कर सकते हैं। सौभाग्य से k8s अवधारणाएँ और API खुला स्रोत हैं, इसलिए उन्हें अन्य परियोजनाओं में लागू किया जा सकता है, और मैंने यह समझाने के लिए एक उदाहरण दिया कि k8s चुनना Oracle जैसा वेंडर लॉक-इन नहीं है

मैं हमेशा उन सभी बेहतरीन चीज़ों के बारे में सुनता हूँ जो आपको क्लाउड प्रदाताओं से व्यावहारिक रूप से निःशुल्क मिलती हैं। क्या वह सामान वास्तव में स्थापित करना और उपयोग करना इतना आसान है? जब भी मैंने क्लाउड सेवा पर अपना LAMP स्टैक स्थापित करने का प्रयास किया तो यह इतनी भ्रमित करने वाली और भयावह प्रक्रिया थी कि मैंने हार मान ली। मैं सोच रहा हूं कि क्या मुझे बस थोड़ा और जोर लगाने की जरूरत है और मैं क्लाउड हेवेन तक पहुंच जाऊंगा
यह कहने में सक्षम होना कि "मुझे यहां इस तरह की विशिष्टताओं के साथ एक क्लस्टर्ड MySQL चाहिए"इसे अपने आप करने की तुलना में बहुत बेहतर (समय-वार) है। अपडेट भी सिस्टम में अच्छी तरह से लपेटे गए हैं, इसलिए मैं मैन्युअल रूप से फेलओवर/रीस्टार्ट को सही क्रम में सुनिश्चित करने के बजाय केवल "नवीनतम अपडेट लागू करें"कह रहा हूं।

तो आप चीजों को सरल बनाने के लिए भुगतान करते हैं, लेकिन उस सरलीकरण से लाभ केवल बड़ी परियोजनाओं से ही मिलता है। यदि आपके पास एक ही सर्वर में कुछ है जिसे आप अपने उपयोगकर्ताओं को त्रुटि पृष्ठ मिलने पर पुनः आरंभ कर सकते हैं, तो यह इसके लायक नहीं हो सकता है

क्लाउड में एक छोटे सर्वर रूम की कूलिंग और पावर दक्षता प्राप्त करना आसान नहीं है, दक्षता स्तर के आसपास कहीं भी अधिकांश बड़े डेटा-सेंटर का प्रकाशन असंभव के बगल में है क्योंकि मल्टी वेंडर इंटरनेट कनेक्टिविटी है

क्लाउड के साथ यह सब समाप्त हो जाता है क्योंकि यह क्लाउड पर चलने वाले किसी भी डेटा-सेंटर ऑपरेटर द्वारा प्रबंधित किया जाता है, लेकिन लोग यह भूल जाते हैं कि यह पुराने जमाने की कोलोकेशन सेवाओं के लिए भी सच है जो अक्सर क्लाउड की तुलना में बेहतर लागत/मूल्य की पेशकश करती है।
और जबकि AWS या Azure जैसी चीज़ों को प्रबंधित करना निश्चित रूप से कठिन है क्योंकि यह बहुत सारे अमूर्त तत्वों को नष्ट कर देता है जिन्हें छोटे पैमाने के VPC प्रदाता आपसे छिपाते हैं या जो आपको वास्तव में एक होम सर्वर के साथ नहीं मिलते हैं, एक जोड़े को चलाने के पैमाने पर यह कठिन नहीं है SAN आधारित भंडारण के साथ vmware सर्वर के रैक के लायकक्लाउड सामग्री के साथ आपके पास करने के लिए अधिक कॉन्फ़िगरेशन है क्योंकि यह वर्चुअल सर्वर आदि को कॉन्फ़िगर करने के बारे में है।पीसी को अंदर ले जाने के बजाय अपने कमरे में बॉक्स को उपलब्ध कराने के लिए आपको इसे "कॉन्फ़िगर"करना होगाडीओ डेटाबेस में बैकअप होते हैं जिन्हें आप अपनी पसंद के अनुसार कॉन्फ़िगर कर सकते हैं, उन्हें डीओ स्पेस (जैसे एस3) पर संग्रहीत कर सकते हैं।डीबी उपयोगकर्ता प्रबंधन आसान है।रेडिस के लिए कैश सर्वर भी हैंआप एक लोड बैलेंसर जोड़ सकते हैं और इसे अपने विभिन्न वेब सर्वर से कनेक्ट कर सकते हैंमुझे लगता है कि इसमें मुझे लग गया 2x वेब सर्वर, एक DB सर्वर, कैशे सर्वर, लोड बैलेंसर, एक स्टोरेज सर्वर को सेटअप करने और कुछ सरल रूपों का उपयोग करके आवश्यकतानुसार उन सभी को कनेक्ट करने में लगभग 30 मिनट का समय लगा।वास्तव में उसे हरा नहीं सकतायदि आपके पास कोई और जानकारी या राय है तो कृपया साझा करेंइंटरनेट पर इसके बारे में बहुत सारे लेख हैं लिनक्स सर्वर को सख्त करने के लिए, मैंने जिन चरणों का पालन करने का प्रयास किया है, उन्हें चरणों का पालन करने में 30 मिनट से थोड़ा अधिक समय लगता है, अगर मैं वास्तव में सीखने और समझने की कोशिश कर रहा हूं कि प्रत्येक चीज़ क्या कर रही है, यह क्यों महत्वपूर्ण है, अंतर्निहित भेद्यता क्या है, तो बहुत अधिक समय लगता है। है, और मुझे अपने विशेष उपयोग के मामले के लिए कुछ सेटिंग्स को कैसे अनुकूलित करने की आवश्यकता हो सकती हैमुझे यकीन है कि आप उदाहरण सेटअप स्क्रिप्ट ऑनलाइन पा सकते हैं (ऑटोअपडेट्स, फ़ायरवॉल, एप्लिकेशन इत्यादि को कॉन्फ़िगर करना एक मामला होना चाहिए) 'कर्ल $URL'और फिर 'chmod +x $FILE'और 'bash $FILE'चलाने की।मुझे कॉन्फ़िगरेशन प्रबंधन की आवश्यकता नहीं थी (मैं अपने प्रदाता की बैकअप सेवा का उपयोग करता हूं जो मुझे लगता है कि महत्वपूर्ण है)कुछ इस तरह: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(httpswww.reddit.com/r/selfhosted में देखा गया) /comments/f18xi2/ubuntu_d )स्पष्ट रूप से लंबे समय तक चलने वाले वीएम के लिए भी यही कहा जा सकता है, और इसे एक अनुशासित टीम के साथ हल किया जा सकता है, लेकिन मुझे लगता है कि आम तौर पर लंबे समय तक चलने वाले समर्पित वातावरण में इसकी संभावना अधिक होती है मशीनहेट्ज़नर के पास प्रबंधित डेटाबेस को छोड़कर यह सब हैhttpswww.hetzner.com/managed-serverवेबहोस्टिंग पैकेज में 1 भी शामिल है। .असीमित डीबी (MySQL और PostgreSQL)httpswww.hetzner.com/webhosting/क्या इसमें स्वचालित बैकअप है और विफल हो गया है?>बुक किए गए दैनिक बैकअप या सर्वर के प्रकार में शामिल बैकअप के साथ, सभी डेटा का दैनिक बैकअप लिया जाता है और अधिकतम 14 दिनों तक रखा जाता है।बैकअप की पुनर्प्राप्ति (पुनर्स्थापना) konsoleH प्रशासन इंटरफ़ेस के माध्यम से संभव हैलेकिन मुझे लगता है कि प्रबंधित सर्वर पर डेटाबेस उस सर्वर पर चल रहे ऐप्स द्वारा उपयोग के लिए हैं, इसलिए वास्तव में फेलओवर की कोई अवधारणा नहीं हैhttpswww.hetzner.com/legal/managed-server/एकल सर्वर पर एकल ड्राइव के विफल होने से कभी भी उत्पादन नहीं होना चाहिए आउटेजबहुत सारी कॉन्फ़िगरेशन समस्याओं को स्व-निहित तैनाती में ट्रैक किया जा सकता है।क्या उस फ़ॉन्ट फ़ाइल या JRE को वास्तव में पूरे सर्वर पर स्थापित करने की आवश्यकता है या क्या आप इसे अपनी तैनाती में बंडल कर सकते हैंहमारी तैनाती ऑन-प्रिमाइस और EC2 लक्ष्यों का उपयोग करती है।परिनियोजन स्क्रिप्ट अलग नहीं है, केवल होस्ट के लिए आईपी हैअब, मैं कहूंगा कि अगर मैं किसी चीज़ के लिए एस3 का उपयोग कर सकता हूं तो मैं 100% करूंगा।समान फीचर सेट के साथ इसके लिए कोई ऑन-प्रिमाइस विकल्प नहीं हैDevOps का मुद्दा "मवेशी है, पालतू जानवर नहीं।"अपने विफलता बिंदुओं को खोजने के लिए सप्ताह में एक बार अपने सर्वर में एक बुलेट डालेंमुझे अच्छा लगेगा यदि आप हमारे डिसॉर्डर/स्लैक में शामिल हो जाएं और कुछ ऐसे मुद्दे सामने लाएं जो आप देख रहे थे ताकि हम कर सकें कम से कम डोक्कू का उपयोग करके दूसरों के लिए अनुभव को बेहतर बनाएं।बेझिझक मुझे वहां बुलाएं (मेरा उपनाम 'सेवंत'है)मुझे प्रस्तावना करने दें और कहें कि मैं एक एप्लिकेशन डेवलपर हूं जिसके पास केवल डॉकर का कार्यसाधक ज्ञान है।मैं इन्फ्रा में सुपर कुशल नहीं हूं और जिस एप्लिकेशन के साथ मुझे संघर्ष करना पड़ा, उसमें अजीब परिनियोजन पैरामीटर हैं: यह एक पायथन ऐप है जो बिल्ड-टाइम पर एक पोस्टग्रेज डेटाबेस को पॉप्युलेट करने के लिए स्थिर HTML क्रॉल के कई गिग्स को पार्स करता है जो बनने के बाद स्थिर होता है।एक फ्लास्क वेब ऐप उस डेटाबेस के विरुद्ध कार्य करता है।HTML पार्सिंग तेजी से विकसित होती है और इसलिए पॉप्युलेट किए गए DB डेटा को एप्लिकेशन छवि(छवियों) के हिस्से के रूप में बंडल किया जाना चाहिएIIRC, जब DB था तब मुझे Dockerfiles को संरचित करने में संघर्ष करना पड़ा। यह लगातार बना रहा, बल्कि ऐप का सिर्फ एक और क्षणिक हिस्सा था, लेकिन यह पार करने योग्य लग रहा था।बड़ा मुद्दा यह प्रतीत होता है कि प्रत्येक बिल्ड के लिए S3 से शायद ही कभी बदले गए डेटा को खींचने से कैसे बचा जाए, जब आदर्श रूप से इसे कैश किया जाएगा, विशेष रूप से इस तरह से कि DigitalOcean और मेरे स्थानीय वातावरण में समझदारी से व्यवहार किया जाए।मुझे लगता है कि सही डॉकर छवि परत कैशिंग समस्या का समाधान करेगी, लेकिन मैं बहुत तेजी से अपने ज्ञान और धैर्य के अंत तक पहुंच गयाडोक्कू का डीएक्स सामान्य काम करने वाले लोगों के लिए बहुत अच्छा लगता है .:)0. httpscoolify.io/साथ ही कौन दूसरे के पैसे से सबसे नए, सबसे अच्छे खिलौने के साथ खेलना नहीं चाहता?निश्चित रूप से यात्रा के बाद में (कुछ) सामान को क्लाउड से हटाने का एक तर्क है जब लचीलापन (या फ्लक्स/पिवोटिंग से निपटना) प्राथमिक चालक से कम हो जाता है और स्केल/लागत हावी होने लगती हैनिश्चित रूप से, आप हेट्ज़नर पर कुछ काम कर सकते हैं लेकिन कई और सवालों के जवाब देने के लिए तैयार रहेंआपके उद्यम के आखिरी बिंदु पर इस बात पर सहमत हुए कि यह फिर से दुखद है कि ये व्यवसाय "आवश्यकताएँ"यह निर्धारित करती हैं कि आपके सॉफ़्टवेयर को कैसे आर्किटेक्ट और होस्ट किया जाए जबकि कोई अन्य तरीका बहुत बेहतर हो सकता हैआपदा पुनर्प्राप्ति एक बहुत ही वास्तविक समस्या है।यही कारण है कि मैं नियमित रूप से इसका परीक्षण करता हूं।झुलसी-पृथ्वी के परिदृश्य में, मैं एक घंटे से भी कम समय में द्वितीयक (स्टेजिंग) सिस्टम या टेराफॉर्म्ड क्लाउड सिस्टम पर काम कर सकता हूं।मेरे व्यवसाय के लिए, यह पर्याप्त है
हम विकास में तेजी के दौर से गुजर रहे थे और पहले की तरह ही, इसका मतलब था कि बहुत से अनुभवहीन लोगों को ढेर सारा पैसा और जरूरी उम्मीदें दी जा रही थीं। यह कार्गो पालन और शोषणकारी विपणन का एक नुस्खा है

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

एक ठोस समर्पित सर्वर 99% मामलों में साझा हार्डवेयर पर खराब वीपीएस की तुलना में कहीं अधिक उपयोगी होता है, लेकिन यदि आपको उनके द्वारा प्रदान किए गए सभी संसाधनों की आवश्यकता नहीं है तो यह स्पष्ट रूप से बढ़ी हुई लागत पर आता है।

हां - लेकिन "वह करने की इच्छा जो सभी अच्छे बच्चे अब कर रहे हैं"कम से कम उन लोगों में उतनी ही प्रबल होती है जिन्हें आम तौर पर "प्रबंधक"बनाम "कर्मचारी"कहा जाता है।

परिणाम ए) भारी माइक्रोसर्विसेज/क्लाउड खर्च गलत हो जाता है, कम से कम आप सर्वोत्तम प्रथाओं का पालन कर रहे थे, ये चीजें होती हैं, आप क्या कर सकते हैं

परिणाम बी) आप हेट्ज़नर सर्वर के साथ गए और कुछ गलत हो गया, ठीक है आप हैं और आपको माइक्रोसर्विसेज के साथ जाना चाहिए था, नई नौकरी की तलाश का आनंद लें

इस प्रकार प्रबंधकों को माइक्रोसर्विसेज/क्लाउड चुनने के लिए प्रोत्साहित किया जाता है। हो सकता है कि यह कंपनी के लिए सही निर्णय न हो, लेकिन प्रबंधक के लिए यह सही निर्णय है, और प्रबंधक ही निर्णय ले रहा है

(जैसा कि एक सलाहकार होने के नाते एक एक्सटेंशन और लेखन सॉफ्टवेयर चाहता है जो काम करता है, जैसा कि मुझे कठिन रास्ता पता चला।)
संस्थापकों और बाकी सभी के बीच एक अलगाव है

संस्थापकों का मानना ​​है कि वे हर साल >10 गुना तक जा रहे हैं

वास्तविकता यह है कि उनके असफल होने की 90% संभावना है

90% समय - आप किसी भी चीज़ में असफल होने पर ठीक हैं

10% समय में से कुछ% जब आप सफल होते हैं तो आप क्लाउड के बिना भी ठीक रहते हैं - कम से कम कई वर्षों की सफलता के लिए, यदि आवश्यक हो तो स्विच करने के लिए पर्याप्त समय

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

बेशक, मैं कई अन्य क्लाउड सेवाओं पर निर्भर होने से बचने के लिए भी सावधान हूं। उदाहरण के लिए, मैं सर्वरों के बीच संचार के लिए VpnCloud (httpsgithub.com/dswd/vpncloud) का उपयोग करता हूं। एक अतिरिक्त लाभ के रूप में, इससे मुझे किसी भी समय किसी भी बुनियादी ढांचा प्रदाता पर स्विच करने की सुविधा मिलती है
मेरा मुख्य मुद्दा यह था कि जबकि वर्चुअलाइज्ड पेशकशों के अपने उपयोग होते हैं, $10/माह के हॉबी वीपीएस और तेजी से विकास करने वाले बी2सी व्यवसाय वाली कंपनी के बीच एक (बहुत बड़ा) अंतर होता है। अधिकांश नए व्यवसाय वास्तव में उस अंतर में आते हैं: आप लाभदायक B2B SaaS में हॉकी-स्टिक घातीय वृद्धि की उम्मीद नहीं करते हैं। यहीं पर आपको "AWS का उपयोग करें"के सामान्य डिफ़ॉल्ट विकल्प पर सवाल उठाना चाहिए। मुझे अपने सीओजीएस और अपने मार्जिन की परवाह है, इसलिए मैं इस विकल्प को बहुत ध्यान से देखता हूं

आप कोई सॉफ़्टवेयर कंपनी नहीं हैं, मूलतः आप स्प्रोकेट बनाते और बेचते हैं

यहां राय यह होगी कि "सर्वर खरीदने और बनाए रखने"के लिए एक बड़े इंजीनियरिंग/आईटी स्टाफ को नियुक्त किया जाएगा (PaaS खराब है) और फिर संभवतः "कोड का स्वयं लिखें"(SaaS खराब है) या जो कुछ भी वर्तमान में यहां लोकप्रिय है (अंतिम धागा यहां था) "गिट के बिना एसएफटीपी पर PHP को पुश करना, और यदि आपको और अधिक की आवश्यकता है तो आप"हाहा)
लेकिन मेरा मानना ​​है कि व्यवसायों को एक काम अच्छा करना चाहिए और अपनी मूल योग्यता से बाहर की चीजों के लिए प्रतिस्पर्धा करने (इसे मैन्युअल रूप से करने) से बचना चाहिए। इस मामले में, मैं निश्चित रूप से सोचूंगा कि स्प्रोकेट मास्टर्स को अपने स्वयं के हार्डवेयर को प्रबंधित करने का प्रयास नहीं करना चाहिए और स्केलिंग, सुरक्षा, अपटाइम, अनुपालन और सभी छोटे विवरणों को संभालने के लिए प्रदाता पर निर्भर रहना चाहिए। मैं यह भी सोचता हूं कि उनका सॉफ्टवेयर जितना संभव हो उतना कम इन-हाउस के साथ ख़राब-मानक होना चाहिए। वे कोई सॉफ़्टवेयर दुकान नहीं हैं और उन्हें यथासंभव कम कोड लिखना चाहिए

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

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

लेकिन वे एजेंसियाँ भौतिक हार्डवेयर के रखरखाव के लिए भी कर्मचारी नहीं रखना चाहतीं।

लेकिन स्प्रोकेट मास्टर्स को अभी भी आपात स्थिति से निपटने के लिए रिटेनर पर एक महंगा क्लाउड कंसल्टेंट रखना होगा

यदि आप क्लाउड समस्याओं से निपटने के लिए किसी को स्टाफ में रखने जा रहे हैं, तो आप इसके बजाय एक सर्वर किराए पर भी ले सकते हैं

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

कईयों के लिए तो उससे भी बहुत कम। मैं एक छोटा साइड प्रोजेक्ट चलाता हूं[1] जो कुछ बार वायरल हुआ (24 घंटों में 30 हजार बार देखा गया) और यह सिंगल कोर सीपीयू वेब सर्वर पर चल रहा है और इसी तरह सिंगल सीपीयू कोर पर प्रबंधित पोस्टग्रेज भी चल रहा है। यह पूर्ण उपयोग के करीब भी नहीं है
1: httpsaihelperbot.com/ क्या मैं उनमें से कुछ को लैम्ब्डा फ़ंक्शंस में बदल सकता हूँ? या ईसीएस पर स्विच करें? या किसी अन्य क्लाउड सेवा पर स्विच करें? शायद। लेकिन मैंने इस टिप्पणी को लिखने में जितना समय बिताया, वह ऐसे स्विच के लिए पहले से ही लगभग छह महीने की बचत के बराबर है। यदि यह "पुश बटन, 100% विश्वसनीय-अनुवादित सेवा प्राप्त करें"से अधिक कठिन है, तो इसे उचित ठहराना कठिन है  इसका कुछ कारण यह भी है कि क्लाउड अब कुछ अन्य सेवाएँ भी प्रदान करता है जो इस प्रकार की चीज़ों को सक्षम बनाती हैं। मुझे बुनियादी संदेश भेजने के लिए काफ्का क्लस्टर चलाने की आवश्यकता नहीं है, वे सभी एक संदेश बस के साथ आते हैं। मैं उसका उपयोग करता हूं. मैं होस्ट किए गए DB विकल्पों का उपयोग करता हूं। मैं S3 या समकक्ष आदि का उपयोग करता हूं। मुझे लगता है कि जो कुछ बचा है वह शायद ही खुद को किसी अन्य प्रतिमान में फंसाने की परेशानी के लायक है, जब मैं EC2 उदाहरण पर चलने के लिए प्रति माह एकल-अंकीय डॉलर का भुगतान कर रहा हूं।  यह बिलकुल सच है कि हर कोई या हर प्रोजेक्ट ऐसा नहीं कर सकता। मैं इसे अंतिम लक्ष्य के रूप में लेकर अटका नहीं हूं। जब यह काम नहीं करता तो मैं तुरंत उचित स्केलिंग कार्रवाई करता हूं। मैं यह सुझाव नहीं दे रहा हूं कि आप इसके आधार पर किसी चीज़ की खोज करें। मैं सिर्फ यह कह रहा हूं कि यह तिरस्कृत होने का विकल्प नहीं है। इसमें बहुत अधिक लचीलापन है, और बिलिंग काफी सुसंगत है (या, इसे दूसरे तरीके से कहें तो, तथ्य यह है कि अगर मेरे पास अचानक 50x ट्रैफ़िक है, तो मेरा सिस्टम मुझसे सैकड़ों डॉलर चार्ज करने के बजाय स्पष्ट रूप से बंद और स्पंदन करना शुरू कर देता है। मेरे लिए अधिक एक बग के बजाय एक सुविधा है), और आप आम तौर पर अपने आप को किसी ऐसे प्रतिमान में बदलने के लिए नहीं खींच रहे हैं जो कुछ क्लाउड सेवा के लिए सुविधाजनक है लेकिन आपके लिए सुविधाजनक नहीं हो सकता है  क्या आपको कभी उन परिवेशों में से किसी एक का प्रबंधन करना पड़ा है? बात यह है कि, यदि आप कुछ बुनियादी-एक से अधिक-व्यक्ति स्केलेबिलिटी और उचित डेवॉप्स प्राप्त करना चाहते हैं तो आपको एक महत्वपूर्ण कारक द्वारा अधिक प्रावधान करना होगा (संभवतः आपकी बचत को शून्य करना)  आप अनिवार्य रूप से एक विशेष समाधान के साथ समाप्त होने जा रहे हैं, जिसका अर्थ है कि नए जुड़ने वालों को सिस्टम पर महारत हासिल करने में कठिन समय लगेगा और कंपनी छोड़ने वाले महत्वपूर्ण लोग आपके बुनियादी ढांचे के बारे में अपना गहन ज्ञान अपने साथ लाएंगे। आप मवेशियों के बजाय पालतू जानवरों की ओर वापस आ गए हैं। कुछ सर्वर विशेष होते हैं, कुछ समय के बाद स्वचालन का अर्थ है "यहाँ और वहाँ बहुत सारी ग्लू शेल स्क्रिप्ट"और एक OS अपग्रेड का मतलब है कि या तो आधा इन्फ्रा कुछ समय के लिए KO है या आप OS अपग्रेड बिल्कुल नहीं करते हैं  और भाग्यशाली मामले में आपको बड़े पैमाने पर काम करने की ज़रूरत है, आपको अप्रिय आश्चर्य मिल सकता है  और मुझे कभी भी नेटवर्किंग की ओर मत ले जाना। जब तक आप अपना पूरा रैक किराए पर नहीं ले रहे हैं और अपना खुद का नेटवर्किंग हार्डवेयर नहीं रख रहे हैं, आपको वही मिलेगा जो आपको मिलता है। जो कार्यक्षमता या प्रदर्शन में बहुत खराब हो सकता है, यह मानते हुए कि आप कुछ भी अच्छा नहीं कर रहे हैं  यदि आप 100.000% अपटाइम चाहते हैं, तो निश्चित रूप से। लेकिन आप आमतौर पर ऐसा नहीं करते. जो कंपनियाँ इस प्रकार का अपटाइम चाहती हैं उनके पास आमतौर पर इसके लिए समर्पित टीमें होती हैं  और यदि आप लंबवत रूप से स्केल करते हैं तो स्केलिंग बेयर-मेटल पर भी अच्छी तरह से काम करती है - क्या आपको पता है कि आप एक सर्वर से कितनी शक्ति और थ्रूपुट प्राप्त कर सकते हैं? जब स्पीकर का अर्थ "क्षैतिज स्केलिंग"हो तो "स्केलिंग"के बारे में सुनते रहना चिंताजनक है  यदि आपकी आवश्यकताएं "स्केलिंग"हैं, तो ऊर्ध्वाधर स्केलिंग आपको बहुत दूर तक ले जाएगी  यदि आपकी आवश्यकताएं "मांग पर क्षैतिज स्केलिंग"हैं, तो, निश्चित रूप से, क्लाउड प्रदाता वहां मदद करेंगे। लेकिन, कुछ स्थानों पर उस प्रकार के स्केलिंग की आवश्यकता होती है  मैं यह नहीं कह रहा हूं कि बेअर मेटल पर 100% अपटाइम सस्ता है, मैं यह कह रहा हूं कि 100% अपटाइम की अक्सर आवश्यकता नहीं होती है  क्योंकि उद्योग ऐसे लोगों से भरा है जो रुझानों और कीवर्ड का पीछा कर रहे हैं और जिनके लिए सबसे महत्वपूर्ण बात उन कीवर्ड को सीवी में जोड़ना है  स्केलेबिलिटी के लिए IME का लक्ष्य अधिकांश सेवाओं/अनुप्रयोगों/जो भी हो, के लिए बेहद गलत है। और आम तौर पर आप "स्केलेबल"समाधानों के लिए इतना अधिक भुगतान करते हैं कि फिर आपको इसकी भरपाई के लिए स्केल करने की आवश्यकता होती है  मुझे सचमुच इस पर संदेह है.एक विषय जो आप लगभग हर AWS प्रस्तावक पर देखते हैं, वह यह है कि AWS वास्तव में आपको क्या गारंटी देता है, इसके बारे में कुछ हद तक भ्रम हैहाँ, निश्चित रूप से।आईबीएम से खरीदारी करने पर किसी को नौकरी से नहीं निकाला जाताखैर, अगर बड़ी कंपनियों में निर्णय लेने की कोई क्षमता होती, तो वे अपराजेय होतीं और किसी और चीज पर काम करना निराशाजनक होता सभी।तो, हाँ, यह एक सार्वजनिक भलाई हैस्रोत: लगभग तीस साल का ऑप्सअब तक मैंने इस बात पर ध्यान नहीं दिया है कि अगर मैं अधिक खर्च करता हूं कंपनी के लिए मुझे अधिक भुगतान मिलता हैआयरन के साथ समतुल्य विश्वसनीयता प्राप्त करना "दो समर्पित सर्वर"किराए पर लेने की तुलना में बहुत अधिक महंगा है - अब आप एक सर्वर और एक बैकअप समाधान के साथ ठीक हो सकते हैं , और यह उचित है। लेकिन यह सब बनाने के लिए एक सिस्टम, यहां तक ​​​​कि शुरुआती सेटअप और बिना किसी रखरखाव के लिए एक छोटे अनुबंध पर, क्लाउड मूल्य अंतर से काफी आगे जाने वाला है, खासकर अगर मिश्रण में एक डेटाबेस है और आप उस डेटा की परवाह करते हैंआज, बादल समान है - बाजार में आने का समय जल्दी है क्योंकि कम चलने वाले हिस्से हैं।जब अर्थव्यवस्था गिरती है और विकास धीमा हो जाता है, तो बीनकाउंटर आते हैं और अपना काम करते हैंऐसा हर बार होता हैयह केवल AWS को समृद्ध बनाता है कंपनियों और क्लाउड टीमों मेंयदि आपकी तैनाती को बढ़ाने या घटाने की आवश्यकता है, तो सेकंड के भीतर स्वचालित रूप से EC2 इंस्टेंस का प्रावधान और गैर-प्रावधान करना मामूली बात है।यही बात इसे मूल रूप से बेयर मेटल सर्वर से अलग बनाती है
अब, मैं इस बात से इनकार नहीं कर रहा हूं कि AWS की तुलना में आपकी आवश्यकता से कुछ अधिक समर्पित सर्वरों का प्रावधान करना अभी भी अधिक लागत प्रभावी हो सकता है, लेकिन जब आपके पास वास्तव में अप्रत्याशित कार्यभार होता है तो इसे बनाए रखना आसान नहीं होता है

यदि आप मांग वक्र को पूरा करने के लिए वीएम को चालू और बंद कर रहे हैं - तो आपके आर्किटेक्चर में कुछ गंभीर रूप से गलत है

क्या आपके साथ कभी ऐसा हुआ कि स्टैकओवरफ़्लो पूरी दुनिया की सेवा के लिए ~8 समर्पित सर्वरों का उपयोग कैसे करता है और वैश्विक ग्राहक मांग को पूरा करने के लिए वीएम को स्पिन करने और बंद करने की आवश्यकता नहीं होती है?
--
कंप्यूट इंफ्रास्ट्रक्चर की योजना बनाते समय, बुनियादी बातों पर वापस जाना महत्वपूर्ण है और क्लाउड विक्रेता के प्रचार में न पड़ें
ये तो आपने खुद ही कहा. सभी अनुप्रयोगों को पूरी दुनिया की सेवा करने की आवश्यकता नहीं है, इसलिए जब लोग सो जाएंगे तो मांग कम हो जाएगी

यहां तक ​​कि वैश्विक अनुप्रयोगों के साथ भी ऐसे नियम हैं जिनके लिए आपको विशिष्ट क्षेत्रों में एप्लिकेशन और डेटा होस्ट करने की आवश्यकता होती है। एक ऐसे एप्लिकेशन की कल्पना करें जिसका उपयोग यूरोप, ऑस्ट्रेलिया और अमेरिका में ग्राहकों द्वारा किया जाता है। उन्हें क्षेत्रीय डेटा केंद्रों से सेवा प्रदान करने की आवश्यकता है, और एक क्लस्टर अधिकतर तब सो रहा होगा जब दूसरा चल रहा होगा (समयक्षेत्र के कारण)। समर्पित सर्वर के साथ आप अपने संसाधनों का 60-70% बर्बाद कर देंगे, जबकि EC2/Fargate जैसी किसी चीज़ का उपयोग करके आप अपने क्षेत्र के निष्क्रिय होने पर लगभग 0 तक स्केल कर सकते हैं

पागलपन का एक तरीका है, यहां इसे "नौकरी-सुरक्षा-संचालित विकास"कहा जाता है

क्योंकि ये उनकी नौकरी के लिए ख़तरा है

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

इसके लिए मैं अपने शयनकक्ष में थोड़ी रास्पबेरी पाई 400 का भी उपयोग करता हूं

httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..

अब लगभग एक दशक से मैंने अपना सामान स्वयं होस्ट किया है। किसी ने भी मेरे सेटअप को DDoSing करने का प्रयास नहीं किया है, क्योंकि वे ऐसा क्यों करेंगे? इससे उन्हें संभवतः क्या लाभ होगा? मैं लगभग एकमात्र प्रभावित व्यक्ति होता, और एक बार जब वे रुक जाते तो उन्हें ठीक होने में अधिक समय नहीं लगता

व्यक्तिगत बॉक्स DDoS के लिए बहुत कम या कोई प्रोत्साहन नहीं है, इंटरनेट रैंडो की तो बात ही छोड़ दें

आप एक किशोर की क्षमताओं को अत्यधिक महत्व दे रहे हैं

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

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

तकनीकी रूप से मेरा होमलैब एक स्थिर सार्वजनिक आईपी पर भी है - यह "वास्तव में आवश्यक"की तुलना में "क्या मैं ऐसा कर सकता हूं"पर अधिक अभ्यास था, लेकिन यह अभी भी अच्छा है और मैं बहुत खुश हूं

एकमात्र हैंगअप के बारे में मुझे सुरंग को जीवित रखने के लिए वायरगार्ड को कॉन्फ़िगर करना पड़ा, अन्यथा कभी-कभी वीपीएस को आने वाला ट्रैफ़िक प्राप्त होता था और यदि मेरी प्रयोगशाला थोड़ी देर में नहीं पहुंचती (जो, ऐसा क्यों होगा?) तो सुरंग बंद हो जाती, और प्रॉक्सी कनेक्शन होगा. शुक्र है कि यह अंतर्निहित कार्यक्षमता है

तो, ऐसा लगता है कि जेकिल या गिटहब पेज साइट पर आरएसएस/एटम फ़ीड जोड़ना बहुत सीधा है

1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..

3. httpspages.github.com/versions/
एटम 2सी/4टी, 4जीबी रैम, 1टीबी ड्राइव, 100एमबीटी
इस बिंदु पर कुछ वर्षों का अपटाइम
यदि निर्बाध: कुछ उन्नयन देय हो सकता है।
कर्नेल सुरक्षा अद्यतन एक चीज़ है


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

बिल्कुल। ये $10 से कम के वीपीएस उदाहरण छोटी परियोजनाओं के लिए बहुत अच्छे हैं जहां आप लंबे अनुबंध में प्रवेश नहीं करना चाहते हैं या अपने स्वयं के सर्वर का प्रबंधन नहीं करना चाहते हैं

यदि आप एक वास्तविक व्यवसाय चला रहे हैं, जहां मार्जिन बहुत कम है और आपके पास सर्वर संबंधी समस्याओं को संभालने के लिए दुनिया का सारा खाली समय है, यदि (जब) ​​वे सामने आती हैं, तो उन ~$50 समर्पित सर्वरों का पता लगाना दिलचस्प हो सकता है।

लेकिन यदि आप एक वास्तविक व्यवसाय चला रहे हैं, तो $10,000/माह का AWS बिल भी आपके समर्पित सर्वर को प्रबंधित करने में मदद करने के लिए किसी अन्य कुशल डेवलपर को काम पर रखने से सस्ता है।

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

उह, क्षमा करें लेकिन आप इस DevOps आदमी को कितना भुगतान कर रहे हैं? यह बिल्कुल अमेरिकी परिप्रेक्ष्य जैसा लगता है, यहाँ तक कि घाटी क्षेत्र भी। यूरोप में, एक आदमी को काम पर रखना सस्ता होगा

पूरी तरह से भरी हुई रोज़गार लागत आपके वेतन के रूप में घर ले जाने वाली लागत से काफी अधिक है। यूरोप में यह वास्तव में बदतर है। इन चार्टों पर एक नज़र डालें: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
यदि आप यूके में किसी को 1000 यूरो का भुगतान करते हैं, तो कंपनी को कुल 1245 यूरो का खर्च आता है

यदि आप रोमानिया में किसी को 1000 यूरो का भुगतान करते हैं, तो कंपनी को कुल 1747 यूरो का भुगतान करना पड़ता है

तो $120,000 की पूरी लागत आपको केवल $68,000 USD वेतन पर खरीद सकती है, जो कि EU के एक व्यक्ति के लिए है।

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

मैं तुम्हें लगभग 3 घंटे में फंसा सकता हूँ

AWS अन्य सेवाओं (S3, SES, SQS, आदि) के लिए बहुत लागत प्रभावी है लेकिन वर्चुअल मशीनें अच्छा सौदा नहीं हैं। आपको कम रैम मिलती है& सीपीयू, वर्चुअलाइजेशन ओवरहेड के साथ, और बहुत अधिक पैसे का भुगतान करता है

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

हो सकता है कि अपना खुद का बुनियादी ढांचा बनाने में सक्षम होने का सिस्टम एडमिन कौशल एक खोई हुई कला बनता जा रहा है, अन्यथा मैं यह नहीं समझा सकता कि लोग कम प्रदर्शन के लिए 5 गुना भुगतान करने के इतने शौकीन क्यों हैं

हेट्ज़नर यूरोप में सस्ता और विश्वसनीय है, यदि आप उत्तरी अमेरिका में हैं तो ओवीएच पर एक नज़र डालें। विशेष रूप से उनका लागत-बचत विकल्प जिसे SoYouStart कहा जाता है। आप $65 में 4/8 4.5GHz, 64 रैम और एक NVME ड्राइव प्राप्त कर सकते हैं

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

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

जहां तक ​​प्रतिकृति, बैकअप आदि की बात है, मैंने वह सब सेट किया, और ईमानदारी से कहूं तो यह कोई बड़ी बात नहीं थी। यह पोस्टग्रेज़ पुस्तक में कुछ छोटे अध्याय हैं जो यह सब बहुत सरलता से समझाते हैं, कैसे कॉन्फ़िगर करें, लगातार (और स्वचालित रूप से) परीक्षण करें, आदि।

मैं इस बात से सहमत हूं कि SAN एक दुःस्वप्न है। यही कारण है कि मैं अपने सभी वाल (पीजी बैकअप फ़ाइलें) को एस3 (और अंततः ग्लेशियर) पर भेजता हूं। इस तरह मुझे उन फ़ाइलों को खोने के बारे में सोचने की ज़रूरत नहीं है और यह बहुत सस्ता है

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

स्व-सेवा बुनियादी ढांचे के तेजी से व्यवहार्य होने की संभावना प्रतीत होती है क्योंकि हम अंतिम मील वितरण में सुधार जारी रखते हैं और फाइबर पहुंच का विस्तार करते हैं। क्या बादल स्वयं-नरभक्षी बन जायेंगे? निश्चित रूप से हो सकता है

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

httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..

संपादित करें: यदि कोई स्वयं-होस्टिंग में रुचि रखता है, तो क्लाउडफ्लेयर के साथ यह सरल है। मेरे पास 2017 Google Pixelbook है जो कस्टम फर्मवेयर पर उबंटू चला रहा है जो फ्लास्क-आधारित वेबसाइट पर काम कर रहा है। अतिथि वाईफाई नेटवर्क से कनेक्ट होने पर मैं अपने डेस्क को चार्ज कर रहा हूं। यह 100/100 मोबाइल पेजस्पीड स्कोर प्राप्त करता है और पूरी तरह से लोड होने में 0.8 सेकंड लेता है

डीओ से मुझे एक विश्वसनीय कंपनी, स्केलेबिलिटी, स्वचालित बैकअप इत्यादि के सभी लाभ मिलते हैं। कोई रास्ता नहीं है कि मैं बदलूं

हेट्ज़नर क्लाउड में अब दो अमेरिकी स्थान हैं, फिर भी कोई अमेरिकी समर्पित सर्वर नहीं है - वे वास्तविक होंगे। भले ही उनकी वर्तमान क्लाउड पेशकश पहले से ही प्रमुख क्लाउड समकक्षों की कीमत का ~30% हो।

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

हालाँकि, मैं दिसंबर में उनके पास चला गया जब मेरा वर्सावेब उदाहरण हाल ही में समाप्त हो गया, शायद बुढ़ापे से एसएसडी। मैं अब वर्सावेब को भुगतान की गई राशि का 50% भुगतान कर रहा हूं, और मैं ऐसे 6 पोस्टग्रेज इंस्टेंसेस चला सकता हूं

फिर यह आश्चर्यचकित करता है कि फैंसी क्लाउड यूआई, स्वचालित अपग्रेड और बैकअप इत्यादि के साथ प्रबंधित सेवा के लिए $800 में से $700 का भुगतान करना उचित है या नहीं।

1 व्यक्ति शो या छोटे स्टार्टअप के लिए, मुझे नहीं लगता। उपलब्ध सेवा का उपयोग करना और बैकअप को S3 या कुछ सस्ते में डंप करना सस्ता है

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

वहां एक अंतर्निहित लागत है. यदि यह उनमें से केवल एक या दो चीजें हैं, तो केवल प्रबंधित सेवाएं लें

यदि आप स्केल करना शुरू करते हैं, तो इस पर बचत करने के लिए एक प्रशासक प्रकार का कर्मचारी प्राप्त करें
अन्यथा, मुझे किसी बहुत अनुभवी व्यक्ति को नियुक्त/अनुबंधित करना होगा, या अपने समय का एक ठोस महीना या अधिक समर्पित करना होगा (जो उपलब्ध नहीं था), बस 100% सुनिश्चित करने के लिए कि हम हमेशा जर्नल किए गए पीआईटीआर बैकअप को जल्दी से बहाल कर सकते हैं

मैं अन्य स्थानों पर क्लाउड लागत के परिमाण को बचा सकता हूं, लेकिन विश्वसनीय रूप से प्रबंधित PostgreSQL एक बहुत आसान कॉल था (भले ही प्रवेश स्तर का मूल्य टैग आपकी अपेक्षा से अधिक था)

एक प्रारंभिक स्टार्टअप जो एक घंटे का उत्पादन डेटा खोने का जोखिम नहीं उठा सकता, संभवतः जीवित रहने के लिए बहुत नाजुक है

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

(मैं जिस विशिष्ट स्टार्टअप के बारे में सोच रहा था, उसमें मेरे पास पहले से ही कुछ अच्छे स्वचालित डीबी-ऑनलाइन डंप थे, जो कि रिटेंशन लागू होने के साथ एस3 में थे, लेकिन मुझे नहीं लगता था कि यह इस विशेष परिदृश्य के लिए पर्याप्त था। लेकिन मुझे यकीन नहीं है कि हम इससे उबर पाएंगे। पीआईटीआर/जर्नलिंग एक व्यवसाय की सफलता पर विफलता का एक नया एकल बिंदु जोड़ देगा जो अन्यथा कुछ सौ बचाने के लिए कुछ/कई वर्षों में 9+ अंक से बाहर निकल सकता है।)
साथ ही, मेरा मानना ​​है कि कुछ शुरुआती स्टार्टअप जिनकी आवश्यकताएं कम हैं, लेकिन ग्राहकों/उपयोगकर्ताओं के डेटा के प्रति अपने दायित्वों के बारे में सतर्क हैं, वे अभी भी न्यूनतम बुनियादी प्रथाओं के प्रति लापरवाही बरत रहे हैं।

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

मैं इसे अंत में संबोधित करूंगा

>एचएन पर एक बिज़ न्यूज़ स्टोरी की कल्पना करें, जिसमें कुछ स्टार्टअप ऑपरेशंस की गेंद गिर रही है, जिसमें स्टार्टअप संस्थापकों के नाम संलग्न हैं, और कहानी कहती है और यह पता चलता है कि उनके पास अच्छे बैकअप नहीं थे

ITIM और यह पता चला कि उनके पास अंतिम घंटे का बैकअप नहीं था
मैं आपके परिदृश्य में हर चीज की कल्पना कर सकता हूं, यहां तक ​​​​कि अनस्निप्ड बिट्स भी, और यह सब सामान्य लगता है, जब तक कि आप यह न पढ़ें "हमारे स्टार्टअप क्लाइंट, जो एक महीने से हमारा उपयोग कर रहे थे, जब हमने उनका डेटा का आखिरी घंटा खो दिया तो सभी तुरंत चले गए"मैं सचमुच उस परिदृश्य की कल्पना नहीं कर सकता

अब, मान लिया गया है, कुछ व्यवसाय ऐसे हैं जहां इसका उपयोग करने का लाभ यह है कि एक घंटे का भी डेटा नष्ट नहीं होता है
IOW, ग्राहक इसका उपयोग करते हैं क्योंकि इससे कोई डेटा नहीं खोएगा: ऑनलाइन दस्तावेज़ सहयोग[1], उदाहरण के लिए[2]। यदि आपके पास एक मेल्टडाउन है जिसमें अंतिम इनपुट डेटा का एक घंटा खो जाता है, तो निश्चित रूप से, उम्मीद करें कि सभी प्रभावित वर्तमान उपयोगकर्ता तुरंत भाग जाएंगे

[1] हालाँकि, व्यक्तिगत रूप से, मैं वर्तमान दस्तावेज़ को संपादित करते समय लोकलस्टोरेज में डुप्लिकेट करके जोखिम को कम करूँगा

[2] शायद स्टॉक एक्सचेंज को भी आखिरी घंटे का डेटा रखने के लिए सिस्टम की जरूरत है? और क्या?
मुझे लगता है कि बड़ी टीमों के लिए भी डेटाबेस को स्वयं प्रबंधित करना सार्थक हो सकता है, यह मानते हुए कि आपके पास इसे अच्छी तरह से करने की क्षमता है। ऐसी बहुत सी चीजें हैं जो प्रबंधित सेवाओं के साथ गलत हो सकती हैं और वे अंतर्निहित कार्यान्वयन को उस तरह से नहीं छिपाते हैं जैसे ब्लॉक स्टोरेज या ऑब्जेक्ट स्टोरेज जैसी चीजें छिपाती हैं।

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

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

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

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

उदाहरण के तौर पर, आप अतिरेक के लिए अलग-अलग कोलो सुविधाओं में चार पूरी तरह से अधिक प्रावधानित $100k भौतिक 1यू मशीनों के एक अविश्वसनीय रूप से सक्षम समूह को तैनात कर सकते हैं। XYZ क्लाउड सेवा, DNS, एनीकास्ट, जो भी आप चाहते हैं, के साथ लोड संतुलन और फेलओवर के लिए यहां सभी प्रकार की तरकीबें हैं। आप विभिन्न कोलो सुविधाओं के साथ जा सकते हैं जो दुनिया भर में डेटासेंटर संचालित करते हैं, हार्डवेयर को विक्रेता से उनके पास भेजते हैं, फिर सुविधा को देखे बिना या हार्डवेयर को छुए बिना उन्हें Ansible या जो भी आप पसंद करते हैं, उसके साथ प्रावधान करते हैं।

तो अब आपके पास अनावश्यक भौतिक हार्डवेयर है जो निश्चित रूप से अधिकांश क्लाउड प्रदाताओं (विशेष रूप से I/O के लिए) के चारों ओर सर्कल चलाएगा, आपके सभी बैंडविड्थ की तरह निश्चित लागत (जिसमें क्लाउड सेवाओं का 800% मार्कअप नहीं है, आदि) - अब और इंतजार नहीं करना पड़ेगा अपरिहार्य $50k क्लाउड बिल के लिए या यह पता लगाने की कोशिश कर रहे हैं (घबराहट में) कि किस कारण से आपने एक महीने के बजाय एक दिन में अपने कॉन्फ़िगर किए गए क्लाउड बजट को पार कर लिया। ओह वैसे, आप $BIGCLOUD द्वारा प्रस्तावित वर्चुअल मशीनों के अलावा अन्य सेवाओं का प्रावधान करने और यहां तक ​​कि उनका उपयोग करने के लिए खुद को नासमझ मालिकाना एपीआई में बंद नहीं कर रहे हैं

यदि आप कोई एमएल कर रहे हैं तो आप अपने स्वयं के हार्डवेयर या (या कभी-कभी क्लाउड) पर प्रशिक्षण ले सकते हैं और NVIDIA A10 जैसी चीजों के साथ 24/7 अनुमान चला सकते हैं। GPU उदाहरणों के लिए निरंतर क्लाउड रेंटल अविश्वसनीय रूप से महंगा है और हार्डवेयर खरीदने पर ROI आम तौर पर कुछ महीनों की सीमा में होता है (या धारा 179 के साथ लगभग तुरंत आगे)। उदाहरण के तौर पर, मैंने हाल ही में जिस मॉडल की हम सेवा कर रहे हैं उसके लिए एनवीडिया ए10 के साथ एक बेंचमार्क किया है और यह 10 एमएस से कम विलंबता के साथ एफपी32 में 700 से अधिक अनुमान अनुरोध/एस कर सकता है। चार स्वस्थ उदाहरणों में एक A10 प्रति चेसिस के साथ जो 2800 req/s है (और संभवतः इसे आगे भी ट्यून किया जा सकता है)

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

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

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

[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
अगर मैं कोई नया प्रोजेक्ट बनाना चाहता हूं या कुछ नया होस्ट करना चाहता हूं तो इसमें कुछ मिनट लगते हैं और मुझे स्क्रिप्ट मिल जाती है। तैनाती तेज़ है, रखरखाव कम है, और मेरे पास पैसे के लिए कहीं अधिक है

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

महत्वपूर्ण बात यह है कि किसी भी चीज़ को मैन्युअल रूप से प्रबंधित न करें, जैसे भौतिक सर्वर को किसी अन्य क्लाउड सर्वर की तरह ही व्यवहार करें। इससे कोई फ़र्क नहीं पड़ना चाहिए कि यह भौतिक है या आभासी

मैंने बहुत से कम अनुभवी लोगों को हेट्ज़नर के लिए अधिक भुगतान करते देखा है और इसी तरह जब $5-10 वीपीएस काम करता था

हाँ, आप उस समय अपने स्वयं के हार्डवेयर का समर्थन कर रहे हैं। नहीं, यह कोई बहुत बड़ा सिरदर्द नहीं है

इसकी सबसे बड़ी अतिरिक्त लागत अधिक IPv4 पते किराए पर लेना है, जिसके लिए हेट्ज़नर बहुत अधिक शुल्क लेते हैं क्योंकि अब बहुत कम उपलब्ध हैं

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

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

अधिक जानकारी httpseuropa.eu/youreurope/business/taxation/VT/cross-bor..

Postgres को स्थापित करना और प्रबंधित करना कष्टकारी है। यह सब ठीक करने का एक आसान तरीका अपनाना अच्छा रहेगा

1. कॉन्फ़िगरेशन को प्रतिलिपि प्रस्तुत करने योग्य होने के लिए बाध्य करता है, क्योंकि VM नीचे चला जाएगा

2. दर्द कम करने वाले AWS पर आपको भारी छूट मिल सकती है

3. वीएम के शीर्ष पर आपके पास अन्य सामान तक पहुंच है जो एक बार आपका सामान पहले से ही क्लाउड में होने के बाद सस्ता/तेज़ है
4. लोगों को प्रशिक्षित करने/आपके पास घर में क्या विशेष सामान है, इसका दस्तावेजीकरण करने की तुलना में एक दस्तावेजित सिस्टम कॉन्फ़िगरेशन (उदाहरण के लिए एडब्ल्यूएस दस्तावेज़) रखना आसान है। नए लोगों को काम पर रखने में विशेष रूप से उपयोगी

5. आपको परिसर में स्थान या अनावश्यक बिजली/इंटरनेट/आदि की आवश्यकता नहीं है। बस लोगों को अपना लैपटॉप चलाने देने के लिए पर्याप्त है

मैंने उससे पहले एक वीपीएस का उपयोग किया था, लेकिन बंद कर दिया और भौतिक वीपीएस पर स्विच कर दिया क्योंकि यह एक बेहतर सौदा था और हम सीपीयू सीमा (एशन) में नहीं चले।

हालाँकि डिस्क की निगरानी बहुत कठिन नहीं है। हार्ड ड्राइव के लिए, एक घंटे में एक बार स्मार्टसीटीएल चलाएं, जब पुनः आवंटित या लंबित सेक्टर तेजी से बढ़ते हैं या 100 तक पहुंचते हैं तो अलर्ट करें। एसएसडी के लिए, अपनी उंगलियों को क्रॉस करें; कुछ हज़ार लोगों के साथ मेरे अनुभव में, वे तब तक बढ़िया काम करते हैं जब तक वे बस से गायब नहीं हो जाते, फिर कभी नज़र नहीं आते। एक डेटा पुनर्प्राप्ति योजना बनाएं जिसमें समान मॉडल उपकरणों पर डेटा का भंडारण शामिल न हो, जिसमें घंटों की बिजली पर बहुत समान शक्ति हो, सहसंबद्ध फर्मवेयर त्रुटियां वास्तविक हैं

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

मैं उस समय एक कनिष्ठ डेवलपर था, इसलिए शायद मैं अनभिज्ञ था, लेकिन मैं इसे बिल्कुल भी मिस नहीं करता। सैद्धांतिक रूप से मैं आपकी बात से सहमत हूं, लेकिन Google क्लाउड रन जैसी किसी चीज़ पर डॉकरफ़ाइल को तैनात करना बहुत आसान है। हाँ, मैं अपने स्वयं के वीपीएस के प्रबंधन से अधिक भुगतान कर रहा हूँ, लेकिन मुझे लगता है कि यह बचाए गए विकास घंटों की भरपाई से कहीं अधिक है

- भौतिक हार्डवेयर में परेशानी है, उदा. पंखे की विफलता ->मेरा वीएम एक अलग होस्ट पर लाइव माइग्रेट हो जाता है, मुझे इस पर ध्यान या परवाह नहीं है
- भौतिक हार्डवेयर में विस्फोट ->मेरा वीएम एक अलग होस्ट पर पुनः आरंभ होता है, मैं नोटिस कर सकता हूं लेकिन मुझे परवाह नहीं है
वीएम के साथ आपदा योजना बनाना बहुत आसान है (यहां तक ​​कि पालतू जानवरों के साथ भी, मवेशियों के साथ भी)

एक शुरुआत के लिए, सबसे सस्ते वाले काम पूरा कर देते हैं

मुझे यकीन है कि जैसे-जैसे क्लाउड कंप्यूटिंग विकसित होती है, ये पेशकशें अधिक सामान्य हो जाती हैं

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

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

ऑन-प्रिमाइसेस ऐप्स की लागत लगभग 40% कम है। जो ऐप्स क्लाउड में अधिक लागत प्रभावी हैं वे वहां बने रहते हैं

मुझे लगता है कि मामला यह है कि यूरोप में AWS/GCP/Azure बहुत अधिक लागत-प्रतिस्पर्धी पेशकश नहीं हैं। जो मैं नहीं देख रहा हूं वह अमेरिका के लिए इसका सबूत है

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

किसी भी स्थिति में बैकअप रखें. अधिमानतः किसी अन्य प्रदाता पर या कम से कम किसी भिन्न भौतिक स्थान पर। और, निःसंदेह, उनका परीक्षण करें

और यदि आप एक अच्छी बैकअप व्यवस्था का प्रबंधन कर रहे हैं, और किसी भी तरह अपने डेटा/ऐप की निगरानी कर रहे हैं, तो क्या निगरानी ड्राइव एक महत्वपूर्ण अतिरिक्त कठिनाई है?
--
[1] वास्तव में यदि आप पुनर्स्थापना प्रक्रिया को किसी अन्य स्थान पर स्वचालित करते हैं, जो मैं अपने कुछ बिट्स के लिए करता हूं, तो आप बस उस बटन को दबा सकते हैं और पूरा होने पर DNS को अपडेट कर सकते हैं, और शायद थोड़ा और रैम + कोर आवंटित कर सकते हैं (मेरा परीक्षण) दर्पण लाइव वीएम से छोटे होते हैं क्योंकि उन्हें वास्तविक उपयोग पैटर्न पेश करने की आवश्यकता नहीं होती है)

बिल्कुल वही जो मैं अपने और अपने ग्राहकों के लिए करता हूं। ढेर सारा दोष बचाता है

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

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

दूसरे शब्दों में, एकमात्र अंतर यह है कि उत्तरदायी इन्वेंट्री फ़ाइल कहां से आती है। या तो यह आईपी की एक स्थिर सूची है, या यह टेराफ़ॉर्म से आती है

यदि आप ईसीसी रैम चाहते हैं, तो यह 60/माह प्रतीत होता है, और यह अधिक शक्तिशाली 8-कोर सीपीयू तक भी जाता है

भले ही, अगर हम "पूर्ण उत्पादन वातावरण और डुप्लिकेट स्टेजिंग/स्टैंडबाय वातावरण"(जिस व्यक्ति को आपने उत्तर दिया है उसे उद्धृत करने के लिए) के बारे में बात कर रहे हैं, तो किसी भी स्टार्टअप के एडब्ल्यूएस की तुलना में 60/माह * (2 या 3) अभी भी बहुत सस्ता है। बिल जो मैंने देखा है

उपयोग के मामले अलग-अलग होते हैं, लेकिन मैं इस बात से सहमत हूं कि AWS/GCP/Azure हर समस्या का उत्तर नहीं है

किसी ऐसे व्यक्ति के लिए जो अपने एप्लिकेशन को $4 वीपीएस पर फिट कर सकता है, यह स्पष्ट रूप से किसी भी साधारण धातु से सस्ता होगा, लेकिन कई मामलों में क्लाउड बहुत महंगा हो जाता है। बेअर मेटल हर समस्या का समाधान नहीं है, लेकिन उद्योग में बहुत से लोग इस बात की सराहना नहीं करते कि यह कब सही उत्तर हो सकता है।