मैं एक cloud बना रहा हूँ

• मौजूदा cloud abstractions CPU, memory और disk को मनचाहे तरीके से जोड़कर इस्तेमाल करना मुश्किल बना देते हैं, और VM व PaaS दोनों ही एक सामान्य computer से ज़्यादा constraints लगा देते हैं
• Remote block storage और ऊँची egress लागत HDD युग की धारणाओं पर टिके ढाँचे को बनाए रखते हैं, जिससे SSD और आधुनिक network वातावरण में performance और cost की समस्या और बढ़ जाती है
• Kubernetes मुश्किल cloud APIs को ऊपर से ढँक देता है, लेकिन गलत मूल abstraction को बदल नहीं पाता, इसलिए VM, disk और network की सीमाएँ वैसी की वैसी रहती हैं
• जैसे-जैसे agents की वजह से software और execution की मांग बढ़ती है, private execution space, आसान sharing और कम operational overhead और महत्वपूर्ण हो जाते हैं, और मौजूदा cloud की संरचनात्मक bottlenecks भी साथ में बढ़ती हैं
• exe.dev पहले CPU और memory उपलब्ध कराता है, फिर उसके ऊपर सीधे VM चलाने देता है, और TLS proxy, auth proxy, local NVMe, asynchronous replication और anycast-आधारित placement को जोड़कर ऐसे cloud के करीब पहुँचना चाहता है जिसे लोग सच में इस्तेमाल करना चाहें

---

नया cloud फिर से क्यों बनाया जा रहा है

• मौजूदा cloud abstractions computers को मनचाहे तरीके से इस्तेमाल करना कठिन बना रहे हैं, और यही नई company शुरू करने का सीधा कारण बना
• Computer अपने आप में अच्छे हैं, लेकिन आज के clouds लगभग हर product में वही constraints दोहराते हैं, और समस्या का मूल सिर्फ UX या API design की गलती नहीं बल्कि मूल building blocks के स्वरूप में है
• VM CPU और memory से बँधे अलग-अलग instances के रूप में दिए जाते हैं, जबकि ज़रूरत ऐसी संरचना की है जिसमें पहले CPU, memory और disk resources लिए जाएँ और फिर उनके ऊपर जितने VM चाहिए उतने चलाए जाएँ
  • Linux VM दरअसल किसी दूसरे Linux के cgroup के भीतर चलने वाली process है, फिर भी मौजूदा cloud में इसे आसानी से संभालना मुश्किल है
  • इसका workaround करने के लिए gVisor या nested virtualization को एक cloud VM के ऊपर चलाना पड़ता है, और performance नुकसान के साथ कम-से-कम reverse proxy चलाने की जिम्मेदारी भी खुद लेनी पड़ती है
• PaaS भी इस समस्या को हल नहीं करता, बल्कि एक सामान्य computer से कम शक्तिशाली vendor-locked abstractions थोप देता है
  • हर compute provider के लिए development का नया तरीका सीखना पड़ता है
  • Project कुछ आगे बढ़ने के बाद ही पता चलता है कि जो काम सामान्य computer पर आसान है, वह platform की गहरी limitations की वजह से लगभग असंभव है
  • कई बार “इस बार हो जाएगा” लगता है, लेकिन फिर आधे-अधूरे abstraction पर जाकर काम अटक जाता है

Disk और network में दिखने वाली संरचनात्मक सीमाएँ

• Disk के मामले में cloud providers remote block storage या उससे भी ज़्यादा सीमित और धीमे S3 जैसे तरीकों को पसंद करते हैं, जो HDD युग में कुछ हद तक तर्कसंगत था
  • Remote storage में sequential read/write पर बहुत बड़ा नुकसान नहीं होता था, और HDD का random seek लगभग 10ms होने से Ethernet connection का 1ms RTT स्वीकार्य लागत था
  • Provider के नज़रिए से standard instance types में एक axis कम हो जाती थी, इसलिए operations आसान हो जाते थे
• लेकिन SSD पर जाने के साथ यह धारणा टूट गई
  • seek time 10ms से घटकर 20 microseconds रह गया
  • Remote block systems का network RTT बेहतर हुआ, लेकिन IOPS overhead HDD दौर के लगभग 10% से बढ़कर SSD युग में 10x से भी अधिक हो गया
  • EC2 में 200k IOPS configuration बनाने के लिए setup भी जटिल है और हर महीने $10,000 देने पड़ते हैं, जबकि MacBook 500k IOPS देता है
• Network technology अपने आप में काफी अच्छी है, लेकिन egress लागत और business structure usability के खिलाफ काम करते हैं
  • Hyperscaler networks बेहतरीन हैं, लेकिन उनकी लागत बहुत अधिक है और दूसरे vendors के साथ interop भी असुविधाजनक बनाती है
  • Cloud providers की egress pricing सामान्य datacenter में server rack करने की तुलना में प्रति GB 10x तक बताई जाती है
  • Usage थोड़ा बढ़ते ही यह multiplier और खराब हो जाता है
  • हर महीने करोड़ों डॉलर खर्च करने वाले customers को बेहतर pricing मिल सकती है, लेकिन हर महीने कुछ दर्जन या कुछ सौ डॉलर वाले projects के लिए यह उपयुक्त नहीं है
  • इस range में आप कुछ भी बनाना चाहें, सस्ते में operate करना मुश्किल बना दिया जाता है

Kubernetes और APIs समस्या को ढँकते हैं, हल नहीं करते

• Cloud APIs से काम करना कष्टदायक है, और Kubernetes इसी दर्द को engineers के लिए कम करने के मकसद से ऊपर की परत के रूप में आया
• लेकिन VM आज भी ऐसे ही कठिन हैं, क्योंकि cloud nested virtualization की जटिलता सीधे उपयोगकर्ता पर डाल देता है
• Disk के मामले में भी Kubernetes के design समय Google के पास कोई सचमुच उपयोगी remote block device जैसा विकल्प नहीं था, और आज भी common pattern मिल जाए तो अंत में अक्सर धीमे storage से बँध जाना पड़ता है
• Network भी अगर आसानी से खोल दिया जाए, तो पास के खुले datacenter के कुछ systems को private link से जोड़कर cloud लागत में से एक शून्य कम किया जा सकता है, इसलिए इसे आसान बनाने का प्रोत्साहन कम है
• Kubernetes को सिर्फ नकली busywork कहने के बजाय, इसे portable और usable cloud बनाने की लगभग असंभव समस्या से निकले परिणाम के रूप में देखा गया है
• बुनियादी रूप से गलत cloud abstraction के ऊपर नया abstraction रखकर समस्या हल नहीं की जा सकती, और Kubernetes को बेहतर बनाते जाने का भी अंततः स्पष्ट limit है
• ऐसे असुविधाजनक cloud के साथ बिताया समय अब 15 साल तक पहुँच चुका है, और इस दौरान इसे किसी अप्रिय software stack की तरह बस सहते हुए न्यूनतम संपर्क में रहकर काम चलाया गया

अब सुधार का सही समय क्यों है

• अभी turning point होने की वजह agents का आना है
• Jevons paradox की तरह, code लिखना जितना आसान होगा, कुल software उतना ही अधिक बनेगा, और लोग काम तथा शौक दोनों के लिए ज़्यादा programs चलाएँगे
• उन बढ़ते programs को चलाने के लिए private execution space, आसान sharing और कम operational overhead चाहिए
• Software की कुल मात्रा बढ़ने के साथ cloud की वे समस्याएँ, जो पहले सिर्फ झुंझलाहट थीं, अब कहीं बड़े bottleneck बन जाती हैं
  • ज़्यादा compute चाहिए और management भी आसान होना चाहिए
  • Agents AWS API को आपकी जगह manipulate करने में मदद कर सकते हैं, लेकिन उन्हें credentials देने पड़ते हैं और वे कभी-कभी production DB भी delete कर सकते हैं
  • सबसे बढ़कर, agents भी मौजूदा cloud abstractions की बुनियादी सीमाओं से टकराकर वहीं अटकते हैं जहाँ इंसान अटकते हैं
  • ज़रूरत से ज़्यादा tokens खर्च होते हैं और नतीजे भी उम्मीद से खराब आते हैं
  • Agent का context window जितना ज़्यादा पुराने cloud मॉडल को जबरन फिट करने में लगेगा, उतनी कम गुंजाइश वास्तविक समस्या हल करने के लिए बचेगी

exe.dev ने सबसे पहले क्या ठीक करना शुरू किया

• exe.dev ने सबसे पहले VM resource isolation problem के समाधान के रूप में अपना product जारी किया
• अलग-अलग VM provision करने के बजाय, पहले CPU और memory दी जाती है और फिर उनके ऊपर मनचाहे VM सीधे चलाए जा सकते हैं
• यह मानकर कि हर नए VM को सीधे internet पर expose नहीं करना चाहिए, TLS proxy और auth proxy दोनों को साथ में संभाला जाता है
• Disk के लिए local NVMe इस्तेमाल होता है, और blocks को machine के बाहर asynchronous replication से कॉपी किया जाता है
• दुनिया के कई regions में machines रखी जा सकती हैं ताकि execution उपयोगकर्ता के करीब हो
• Machines को anycast network के पीछे रखा जाता है ताकि दुनिया भर के users को कम-latency entry point मिले
  • इसी आधार पर आगे और नई features जल्दी जोड़ी जा सकें, ऐसा design किया गया है
• अभी भी बहुत कुछ बनाना बाकी है
  • Static IP जैसी अपेक्षाकृत स्पष्ट चीज़ें अभी बाकी हैं
  • अपने-आप बनने वाले पुराने disk snapshots तक पहुँचने के UX जैसे काम भी बचे हैं
• साथ ही, टीम फिर से उस स्तर पर लौट रही है जहाँ datacenter में सीधे computers rack किए जाते हैं, और software stack की पूरी परतों को network connectivity सहित दोबारा देखा जा रहा है
• अंतिम लक्ष्य ऐसा cloud बनाना है जिसे लोग वास्तव में इस्तेमाल करना चाहें