एक बड़ा सर्वर इस्तेमाल करें (2022)

 (specbranch.com)
34 पॉइंट द्वारा GN⁺ 2025-09-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बहस का असली मुद्दा monolithic vs microservices नहीं, बल्कि यह निर्णय है कि distributed systems डेवलपमेंट/ऑपरेशंस ओवरहेड के मुकाबले वास्तव में मूल्य देते हैं या नहीं
  • आधुनिक single server में दर्जनों से सैकड़ों cores, TB-स्तर की memory, और दर्जनों से सैकड़ों Gbps I/O होता है, इसलिए अधिकांश web services के लिए इसमें पर्याप्त performance headroom होता है
  • वास्तविक benchmarks दिखाते हैं कि एक ही सर्वर से Nginx 500k RPS, PostgreSQL 70k IOPS, NoSQL 1M IOPS, 4K encoding 75 FPS जैसी उच्च-प्रदर्शन प्रोसेसिंग संभव है
  • cloud का उपयोग करने पर सुविधा और availability बढ़ती है, लेकिन cost premium भी काफी अधिक होता है, इसलिए निवेश के मुकाबले दक्षता का आकलन ज़रूरी है
  • केवल वही स्थिति, जहाँ usage pattern बेहद अधिक उतार-चढ़ाव वाला हो, cloud-native और serverless architecture को cost के लिहाज़ से लाभ देती है
  • लेकिन serverless/mini-VM कॉन्फ़िगरेशन का cost premium बड़ा है, और यदि workload लगातार/पूर्वानुमेय है तो vertical scaling अधिक किफायती है
  • availability का बड़ा हिस्सा primary/secondary (या 2×2) redundancy और अलग-अलग hardware संयोजन से हल किया जा सकता है, और केवल CDN·backup को distributed रूप में खरीदने की रणनीति व्यावहारिक है

अवलोकन: distributed systems के बजाय “एक बड़े सर्वर” का मूल्य

  • “monolithic vs. microservices” बहस का केंद्र distributed systems अपनाने में लगने वाले वास्तविक developer time और cost की उपयोगिता का आकलन है
  • आधुनिक software सर्वर virtualization और कई abstraction layers के ऊपर चलता है, और “serverless” या “bare metal” भी अंततः physical server resources पर ही निर्मित होते हैं
  • आज के सर्वर हमारी सामान्य धारणा से कहीं अधिक performance-to-cost efficient हैं
    • पहले की तुलना में server specs core count, memory bandwidth, PCIe lanes, और NVMe storage के मामले में बहुत बढ़ चुके हैं, और कई services distributed हुए बिना भी target QPS हासिल कर सकती हैं

सर्वर हार्डवेयर की शक्तिशाली performance

  • Microsoft Azure के एक उदाहरण सर्वर में AMD 3rd Gen server CPU के 2 units हैं, कुल 128 cores और 256 threads के साथ
  • एक single server पर 4 TFLOPs स्तर की compute performance संभव है, जो 2000 के शुरुआती दशक के supercomputers से भी अधिक है
  • 16-slot DDR4-3200 RAM, प्रति socket व्यवस्था के साथ अधिकतम 8TB memory scalability, और व्यावहारिक खरीद विकल्पों में 1TB memory भी उपलब्ध है
  • कुल 128 PCIe Gen4 lanes, 30 NVMe SSDs, और 50~100Gbps network cards के साथ high-performance storage और network connectivity संभव है

ऐसे single server से क्या-क्या संभव है (benchmark उद्धरण)

  • 400–800 Gbps video transfer, NoSQL 1M IOPS, PostgreSQL 70k IOPS, Nginx 500k RPS हासिल किए जा सकते हैं
  • Linux kernel 20-second build, x264 4K 75FPS encoding जैसे CPU·memory·I/O-intensive workloads में भी उच्च throughput मिलता है

सर्वर किराये और खरीद की लागत तुलना

  • OVHCloud: 128 cores/512GB RAM वाला सर्वर लगभग $1,318 प्रति माह में किराये पर उपलब्ध
  • Hetzner: 32 cores/128GB RAM सर्वर €140 प्रति माह में देता है, और size के अनुसार कीमत बदलती है
  • AWS का m6a.metal: 96 physical cores/768GB RAM सर्वर $8.29 प्रति घंटा, यानी लगभग $6,055 प्रति माह, इसलिए cloud premium बड़ा है
  • Dell से समान spec वाला सर्वर सीधे खरीदने पर लगभग $40,000 खर्च आता है, और cloud की तुलना में लगभग 8 महीनों में निवेश की भरपाई संभव है
  • यदि वही throughput serverless पर माना जाए, तो instance की तुलना में 5.5x, low-cost hosting की तुलना में 25x cost premium का अनुमान है

distributed systems लोकप्रिय क्यों हुए

  • पहले (लगभग 2010 के आसपास) CPU, memory, और storage performance सीमाओं के कारण बड़े पैमाने की services के लिए कई सर्वरों का संयोजन ज़रूरी था
  • हाल के वर्षों में बड़े single servers, NVMe SSDs, और उच्च memory bandwidth के कारण single-node processing limits बहुत बढ़ गई हैं, लेकिन VM और container units अभी भी छोटे server resources को ध्यान में रखकर डिज़ाइन किए जाते हैं

कब केवल एक बड़ा सर्वर पर्याप्त होता है

  • 10k QPS से कम वाली अधिकांश web services के लिए एक सर्वर पर्याप्त है, और सरल services मिलियन QPS स्तर तक भी जा सकती हैं
  • video streaming में भी control plane को single server पर चलाना व्यावहारिक है, और benchmark व सामान्य performance tables के आधार पर उपयुक्त server size का अनुमान लगाया जा सकता है
  • विशेष परिस्थितियों को छोड़कर, केवल primary server और backup server कॉन्फ़िगरेशन से भी availability पर्याप्त रूप से सुनिश्चित की जा सकती है

“चौड़ाई” से अधिक “ऊँचाई”: बड़े server clusters की बजाय कुछ बड़े सर्वर

  • cluster की ज़रूरत हो तब भी कुछ बड़े सर्वर, बहुत सारे छोटे सर्वरों की तुलना में coordination overhead (O(n)) कम रखते हैं
    • यानी लंबी अवधि में सर्वरों की संख्या कम करके उनकी capacity बढ़ाना अधिक efficient है
  • serverless और short-lived container आधारित setup में overhead ratio विशेष रूप से अधिक हो जाता है
  • कमी यह है कि single point of failure बनता है, लेकिन primary/secondary (अलग DC में) से इसे काफी हद तक कम किया जा सकता है
  • और अधिक मजबूती के लिए 2×2 setup (primary DC में 2 सर्वर + secondary DC में 2 सर्वर) और अलग hardware/manufacturer combinations के ज़रिये correlated failures से बचा जा सकता है
  • rental में server model diversification से एक ही batch के disk/SSD की cascade failure risk घटाई जा सकती है

cloud उपयोग के फायदे और सीमाएँ

  • cloud की ताकत availability, recovery speed, और operational convenience है, और इसके लिए premium cost देना कई बार उचित हो सकता है
    • downtime के बिना, तय cost के भीतर तेज़ restart संभव होता है, और grid की तरह प्रबंधित बड़े resource pool का उपयोग किया जा सकता है
    • rental server providers सस्ते होते हैं, लेकिन quality, network, और premium support के मामले में सीमाएँ हो सकती हैं
  • लेकिन cloud sales अक्सर autoscaling VM, serverless, managed HA DB जैसी vendor-locked architecture की सिफारिश करती है, इसलिए cost और complexity से सावधान रहना चाहिए
  • बड़े पैमाने का traffic संभालना मात्र cloud-native होने का मुख्य कारण नहीं है, क्योंकि एक बड़ा single server भी लाखों concurrent users को संभालने वाले कई उदाहरण रखता है

peak load cost और bursty workload का मानदंड

  • किसी न किसी को peak के हिसाब से capacity तैयार रखनी पड़ती है, इसलिए अंततः peak cost supply chain में कहीं न कहीं वसूली ही जाती है
  • bursty और अस्थायी workloads (जैसे एकमुश्त बड़े simulation) के लिए serverless/autoscale किफायती है, लेकिन लगातार और पूर्वानुमेय load के लिए बड़े सर्वर का स्थायी संचालन अधिक cost-efficient है
  • 1-year commitment/spot/sales negotiation का उपयोग करने पर instance cost और कम हो सकती है, जबकि serverless के मुकाबले premium और बढ़ जाता है

“cloud premium” का मात्रात्मक आकलन

  • AWS Lambda जैसी serverless computing में समान server के मुकाबले 5~30x तक cost premium हो सकता है
  • मान लें: $8.2944/घंटा वाला सर्वर 1k QPS, 768GB RAM देता है; वही throughput यदि Lambda से बदलें तो लगभग $46/घंटा, यानी 5.5x premium होता है
  • OVH rental की तुलना में 25x premium का अनुमान है, और केवल 5% utilization पर भी low-cost hosting, serverless से अधिक किफायती हो जाती है
    • long-term contract, spot instances आदि का उपयोग करने पर premium gap और बड़ा हो सकता है
  • QPS अलग होने पर भी memory-time conversion के आधार पर premium multiple लगभग समान रहता है, और workload size के अनुसार server scaling ही मुख्य बिंदु है

आम आपत्तियाँ और गलतफहमियाँ

  • “cloud में system operations staff की ज़रूरत नहीं होती”: केवल role का नाम Cloud Ops हो गया है; documentation, change tracking, deprecation handling जैसी क्षमताएँ फिर भी चाहिए, इसलिए labor cost बढ़ सकती है
  • “cloud में security updates की ज़रूरत नहीं”: कुछ मामलों में छूट मिलती है, लेकिन यह केवल आसानी से automated क्षेत्रों तक सीमित है; library audit और configuration verification अब भी ज़रूरी हैं
  • “cloud की high availability design से निश्चिंत रहा जा सकता है”: बढ़ी हुई complexity नई vulnerabilities पैदा करती है, और region/provider redundancy भी correlated failures को पूरी तरह नहीं हटाती
  • “cloud से development speed तेज़ होती है”: शुरुआती agility एक वास्तविक लाभ है, इसलिए इसका उपयोग करें, लेकिन cost inflection point की निगरानी करके सही समय पर migration ज़रूरी है
  • “हमारा traffic बहुत bursty है”: इस स्थिति में serverless/autoscale उपयुक्त है
  • “CDN का क्या?”: latency और bandwidth reduction के लिए CDN ज़रूरी distributed purchase target है, और backup भी इसी तरह खरीदकर उपयोग करने वाला क्षेत्र है

monolithic vs. microservices और server structure

  • “बड़ा सर्वर” स्वाभाविक रूप से monolithic architecture से जुड़ता है, लेकिन एक ही सर्वर पर कई containers के रूप में microservices भी बनाई जा सकती हैं
    • लेकिन inter-process communication, deployment, और observability overhead single host पर भी बोझ पैदा करते हैं, इसलिए complexity के मुकाबले वास्तविक performance लाभ काफी कम हो जाता है
  • शुरुआती और मध्यम scale पर monolithic या कुछ ही services operational simplicity के लिहाज़ से अधिक फायदेमंद हैं

निष्कर्ष

  • अधिकांश स्थितियों में horizontal scaling या cloud-केंद्रित architecture की तुलना में vertical scaling (एक बड़ा सर्वर) अधिक सरल और किफायती विकल्प है
  • primary/secondary redundancy, heterogeneous hardware, और CDN/backup externalization को मिलाकर व्यावहारिक reliability हासिल की जा सकती है, और लगातार workload वाले वातावरण में total cost of ownership (TCO) का लाभ बड़ा होता है
  • यदि मजबूत hardware redundancy रणनीति उपलब्ध हो, तो “एक बड़ा सर्वर” दृष्टिकोण वास्तविक services के लिए बेहद उपयुक्त विकल्प हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2025-09-02
Hacker News की राय
  • Cloud Tax की सबसे बड़ी समस्याओं में से एक यह है कि यह इंजीनियरों द्वारा विचार की जा सकने वाली solutions की range को कृत्रिम रूप से सीमित कर देता है। उदाहरण के लिए, AWS को लगभग $200/माह देने पर 4 vCPU और 16GB RAM वाला server मिलता है, जो लगभग 5 साल पुराने development laptop जैसी spec है। दूसरी ओर Hetzner में उसी कीमत पर 48-core, 128GB RAM server किराए पर मिल सकता है। compute performance का अंतर बेहद बड़ा है। अगर आपके पास 10 गुना ज़्यादा capacity हो, तो कई ऐसी methodologies प्रभावी बन जाती हैं जिनका छोटे node पर कोई मतलब नहीं रह जाता। ऐसी स्थितियाँ कभी-कभी ज्यादा complex system बनाने में लगने वाला engineering time बचाने का तरीका भी होती हैं। बेशक durability जैसी दूसरी बातों पर भी ध्यान देना होता है, लेकिन दूसरी तरफ dedicated server noisy neighbor की चिंता के बिना consistent performance देता है
    • 2025 में convenience और complex procedures के बिना fly.io जैसी services को general purpose use के लिए इस्तेमाल किया जा सकता है, और कुछ frameworks के लिए Vercel जैसे options भी हैं (कुछ stacks के लिए अच्छे specialized विकल्प)। उससे आगे ज़रूरत हो to OVH/Hetzner/Latitude से सचमुच monster-class machines सस्ते में rent की जा सकती हैं। अगर बस blog चलाना है, तो VPS के विकल्प बहुत हैं। traditional cloud अब बस regulation, internal process, या inefficiency के लिए ही बचा है। न developer productivity है, न machine cost efficiency। जब तक किसी team पर बिल्कुल कोई constraint न हो और वह DMV-style approval systems, शोर मचाते Intel nodes, महंगे margins, और खराब support को पसंद न करती हो, ज्यादातर मामलों में इसका कोई मतलब नहीं
    • यह उससे भी आगे की बात है—bare metal server इस्तेमाल करने पर network latency, VM की memory bandwidth latency/contention, और अलग caching structure जैसी चीज़ों की ज़रूरत नहीं पड़ती। उदाहरण के लिए, Postgres को ढेर सारी RAM दे दीजिए और सिर्फ Linux disk caching इस्तेमाल कीजिए। यह कहीं ज्यादा simple और fast है
    • मुझे समझ नहीं आता कि छोटे-मोटे service के लिए भी सीधे AWS ही क्यों लेना चाहिए। मैं आपकी तरह इतने complex level पर नहीं हूँ, लेकिन एक client छोटे PHP web app + AWS server/SQS/S3 combination पर $100/माह खर्च कर रहा था। मैंने इसे Python/Django/PostgreSQL (शुरुआत में SQLite) में implement करके $25/माह वाले VPS पर migrate कर दिया। PDF OCR, price updates, missing product detection, site service—सब कुछ 4-core 6GB RAM पर ठीक चल रहा है। यह एक internal app है जिसमें 100 से कहीं ज्यादा users होने की संभावना नहीं, इसलिए बाद में बड़ा भी हो जाए तो migration बहुत आसान रहेगा। अभी के स्तर पर AWS के $100 server की कोई ज़रूरत नहीं, जब तक कि वाकई बहुत बड़े scale पर न पहुँचे
    • पूरी तरह सहमत। sqlite जैसे embedded database का इस्तेमाल करें, और writes (batch) को optimize करें, तो Hetzner पर भी बहुत दूर तक जाया जा सकता है। “ज्यादा capacity reserve करके waste करना” वाला दावा AWS के बाहर निकलते ही बेमानी हो जाता है (cost-performance का मुकाबला ही नहीं)। उल्टा कई बार system जितना complex होता है, single node की तुलना में reliability और resilience उतनी कम हो सकती है। अक्सर ऐसा नहीं होता कि बस एक ही चीज़ isolate होकर fail हो जाए
    • मेरी राय उलटी है। Hetzner छोटे sites के लिए बहुत अच्छा है, लेकिन बड़े projects में cloud लगभग बिना constraint वाला लगता है। अगर project इतना valuable है कि मेरा समय मायने रखता है, तो hosting cost $200 हो या $2000, फर्क नहीं पड़ता। AWS CDK/Terraform+GitHub Actions और Docker/K8s/Ansible+CI pipeline के development time में भी मुझे कोई खास अंतर नहीं दिखता। मुझे bare metal approach engineering time बहुत बचाती है, ऐसा महसूस नहीं हुआ। Fargate+RDS जैसी IaC setup भी convenient है। अगर सच में file storage को अलग, scalable, durable बनाना हो, या dynamic subdomain generation जैसी चीज़ों सहित infrastructure layer की कई dedicated services integrate करनी हों, तो नए services को सीखने और जोड़ने का बोझ कहीं ज्यादा बड़ा हो सकता है। सच कहूँ तो मैं cloud से पहले के दौर से ही यह काम कर रहा हूँ, और revenue-generating project के लिए cloud cost निवेश के लायक लगती है। अगर कोई project cost के बोझ से ही दब रहा है, तो वह business से ज्यादा hobby है। RAID या कई clustered file systems को manage करना, ज़्यादातर startups/companies के resources या मेरे समय से मैं नहीं करना चाहूँगा। यह कुछ वैसा लगता है जैसे Arch+Emacs से छेड़छाड़ पसंद करने का स्वाद बनाम MacBook से संतुष्ट रहने का स्वाद। अगर kernel scheduler बदलना है तो Arch कहूँगा, वरना MacBook recommend करूँगा। दूसरी तरफ, अगर सचमुच budget नहीं है और raw throughput सबसे महत्वपूर्ण है, तो dedicated server मेरे अनुभव में बिल्कुल सही रहा है (हज़ारों डॉलर बचाए)। अगर वह सफल हो जाता, तो शायद उसके बाद vertical scale किया जाता—लेकिन यह rare case है
  • HN (Hacker News) production server और backup server, कुल 2 machines चलाता है। hardware issue या upgrade की ज़रूरत होने पर तुरंत failover किया जा सकता है, इसलिए यह useful pattern है। लेकिन अगर दोनों servers पूरी तरह identical clone हों, तो दोनों एक साथ fail भी हो सकते हैं—इसलिए सावधान रहना चाहिए
    • SSD जितना critical नहीं, लेकिन AMD CPU में भी एक दिलचस्प error था। लगभग 1044 दिन बाद एक specific core पूरी तरह रुक जाता था। AMD EPYC Rome CPU Hang case
    • मुझे जानना है कि HN (Hacker News) downtime के बारे में कोई statistics हैं क्या। पिछले 10 साल में मुझे सिर्फ एक-दो बार इसके down होने की याद है, और अनुभव के हिसाब से यह 99.99% से ज्यादा uptime जैसा लगता है
  • मैं 10 साल से अधिक समय से hybrid colo + public cloud इस्तेमाल कर रहा हूँ, और एक निश्चित scale के बाद यह हमेशा cost optimization के लिए सबसे अच्छा रहा है। hardware efficiency भी लगातार बेहतर हो रही है। network/infrastructure admin की ज़रूरत पड़ती है, लेकिन सच कहें तो आजकल management बहुत आसान है, और दूसरी तरफ “cloud” admin भी मूलतः चाहिए ही होता है, इसलिए labor cost savings लगभग नहीं के बराबर हैं। colocation के कई options हैं, और providers bandwidth को bundle करके बेचते हैं। एक समय मैंने 8 dell vrtx clusters, SAN, और 500+ VM (बड़े msSQL से लेकर kube तक) चलाए थे; अगर यह public cloud पर होता, तो reserved discounts के बाद भी bill six figures में जाता। लेकिन colo cost $2,400/माह थी (मुख्यतः power cost)। public cloud nodes की साफ़ धीमी performance भी हमेशा चौंकाती है (एक ही CPU/VCPU generation होने पर भी)। device deals, updates, licenses, और support contracts को समझना पड़ता है, लेकिन व्यावहारिक रूप से यह पूरी तरह manageable है। और अब cloud और networking को जोड़ना भी आसान हो गया है—fiber drop लें और VPC से connect कर दें, काम हो गया
    • मेरी समझ से colocation का मतलब अपना hardware खरीदकर data center में सिर्फ power/rack/line किराए पर लेना है। क्या सच में ऐसा ही है? और यह सामान्य bare metal server rental से किस तरह बेहतर है, यह जानना चाहता हूँ
  • मैं कई सालों से दोस्तों के साथ इस विषय पर चर्चा कर रहा हूँ। local infrastructure की सबसे बड़ी कमी यह है कि इसे सही से चलाने के लिए विशेषज्ञ staff चाहिए। यह लेख ऊपरी scale पर केंद्रित है, लेकिन निचले बाजार में भी अगर आपके पास कुछ equipment है, तो छोटा rack या networking लेकर 1 साल में break-even हो सकता है। आज के cloud premium को देखते हुए, शायद एक admin hire करने पर भी local infrastructure ज्यादा economical पड़ेगा
  • जिस कंपनी की founding में मैं शामिल था, वहाँ हमने enterprise automation engine बनाया था, और team चाहती थी कि solution को SaaS के रूप में deploy करके revenue maximize किया जाए। सच यह है कि multi-tenant DB schema + VPS से भी काम चल जाता, लेकिन team kubernetes सीखने और cloud-native stack में इतनी उलझ गई कि 1 साल development environment और operations automation में ही लगा दिया। अंत में कंपनी ज्यादा समय नहीं टिक पाई और बंद हो गई
    • लेकिन engineers को उस experience से k8s का track record मिल गया, और वे नई jobs ढूँढ पाए
    • मेरा भी ऐसा ही अनुभव रहा है—मैंने उन समस्याओं को पहले से सुलझाने में बहुत समय बर्बाद किया जो शायद 5 साल बाद कभी आतीं। ज़्यादातर projects और शुरुआती startups के लिए बस PaaS या nginx+docker containers ही काफी होते हैं। जब सचमुच कोई pain point आए, तब सोचना चाहिए
    • इसलिए मैं “जब तक bill सच में दर्द न दे” तब तक बस PaaS पसंद करता हूँ। heroku/render/fly की cost देकर PMF(Product-Market Fit) पर ध्यान दो। या फिर servers के मज़े के लिए K8s पर VC का पैसा जलाओ और फिर अगली job में वही cycle दोहराओ
  • बहुत से businesses उतने महत्वपूर्ण नहीं होते। service बंद होने पर लोग बेवजह बहुत stress लेते हैं, जबकि वे जिन services को संभाल रहे हैं वे इतनी critical नहीं होतीं। अगर दोपहर में production environment उड़ भी जाए, तो थोड़ी परेशानी होगी, लेकिन दुनिया खत्म नहीं होगी। ऐसी कंपनियाँ पहले साधारण office server पर 250 लोगों तक आराम से चला लेती थीं, फिर बेवजह cloud पर जाकर सिर्फ budget उड़ा देती हैं। cloud कुछ खास कामों में शानदार है, लेकिन बाकी मामलों में यह marketing hype के करीब है। फिर भी कई engineers “perfect scalability” के जुनून में reasonably good solution की बजाय ideal architecture ही ढूँढते रहते हैं
    • मेरे एक पुराने teammate काम के दौरान हमेशा कहा करते थे: “कम से कम अगर हम गलती करें तो कोई मरेगा नहीं, इसलिए इतनी चिंता की ज़रूरत नहीं।” उनका background कहीं ज्यादा जिम्मेदारी वाले काम का था, इसलिए मुश्किल हालात में यह mindset बहुत मददगार था
  • 100% uptime पाने के लक्ष्य में complex structures बनाते-बनाते लोग अक्सर reliability घटाने वाली गलतियाँ ज्यादा करने लगते हैं। ज़्यादातर businesses वास्तव में कभी-कभार 1–2 घंटे का downtime या कुछ data loss भी सहन कर सकते हैं। अगर यह expectation पहले से साफ़ कर दी जाए, तो कहीं ज्यादा simple और reliable architecture के साथ engineering की जा सकती है
    • cost भी बहुत कम आती है। लेकिन ऐसी expectations को engineers के अलावा non-technical executives अक्सर स्वीकार नहीं करते (खासकर data loss तो लगभग कभी नहीं)। engineers कहते हैं कि वे सिर्फ environment manage करते हैं, लेकिन वास्तविकता में यह इतना आसान नहीं होता, और गलती हो जाए तो आप incompetent भी दिख सकते हैं
  • यह काफ़ी अच्छा article है। इस approach (non-cloud) से scale करते समय CDN जोड़ने पर भी विचार किया जा सकता है। CDN इस्तेमाल करने से WAF और DNS failover जैसा असर भी मिलता है। लेकिन non-cloud approach में DB खुद operate करनी पड़ती है, यही थोड़ा drawback है। इसलिए उन providers पर विचार किया जा सकता है जो cloud DB को भी option के रूप में देते हों, या active/passive setup में passive node को cloud VM + autoscale के साथ और सस्ते में चलाया जा सकता है। आजकल server rental pricing वाकई बहुत सस्ती है—4GB VPS लगभग $6, और 32GB quad-core bare metal लगभग $90 में। serversearcher.com जैसी price comparison sites उपयोगी हो सकती हैं
    • Postgres को Docker container में चलाकर और बस नियमित backups लेकर भी मुझे कोई खास समस्या नहीं हुई। operations भी simple हैं, इसलिए इसमें खास असुविधा नहीं है
    • single machine पर Postgres/MySQL की तुलना में sqlite कहीं ज्यादा performance और आसान management दे सकता है
  • मैं भी VPS पर services चलाता हूँ। cloud को मैंने बहुत पहले छोड़ दिया। अगर मेरा project पैसे कमाने लगे, तो मैं hardware खरीदकर colo में डालने की योजना रखता हूँ। cloud मुझे dating app जैसा लगा—अब मज़ा खत्म हो गया, और अब कुछ सचमुच productive करना है
    • colo खुद भी समस्याओं से भरा है। data center की power failure जैसी वजहों से hardware का मर जाना वास्तव में आम बात है। विडंबना यह है कि कई बार मेरे घर की बिजली ज्यादा stable लगती है। अगर आपका business कुछ मिनट के downtime से लाखों की revenue hit नहीं लेता, तो ज़्यादातर मामलों में basement में server चलाने से भी कोई बड़ी दिक्कत नहीं। बहुत से लोग 99.999% uptime या bandwidth की ज़रूरत को बहुत बढ़ा-चढ़ाकर आँकते हैं। colo उतना सस्ता भी नहीं जितना लोग सोचते हैं। data center की बिजली दरें सामान्य/business या residential power rates से ज्यादा हो सकती हैं। वास्तव में सस्ता सिर्फ internet/fiber line है, और आजकल कई देशों में 5–10Gbit business-grade connection भी 100 यूरो में मिल जाता है (पहले 1Gbit के लिए भी 2,000 यूरो से ऊपर माँगते थे)
  • cost या capacity analysis से अलग, industry trend के खिलाफ जाना ही आसान नहीं है। “hardware की बिल्कुल चिंता न करनी पड़े” यह लाभ सच में मौजूद है। इसके अलावा capex (पूंजीगत व्यय) से हर हाल में बचना चाहिए—ऐसी सोच भी बहुत मजबूत है (server hardware में upfront investment बड़ा होता है)। और AWS region में outage हो जाए तो वह “हमारी गलती” जैसा नहीं लगता, लेकिन internal server बंद हो जाए तो वह “हमारी जिम्मेदारी” जैसा दिखता है
    • capex से इतनी तीखी नफरत लगभग VC investment structure का असर है—जब investors सिर्फ high growth चाहते हैं, तब upfront investment (server खरीदना) को तर्कसंगत ठहराना मुश्किल हो जाता है। इसके विपरीत, स्थिर business हर साल छोटे capex को आराम से संभाल सकता है
    • server hardware को खरीदना ज़रूरी नहीं—Hetzner जैसी जगहों से rent पर लेना भी काफी है। “hardware की चिंता न करनी पड़े” वाले लाभ से आपका ठीक-ठीक मतलब क्या है, यह और सुनना चाहूँगा
    • capex बचाने वाली सोच सचमुच मौजूद है। जिसे calculator चलाना आता है, वह देख सकता है कि आजकल server cost पूरे business के संदर्भ में बहुत बड़ी चीज़ नहीं है। असल महंगी चीज़ server के आसपास का “space” है, इसलिए ज़्यादातर लोग server नहीं बल्कि space (rack/power) किराए पर लेते हैं
    • कंपनियाँ आखिरकार जिस चीज़ के लिए पैसे देती हैं, वह है “responsibility की abstraction”। बड़ी कंपनियों के executives, MS या AWS जैसी बड़ी कंपनियों के solutions चुनकर आश्वस्त महसूस करते हैं
    • bare metal server rent करने पर capex या maintenance की चिंता करने की ज़रूरत नहीं रहती