मैं एक cloud बना रहा हूँ
(crawshaw.io)- मौजूदा 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 बनाना है जिसे लोग वास्तव में इस्तेमाल करना चाहें
6 टिप्पणियां
अब आकर लगता है, क्यों? ..
लेकिन यह देखकर कि लेखक Tailscale के सह-संस्थापक हैं, किसी वजह से उनका समर्थन करने का मन हो रहा है
कृपया इसे अच्छी तरह बनाइए!
प्राइसिंग टेबल बहुत भ्रमित करने वाली है, क्योंकि उसमें 2 कोर 8 गीगाबाइट, vm 50 जैसी तरह से लिखा है। मेरा ख्याल है कि इसे ऐसे समझना चाहिए कि एक VM मिलता है और उस पर 50 कंटेनर चला सकते हैं।
क्लाउड जटिल होने की एक वजह है।
अकाउंट हटाने का फ़ीचर दिख नहीं रहा, क्या किसी को यह मिला है?
अगर सिर्फ drag and drop से services को आपस में जोड़ा जा सके, तो बहुत अच्छा होगा।
Hacker News की राय
Kubernetes शुरुआत में कुछ web app containers चलाने के लिए ठीक लग सकता है, लेकिन जल्द ही उस पर SDN चढ़ जाता है और तरह-तरह की services जुड़ते-जुड़ते वह काबू से बाहर फूला हुआ ढांचा बन जाता है
क्लस्टर को जितना ज़्यादा "optimize" और "harden" किया, cloud cost, outages, downtime, debugging effort—सब कुछ 2~3 गुना बढ़ गया
आखिरकार उस DevOps inertia को छोड़कर cluster हटा दिया, फिर Debian single VM पर firewall चालू करके Kamal से Docker deploy किया तो infra stability और reliability सबसे बेहतर हुई, और लागत भी बहुत कम हो गई
ज़्यादातर business apps सैकड़ों से लेकर कुछ हज़ार users के स्तर के होते हैं, इसलिए एक बड़ा VM ही अक्सर काफ़ी होता है, और Google जैसी cloud कंपनियाँ hardware failure संभाल लेती हैं, इसलिए ज़रूरत पड़ने पर दूसरा VM उठाकर Cloudflare में सिर्फ IP बदल देना ही काफी हो सकता है
बहुत छोटे scale पर भी k8s ठूंस दिया जाता है, और ऐसे में लगता है कि शुरू से ही वह k8s की ज़रूरत वाला scale नहीं था
इसलिए आम deployment patterns को सरल बनाने वाली ऊपरी layer की ज़रूरत होती है, और Knative उसका एक उदाहरण है
जो समाधान नीचे के सारे primitives expose करना चाहता है, वह अंततः Kubernetes जितना ही complex हो जाता है
मेरा बनाया https://github.com/openrundev/openrun teams के लिए internal web app deployment को declarative तरीके से संभालता है, SAML/OAuth और RBAC भी जोड़ता है, और Docker single machine तथा Kubernetes दोनों को support करता है
ज़रूरत से ज़्यादा complex, debug करना मुश्किल और महँगी सोच VM पर भी वैसी ही दोहराई जा सकती है
बस अभी single Debian VM शायद उनकी policy radar से बाहर है, इसलिए वह आज़ाद है
जैसे ही कोई बीच में दखल देगा, HA, rollout/rollback, 3~5 VM, virtual network policies, 4 security scanners, 2 log processors, watchdog, network monitor, mTLS, traffic visibility उपकरण—सब जोड़ने की कोशिश शुरू हो सकती है
एक और machine होने से upgrades या changes के दौरान outage हो जाए तो भी कम घबराहट होती है
मैं जो https://github.com/psviderski/uncloud बना रहा हूँ, वह Kamal से प्रेरित है और multi-machine setup को single VM जितना simple बनाता है, zero-config WireGuard overlay और standard Docker Compose के साथ कई VMs पर deploy करता है
orchestrator या control plane की complexity के बिना 1 machine से शुरू कर सकते हैं, और ज़रूरत पड़ने पर cloud VM और on-prem को मिलाकर scale कर सकते हैं
production में इस्तेमाल किया तो हर पल शानदार लगा, और लगा कि इसने computing को ही दोबारा परिभाषित कर दिया
इसलिए इतना नापसंद करने वाले पक्ष का नज़रिया शायद मुझसे छूट रहा है
OP, Tailscale के cofounders में से एक हैं, इसलिए संदर्भ के हिसाब से यह और दिलचस्प है
यह बात बिल्कुल सही लगती है कि पारंपरिक Cloud 1.0 कंपनियाँ VM के default में लगभग 3000 IOPS देती हैं, जबकि laptop 5 लाख IOPS दे सकता है
vision वाकई अच्छा है, और मैं खुद भी शायद target customer जैसा हूँ, लेकिन डर यह है कि जैसे-जैसे सफलता बढ़ेगी, आदर्शों से ज़्यादा revenue pressure आगे आ जाएगा
cloud pricing अक्सर cost-based नहीं होती, और ख़ासकर bandwidth या NAT gateway जैसी चीज़ों में, जहाँ ग्राहक गहराई से lock-in हो चुके होते हैं, वहीं मुनाफ़ा ज़्यादा निकालने के लिए इसे design किया जाता है
मुझे नहीं लगता कि OP इस ढांचे से अनजान होंगे
लेकिन वह storage मूल रूप से ephemeral होती है, और redundancy भी पर्याप्त नहीं होती
RAID1 से hardware failure का जोखिम कुछ कम कर सकते हैं, लेकिन इससे लगाए जा सकने वाले NVMe की संख्या घट जाती है, और host की RAM/CPU जैसी दूसरी समस्याओं के कारण VM को कहीं और ले जाना हो तो उसका साफ-सुथरा तरीका नहीं होता
आखिर में ऐसे VM को लगभग bare metal की तरह treat करना पड़ता है, और database replication जैसी application-layer redundancy चाहिए होती है
Azure में मानकर चलना पड़ता है कि वे जब चाहें VM migrate कर सकते हैं और ephemeral data उड़ा सकते हैं, लेकिन OpenStack में ज़रूरत पड़ने पर VM बंद करके local block-level migration से NVMe data समेत दूसरे host पर कॉपी किया जा सकता था
फिर भी अगर host crash हो जाए तो वह VM host के वापस आने तक down ही रहता था, इसलिए app-level redundancy पहले से मानकर चलनी पड़ती थी
लेकिन 99.9 percentile latency Hetzner में लगभग 5ms और DO में लगभग 18ms थी, और max latency Hetzner में 7ms के आसपास जबकि DO में 85ms थी, यानी फ़र्क काफ़ी बड़ा था
sequential dd में Hetzner 1.9GB/s और DO 850MB/s था
कीमत में भी बड़ा फ़र्क था: Hetzner 4 euro, जबकि DO instance 18 dollars का था
मैंने पूरा लेख पढ़ने से पहले ही यह लिख दिया था, और संयोग से OP भी ठीक इन्हीं दो चीज़ों की बात कर रहे थे
यानी simple server पर भी machine-internal DB चलाना मुश्किल बनाकर lock-in कराया जा रहा हो सकता है
किसी चीज़ को बनाने में X खर्च आया तो 1.y*X पर Y price तय कर देंगे—असल market pricing ऐसा नहीं चलती
bottom-up से ज़्यादा top-down ज़्यादा यथार्थवादी है
जैसे AI के इर्द-गिर्द बहस चरम ध्रुवों में बँटी दिखती है, वैसे ही Kubernetes भी वैसा ही polarized लगता है
मैंने कई साल अलग-अलग आकार के clusters चलाए हैं, लेकिन outage का root cause कभी k8s खुद नहीं रहा
एक बार एक घंटे का लगभग total blackout जैसा outage हुआ था, और k8s से नफ़रत करने वाले लोग तुरंत उसी "कमबख्त k8s system" को दोष देने लगे
असली कारण यह था कि एक service ने खास परिस्थिति में अचानक tens of thousands ports खोल दिए और self-DOS कर लिया
मैं न तो मानता हूँ कि k8s ही पूरा future है, न यह कि वह कूड़ा है; जब सच में ज़रूरत हो, तब यह बहुत अच्छा system है
एक, सीखने के लिए यह बहुत complex है जबकि मेरी समस्या में इसकी ज़रूरत नहीं और पुराना deployment तरीका ही काफी है; दूसरा, bare metal की तुलना में इसकी cost/energy efficiency कम है
अक्सर दोनों बातें साथ-साथ चलती हैं
संतुलित, तटस्थ या उदासीन रुख अब उल्टा कम मिलता है, और अमेरिकी राजनीति भी तुरंत याद आती है
मुझे भी k8s की ज़्यादा समझ नहीं है; staff engineer जब pod और cluster की बात करता है तो मेरी नज़रें खाली हो जाती हैं, लेकिन हमारी team के लिए यह सही बैठता है और सच में काम करता है
जिसके हाथ में सिर्फ हथौड़ा हो, उसे हर चीज़ कील लगती है; और जिसके पास कुल्हाड़ी हो, उसे समझ नहीं आता कि लोग लकड़ी को हथौड़े से क्यों पीट रहे हैं
अगर काम सच में कुल्हाड़ी वाला हो, फिर भी हथौड़ा पकड़े आदमी से नौकरी छिन जाए, तो हथौड़े से नफ़रत करना और भी आसान हो जाता है
k8s में कई use cases के लिए best practices कुछ हद तक तय हो चुके हैं, लेकिन LLM में तो अभी यह भी साफ़ नहीं कि best practice है क्या
इस बात से मैं बहुत सहमत हूँ कि VM का CPU/memory से बँधा होना मतलब काम के लिए नहीं, समय के लिए पैसे देना है
इसी वजह से मैंने एक सस्ता Hetzner auction server लिया और उसे अपने बनाए self-hostable Firecracker orchestrator पर चला रहा हूँ
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
मैं चाहता था कि hardware खरीदूँ, VMs को मनमर्जी से टुकड़ों में बाँटकर इस्तेमाल करूँ, और provisioning या lifecycle की चिंता न करूँ
idle VM अपनी memory state को disk पर snapshot कर देता है और RAM पूरी वापस कर देता है, इसलिए hardware मेरा है, VM disposable हैं, और idle रहने पर लागत लगभग शून्य हो जाती है
खासकर memory-state snapshot आने के बाद, हर चीज़ को resume कर पाना मेरी अपेक्षा से कहीं ज़्यादा शक्तिशाली निकला
logged-in Chromium state को snapshot करके ज़रूरत पड़ने पर session clones तुरंत उठाए जा सकते हैं, agents sandbox के अंदर काम करते हैं, और preview environment के लिए docker compose भी वहीं चलता है
जब कुछ नहीं चल रहा होता, server लगभग idle होता है, और 100 डॉलर प्रति माह का एक box यह सब संभाल लेता है
इसका विवरण https://shellbox.dev/blog/race-to-the-bottom.html में है
documentation अच्छी और उपयोगी है, लेकिन काफ़ी हिस्सों में AI से लिखी हुई लगने वाली शैली दिखती है; थोड़ा और संक्षिप्त हो तो बेहतर हो
फिर भी "design decisions" section खास तौर पर अच्छा लगा, और वहाँ मैंने कुछ नया सीखा भी
अगर अभी तक नहीं किया है, तो इसे Show HN पर भी डालना चाहिए
जब पहले से ही इतना software है जिसे कोई इस्तेमाल नहीं करता, तो समझ नहीं आता कि हम और ज़्यादा code उगलने को लेकर इतने obsessed क्यों हैं
app store देख लो—ऐसे software से भरे पड़े हैं जिन्हें कोई नहीं चलाता
LLM का ज़्यादा स्पष्ट उपयोग software को और बढ़ाने में नहीं, बल्कि बेहतर software बनाने में होना चाहिए
उम्मीद है फोकस सिर्फ code generation से हटकर दूसरी दिशा में जाएगा, क्योंकि LLM बेहतर code लिखने में मदद करने के कई तरीके हैं
बारीकी से बनाया, maintain किया और update किया जाने वाला deterministic system वाला चित्र बना रहेगा, लेकिन AI पहले से ही users के computer interactions का तरीका बदल रहा है
इसके नतीजे में कहीं ज़्यादा disposable जैसा software पैदा होगा
अभी हम "AI engineers को software लिखने में कैसे मदद करे" वाले चरण में हैं, लेकिन धीरे-धीरे यह "engineers AI को software बेहतर लिखने में कैसे मदद करें" की तरफ़ जा रहा है
तब software क्या है और computer interaction कैसे बनाया जाना चाहिए, इस पर बिल्कुल अलग नज़रिए वाले नए engineers का एक समूह सामने आएगा
बहुत-सा ऐसा custom software होगा जो कभी app store तक पहुँचेगा ही नहीं
Jevons paradox तब होता है जब software production की unit cost कम होने के बावजूद demand इतनी बढ़ जाए कि कुल खर्च उल्टा बढ़ जाए
यह विचार उन markets में लागू होता है जहाँ price changes पर demand quantity बहुत संवेदनशील हो, यानी demand elasticity ऊँची हो
games को छोड़ दें, तो बाद में शायद हम पलटकर देखेंगे कि करोड़ों या अरबों लोगों के लिए एक ही software बनाना कितना अजीब मॉडल था
अब लोग टकराती priorities या विकृत revenue model के कम बंधक होंगे, और ऐसा software बना सकेंगे जो ठीक वही करे जो वे वास्तव में चाहते हैं
परिभाषा के हिसाब से ऐसा software ज़्यादा high-quality भी माना जा सकता है
इससे दोनों पक्षों के लिए cost और revenue का अनुमान लगाना आसान हुआ, लेकिन मूल बात यह थी कि software को जितना हो सके अधिकतम generic बनाया जाए
नतीजतन जो UX या features सिर्फ कुछ users के लिए अहम थे, वे बार-बार कटते गए
Vibe coding और LLM-accelerated development इस व्यवस्था को उलट सकते हैं
अब हर कोई अपनी ज़रूरतों और पसंद के मुताबिक custom software अफोर्ड कर सकेगा, और आप ऐसी दुनिया की कल्पना कर सकते हैं जहाँ Salesforce के 1.5 लाख customers एक ही CRM नहीं, बल्कि 1.5 लाख customized CRM इस्तेमाल करें
software के विस्तार की गुंजाइश अभी बेहद विशाल है
अगर आप software bloating cycle को नहीं समझते, तो वही गलतियाँ बार-बार दोहराएँगे
lean software से शुरुआत होती है, फिर user-requested features जुड़ते जाते हैं, चीज़ bloated mess बन जाती है, फिर छोटे rewrite की ज़रूरत पड़ती है, और फिर वापस lean software पर लौट आते हैं
reboot अक्सर असफल हो जाते हैं, या फिर किसी अहम चीज़ को सही पकड़ लेते हैं और मौजूदा ताकतवर खिलाड़ियों को चुनौती देने लायक आगे बढ़ जाते हैं
DevOps को resume padding या अनावश्यक complexity की जड़ मानकर नीचा दिखाने वाला नज़रिया मुझे ज़्यादा startup mindset लगता है
छोटी कंपनी में एक DevOps व्यक्ति शायद पूरी infrastructure संभाल ले, लेकिन खासकर finance में, असली दिशा तय करने वाले अक्सर platform engineering MDs होते हैं
वे software engineers को ढेर सारे छोटे groups में बाँटते हैं, चाहते हैं कि हर team अपने repo, अपनी deployment, अपना सब कुछ खुद control करे, और मानते हैं कि microservices उन्हें वही ताकत देते हैं
मैं दावे से कह सकता हूँ कि DevOps वाले complexity से नफ़रत करते हैं
रात और weekend में page होकर उठने वाले वही लोग होते हैं, और हर बार शुरुआत इसी मानकर होती है कि "infra problem" है
deployment logs भले log aggregation system में मौजूद हों, फिर भी developers का अपने deployment issue को खुद logs देखकर सुलझाना दुर्लभ है; बात जल्दी ही Incident बन जाती है
अब क्या microservices को भी बीत चुका fad नहीं मान लेना चाहिए?
exe.dev मुझे अच्छा लगा, और मुझे भी लगता है कि LLM development flow को smooth बनाते हुए root access वाले Linux machine की flexibility देने में निश्चित अवसर है
लेकिन जब मैंने यह पंक्ति पढ़ी कि "आधे-अधूरे implemented और आधे-अधूरे सोचे गए abstractions ने बार-बार धोखा दिया", तो विडंबना से वही अनुभव मुझे Tailscale के साथ भी हुआ था
networking आसान बनाने का दावा था, फिर battery इतनी जल्दी क्यों खत्म होती है, firewall rules दूसरे tools से टकराने लायक क्यों बदल दिए जाते हैं, bug tracker इतना शांत क्यों है—आख़िर में खुद मुझे इसकी internal implementation समझनी पड़ती है
और तब मन से निकलता है: "No thank you"
service खुद तो सच में शानदार लगती है
मैं router ACL नहीं लिखना चाहता, बल्कि peer-to-peer network layer बनाना चाहता हूँ, और वही हिस्सा निराश करता है
मैं तो बस Hetzner इस्तेमाल करता हूँ
cloud कंपनियाँ जो कुछ देती हैं वह सब बहुत महँगा है, और मेरे अपने Postgres HA और backups 10 साल से बिना downtime के चल रहे हैं, फिर भी उनकी लागत production RDS या CloudSQL की दसवें हिस्से के करीब रही है
Grafana से जुटाए metrics के आधार पर मैं instances को खुद autoscale करता हूँ, और webhook-based autoscaler भी बहुत simple है और कभी समस्या नहीं बनी
इसलिए अब समझ नहीं आता कि GCP या AWS की जरूरत क्यों है
services सब HA हैं और backups भी रोज़ बहुत अच्छी तरह होते हैं
तब लक्ष्य था dedicated server के सबसे flexible अनुभव को सस्ते में दोहराना, और UML ने यह संभव बनाया
लेकिन 2010s भर मैं यह सोचने में पूरी तरह गलत निकला कि ज़्यादातर developers थोड़ी-सी convenience के लिए stack के हर हिस्से पर metered billing वाला मॉडल नहीं चुनेंगे
सोचता हूँ आज के 20s में software engineers में कितने लोग eBay से खरीदे server और router के साथ high-traffic webapp platform खड़ा करना जानते हैं
मैंने खुद पिछले साल ऐसा करके 50PiB+ datastore बनाया था, और सचमुच जानना चाहता हूँ कि medium-to-large projects में यह तरीका कितना इस्तेमाल होता है
Hetzner physical झंझट बहुत कम कर देता है, जबकि economic advantage लगभग वैसा ही देता है; फिर भी वह hosting world का king क्यों नहीं है और 2021 के हिसाब से सिर्फ 367 million euro revenue पर क्यों है, यह अजीब लगता है
dedicated servers के समूह को संभालने का ज्ञान इतना भी niche हो गया है कि लोग इतनी बड़ी बचत को नज़रअंदाज़ कर दें—यह मानना मुश्किल लगता है
लेकिन हाँ, अगर सही लोग मिल जाएँ तो खुद चलाना कहीं सस्ता पड़ सकता है
हर minute cron
docker pullसे latest image खींचता है, और सिर्फ नया version होने परdocker up -dसे उसे बदल देता हैसामने HTTPS के लिए caddy है, और यह setup कई सालों से बहुत सस्ते और स्थिर तरीके से चल रहा है
यह मिलती-जुलती philosophy वाला UK-based provider लगा; अभी इस्तेमाल नहीं किया, लेकिन अगले VPS candidate के रूप में account बना लिया है
शुरुआत से ही 5 गुना तेज़ server झेला जा सकता है, इसलिए autoscaling की ज़रूरत ही नहीं पड़ती
विकल्प पहले से बहुत हैं, और मैंने https://shellbox.dev बनाया है
exe से अलग यह जितना इस्तेमाल उतना भुगतान मॉडल पर है, scale-to-zero करता है, और SSH से तुरंत VM उठा सकते हैं
यह सामान्य Linux है, इसलिए VSCode और Zed remote को support करता है, और nested virtualization भी संभव है
अगर निवेश करना चाहें, तो 5 million dollars भी चलेगा
बाहर की ओर खुला कोई port नहीं है, और सारे web frontends password-protected हैं
इसे public करने का इरादा नहीं; यह TV के पीछे रखे निजी Raspberry Pi पर चलने वाला मेरा isolated development environment है
लागत भी लगभग शून्य है
service के लिए शुभकामनाएँ
underlying infrastructure कहाँ है, कौन-सी security guarantees हैं—यह सब स्पष्ट नहीं है, इसलिए workload सौंपना कठिन लगता है