2023 में, महिमा सिर्फ 11MB/सेकंड दूर

 (thmsmlr.com)
2 पॉइंट द्वारा GN⁺ 2024-04-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें

क्लाउड लागत की सच्चाई

  • यह धारणा है कि क्लाउड सेवाएं सस्ती होती हैं, लेकिन वास्तव में उपयोगकर्ता जरूरत से ज्यादा लागत चुका सकते हैं.
  • AWS, Amazon के अधिकांश मुनाफे का स्रोत है, लेकिन इसका मतलब यह भी हो सकता है कि क्लाउड सेवाएं वास्तव में महंगी हैं.

फर्स्ट प्रिंसिपल्स से गणना

  • अगर आप शीर्ष 1000 वेबसाइटों में से एक बनाना चाहते हैं, उदाहरण के लिए businessinsider.com जैसी साइट, तो आपको प्रति माह 200M विज़िटर और 400M page views की जरूरत होगी.
  • सिर्फ HTML दस्तावेज़ों के लिए प्रति माह 30TB bandwidth चाहिए, लेकिन यह केवल 11MB प्रति सेकंड है, जो आधुनिक हार्डवेयर के लिए बहुत कम स्तर है.

लेटेंसी को समझना

  • प्रकाश की गति के हिसाब से पृथ्वी के विपरीत छोर तक round trip में लगभग 200ms लगने चाहिए, लेकिन वास्तविकता में यह लगभग 300ms लेता है.
  • अगर JS, CSS और मीडिया को CDN के जरिए डिलीवर किया जाए, तो server processing time में 300ms की कमी लाकर ऐसा प्रभाव बनाया जा सकता है मानो सर्वर उपयोगकर्ता के पास ही हो.

एज तकनीक की सीमाएं

  • एज तकनीक, serverless की दूसरी पीढ़ी में प्रगति के बावजूद, डेटाबेस की समस्या हल नहीं कर पाती.
  • अधिकांश जटिल पेजों को database queries की जरूरत होती है, और इससे लेटेंसी बढ़ सकती है.

लागत पर विचार

  • Hetzner.com, AWS EC2 की तुलना में सर्वर और bandwidth के लिए कहीं अधिक सस्ते विकल्प देता है.
  • क्लाउड वेंडर शुरुआत में बहुत कुछ मुफ्त देते हैं, लेकिन scale होने पर लागत काफी बढ़ जाती है.

वास्तविक स्थिति

  • खास use case न हो तो अधिकांश वेबसाइटें या SaaS एक ही सर्वर पर चल सकती हैं, जो अधिक सस्ता और maintain करना आसान होता है.
  • SQLite को लोकल में इस्तेमाल करके, CDN के जरिए CSS, JS और images को cache करके, और server rendering के माध्यम से performance बेहतर की जा सकती है.
  • जटिल Docker या virtualization के बिना भी पर्याप्त scale किया जा सकता है, और इसे manage करना आसान व कम खर्चीला होता है.

GN⁺ की राय

  • यह लेख क्लाउड सेवाओं की cost efficiency को लेकर प्रचलित धारणा को चुनौती देता है और दिखाता है कि उपयोगकर्ता शायद अपनी वास्तविक जरूरत से अधिक भुगतान कर रहे हैं.
  • क्लाउड सेवाओं की cost structure की तुलना में यह दिखाता है कि पारंपरिक single-server hosting अब भी एक व्यवहार्य विकल्प हो सकती है.
  • यह जोर देता है कि serverless, Docker और horizontal scalability जैसी तकनीकें हर स्थिति में जरूरी नहीं होतीं, और कई बार सरल approach बेहतर performance और कम लागत दे सकती है.
  • यह database optimization और regional placement के महत्व को रेखांकित करता है, जिससे क्लाउड सेवाओं के बराबर या उससे बेहतर performance हासिल की जा सकती है.
  • तकनीकी चयन करते समय वास्तविक ट्रैफिक और performance requirements का आकलन करके, cost-effectiveness के आधार पर क्लाउड के बजाय पारंपरिक server hosting पर विचार किया जा सकता है.

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

1 टिप्पणियां

 
GN⁺ 2024-04-08
Hacker News राय

  • होस्टिंग बिज़नेस का अनुभव

    • पहले होस्टिंग बिज़नेस में ग्राहकों की मांग के अनुसार जटिल सिस्टम उपलब्ध कराए जाते थे.
    • AWS का मुकाबला करने के लिए API-आधारित cloud hosting platform विकसित किया गया, लेकिन 2012 में revenue अपने शिखर पर पहुंच गया.
    • ग्राहक AWS-आधारित और अधिक जटिल solutions चाहते थे, और साधारण servers पर भरोसा नहीं करते थे.
    • कंपनी bootstrap तरीके से चलाई जा रही थी, और AWS की cost risk उठाने की ज़रूरत को समझ नहीं पाई.
    • AWS को software developers की पीढ़ी में गहराई से जमी हुई 'cleverness' के कारण पसंद किया जाता है.

  • ट्रैफिक विश्लेषण की त्रुटि

    • ट्रैफिक समान रूप से वितरित नहीं होता, और peak समय में bandwidth की मांग औसत से कहीं अधिक होती है.
    • वास्तविक services में TCP और TLS connection setup के लिए कई round trips की ज़रूरत होती है, और user experience के लिए response time महत्वपूर्ण होता है.

  • server errors और ट्रैफिक

    • 500 Internal Server Error यह दिखाता है कि server अपेक्षा से अधिक ट्रैफिक संभाल रहा है.

  • service scaling के प्रति दृष्टिकोण

    • अनावश्यक scaling से बचना और केवल ज़रूरत पड़ने पर निर्माण करना बेहतर है.
    • performance समस्या आने पर उसी समय प्रतिक्रिया देना अच्छा है.

  • AWS के फायदे

    • AWS का उपयोग करने से service outage होने पर सफाई देने की कुछ गुंजाइश मिलती है.

  • cloud architecture पर चर्चा

    • यह cloud architecture की आवश्यकता पर बहस नहीं, बल्कि विकल्प प्रस्तुत करने का एक तरीका है.
    • server down होने पर availability की समस्या को दूसरे तरीकों से हल किया जा सकता है.

  • SQLite और vertical scaling

    • SQLite की जगह self-hosted Postgres का उपयोग किया जा सकता है, हालांकि इसके लिए अधिक setup effort चाहिए.
    • ऐसी architecture संभव है जिसमें पूरा global state memory में रखा जाए और disk पर snapshots सहेजे जाएं.

  • API और SQLite database का संयोजन

    • SQLite एक single thread में बहुत सारे queries संभाल सकता है.
    • API side पर memory caching का उपयोग करके, और static pages के लिए database को bypass करके performance सुधारी जा सकती है.

  • single server की availability समस्या

    • single server पर service चलाने से unplanned downtime हो सकता है.
    • data recovery time और data loss की मात्रा पर विचार करना चाहिए.

  • cloud की ओर जाना और availability

    • cloud की ओर जाना अक्सर peer pressure जैसा महसूस होता है.
    • availability के लिहाज़ से single server जोखिमपूर्ण हो सकता है, इसलिए CDN और cloud को समझदारी से मिलाकर उपयोग करना बेहतर है.