EC2-Classic को विदाई, यह एक शानदार दौर था

 (allthingsdistributed.com)
1 पॉइंट द्वारा GN⁺ 2023-09-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS ने 15 अगस्त 2023 को EC2-Classic के आखिरी instance को बंद कर दिया, और इसके साथ 2006 में EC2 लॉन्च के समय शुरू हुए शुरुआती cloud compute model का संचालन समाप्त हुआ
  • Classic की मुख्य विशेषता 10.0.0.0/8 single flat network थी, और उस समय इसकी सबसे बड़ी नवाचार यही थी कि इसने जटिल internal implementation को छिपाकर compute हासिल करना आसान बना दिया
  • 2006 में m1.small ने 1.7GHz Xeon-स्तर का vCPU, 1.75GB RAM, 160GB local disk, 250Mb/s network को प्रति घंटा $0.10 में उपलब्ध कराया था, और बाद में EC2, P3dn.24xlarge जैसे बड़े instances तक विस्तृत हुआ
  • Elastic IP, Auto Scaling, Load Balancing, CloudWatch और नए instance types जोड़े गए, और 2013 में VPC प्रत्येक ग्राहक के लिए isolated और definable cloud area के नए standard के रूप में उभरा
  • Nitro जैसे नए virtualization platform आने के बाद भी Classic को ग्राहकों के उपयोग के कारण 10 साल और बनाए रखा गया, और सभी instances के बंद या migrate होने तक documentation, tools और support जारी रहे

EC2-Classic का अंत और शुरुआती संरचना

  • AWS ने हमेशा उन services को बंद करते समय सावधानी बरती है जिन पर ग्राहकों का business निर्भर करता है
    • SimpleDB आज भी उपलब्ध है, जबकि DynamoDB ग्राहकों के लिए “NoSQL” DB विकल्प के रूप में स्थापित हो चुका है
  • Jeff Barr की EC2-Classic retirement announcement के 2 साल बाद, 15 अगस्त 2023 को Classic का आखिरी instance बंद हुआ
  • EC2 लगभग 17 वर्षों तक चला, और AWS services में केवल SQS और S3 ही EC2 से पुराने हैं
  • “Classic” को अलग करने वाला सबसे बड़ा तत्व network architecture था
    • 2006 में EC2 की शुरुआत 10.0.0.0/8 के एक विशाल network से हुई
    • सभी instances एक single flat network पर चलते थे जिसे दूसरे ग्राहकों के साथ साझा किया जाता था
    • इसमें security groups और instance launch के समय assign होने वाले Public IP जैसी सुविधाएँ थीं
  • Internal stack बेहद जटिल थी, लेकिन उपयोगकर्ता अपनी ज़रूरत का compute आसानी से हासिल कर सकते थे

instance performance में बदलाव

  • 2006 में m1.small instance चलाने पर यह configuration मिलती थी
    • 1.7GHz Xeon processor के बराबर virtual CPU
    • 1.75GB RAM
    • 160GB local disk
    • 250Mb/s network bandwidth
    • प्रति घंटा $0.10
  • बाद में EC2, P3dn.24xlarge जैसे instances तक विस्तृत हुआ
    • 100Gbps network throughput
    • 96 vCPU
    • 32GiB memory वाले 8 NVIDIA v100 Tensor Core GPU
    • 768GiB system memory
    • 1.8TB local SSD storage
    • ML workloads को accelerate करने के लिए EFA
  • EC2-Classic ने hardware को programmable resource में बदल दिया, जिससे developers, founders, startups और enterprises अपनी ज़रूरत के अनुसार जब चाहें जितना compute इस्तेमाल कर सकें
    • Infrastructure management, नया hardware खरीदना, software upgrades, और खराब disk बदलने जैसी जटिलताएँ abstract हो गईं

VPC में बदलाव और दीर्घकालिक support

  • यह blog EC2 launch के तुरंत बाद m1.small पर migrate किया गया था, और Moveable Type तथा local database चलाता था
    • बाद में यह RDS failover जैसी सुविधाओं वाली high-availability service में बदल गया
    • 2011 में Amazon S3 Website feature आने के बाद इसे S3-आधारित setup में migrate किया गया
    • इसके बाद 12 साल तक यह “serverless” स्थिति में चला
  • ग्राहकों की बढ़ती मांग के साथ Elastic IP, Auto Scaling, Load Balancing, CloudWatch और कई नए instance types जोड़े गए
  • 2013 में VPC उपलब्ध होने के बाद हर AWS ग्राहक सुरक्षित, isolated और अपने business के अनुरूप परिभाषित cloud area को manage कर सकता था
    • VPC नया standard बन गया और इसने ग्राहकों को cloud में अधिक व्यापक systems बनाने के लिए बेहतर स्तर का control दिया
  • EC2 के Nitro नामक नए virtualization platform में विकसित हो जाने के बाद भी Classic को ग्राहक उपयोग के कारण 10 साल और support मिला
  • EC2 team ने सभी Classic instances के बंद या migrate होने तक इसे चालू रखा
    • पूरी प्रक्रिया के दौरान documentation, tools, engineering team support और account management team support उपलब्ध कराया गया
  • EC2-Classic का अंत दिखाता है कि 2006 के बाद cloud कितना बदल चुका है, और यह कि evolvable systems बनाना और architecture को खुले दृष्टिकोण से दोबारा देखना ज़रूरी है

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

1 टिप्पणियां

 
GN⁺ 2023-09-03
Hacker News की राय

  • EC2-Classic जादू जैसा था
    आखिरकार ऐसा लगा कि हम उस भविष्य में पहुंच गए हैं जहां software networking की जिम्मेदारी लेता है, और cables से network बनाने वाले दौर की पुरानी जटिलताओं को भुलाया जा सकता है
    पारंपरिक IP subnet की तुलना में cloud security groups के इर्द-गिर्द चलता था, और अगर hierarchical structure जैसी कुछ क्षमताएं होतीं, तो लगता है यह traditional networking में subnet की भूमिका को पूरी तरह replace कर सकता था
    EC2-Classic को लंबे समय तक इस्तेमाल करने पर network engineering आसान और मजेदार लगी, लेकिन नया VPC तरीका इतना जटिल है कि उत्साह टूट जाता है, और यह भी साफ नहीं कि वह security groups से व्यक्त न हो सकने वाली कौन-सी चीज संभव बनाता है
    पहले भी मैंने इस पर ज्यादा विस्तार से, या मूड के हिसाब से ज्यादा तीखे अंदाज में लिखा है, लेकिन EC2-Classic से हटते समय सबसे बड़ी भावना वही निराशा थी जो तब होती है जब लोग किसी ठीक-ठाक चीज को और खराब बना देते हैं
    https://news.ycombinator.com/item?id=36829190
    https://news.ycombinator.com/item?id=33569889
    https://news.ycombinator.com/item?id=27990847
    https://news.ycombinator.com/item?id=25988915

    • नया account बनाने पर यह असल में पुराने EC2-Classic की तरह ही काम करता है
      पीछे से AWS अपने-आप VPC बना देता है, और जब तक user किसी “कांच तोड़ो” जैसी स्थिति में VPC settings को छेड़ने की जरूरत महसूस न करे, तब तक इसे पुराने Classic जैसा ही इस्तेमाल किया जा सकता है
    • हाल में आया VPC Lattice मूल रूप से “EC2 Classic networking” ही है, बस अब इसके लिए पैसे देने पड़ते हैं
      https://aws.amazon.com/vpc/lattice/
      हालांकि यह सिर्फ flat network पर security groups चढ़ाने से आगे जाता है: हर HTTP endpoint अपने-आप IAM resource बन जाता है, सभी services को AWS-native की तरह संभाला जा सकता है, और वही IAM policies इस्तेमाल की जा सकती हैं, इसलिए यह काफी अच्छा है
    • VPC साफ तौर पर वे काम संभव बनाता है जो Classic नहीं कर सकता था
      public internet से गुजरे बिना internal routing table में AWS की ओर जाने वाली एक single entry जोड़ी जा सकती है; shared flat network में ऐसी configuration समस्या बन जाती है
    • जिन startups में मैंने शुरुआत में काम किया था, उनमें से एक पूरी तरह EC2-Classic पर था, और उसकी simplicity अच्छी लगती थी
      internal network, VPN वगैरह के साथ integrate करते समय VPC की जरूरत समझ आती है, लेकिन असल में कई बार VPC की बिल्कुल जरूरत न होने पर भी यह काम को जरूरत से ज्यादा जटिल बना देता है

  • quote में IPv4 notation confusing है
    लिखा है, “2006 में EC2 launch करते समय यह 10.2.0.0/8 का एक विशाल network था,” लेकिन मेरी समझ में /8 का मतलब है कि सिर्फ पहला octet fixed होता है, यानी range 10.0.0.0~10.255.255.255 होती है
    तो यहां 2 क्यों महत्वपूर्ण है, यह समझ नहीं आता; और अगर 2 महत्वपूर्ण है तो इसे /16 लिखा जाना चाहिए था, ऐसा लगता है
    source और notation को लेकर अपने confidence को देखते हुए लगता है शायद कोई expert इसका कोई और अर्थ निकाल पाए, इसलिए जिज्ञासा है; और अगर यह सिर्फ typo है तो इतना बाल की खाल निकालने के लिए माफी

    • सही point है और यह typo था
      इसे 10.0.0.0/8 होना चाहिए था; blog में इसे ठीक कर दिया गया है, और P3dn.24xlarge की memory से जुड़ी confusion भी साथ में सुधार दी गई है
    • शायद typo ही होगा, लेकिन यह भी संभव लगता है कि 10.0.0.0~10.255.255.255 subnet के अंदर EC2-Classic machines को केवल 10.2.0.0~10.2.255.255 से allocate किया जाता था, और 10.x.0.0~10.x.255.255 को दूसरी services के लिए रखा गया था
    • 10.2.0.0/8 valid subnet mask नहीं है, इसलिए typo होने की संभावना ज्यादा है
      10.2.0.0 से शुरू करके बनाया जा सकने वाला सबसे बड़ा subnet 10.2.0.0/15 है
    • सही है, /8 तो 10.0.0.0/8 है
      मुझे लगता है यह typo से ज्यादा शायद 10.1.0.0/16 को छोड़कर 10.0.0.0/8 को अजीब तरीके से लिखने जैसा भी हो सकता है
    • 10.2.0.0/16 को मैंने मूल रूप से private network address range 10.0.0.0/8 का हिस्सा माना
      मैंने इसे ऐसे समझा कि लेखक कहना चाहता है: machines को 10.2/16 addresses मिलते थे, लेकिन वे 10.1/16 जैसे दूसरे 10/8 subnets में मौजूद AWS services या machines तक भी route कर सकती थीं

  • कहा गया कि “infrastructure management, नया hardware खरीदना, software upgrade, और खराब disk बदलने की complexity abstract हो गई,” लेकिन उसकी जगह सिर्फ AWS की complexity आ गई
    AWS से पहले भी hardware खुद खरीदने या खराब disk खुद बदलने की जरूरत नहीं थी; web hosting provider यह कर देते थे

    • “web hosting provider कर देते थे” कहना बहुत ज्यादा simplify करना है
      बेशक आप खुद data center में जाकर disk नहीं बदलते थे, लेकिन प्रक्रिया AWS में मिलने वाले तरीके से बहुत अलग थी
      आज भी पुराने तरीके से चलने वाले कई web hosting providers हैं, लेकिन लोग AWS जैसी services को पसंद करते हैं तो उसकी वजह है
    • सही है, लेकिन आम तौर पर a) आपको खुद detect और diagnose करना पड़ता था और b) hosting provider के मानने और replace करने में कुछ घंटों से लेकर कई हफ्तों तक लग जाते थे
      कुछ clicks में अलग hardware पर नया server spin up करने की क्षमता से यह बहुत अलग है
    • अगर requirements बड़ी नहीं हैं तो AWS को जरूरी नहीं कि complex होना पड़े; Lightsail जैसी चीज इस्तेमाल की जा सकती है
      अगर जरूरत सिर्फ VPS की है तो VPS इस्तेमाल करें, और निजी तौर पर उस मामले में मुझे Hetzner ज्यादा पसंद है
      लेकिन बड़े organizations की needs handle करनी हों तो AWS का complex होना लाजिमी है
      साथ ही AWS console का EC2 launch interface वाकई काफी बेहतर हो गया है और काफी complexity अपने-आप संभाल लेता है
    • यह देखते हुए कि AWS या Azure जितना बड़ा कोई single web hosting provider नहीं हुआ, industry किस तरह की complexity स्वीकार करने को तैयार है, यह काफी साफ है
      Oracle भी अपनी तमाम reputation के बावजूद अब भी अरबों dollars कमा रहा है

  • मैं “किसी सेवा को बंद करना AWS में आम बात नहीं है, और यह काफी दुर्लभ है” वाला वाक्य पढ़ ही रहा था, और उसी समय मई में बंद होने से पहले OpsWorks से अपनी चीज़ें हटाने के बड़े एपिक काम से ब्रेक ले रहा था

    • मेरे अनुभव में OpsWorks एक बेहतरीन सेवा थी और इसके बंद होने का सच में अफसोस है
      Kubernetes और Terraform के आने से पहले हमने कुछ क्लस्टर OpsWorks से बनाए थे
      हालांकि AWS के लोगों से जो सुना, उसके मुताबिक अंदरूनी तौर पर इसका रखरखाव ठीक से नहीं हो रहा था और बैकएंड काफी गड़बड़ था, इसलिए जब यह सेवा पहली बार आई थी तब से टेक्नोलॉजी लैंडस्केप इतना बदल चुका है कि अब इसका बंद होना चौंकाने वाला नहीं है
      RIP OpsWorks
    • यह हिस्सा काफी अटपटा लगा
      शीर्षक “हम X करते हैं” जैसा है, लेकिन मुख्य टेक्स्ट “हम यहाँ X नहीं करते” जैसा पढ़ा जाता है, इसलिए शुरू में समझ नहीं आया कि लेख कहना क्या चाहता है
    • मैं भी AWS Data Pipeline से कुछ माइग्रेट करने के बाद की दिक्कतें संभाल रहा था, तो मुझे भी वैसा ही महसूस हुआ
      वह सेवा “maintenance mode” में चली गई थी और इस साल की शुरुआत में console access भी हटा दिया गया

  • “10 साल पहले 2013 के re:Invent keynote में हमने कहा था कि हम आज के workloads और कल के workloads दोनों को support करना चाहते हैं, और Classic के प्रति हमारी प्रतिबद्धता इसका सबसे अच्छा सबूत है” वाला हिस्सा ही वह कारण है कि कंपनियां AWS पर भरोसा करती हैं
    EC2 टीम ने तब तक Classic को अच्छे से चलाए रखा जब तक सभी instances बंद या migrate नहीं हो गए, और मुझे लगता है ऐसे काम भरोसा बनाते हैं

  • Serif में काम करते समय, मुझे अभी भी वह समय याद है जब scrapbook desktop software के साथ integrate होने वाली नई social media website के लिए web hosting की जरूरत थी
    उस समय हमेशा की तरह कई चमकदार नई technologies थीं, उनमें से एक Microsoft Silverlight थी, और हमने website पर “Deep Zoom” implement किया ताकि users प्रकाशित scrapbooks को आसानी से zoom करके details देख सकें
    एक और नई technology AWS थी, और EC2 अभी-अभी launch हुआ था, इसलिए एक button से US, Ireland और Amsterdam में instances शुरू करना और वे मर जाएं तो फिर button दबाकर नए शुरू कर देना काफी exciting था
    आज की तरह उस समय भी सरल UI के पीछे काफी complexity छिपी थी, और हमें कई storage types और उनमें से कौन persistent है, यह सीखना पड़ा
    शुरुआती EC2 instances शायद आज जितने reliable नहीं थे, और वास्तव में हमने एक-दो पूरी तरह खो दिए थे, जिन्हें फिर से बनाना पड़ा, इसलिए हमने काफी snapshots लिए
    Infrastructure as Code या DevOps नहीं था, लेकिन हमने अपना high-availability cluster बनाया था, और मेरे साथ काम करने वाले एक engineer ने C++ में scratch से software लिखा था, जो कई EC2 instances के databases को monitor करता और cluster को alive रखता था
    उस समय cloud architects भी नहीं थे, इसलिए हमें ठीक-ठीक नहीं पता था कि हम क्या कर रहे हैं या क्या समझदारी है, लेकिन technology बहुत अच्छी तरह काम करती थी, और शुरुआती trial-and-error पार करने के बाद हमने एक काफी active internet community बना ली थी
    website PHP और MySQL से बनी थी, SQL के relational data से बने XML को XSLT से HTML में बदला जाता था, JavaScript ज्यादा नहीं था, बस jQuery जैसा कुछ था
    deployment शायद FileZilla से upload करके होता था, जिसके बाद C++ cluster software upload हुई files को दूसरे availability zones के EC2 instances में replicate करता था
    पीछे मुड़कर देखें तो शायद तीन availability zones में servers रखने की जरूरत नहीं थी, लेकिन काम सच में मजेदार था और AWS से मेरा पहला परिचय कराने वाला अच्छा दौर था

    • वह दौर याद है
      AWS में database layer नहीं थी, इसलिए durability के लिए हम Elastic Block Store लगे हुए instances इस्तेमाल करते थे

  • अब बस इतना चाहिए कि credit card bill के बेकाबू हो जाने की संभावना के बजाय सच में fixed budget allow किया जाए
    Microsoft यह करता है और मुझे याद है Google भी करता था, लेकिन समझ नहीं आता Amazon क्यों नहीं करता
    इसका इंतजार भी करीब 20 साल से कर रहा हूं

    • ऐसा हुआ तो AWS console में कुछ switches on करने से ज्यादा कुछ न करने वाले महंगे cloud cost optimization consultants का ecosystem ढह जाएगा
    • ऐसा करने पर उनकी कमाई कम होगी, और AWS customers price को लेकर इतने sensitive नहीं हैं
    • वही चीज नहीं है, लेकिन billing alarms और budget notifications set किए जा सकते हैं

  • व्यक्तिगत रूप से मुझे अच्छा लगता अगर AWS बस फैसला लेकर Classic में IPv6 जोड़ देता और उसे जारी रखता
    विडंबना यह है कि post-Classic पीछे हटने जैसा लगता है, और cloud से पहले जिस infrastructure से निपटना पड़ता था, उससे यह कहीं ज्यादा मिलता-जुलता हो गया
    नई चीजों में से ज्यादातर मैं Cloudflare के ऊपर बना रहा हूं, इसलिए अब subnets, VPC जैसी चीजों के बारे में लगभग सोचता ही नहीं

    • EC2 business बढ़ाने का तरीका सिर्फ नए startups को नहीं, बल्कि existing enterprises को cloud में लाना था
      इन सभी को अपने internal networks के साथ integrate करना होता है, इसलिए VPC की जरूरत पड़ती है

  • अगर मैंने सही समझा है, तो मुझे आश्चर्य है कि क्या सभी Classic instances account owner के हस्तक्षेप के बिना ज़्यादा आधुनिक types पर migrate कर दिए गए थे
    यह भी जानना चाहूंगा कि उस प्रक्रिया में reboot हुआ था, या इसे live migration से संभाला गया था
    क्योंकि virtualization platform से live migration निकालना मुश्किल होता है, अगर उसे मूल रूप से इस बात को ध्यान में रखकर नहीं बनाया गया हो
    यह भी जिज्ञासा है कि मूल network settings अभी भी emulate की जा रही हैं, या कुछ customer applications टूट भी सकती थीं

    • नहीं, migration के लिए account owner का हस्तक्षेप ज़रूरी था
      ज़्यादा जानकारी यहाँ है: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
      लगता है AWS ने ग्राहकों को EC2-Classic से हटाने के लिए समय, लोग और पैसा लगाया, और process को automate करके कम दर्दनाक बनाने की भी काफ़ी कोशिश की
      उदाहरण: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
      मूल network उस model से बदल गया था जिसमें सभी एक ही subnet में थे, उस model में जहाँ हर किसी को अपना subnet मिलता है, इसलिए customer applications सचमुच टूट सकती थीं
      जैसे nameserver के बंद होने पर /etc/hosts में IP address hardcode कर देना और बाद में वापस बदलना भूल जाना—लोग पर्याप्त वजह होने पर बहुत समझदारी वाली चीज़ें नहीं भी करते
      इस तरह की migration सही से करने के लिए stick और carrot दोनों चाहिए
      stick यह है कि अंततः service बंद कर दी जाएगी और provide करने से इनकार किया जाएगा, और carrot है automation, maintenance window की ज़रूरत के बारे में बार-बार reminders, स्पष्ट guidance, और सबसे बढ़कर ग्राहकों से सचमुच बात करने और respond करने की इच्छा
    • सिर्फ़ restart ही ज़रूरी नहीं था, network reconfiguration भी करनी पड़ी
      हालांकि AWS ने लोगों को यह करने के लिए कई साल दिए, और ज़रूरत पड़ने पर हर user तक जाकर मदद की
    • साफ़ नहीं है, लेकिन मेरी व्याख्या में AWS ने सभी account owners से संपर्क करके किसी तरह उन्हें migrate करने के लिए मनाया, और सबके move हो जाने के बाद इसे बंद किया
      discounts या shutdown की धमकी भी रही होगी
      यह हैरानी की बात है कि ऐसा एक भी instance नहीं था जिसे owner ने भूल गया हो या जिस पर काम करने से मना कर दिया हो, इसलिए यह कैसे संभव हुआ, यह वाकई दिलचस्प है
      credit card expiry अहम वजह रही होगी; संभव है कि भूले हुए ज़्यादातर accounts अपने-आप deactivate हो गए हों
    • इस specific migration की details नहीं जानता, लेकिन पहले मैंने low-cost tier VM कई साल तक चलाया था और अंत में AWS ने maintenance कारणों से इसे terminate करने की email भेजी थी
      शायद तरीका कुछ ऐसा ही रहा होगा
      VM को move करना मुश्किल होता है, जब तक उसे खास तौर पर movable बनाने के लिए configure न किया गया हो; उदाहरण के लिए PCIe bus में devices का order बदल सकता है, और MAC address जैसे कई machine IDs भी बदल सकते हैं
      अगर यह guarantee न हो कि VM ऐसी changes से प्रभावित नहीं होगा, तो move के बाद problems आने की संभावना काफ़ी होती है

  • इस स्तर का support level हर software company का लक्ष्य होना चाहिए
    enterprise customers यही देखना चाहते हैं, और वे इसी के लिए पैसा भी देते हैं

    • जिन companies में मैं काम करता हूँ, वहाँ हम AWS को इसलिए चुनते रहते हैं कि उसकी offered capabilities बेहतर हैं, ऐसा नहीं; बल्कि इसलिए कि support कहीं ज़्यादा बेहतर है