AWS से bare metal पर माइग्रेट किए 2 साल: AWS छोड़ने पर उठे सवालों के जवाब

 (oneuptime.com)
16 पॉइंट द्वारा GN⁺ 2025-10-30 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • 2 साल पहले AWS से bare metal पर माइग्रेट करके सालाना $230,000 की बचत करने के अनुभव साझा करने के बाद, कम्युनिटी के विभिन्न सवालों पर फॉलो-अप जवाब संकलित की गई यह रिपोर्ट 2 साल के वास्तविक ऑपरेशन डेटा को सार्वजनिक करते हुए सालाना $1.2M से अधिक की बचत हासिल करने की बात कही गई है
  • वास्तविक संचालन के साथ बचत बढ़कर सालाना $1.2M से अधिक हो गई, और इसे AI-आधारित incident summary और automatic code fix के लिए server निवेश में दोबारा लगाया गया, जिससे सेवा गुणवत्ता बेहतर हुई
  • MicroK8s + Ceph stack के आधार पर 99.993% availability बनाए रखी गई, और dual data center configuration से single point of failure हटाया गया
  • वास्तविक ऑपरेटिंग लागत, outage response, hardware lifespan, security certification, cloud replacement services जैसे मुख्य मुद्दों को ठोस संख्याओं के साथ समझाया गया है
  • नतीजतन स्थिरता और cost efficiency दोनों में सुधार हुआ, और एक निश्चित पैमाने से ऊपर के लगातार लोड वाले सिस्टम के लिए Bare Metal अधिक तर्कसंगत होने का निष्कर्ष दिया गया

2 साल के संचालन परिणामों का सारांश

  • 24 महीनों तक MicroK8s + Ceph stack को production environment में चलाकर 99.993% availability हासिल की गई
    • single rack समस्या को खत्म करने के लिए Frankfurt में दूसरा rack जोड़ा गया, और Paris के main rack के साथ DWDM dual connection बनाई गई
    • local NVMe और noise interference हटाने से customer latency में 19% की कमी आई
  • बचाई गई लागत को bare metal AI server खरीदने में दोबारा निवेश किया गया, जिससे OneUptime की LLM-आधारित alert summary और automatic code fix features का विस्तार हुआ

बचत और लागत तुलना

  • शुरुआती अनुमानित बचत सालाना $230,000 थी, लेकिन अब यह बढ़कर $1.2M से अधिक हो गई है
    • यह AWS की तुलना में लगभग 76% की बचत के बराबर है
    • वैश्विक वेतनमान के हिसाब से यह 2~5 engineers के सालाना वेतन के बराबर है
  • Savings Plans / Reserved Instances लागू करने पर भी Bare Metal अब भी फ़ायदे में है
    • Savings Plans, S3·Egress·Direct Connect लागत पर लागू नहीं होते
    • EKS control plane लागत $1,260/माह, NAT gateway $600/माह जैसी लागत भी कम नहीं की जा सकती
    • 24/7 steady workload होने के कारण reserved instance efficiency सीमित रही

माइग्रेशन और संचालन लागत

  • शुरुआती माइग्रेशन लगभग 1 हफ़्ते के engineering work में पूरा हुआ
    • IaC सुधार, backup policy मज़बूत करना जैसे ज़्यादातर काम वैसे भी पहले से ज़रूरी थे
  • मौजूदा ऑपरेटिंग लागत इस प्रकार है:
    • direct management: प्रति quarter लगभग 24 घंटे (patches·firmware update शामिल)
    • Remote Hands: 24 महीनों में केवल 2 बार दखल की ज़रूरत पड़ी (मुख्यतः disk issues), औसत response time 27 मिनट
    • automation: PXE boot (Tinkerbell), Talos image management, Flux/Terraform configuration automation
  • संचालन टीम में AWS के समय की तुलना में उल्टा release speed बढ़ी, और “cost optimization meetings” का बोझ भी खत्म हुआ

outage preparedness और availability सुनिश्चित करना

  • Frankfurt में दूसरा rack जोड़कर, DWDM dual-path connection से single point of failure हटाया गया
    • asynchronous replication-आधारित Ceph mirroring और dual control plane configuration
    • 4G/satellite-आधारित management path जोड़कर network outage के समय remote access संभव किया गया
  • MicroK8s → Talos में migration जारी है
  • AWS failover backup cluster अभी भी रखा गया है, और quarterly disaster recovery rehearsal की जाती है
  • Anycast+BGP-आधारित Ingress से DNS switchover delay भी 1 मिनट से कम हो गई
  • 2 साल तक 99.993% availability बनी रही, और हाल की AWS region outage का असर भी नहीं पड़ा

hardware और CapEx management

  • servers को 5-year depreciation आधार पर चलाया जा रहा है (2×EPYC 9654, 1TB RAM, NVMe configuration)
    • performance saturation होने पर उन्हें analytics cluster में शिफ्ट किया जाता है और नए servers लगाए जाते हैं
    • बचत की वजह से अब हर 2 साल में 40% refresh संभव हो गया है, और फिर भी AWS की तुलना में सालाना लागत कम है
  • Supermicro warranty extension + 3 spare servers रखे गए हैं
    • वास्तविक lifespan 7~8 साल है, लेकिन हिसाब के लिए सावधानी से 5 साल माना गया है

managed services के विकल्प की तर्कशक्ति

  • OneUptime की product philosophy self-hosting capability पर आधारित है, इसलिए वही stack बनाए रखना ज़रूरी है
    • Kubernetes·Postgres·Redis·ClickHouse जैसी open stack consistency बनाए रखी गई
  • Terraform + EKS + RDS → MicroK8s + Argo Rollouts + Ceph की ओर विकास हुआ
    • बिना किसी internal fork के plain open source का उपयोग
  • अब भी cloud का parallel use जारी है: AWS Glacier (backup), CloudFront (edge caching), load testing के लिए temporary instances
  • cloud elasticity-केंद्रित, जबकि bare metal base load-केंद्रित उपयोग के लिए उपयुक्त है

network और security

  • 5Gbps(95th percentile) की 2 links उपलब्ध हैं, जो AWS egress की तुलना में 8 गुना सस्ती हैं
  • DDoS सुरक्षा Cloudflare को front में रखकर संभाली गई
  • स्वतंत्र 4G/satellite-आधारित management network से outage के समय remote access संभव है

compliance और audit response

  • SOC 2 Type II, ISO 27001 certification बनाए रखी गई
    • colocation center के Tier III certification·access logs·CCTV डेटा का उपयोग किया गया
    • Terraform/Talos configuration logs को change history evidence के रूप में उपयोग किया गया
  • auditors ने AWS console screenshots की तुलना में इन्हें अधिक विश्वसनीय माना

cloud alternatives की तुलना

  • Hetzner, OVH, Leaseweb, Equinix Metal, AWS Outposts की तुलना की गई
    • Hyperscaler में egress लागत अब भी अधिक है
    • यूरोपीय hosts के लिए बड़े Ceph cluster और SLA आवश्यकताओं को पूरा करना कठिन था
    • Equinix Metal में CapEx की तुलना में 25~30% premium था
    • अपना hardware चलाना power density·upgrade flexibility के लिहाज़ से बेहतर रहा
  • नतीजतन 15kW rack configuration और components के पुन: उपयोग की संभावना की वजह से colocation लागत और performance दोनों में बेहतर रहा

operational burden (TOIL) का मापन

  • साप्ताहिक: kernel/firmware patch और Ceph checks (1 घंटा)
  • मासिक: Kubernetes control plane canary upgrade (2 घंटे)
  • quarterly: DR drill, capacity planning, telecom contract review (12 घंटे)
  • कुल मिलाकर महीने में लगभग 14 घंटे, जो AWS के समय के समान है, लेकिन फ़ोकस “cost tracking” से “operations automation” पर शिफ्ट हो गया

जहाँ cloud अब भी सही विकल्प है

  • जब workload spiky या seasonal pattern वाला हो
  • जब Aurora Serverless, Kinesis, Step Functions जैसी managed services पर निर्भरता अधिक हो
  • जब Kubernetes·Ceph·monitoring·incident response को खुद चलाने की क्षमता न हो
  • यानी शुरुआती चरण या बड़े variable load वाले business के लिए अब भी cloud की बढ़त मौजूद है

आगे की योजना

  • Colo budget forecasting के लिए Terraform module और Runbook जारी करने की योजना
  • Talos-आधारित संचालन अनुभव पर एक गहरा technical post भी तैयार किया जा रहा है
  • HN·Reddit feedback का जवाब देते हुए वास्तविक संख्याओं पर आधारित केस शेयरिंग जारी रखने की योजना

संबंधित पढ़ाई

3 टिप्पणियां

 
okxrr 2025-10-30

मैं ऐसी कंपनी में काम करता हूँ जो AWS के प्रति बेहद उत्साही है, जबकि हम AWS-विशेष कोई भी service बिल्कुल इस्तेमाल नहीं करते।

यह एक कड़वी-मीठी कहानी है कि इस फैसले पर कुछ leaders की career development जैसी बेहद निजी महत्वाकांक्षा का बड़ा असर पड़ता हुआ मैंने देखा है..
 
GN⁺ 2025-10-30
Hacker News राय

  • AWS बहुत महंगा है। पूरी सिस्टम को पूरी तरह AWS पर चलाने की ज़रूरत जितनी समझी जाती है, उतनी कम ही होती है। पहले लोग खुद bare-metal server चलाना जानते थे, लेकिन अब जैसे वह कौशल भूल गए हैं। हमारी टीम ने 730 दिनों से ज़्यादा समय तक 99.993% availability बनाए रखी, और हाल की AWS region outage से भी बचे रहे। DDoS defense के लिए हम Cloudflare का इस्तेमाल करते हैं, लेकिन यह समझ में आता है कि DNS या ingress management एक full-time काम बन सकता है। फिर भी, कुछ microservices और एक DB जैसी चीज़ें खुद चलाना पूरी तरह संभव है। AWS ज़्यादातर कंपनियों के लिए जरूरत से ज़्यादा महंगा पड़ता है

    • AWS की असली समस्या कर्मचारियों का AWS पर निर्भर हो जाना है। AWS certification लेना, AWS Well Architected Framework के हिसाब से चलना—इस माहौल में लोग खुद सोचना बंद कर देते हैं। AWS की lock-in services को जानबूझकर सस्ता दिखाया जाता है, लेकिन आखिर में वे आपको और गहराई से बाँध देती हैं। उदाहरण के लिए, PostgreSQL से DynamoDB पर जाना short term में बचत जैसा लग सकता है, लेकिन long term में AWS dependency बढ़ती है
    • On-premise सस्ता है, लेकिन कुशल लोगों को ढूंढना मुश्किल है। साधारण products के लिए यह अच्छा बैठता है, लेकिन जटिल systems में labor cost और operational risk उल्टा बढ़ सकते हैं। AWS/Azure/GCP परफेक्ट नहीं हैं, लेकिन आजकल on-premise experts बहुत दुर्लभ हैं
    • AWS की आलोचना करो तो अजीब तरह से रक्षात्मक लोग सामने आ जाते हैं। Reddit पर भी ऐसा ही दिखता है। ऐसा लगता है जैसे कोई पैसे लेकर AWS का बचाव कर रहा हो
    • Self-hosting की success stories में confirmation bias होता है। शुरुआत में अपने server चलाना अच्छा लगता है, लेकिन एक साल बाद documentation और actual config अलग हो जाते हैं, और जिम्मेदार व्यक्ति नौकरी छोड़ दे तो अराजकता बढ़ जाती है। आखिरकार बहुत-से startups फिर AWS पर लौट आते हैं। ऐसी विफलता की कहानियाँ कम ही साझा की जाती हैं
    • Bare metal ठीक से चलाने के लिए अनुभवी engineers चाहिए। नए लोग या consulting company से आए “cloud experts” के भरोसे यह आसान नहीं है

  • शुरुआती cloud सरल और cost-effective services से शुरू हुआ था, लेकिन अब वह 200 से ज़्यादा जटिल services के जाल में उलझ चुका है। ठीक से manage न करो तो बिल फट पड़ता है

    • सच तो यह है कि AWS की शुरुआत से ही मुख्य बात “सस्ता” नहीं बल्कि “तेज़ी से scale कर पाना” थी। 2010 के शुरुआती दशक में भी यह महंगा था, लेकिन flexibility इसकी ताकत थी। आज भी performance के मुकाबले इसकी कीमत ऊँची है। अगर server management की बुनियादी समझ हो, तो dedicated server कहीं बेहतर है
    • AWS अब 200 से ज़्यादा services तक फैल चुका है। इसे बुनियादी चीज़ों पर ध्यान देना चाहिए
    • AWS console में हर बार जाने पर जटिलता और थकान महसूस होती है। यह बहुत फूला हुआ हो गया है
    • AWS की हर service की value-for-money अलग-अलग है। खासकर पुरानी core services अब भी काफ़ी उपयोगी हैं

  • AWS का असली काम है (1) organization scaling और power structure को संभव बनाना, (2) CapEx की जगह OpEx के रूप में accounting करना, (3) अक्षम staffing structure को छिपाना। पहले 5–10 लोग एक datacenter चला सकते थे, अब 3000 लोगों की DevOps organization बन जाती है

    • OpEx बनाम CapEx का फ़र्क इतना महत्वपूर्ण क्यों है, समझ नहीं आता। आखिर पैसा तो पैसा ही है, है ना?
    • Cloud शुरुआती startups के लिए उपयोगी है। Capacity planning की चिंता के बिना जल्दी बढ़ सकते हैं। लेकिन जिन कंपनियों की growth rate कम है, उनके लिए लंबे समय तक cloud पर बने रहना अक्षम हो सकता है
    • On-premise में customization इतना ज़्यादा होता है कि लोगों की जगह बदलना मुश्किल हो जाता है। जबकि AWS skill वाले लोग हर जगह मिल जाते हैं
    • अनुभवी sysadmins सच में मिलना मुश्किल और महंगे होते हैं। सस्ता करने की कोशिश में मैंने ऐसे मामले भी देखे हैं जहाँ 2 साल से backup ही नहीं हुआ था

  • इस सफलता की कुंजी 24/7 स्थिर लोड है। असल में ज़्यादातर कंपनियों का pattern भी लगभग ऐसा ही होता है

    • सच कहें तो शुरुआत में एक rack, एक datacenter से शुरू कर पाना किस्मत की बात थी। Reliability की लागत पहले से नहीं चुकानी पड़ी
    • संबंधित लेख: One Big Server
    • AWS अक्सर “stock नहीं है” जैसा कहकर reserved instances की ओर धकेलता है। आखिर में यह लगातार चलने वाली लागत के लगभग बराबर पड़ता है
    • Hetzner जैसी जगहें AWS से 10 गुना सस्ती में वही performance देती हैं। Cloud की “elasticity” काफी हद तक बढ़ा-चढ़ाकर पेश किया गया मिथक है

  • Elasticity बनाम base load ही असली मुद्दा है। Data collection जैसे कामों में, जहाँ traffic अचानक बहुत बढ़ता है, वहीं cloud फ़ायदेमंद है। बाकी अधिकांश मामलों में bare metal बेहतर है

  • 2010 के दशक में hardware और network धीमे थे, लेकिन अब CPU performance और efficiency सैकड़ों गुना बढ़ चुकी है। जो काम पहले 64 servers करते थे, अब 1 server काफी है। आगे चलकर यह अनुपात 100:1 तक जा सकता है। ऐसी स्थिति में cloud के फायदे लगातार घटते जाते हैं

  • Amazon के कर्मचारी के रूप में मेरे हिसाब से, Kubernetes को खुद manage करना बहुत जोखिमभरा है। etcd जैसे components अस्थिर होते हैं, और हमें खुद patch भी करना पड़ता था। लेख में self-hosting के जोखिम को कम करके दिखाया गया है

    • दूसरे hyperscalers में भी Kubernetes management failures की वजह से बड़े outages हुए हैं। Microk8s जैसी single-rack के लिए सरल alternatives बेहतर हैं। संबंधित लेख: Microk8s 6 Months Later
    • जटिल environments कहीं भी कठिन होते हैं, और आखिर में experts की ज़रूरत पड़ती ही है। AWS भी उतना आसान नहीं है। Cloud outage हो जाए तो भी दुनिया चलती रहती है
    • k3 जैसे lightweight versions काफी सरल हैं
    • Kubernetes का उपयोग तभी करना चाहिए जब सचमुच ज़रूरत हो। इसे default बना देना समय और पैसे की बर्बादी है

  • बहुत-से startups शायद AWS की ऊँची लागत के कारण अस्तित्व में ही नहीं आ पाते। उदाहरण के लिए, GeoIP की मुफ्त download सेवा(लिंक) जैसी चीज़ संभव नहीं होती। Cloud धीमा है, और disk latency तथा CPU overcommit गंभीर होते हैं। महीने के 10,000 डॉलर से नीचे तक तो यह ठीक है, लेकिन उसके ऊपर bare metal कहीं ज़्यादा कुशल है

    • Cloud की धीमी performance की आदत पड़ जाने से अजीब normalization होने लगता है। तुलना हमेशा bare metal को आधार मानकर करनी चाहिए

  • जिस कंपनी में मैं काम करता था, उसका traffic कम था, फिर भी वह AWS पर जाना चाहती थी। वजह सीधी थी — resume में AWS जोड़ना। सिर्फ developers नहीं, management भी यही चाहता था। “AWS migration lead” करियर में अच्छा दिखता था। आखिरकार कंपनी बिक गई और office खाली हो गया। अब शायद “AWS से बाहर निकला” भी नया career point बन जाए

    • अगर developers AWS चाहते हैं, तो अगली पीढ़ी AWS के अलावा कुछ जानती ही नहीं होगी। चर्चा पक्षपाती हो जाती है
    • आखिरकार फैसला leadership की इच्छाशक्ति पर निर्भर करता है

  • अंत में असली बात यह है कि आप करना क्या चाहते हैं

    • अगर यह internal use के लिए data-centric website है, तो एक server rack काफी है
    • अगर traffic अनियमित, बहुत बड़ा और cache न हो सकने वाला है, तो cloud फ़ायदेमंद है
    • अगर DNS या ingress जटिल है, तो hybrid approach बेहतर है
    • जैसे-जैसे data का scale बढ़ता है, cloud की long-term depreciation structure ज़्यादा अनुकूल हो सकती है