AWS से bare-metal पर माइग्रेट करके सालाना $230,000 (लगभग 3 करोड़ वॉन) की बचत

• ओपन सोर्स Observability Platform OneUptime ने अपनी infrastructure को AWS से bare-metal solution पर माइग्रेट किया, जिससे resources पर बेहतर नियंत्रण और महत्वपूर्ण वित्तीय बचत हासिल हुई।
• इसके अधिकांश ग्राहक public cloud का उपयोग करते हैं, और cloud outage के दौरान alerting service देने के लिए एक स्वतंत्र data center की आवश्यकता थी।

शुरुआती सेटअप: AWS पर Kubernetes

• Kubernetes cluster अपनाने के लिए AWS की managed Elastic Kubernetes Service (EKS) का उपयोग किया गया।
• OneUptime को Redis, Postgres, Clickhouse, Docker, NodeJS, BullMQ जैसी open source software पर बनाया गया, जो AWS-विशिष्ट नहीं हैं।
• AWS dependency से बचते हुए ग्राहकों को अपने cluster में OneUptime को self-host करने योग्य बनाया गया।

बदलाव: bare-metal पर माइग्रेशन

• तकनीकी उत्कृष्टता की दिशा में bare-metal solution पर जाने का निर्णय लिया गया।
• Colocation facility में Microk8s cluster चलाने का विकल्प चुना गया, जो पिछले अनुभव और भविष्य उन्मुख लक्ष्यों पर आधारित था।
• Microk8s को production environment में भी उपयोग किया जा सकता है, और bare-metal server पर जाने से dedicated resources और performance optimization संभव हुआ।

Kubernetes और Helm की भूमिका

• Cloud से अपने server पर ट्रांजिशन में Kubernetes और Helm ने महत्वपूर्ण भूमिका निभाई।
• Kubernetes application container की deployment, scaling और operation automation के लिए एक open source platform है।
• Helm एक package manager है जो Kubernetes applications की definition, installation और upgrade को सरल बनाता है।

Storage और load balancer

• Bare-metal Kubernetes cluster में volumes के लिए Network File System (NFS) और load balancer के लिए MetalLB का उपयोग किया गया।
• NFS एक distributed file system protocol है, जो client computers को network के जरिए files access करने देता है।
• MetalLB standard routing protocols का उपयोग करने वाले bare-metal Kubernetes clusters के लिए load balancer implementation है।

वित्तीय प्रभाव: सालाना $230,000 से अधिक की बचत

• AWS का उपयोग करते समय मासिक खर्च $38,000 से अधिक था, यानी सालाना $456,000 से ज्यादा।
• Bare-metal पर माइग्रेट करने के बाद colocation partner के single-rack setup का उपयोग किया गया, जिससे मासिक operating cost घटकर लगभग $5,500 रह गई।
• Server cost को 5 साल में amortize करने पर सालाना $230,000 से अधिक की बचत होती है, और इस cost saving से टीम बढ़ाने तथा business के अन्य क्षेत्रों में resources आवंटित करना संभव हुआ।

विचार करने योग्य बातें

• Data का बैकअप दिन में कई बार दो offices में लिया जाता है, और public cloud में भी backup रखा जा सकता है।
• अलग-अलग महाद्वीपों में स्थित दो colocation facilities में multi-location Kubernetes cluster चलाया जा सकता है।
• AWS में एक backup cluster तैयार रखा गया है, जिसे disaster की स्थिति में 10 मिनट के भीतर चालू किया जा सकता है।
• Bare-metal पर जाने के लिए server administrator की नियुक्ति अनिवार्य नहीं है, क्योंकि colocation facility hardware maintenance का अधिकांश काम संभालती है।
• Microk8s केवल development के लिए नहीं, बल्कि production environment में भी उपयोग होता है, और जरूरत पड़ने पर किसी अन्य Kubernetes distribution पर आसानी से स्विच किया जा सकता है।

निष्कर्ष

• AWS जैसी cloud services flexibility और शक्ति देती हैं, लेकिन वे हर कंपनी के लिए सबसे किफायती विकल्प नहीं होतीं।
• Open source technologies का उपयोग और अपने hardware में निवेश करके resources पर नियंत्रण बढ़ाया जा सकता है और operating cost को काफी घटाया जा सकता है।
• हर business की जरूरतें अलग होती हैं, इसलिए माइग्रेशन से पहले व्यापक मूल्यांकन जरूरी है।

GN⁺ की राय

इस लेख का सबसे महत्वपूर्ण बिंदु यह है कि कोई कंपनी cloud service से bare-metal infrastructure पर जाकर नियंत्रण और cost saving, दोनों में बड़ा लाभ पा सकती है। यह लेख इसलिए दिलचस्प है क्योंकि यह ठोस उदाहरण के जरिए दिखाता है कि तकनीकी फैसले वित्तीय परिणामों को कैसे प्रभावित कर सकते हैं। Docker, Kubernetes, Helm और Microk8s जैसी तकनीकों की प्रगति ने ऐसे बदलाव को कुछ साल पहले की तुलना में काफी आसान बना दिया है, और यह तकनीकी चयन के महत्व तथा रणनीतिक दृष्टिकोण के मूल्य को रेखांकित करता है।

[hhcrux]

$230,000... क्या वह रकम कोलोकेशन सर्वरों को संभालने के लिए सिर्फ़ दो एडमिन रखने में ही खत्म नहीं हो जाएगी? पूरी तरह managed services इस्तेमाल करने की वजह ही यही होती है कि उस खर्च को बचाया जा सके।

[gunrok]

वो बात भी सही है, लेकिन फँसाने वाली बात यह है कि AWS engineers के लिए भी हर क्षेत्र के हिसाब से experts चाहिए होते हैं।

[wedding]

रिव्यूज़ ज़्यादातर नकारात्मक लग रहे हैं। संक्षेपित सामग्री को देखें तो किसी वजह से यह थोड़ा बढ़ा-चढ़ाकर कही गई भी लगती है।

[GN⁺]

Hacker News टिप्पणियाँ

• Reserved Instances और Savings Plans का उपयोग करने पर AWS लागत काफ़ी कम की जा सकती है। यह transfer और storage लागत पर भी लागू होता है, और वास्तव में अच्छी-खासी बचत हो सकती है, लेकिन अंतर उतना नाटकीय नहीं होता जितना शुरू में सोचा गया था।
• मौजूदा आर्थिक स्थिति को देखते हुए, बहुत लोग कहते हैं, "हम एक और engineer hire कर सकते हैं", लेकिन यह याद रखना चाहिए कि "हम एक engineer को और बनाए रख सकते हैं"। सवाल यह है कि क्या AWS बनाए रखने के लिए टीम के किसी सदस्य को निकालना पड़ेगा।
• Server rack मैनेज करना उतना बड़ा काम नहीं है जितना बहुत लोग सोचते हैं। Cloud-native engineers अक्सर hardware management सीखने से कतराते हैं।
• अगर cloud services का उपयोग किए बिना सिर्फ virtual machines ही चलानी हैं, तो उसका मूल्य सीमित होता है। बहुत से लोगों के लिए dedicated servers किराये पर लेना सबसे अच्छा business decision हो सकता है। यह EC2 से काफ़ी सस्ता हो सकता है, और अगर आपके पास बड़ी मात्रा में spare capacity हो, तो सामान्य scalability समस्याओं को हल किया जा सकता है।
• Business goals पर ध्यान देना चाहिए और hype में नहीं बहना चाहिए। कुछ मामलों में downtime बड़ा मुद्दा होता है, लेकिन बहुत से business ऐसे हैं जहाँ कुछ मिनट service बंद रहने की लागत, जटिल और महंगे high availability (HA) mechanisms को engineer करने से कहीं कम होती है।
• AWS पर Ferrari खरीदने के बजाय Toyota Camry खरीदें तो बहुत पैसा बच सकता है। ऐसी कहानियाँ अक्सर blog spam होती हैं जहाँ कंपनियाँ दावा करती हैं कि उन्होंने कोई चौंका देने वाला नया hack कर लिया है। हक़ीक़त में वे सिर्फ़ खर्च नियंत्रित करना नहीं जानते और नकदी जला रहे होते हैं।
• अभी कल ही colocation provider खोज रहे थे, इसलिए इतनी जल्दी 230,000 dollar बचाने के दावे पर संदेह है।
• लागत के मुकाबले दक्षता को देखें, तो अगर आपने अपने server management पर 1 person-year की मेहनत नहीं लगाई, तो आपने सही फैसला लिया।
• पोस्ट में details बहुत संक्षेप में दी गई हैं, इसलिए यह तय करना मुश्किल है कि इसमें वास्तव में कोई value है या नहीं।
• Business का मकसद पैसा कमाना है, और पैसा उत्पाद कमाता है, न कि hardware और IT infrastructure management की क्षमता।
• अगर AWS पर सालाना 500,000 dollar खर्च हो रहे हैं, infrastructure अपेक्षाकृत सरल है, और खर्च में बहुत बड़ी बढ़ोतरी की उम्मीद नहीं है, तो cloud से बाहर जाना वास्तव में समझदारी हो सकती है।
• AWS पर सालाना 500,000 dollar खर्च करने की स्थिति में, सिर्फ़ Excel sheet में रकम दर्ज करके एक घंटे समीक्षा करने भर से भी साफ़ बचत के अवसर दिख सकते हैं, और यह काम AWS पर सालाना सैकड़ों हज़ार dollar खर्च करने से पहले ही कर लेना चाहिए था.