मैं AWS पर वापस गया, और फिर से समझ आया कि मैं वहाँ से क्यों चला गया था

 (fourlightyears.blogspot.com)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • शुरुआत से AWS का समर्थक था, लेकिन client libraries को community पर छोड़ देना, Python 3 migration में देरी, जटिल billing और IAM, तथा AWS Lambda lock-in जैसी बातें जमा होती गईं और अंततः AWS पसंद नहीं रहा
  • DynamoDB इस्तेमाल करने के बाद एक दिन में 75 डॉलर का बिल आया; data egress cost भले ही प्रति GB 20 cent से घटकर 9 cent हो गई हो, लेकिन internal data movement पर भी शुल्क लगने की संरचना अब भी महंगी और समझना मुश्किल लगती है
  • AWS छोड़ने के बाद अधिकांश accounts बंद कर दिए, लेकिन Route53 domains, S3 backups का कुछ हिस्सा, और AWS WorkMail बनाए रखे; बाद में WorkMail के 12 महीनों के भीतर बंद होने की सूचना मिली
  • हाल ही में Claude/Anthropic के AWS Bedrock पर व्यवहार और 192-core·1TB RAM EC2 Spot टेस्ट के लिए फिर AWS में लॉग इन किया; Bedrock काम तो वैसा ही करता है, लेकिन अधिक धीमा और Anthropic subscription की तुलना में कहीं ज्यादा महंगा लगा
  • लगभग 3 घंटे के EC2 Spot टेस्ट के दौरान Suspected security breach अलर्ट के बाद account पर restrictions लग गईं, जिससे business WorkMail email और resource creation रुक गए; कार्रवाई और chat support के बाद भी 4 दिन तक restriction नहीं हटी, इसलिए AWS WorkMail और Route53 भी migrate करने का फैसला किया

शुरुआती AWS समर्थन से दूरी तक

  • उस समय से AWS का मजबूत समर्थक था जब AWS, SQS, S3, EC2 और SimpleDB जैसे अपेक्षाकृत छोटे services तक सीमित था, और Melbourne में अमेरिकी AWS प्रतिनिधियों के साथ AWS का पहला परिचयात्मक कार्यक्रम आयोजित किया था
  • cloud computing एक बड़ा बदलाव था, क्योंकि इससे startups बिना data center में systems install और operate किए कुछ ही मिनटों में अपना computer system चला सकते थे
  • लगभग 15 वर्षों तक AWS पर गहरा भरोसा रहा, लेकिन समय के साथ असुविधाएँ बढ़ती गईं और एक समय ऐसा आया जब AWS अब पसंद नहीं रहा

समय के साथ जमा हुई AWS से शिकायतें

  • Client libraries और Python migration

    • AWS ने शुरुआती 6 वर्षों तक अपनी client libraries नहीं बनाईं और Python जैसी languages के लिए libraries community पर छोड़ दीं, जिसे मुफ्त में समय देने वाले programmers पर बोझ डालने जैसा महसूस किया गया
    • AWS का Python 2 से Python 3 पर जाने में अत्यधिक समय लेना भी बड़ी शिकायत बना रहा

  • DynamoDB और लागत का अनुभव

    • DynamoDB इस्तेमाल करने के बाद दिन के अंत में 75 डॉलर का बिल आया, और सिर्फ लागत ही नहीं, system itself भी कल्पना की जा सकने वाली सबसे खराब तरह का लगा

  • Data transfer cost और जटिल billing

    • AWS की data egress cost पहले प्रति GB 20 cent थी और बाद में घटकर प्रति GB 9 cent हुई, लेकिन फिर भी यह बहुत महंगी लगती है
    • AWS के internal systems के बीच data movement पर भी शुल्क लगता है, और कुछ स्थितियों में यह double या triple billing जैसा महसूस होता है; गहरी समझ के बिना billing traps से बचना मुश्किल है

  • IAM और समग्र जटिलता

    • IAM authentication और access rules को संभालने वाला system है, लेकिन इसकी संरचना अत्यधिक जटिल महसूस होती है
    • AWS समर्थक कहते हैं कि अपना Linux, hardware, networking और security चलाना बहुत जटिल है, इसलिए AWS चाहिए; लेकिन AWS के लगभग हर हिस्से में भी भारी जटिलता है, इसलिए अंततः महंगी विशेषज्ञ टीम की जरूरत पड़ती है

  • AWS Lambda और lock-in

    • AWS Lambda scalability का दावा करता है, लेकिन इसके लिए slow startup time और बड़ी development complexity झेलनी पड़ती है
    • अपना web server चलाने की तुलना में इसमें कोई वास्तविक लाभ नहीं लगा, बल्कि नुकसान अधिक लगे; AWS छोड़ते समय सबसे कठिन चीज़ों में से एक AWS Lambda थी
    • AWS Lambda का उपयोग vendor lock-in के वास्तविक होने का अनुभव बनकर रहा, और यह ऐसा विकल्प लगा जिसे लगातार खुद को बेहतर साबित करके सही ठहराना पड़ता है

  • Open source projects और hosting revenue

    • AWS ने Elasticsearch, Redis और MongoDB जैसे projects की इस इच्छा के बावजूद कि उनकी नकल कर monetization न किया जाए, OpenSearch, Valkey और DocumentDB को आगे बढ़ाया—ऐसा महसूस किया गया
    • इन communities और companies ने market बनाई, और उसके बाद AWS ने hosting services का revenue ले लिया; नतीजतन SSPL, Elastic License, RSAL जैसे defensive licenses और source-available मॉडल बढ़े—ऐसा माना गया

AWS छोड़ने के बाद बचाकर रखी गई कुछ सेवाएँ

  • AWS से लगाव खत्म होने के बाद सब कुछ AWS के बाहर ले जाया गया और लगभग सभी accounts बंद कर दिए गए
  • फिर भी उस समय कुछ services ऐसी लगीं जो वास्तव में सही समाधान थीं, इसलिए उन्हें रखा गया
  • बचाकर रखी गई चीज़ें थीं Route53 के domains, S3 के कुछ backups, और AWS WorkMail
  • बाद में AWS WorkMail के 12 महीनों के भीतर बंद होने की सूचना मिली

थोड़ी देर के लिए AWS पर वापस जाने का कारण

  • हाल ही में research और testing के लिए AWS में फिर लॉग इन किया गया
  • यह देखना था कि Claude/Anthropic, AWS Bedrock पर कितना अच्छा काम करता है; Claude Code के संदर्भ में यह काम तो वही करता है, लेकिन अधिक धीमा और Anthropic subscription से कहीं ज्यादा महंगा लगा
  • घर पर उपलब्ध सबसे तेज machine में 20-core CPU और 32GB RAM थी, और यह benchmark करना था कि code 192-core और 1TB RAM वाली machine पर कितना तेज चलता है
  • लगभग एक महीने पहले AWS Bedrock का टेस्ट बिना समस्या पूरा हुआ और टेस्ट के बाद सब बंद कर दिया गया
  • privacy की जरूरत हो तो AWS Bedrock उपयोगी हो सकता है, लेकिन लागत के कारण Claude को दोबारा AWS Bedrock पर इस्तेमाल करने का इरादा नहीं है

EC2 Spot टेस्ट के दौरान account restriction

  • इसके बाद 192-core EC2 Spot instance चलाकर लगभग 3 घंटे टेस्ट करते समय AWS से “Suspected security breach of your account” email मिला
  • ऐसा लगा कि लंबे समय से लगभग निष्क्रिय account ने अचानक महंगे compute resources का उपयोग शुरू किया, जिससे AWS का internal security alert trigger हुआ होगा
  • उपयोगकर्ता की सुरक्षा करना AWS का उद्देश्य है, इसे समझा गया और सकारात्मक रूप से देखा गया
  • लेकिन AWS ने account को suspend या restrict कर दिया, जिसके परिणामस्वरूप AWS WorkMail पर इस्तेमाल किया जा रहा मुख्य business email account काम करना बंद कर गया
  • अब कोई भी email नहीं भेज सकता था, और कोई AWS resource भी नहीं बनाया जा सकता था, इसलिए मूल रूप से जो टेस्ट करना था वह आगे जारी नहीं रह सका

support की प्रतिक्रिया और देरी

  • AWS support alert का जवाब देकर बताया गया कि account hack नहीं हुआ था और कोई समस्या या billing anomaly नहीं थी, लेकिन कोई response नहीं आया
  • premium support न होने के कारण AWS द्वारा बताए गए 24 घंटे के response time का इंतज़ार करना पड़ा, और 3 दिन बाद भी AWS support की ओर से जवाब नहीं आया
  • AWS forum में मदद मांगने के बाद email instructions का पालन करने और web की जगह chat इस्तेमाल करने की सलाह मिली
  • password बदलना, access tokens हटाना, billing history जांचना जैसी मांगी गई सभी कार्रवाइयाँ की गईं, और chat connection के लिए लगभग 30 मिनट प्रतीक्षा करने के बाद AWS प्रतिनिधि से लंबी बातचीत हुई
  • प्रतिनिधि संतुष्ट दिखा और कहा कि वह संबंधित internal team से कार्रवाई करवाएगा, लेकिन 24 घंटे बाद भी restriction नहीं हटाई गई
  • 8 घंटे बाद follow-up करने पर सिर्फ “कृपया प्रतीक्षा करें” जैसा उत्तर मिला

फिर से स्पष्ट हुआ निष्कर्ष

  • account restricted हुए 4 दिन बीत जाने के बाद भी बड़े hardware पर टेस्ट करने वाले काम बाकी थे, और इसके लिए फिर से “quota” request करनी पड़ेगी—इस चिंता ने भी घेरा
  • business email system अब भी काम नहीं कर रहा था
  • इस बार AWS पर लौटने के अनुभव ने फिर से साफ कर दिया कि AWS क्यों छोड़ा था, और यह तय किया गया कि AWS WorkMail से बाहर निकलना है, Route53 के domains भी migrate करने हैं, और फिर कभी वापस नहीं आना है
  • पहले ही AWS से अधिकांश चीज़ें बाहर ले जाना बहुत राहत देने वाला साबित हुआ, लेकिन जिस email system पर भरोसा करके उसे वहीं छोड़ा गया था, वही AWS पर वापसी की प्रक्रिया में बाधित हो गया—इसे विफलता की तरह महसूस किया गया
  • AWS कभी account restriction हटा भी सकता है, लेकिन वह कब होगा यह पता नहीं

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • कुछ साल पहले मैं एक कंपनी में शामिल हुआ, dev टीम की ज़िम्मेदारी ली, और मुझसे कहा गया कि 3 महीने के भीतर product लॉन्च करना है। AWS में नया machine जोड़ने लगा तो कीमत UI में दिखती ही नहीं थी — यह ढांचा खुद मुझे शत्रुतापूर्ण और शोषणकारी रिश्ते का संकेत लगा।
    specs table और pricing table अलग-अलग खोलकर मिलान करना पड़ता था, और पिछले अनुभव से मेरा मानना था कि ऐसे संकेत देखकर भी अगर कोई न जाए, तो बाद के नतीजों की ज़िम्मेदारी उसी की होती है।
    इसलिए मैंने DigitalOcean account बनाया, सब कुछ वहाँ migrate किया, CI/CD भी वहीं deploy होने के लिए सेट किया, और बचे हुए 2 महीने product पर फोकस किया — नतीजा यह कि तय समय से 1 महीना पहले लॉन्च कर दिया।
    मैंने कभी एक वीडियो देखा था जिसमें नदी किनारे गड्ढा खोदकर उसे pipe से नदी से जोड़ा गया था, ताकि मछलियाँ खुद फंदे में आ जाएँ। उस वीडियो ने मेरे दिमाग में यह बात बिठा दी कि सबसे कम प्रतिरोध वाले रास्ते को चुनना और गलतियों को वापस न पलटना, आखिर में उसी मछली जैसा अंजाम देता है।

    • Azure की जो बातें मुझे पसंद हैं, उनमें से एक यह है कि हर individual item बनाते समय वह कीमत को आक्रामक ढंग से सामने नहीं ठेलता, लेकिन जिन items की कीमत ज़्यादा हो सकती है, वहाँ आम तौर पर कीमत दिखाने का संतुलन मौजूद रहता है।
      अभी तक billing देखकर चौंकना नहीं पड़ा।
    • लगता है Amazon की engineering culture काफ़ी engineer-driven product culture है, इसलिए अक्सर developers को UX और flow तक की ज़िम्मेदारी उठानी पड़ती है।
      मैंने पहले एक junior developer को hire किया था जिसने AWS internship की थी। उसने summer में product manager या designer की मदद के बिना अकेले बनाया dashboard दिखाया, और वह सच में बहुत भयानक लग रहा था।
      कुछ developers में product/UX की समझ अच्छी होती है, लेकिन ज़्यादातर UX में बहुत कमज़ोर होते हैं; इसलिए यह जानबूझकर किया गया कम और बस खराब UX culture ज़्यादा लगता है।
    • सही तरीका यह है कि ऐसा infra provider चुना जाए जो launch में मदद करे।
      AWS अच्छा है, लेकिन हर किसी के लिए सही नहीं। यह Heroku जैसी services और bare metal के बीच कहीं आता है — maintenance का काफ़ी abstraction देता है, लेकिन scaling architecture पर कुछ control भी रहने देता है।
      यानी cloud provider के रूप में AWS scale करने में मदद करता है, लेकिन सबसे सस्ती और सरल setup बनाने का tool नहीं है।
      अगर VC funding है और growth की कहानी आगे रखनी है, तो AWS सुरक्षित विकल्प हो सकता है, और accelerator के 2 साल वाले startup credits की वजह से शुरुआती 18 महीनों में infra budget से ज़्यादा build पर ध्यान दिया जा सकता है।
      अगर आप bootstrap या indie developer हैं, तो कुछ ऐसा चुनिए जो साध्य और सरल हो; Hetzner या DigitalOcean काफ़ी अच्छे से चल जाते हैं।
    • AWS के पास काफ़ी ठीक pricing calculator और काम के presets हैं, लेकिन जाहिर है वह पूरी तरह अलग app है।
      Amazon शायद चाहता हो कि pricing information तक आसानी से पहुँचने में थोड़ा friction रहे, लेकिन मुख्य वजह ज़्यादा Conway’s Law जैसी लगती है।
      AWS अब भी अपनी org chart को product की तरह बाहर भेज रहा है।
    • मैं कुछ हद तक सहमत हूँ, लेकिन AWS pricing इतनी सरल नहीं है कि UI में दिखने वाले किसी एक static number से पता चल जाए कि कितना bill आएगा।
      अगर cost compare करने के लिए 2 tabs खोलना ही असुविधा है, तो शायद AWS ही नहीं, सभी cloud providers से दूर रहना बेहतर हो।
      NAT Gateway, CloudFront, S3, auto scaling, load balancer जुड़ जाएँ तो cost calculation exact science से ज़्यादा art बन जाती है।
      अगर आप यह सब इस्तेमाल ही नहीं कर रहे, तो AWS इस्तेमाल करने की वजह भी कम बचती है, और सस्ते VPS providers बहुत हैं।

  • OpenSearch और Valkey के मामले में “AWS ने fork बनाया, इसलिए license change हुआ” वाली बात पूरी तरह उलटी है।
    AWS ने fork तब बनाया जब upstream project ने license बदल दिया था, और खासकर Valkey तो Redis core team के पुराने सदस्यों ने बनाया था।

    • ऐसे कई projects का business model यह होता है कि core product open source रखा जाता है, और advanced services, installation, maintenance, managed service जैसी चीज़ों से कमाई की जाती है।
      AWS ने managed service देकर उन्हें bypass किया, इसलिए इस मामले में मैं project बनाने वालों के पक्ष में हूँ।
      मूल बात यह है कि AWS ने उनका रोज़गार छीन लिया, और उनके पास license बदलने के अलावा ज़्यादा विकल्प नहीं था।
    • वह license change खुद AWS द्वारा upstream project के काम को अस्थिर और टिकाऊ न रहने वाले तरीके से monetize करने की प्रतिक्रिया था।
    • सोचता हूँ, अगर Amazon अपने द्वारा बेचे जाने वाले open source software के creators और maintainers को हर billing period पर सिर्फ़ 1 cent ही दे, तो उस पर कितना असर पड़ेगा।
      शायद open source teams के लिए वह कुछ meaningful पैसा बन जाए, और वे बिना ज़्यादा जोखिम के product improvement में योगदान भी कर सकें।
    • जब मैंने पहली बार Redis में patch भेजा था, तो एक committer ने मेरे message का जवाब तक नहीं दिया और वही patch अपने नाम से डाल दिया। उसके बाद से कई open source project philosophies के लिए मेरी सहानुभूति कम हो गई।
      वे Valkey deserve करते हैं।
      JBoss और Marc Fleury भी अभी याद हैं।
    • AWS ने fork तभी बनाया जब license बदलकर उसे उस project के code से पैसा कमाने से रोका गया।
      बात का सार यही है।

  • मैं cloud services और self-hosting के बीच कई बार आ-जा चुका हूँ।
    शुरू में Vercel इस्तेमाल किया। Project Next.js में था, इसलिए experience ठीक था, लेकिन 100 users से भी कम वाले project के लिए $20/month देना low-performance जरूरतों के हिसाब से महँगा लगा।
    बाद में Hetzner और Coolify से अपना server setup बनाया। Coolify open source था, इसलिए सिर्फ़ VPS का खर्च था, और $5/month में PostgreSQL instance और web server चल जाता था।
    लेकिन PostgreSQL और Redis maintenance में फिर भी काफ़ी हाथ लगाना पड़ता था, और Docker container में होने के बावजूद services के बीच system variables और environment variables पास करना झंझट था।
    इसलिए बाद में मैं Cloudflare Workers, D1 Database, Cloudflare KV पर चला गया। Worker के अंदर से ही call किया जा सकता था, इसलिए env vars पास करने की ज़रूरत नहीं रही।
    local development experience भी अच्छा है और pricing भी reasonable, इसलिए तब से Cloudflare ecosystem ही इस्तेमाल कर रहा हूँ।

    • Cloudflare की offerings अब उस चीज़ के काफ़ी करीब आ गई हैं जो मैं AWS से चाहता था।
      basic full-stack app और file deployment बहुत सरल है, और AWS तो self-hosting से भी कहीं ज़्यादा कठिन हो गया है।
    • जिज्ञासा है कि क्या Docker ने PostgreSQL management सच में आसान बनाया?
      PostgreSQL में मुझे आम तौर पर बस major version upgrade के समय थोड़ी migration work ही दिक्कत लगती है।
      यह भी जानना है कि services के बीच system variables और environment variables पास करना Docker की वजह से और कठिन तो नहीं हुआ।
    • मैं Cloudflare Workers को पसंद करना चाहता था, और तकनीकी रूप से उसके पक्ष में अच्छे कारण भी हैं, लेकिन email activation जैसी चीज़ों के लिए Wrangler project इस्तेमाल करने का तरीका platform lock-in के बहुत करीब लगा।
      email allow करने के लिए ज़रूरी bindings सेट करनी पड़ती थीं, लेकिन console में उन्हें configure भी नहीं कर सकते थे, और Wrangler से सेट होने के बाद जैसे उन्हें देख भी नहीं सकते थे।

  • हैरानी है कि लेखक को DynamoDB पसंद नहीं है।
    यह मेरी सबसे पसंदीदा AWS services में से एक है — availability अच्छी है, operational burden नहीं के बराबर है, और जब-जब इस्तेमाल किया, cost भी काफ़ी कम रही।
    हाँ, data model पहले से सोच-समझकर design करना पड़ता है, और उसके लिए docs पढ़कर समझना ज़रूरी है।

    • DynamoDB को उसके intended तरीके से इस्तेमाल करें तो यह काफ़ी अच्छा है।
      इसे मूलतः अच्छी durability और लगभग असीम table scaling वाले एक अपेक्षाकृत सरल key-value store की तरह देखना चाहिए, न कि SQL database की तरह।
      prototype code से $75 का bill बनाने का सबसे आसान तरीका है इसे vibe coding के भरोसे SQL database की तरह treat करना, जहाँ JOIN और GROUP BY जैसा सोचा जाए।
      यह तब सबसे ज़्यादा चमकता है जब आपको छोटे persistent storage के लिए 1-2 tables चाहिएँ लेकिन पूरा RDBMS manage नहीं करना, या जब बहुत बड़ी table को सरल तरीके से query करना हो और RDBMS में फिट करने की ज़रूरत न हो।
    • DynamoDB और Lambda जैसी कई services के बहुत specific use cases हैं।
      एक खुशमिज़ाज key-value store को database की तरह मत चलाइए।
    • कुछ साल पहले एक app बनाते समय मुझे लगभग 5 करोड़ records, हर महीने करीब 10 हज़ार read+write operations, और 1 index store करने वाला DB चाहिए था।
      initial load cost लगभग $50 थी, और उसके बाद maintenance cost 10 cent/month जैसी थी।

  • ऐसे पोस्ट देखकर मुझे हमेशा हँसी आती है।
    बात सही भी है और ग़लत भी, और systems को “जितना संभव हो उतना सरल, लेकिन उससे ज़्यादा सरल नहीं” बनाना चाहिए।
    अगर आप सोचते हैं कि details को बस rough तरीके से पार कर लेंगे, तो बाद में और बड़ी झंझट होगी।
    IAM बस जटिल है।
    users, groups, roles, policies, identity providers, OIDC जैसी चीज़ों का कोई सचमुच सरल implementation मुझे याद नहीं आता।
    मैंने पहले एक ऐसे व्यक्ति को देखा था जिसने Kubernetes adoption का विरोध “बहुत complex” कहकर किया, और बाद में वही Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash, थूक, घास-फूस से Kubernetes का बेहद घटिया और अस्थायी पुनर्निर्माण करता दिखा — और खूब गलतियाँ भी कीं।
    कुछ features शुरू में अनावश्यक लगते हैं, फिर आखिरकार वही ज़रूरी निकलते हैं।
    startup में solo infra engineer के तौर पर काम करने के अनुभव से कहूँ, तो AWS ज़्यादातर लोगों की सीखने की क्षमता के भीतर है, और इसके खराब हिस्सों से आम तौर पर बचा जा सकता है।
    अगर Lambda पसंद नहीं है, तो मत इस्तेमाल कीजिए — EKS, ECS, EC2 इस्तेमाल करिए।

    • अंदरूनी नज़रिए से IAM में शायद हज़ारों options हैं, लेकिन असल में सवाल यह है: “यह role किस चीज़ तक पहुँच सकता है और वहाँ क्या कर सकता है (action + resource)?” और “इस role तक कौन पहुँच सकता है?”
      10,000-foot view से देखें तो बस यही है।
      IAM अच्छा इसलिए है क्योंकि यह बाहर और अंदर दोनों पर एक जैसा लागू होता है।
      AWS की internal teams को कोई अतिरिक्त access इसलिए नहीं मिलता कि वे AWS हैं। अगर customer account में किसी specific service के लिए कुछ करने का हक़ है, तो इसलिए कि customer ने IAM trust relationship में उस service principal को access दिया है, और customer उसे देख और audit कर सकता है।
      उदाहरण के लिए Lambda के लिए Lambda role होता है, क्योंकि आप यह नहीं चाहेंगे कि सिर्फ़ “हम AWS हैं” कहकर Lambda service आपका S3 bucket पढ़ ले।
      AWS internal access भी customer साफ़ तौर पर देख और control कर सकता है।
    • “X बहुत complex है” कहकर adoption रोकना, और फिर आखिर में X का घटिया पुनर्निर्माण कर देना — यह pattern tech और software में आश्चर्यजनक रूप से आम है।
      कुछ चीज़ें अब साफ़ तौर पर standard हैं, फिर भी बहुत से लोग उन्हें ठीक से सीखने में समय देना नहीं चाहते।
    • self-hosting की तुलना में AWS महँगा हो सकता है, लेकिन वह बचत engineering cost के सामने छोटी पड़ जाती है।
      अगर एक अच्छा infra engineer “पैसा बचाने” के लिए OVH setup में 2 महीने लगा दे, तो सिर्फ़ Fargate या RDS न इस्तेमाल करने से जितना बचता, उससे ज़्यादा खर्च हो चुका होगा।

  • सोचता हूँ, Anthropic और OpenAI जैसी कंपनियों के बारे में भी यही बातें कब शुरू होंगी।
    मौजूदा AI wave में शुरुआती AWS जैसी गंध है — सब लोग चढ़ रहे हैं, और बाद में महसूस होगा कि उन्होंने एक ऐसी बड़ी dependency बना ली है जिसे आसानी से हटाया नहीं जा सकता।

  • Lambda सच में शानदार है, और बिना ज़्यादा सिरदर्द के तेज़ iteration cycle के साथ deployment service चलाने का बेहतरीन तरीका है।
    ज़रूरी नहीं कि आप microservices पर जाएँ या code को अरबों छोटे repos में तोड़ दें।
    अगर आप request के बीच server-side state share होने की उम्मीद नहीं करते, तो एक standard web server को Lambda पर ले जाया जा सकता है।

  • मैं उस field में काम नहीं करता, इसलिए AWS को कभी-कभी सिर्फ़ personal fun projects के लिए छूता हूँ, और हर बार यह दुःस्वप्न जैसा लगता है।
    मैं बस एक experimental card game server बनाना चाहता हूँ, कोई नई financial institution नहीं खड़ी कर रहा, लेकिन हर चीज़ ऐसे लगती है जैसे कल ही infinite scale के लिए तैयार होनी चाहिए, और मान लिया गया हो कि आपके पास 1,000 लोगों की org और VC budget है।
    शुक्र है कि Netlify जैसी services ऊपर एक layer दे देती हैं, जिससे पूरा समंदर उबालना नहीं पड़ता।
    शायद किसी दिन मुझे सच में IAM, VPN, और न जाने क्या-क्या सीखना पड़े, लेकिन तब तक AWS को छूते ही आँखें बाहर आने लगती हैं।

    • EC2 या Lightsail पर एक raw VPS चलाइए, public IP जोड़िए, और काम खत्म।
      हर enterprise pattern implement करना ज़रूरी नहीं है।
    • हैरानी होती है कि Heroku ने लगभग 20 साल पहले ही ज़्यादातर web apps की ज़रूरतों को कितना सटीक पकड़ा था।
    • अगर आपने Azure नहीं संभाला, तो AWS ही nightmare लगेगा।
    • मैं Cloudflare पर चला गया और सच में राहत मिली।
      ज़रूरत की सब चीज़ें हैं, और pricing भी reasonable है।
    • AWS personal projects नहीं, enterprise को target करता है।
      personal projects से आखिर में सिर्फ़ cost matter करती है, इसलिए वे AWS को कोई meaningful revenue नहीं देते।

  • 2023 के बाद से AWS में technical talent को व्यवस्थित रूप से खाली किया जा रहा है।
    यह बड़े layoffs या performance improvement plans के दो दौर से हुआ, और presales या support में जो capable लोग थे, उनमें से कई अब AWS में नहीं हैं।
    इसके उलट, जिन लोगों का कामकाजी इतिहास सबसे धुँधला था, वे बचे भी और promote भी हुए — ऐसा मैंने कई बार देखा।
    AWS को हर किसी को अपने जोखिम पर इस्तेमाल करना चाहिए; Paul Vixie आकर बचाने नहीं वाले।

  • बहुत पहले से ElastiCache मुझे खास तौर पर खटकता रहा है।
    RDS में scalability, reasonably optimized settings, और backups जैसी value add होती है जिनके लिए पैसा देना समझ में आता है।
    लेकिन ElastiCache में अतिरिक्त value लगभग नहीं के बराबर है, जबकि pricing शोषणकारी लगती है।
    basic Redis install की तुलना में यह धीमा है, कम optimized है, कम stable है, और बिना config वाला Redis कई DBs support करता है जबकि ElastiCache सिर्फ़ एक।
    scaling में कुछ सुधार ज़रूर हैं, लेकिन basic Redis समान instance पर ElastiCache से इतना आगे निकल जाता है कि उन सुधारों की वास्तविक ज़रूरत बहुत कम पड़ती है।

    • ElastiCache वाकई उन services में से है जहाँ self-hosting पर गंभीरता से विचार किया जा सकता है।
      AWS API या polish के मामले में बहुत कुछ extra नहीं देता, और दूसरी तरफ़ Redis/Valkey खुद host करने के लिए सबसे सरल services में से हैं।