GitPod ने Kubernetes छोड़ने का फैसला किया + GitPod Flex की घोषणा

xguru · 2024-11-05T10:11:01+09:00

GitPod ने 6 वर्षों तक Kubernetes का उपयोग करके एक "remote development environment platform" बनाया है, जो 15 लाख उपयोगकर्ताओं को सपोर्ट करता है और हर दिन हज़ारों development environments उपलब्ध कराता है लेकिन बाद में यह समझ आया कि Kubernetes development environments बनाने के लिए उपयुक्त नहीं है यह Kubernetes को production workloads के लिए इस्तेमाल करना चाहिए या नहीं, इस बारे में नहीं है, और न ही K8s पर applications deploy करने के लिए developer experience कैसे बनाया जाए, इस विषय पर है → यह cloud में development environments कैसे बनाए जाएँ (या कैसे न बनाए जाएँ), इस बारे में है [Development environments क्यों अलग हैं] इनमें state बहुत अधिक होती है और interaction भी बहुत सक्रिय होता है इन्हें nodes के बीच आसानी से move नहीं किया जा सकता source code, build cache, Docker containers, test data आदि की बड़ी मात्रा अक्सर बदलती रहती है और migration की लागत अधिक होती है production services के विपरीत, developer और environment के बीच 1:1 interaction होता है developers source code और बदलावों से गहराई से जुड़े होते हैं वे source code changes खोना या system द्वारा block किया जाना पसंद नहीं करते development environments failures के प्रति विशेष रूप से संवेदनशील होते हैं इनमें resource usage patterns अनुमान से बाहर होते हैं ज़्यादातर समय CPU bandwidth की बहुत ज़रूरत नहीं होती, लेकिन कुछ सौ ms के भीतर कई cores की ज़रूरत पड़ सकती है यदि यह उससे धीमा हो, तो अस्वीकार्य latency और unresponsiveness दिखाई देती है इन्हें व्यापक permissions और capabilities चाहिए production workloads के विपरीत, root access और packages download/install करने की क्षमता चाहिए जो चीज़ें production workloads में security risk मानी जाती हैं, वे development environments में अपेक्षित व्यवहार हैं (root access, extended network capabilities, अतिरिक्त filesystem mounts आदि) इन विशेषताओं के कारण ये सामान्य application workloads से अलग हैं, और infrastructure decisions पर इनका बड़ा असर पड़ता है [मौजूदा system: Kubernetes] Gitpod के शुरुआती दिनों में Kubernetes infrastructure के लिए आदर्श विकल्प जैसा लगा scalability, container orchestration और समृद्ध ecosystem जैसी चीज़ें cloud development environments की vision से अच्छी तरह मेल खाती थीं लेकिन scale बढ़ने और user base के विस्तार के साथ security और state management के मोर्चे पर मुश्किलें आने लगीं Kubernetes को सुव्यवस्थित application workloads चलाने के लिए डिज़ाइन किया गया था, कठिन development environments के लिए नहीं बड़े पैमाने पर Kubernetes को manage करना जटिल है GKE, EKS जैसी managed services कुछ समस्याएँ कम करती हैं, लेकिन उनकी अपनी constraints और limitations हैं CDE चलाने की कोशिश करने वाली कई teams Kubernetes की जटिलता को कम आँकती हैं इससे Gitpod के पुराने self-managed product पर काफी support burden पड़ा Resource management की कठिनाइयाँ CPU और memory allocation सबसे बड़ी चुनौतियाँ हैं एक node पर environments साझा करना आकर्षक लगता है, लेकिन व्यवहार में noisy neighbor effect काफ़ी बड़ा निकलता है CPU समस्या development environments को अक्सर CPU कम चाहिए होता है, लेकिन अचानक बहुत ज़्यादा चाहिए हो सकता है CFS-आधारित solutions और custom controllers जैसे प्रयोग किए गए, लेकिन predict करना मुश्किल रहा static CPU limits लगाने पर भी कई processes के बीच contention की समस्या आती है Memory management fixed memory allocate करना सरल है, लेकिन सीमित भी overbooking process termination का कारण बन सकती है swap space आने से overbooking की ज़रूरत कुछ हद तक कम हुई Storage performance optimization IOPS और latency development environment experience को प्रभावित करते हैं speed, stability, cost और performance के संतुलन के लिए कई configurations पर प्रयोग किए गए SSD RAID 0 EBS, persistent disks जैसे block storage PVC backup/restore एक महँगा काम है Autoscaling और startup time optimization startup time को न्यूनतम करना सर्वोच्च लक्ष्य था सोचा गया कि एक node पर कई workspaces चलाने से shared cache के कारण startup time बेहतर होगा, लेकिन ऐसा नहीं हुआ Kubernetes startup time पर एक lower bound लगा देता है scale-out तरीकों का विकास ghost workspaces, ballast pods आदि का उपयोग कर scale-out प्रयोग किए गए autoscaler plugins लाने के बाद scaling strategy में बड़ा सुधार हुआ peak load संभालने के लिए proportional autoscaling खाली pods पहले से शुरू करके demand spikes पर तेज़ी से प्रतिक्रिया दी गई image pull optimization के लिए कई प्रयास DaemonSet pre-pull, layer reuse maximization, pre-baked images, Stargazer और lazy pulling, Registry-facade + IPFS Networking की जटिलता development environment access control environments के बीच पूर्ण isolation होना चाहिए network policies मदद करती हैं, लेकिन services की संख्या बढ़ने पर reliability issues आते हैं network bandwidth sharing CNI network shaping को सपोर्ट कर सकता है, लेकिन यह भी एक और control surface बन जाता है Security और isolation: flexibility और protection के बीच संतुलन users को flexibility देते हुए secure environment उपलब्ध कराना सबसे बड़ी चुनौती है users को root privileges देना समस्याओं से भरा है user namespaces अधिक सूक्ष्म समाधान हैं filesystem UID conversion, masked proc mounts, FUSE support, network capabilities उपलब्ध कराना, Docker सक्षम करना user namespace implementation की कठिनाइयाँ performance impact, compatibility issues, complexity, Kubernetes version support [Micro VM experiments] Kubernetes की सीमाएँ महसूस करते हुए Firecracker, Cloud Hypervisor, QEMU जैसी micro VM (uVM) technologies को एक मध्य मार्ग के रूप में तलाशना शुरू किया गया बेहतर resource isolation, दूसरे workloads (जैसे Kubernetes) के साथ compatibility, और बेहतर security की उम्मीद थी, साथ ही containerization के फ़ायदे बनाए रखने की भी उम्मीद थी Micro VM के फ़ायदे इन्होंने cloud development environments के लक्ष्यों के साथ अच्छी तरह मेल खाने वाले आकर्षक benefits दिए बेहतर resource isolation: overbooking की क्षमता घटती है, लेकिन containers की तुलना में resource isolation बेहतर होती है। shared kernel resource contention खत्म हो जाती है, जिससे हर development environment के performance का अनुमान अधिक विश्वसनीय बनता है memory snapshots और fast resume: Firecracker की userfaultfd सुविधा memory snapshots को सपोर्ट करती है। इससे चल रहे processes सहित पूरी मशीन को लगभग तुरंत resume किया जा सकता है। developer के नज़रिये से environment startup काफ़ी तेज़ हो जाता है और काम वहीं से फिर शुरू किया जा सकता है जहाँ छोड़ा था बेहतर security boundary: uVM मज़बूत security boundary दे सकता है, जिससे Kubernetes में बनाए गए जटिल user namespace mechanisms की ज़रूरत नहीं रहती। इससे nested containerization (development environment के भीतर Docker या Kubernetes चलाना) सहित व्यापक workloads के साथ पूर्ण compatibility मिल सकती है Micro VM की कठिनाइयाँ लेकिन micro VM experiments ने कुछ महत्वपूर्ण चुनौतियाँ भी उजागर कीं overhead: हल्के VM होने के बावजूद uVM containers की तुलना में अधिक overhead लाते हैं। इसका असर performance और resource utilization दोनों पर पड़ता है, जो cloud development environment platform में महत्वपूर्ण बात है image conversion: OCI images को uVM में इस्तेमाल योग्य filesystem में बदलने के लिए custom solutions चाहिए। इससे image management pipeline जटिल होती है और startup time पर भी संभावित असर पड़ता है technology-specific limitations Firecracker: GPU support का अभाव (जो कुछ development workflows के लिए तेज़ी से महत्वपूर्ण हो रहा है), virtiofs support का अभाव (जिससे efficient filesystem sharing options सीमित हो जाते हैं) Cloud Hypervisor: userfaultfd support का अभाव, जिससे snapshot और restore प्रक्रिया धीमी हो जाती है (uVM के मुख्य लाभों में से एक कमज़ोर पड़ जाता है) data movement समस्या: uVM के कारण बड़े memory snapshots संभालने पड़ते हैं, जिससे data movement और कठिन हो जाती है। इसका असर scheduling और startup time दोनों पर पड़ता है, जो cloud development environment user experience के मुख्य तत्व हैं storage considerations: micro VM में EBS volumes जोड़ने के प्रयोगों ने नई संभावनाएँ खोलीं, लेकिन नए सवाल भी खड़े किए persistent storage: attached volumes पर workspace content रखने से S3 से बार-बार data लाने की ज़रूरत खत्म हो सकती है, जिससे startup time बेहतर होने और network usage घटने की उम्मीद है performance considerations: workspaces के बीच high-throughput volumes साझा करने से I/O performance बेहतर होने की उम्मीद है, लेकिन effective quotas, latency management और scalability सुनिश्चित करने को लेकर चिंताएँ भी हैं Micro VM experiments से मिले सबक micro VM आख़िरकार मुख्य infrastructure solution नहीं बने, लेकिन experiments से मूल्यवान insights मिले development environments के लिए full workspace backup और runtime state suspend/resume का अनुभव काफ़ी पसंद आया पहली बार Kubernetes से बाहर जाने पर गंभीरता से विचार हुआ। KVM और uVM को pods में integrate करने की कोशिशों के बाद Kubernetes के बाहर के विकल्पों की खोज शुरू हुई stable startup performance, stable workspaces (data loss की रोकथाम), और optimal machine utilization—इन तीनों को पाने में storage फिर से एक केंद्रीय तत्व के रूप में सामने आया Kubernetes development environment platform के रूप में बहुत चुनौतीपूर्ण है जैसा पहले कहा गया, development environments के लिए ऐसा system चाहिए जो उनकी अनूठी statefulness का सम्मान करे developers को उत्पादक बनने के लिए ज़रूरी permissions देनी होंगी, साथ ही सुरक्षित boundaries भी सुनिश्चित करनी होंगी और यह सब कम operational overhead तथा security से समझौता किए बिना करना होगा आज Kubernetes के साथ यह सब हासिल करना संभव है, लेकिन इसकी लागत बहुत अधिक है application workloads और system workloads के बीच का अंतर कठिन तरीके से सीखना पड़ा Kubernetes अविश्वसनीय रूप से शानदार है एक उत्साही community के समर्थन से इसने सचमुच एक समृद्ध ecosystem बनाया है यदि आप application workloads चला रहे हैं, तो Kubernetes अब भी एक अच्छा विकल्प है लेकिन development environments जैसे system workloads के लिए Kubernetes security और operational overhead, दोनों के लिहाज़ से बहुत बड़ी चुनौतियाँ देता है micro VM और स्पष्ट resource budgets मदद करते हैं, लेकिन लागत और भी निर्णायक कारक बन जाती है इसलिए कई वर्षों तक development environments को Kubernetes platform पर प्रभावी ढंग से उल्टा-डिज़ाइन करके और ज़बरदस्ती फिट करने के बाद, Gitpod ने एक कदम पीछे हटकर सोचना शुरू किया कि future development architecture कैसा होना चाहिए जनवरी 2024 में इस पर काम शुरू हुआ और अक्टूबर में Gitpod Flex लॉन्च किया गया इंटरनेट-स्केल पर development environments को सुरक्षित रूप से चलाने से मिली 6+ वर्षों की बेहद कठिन कमाई हुई insights इसकी architecture foundation में समाई हुई हैं Development environments का भविष्य Gitpod Flex में Kubernetes के मूल पहलुओं—यानी control theory का लचीला अनुप्रयोग और declarative API—को आगे बढ़ाते हुए architecture को सरल बनाया गया है और security foundation को मज़बूत किया गया है development environments को orchestrate करने के लिए Kubernetes से गहराई से प्रेरित control plane का उपयोग किया जाता है development environments के लिए विशेष रूप से आवश्यक abstraction layers जोड़ी गई हैं और अनावश्यक infrastructure complexity का अधिकांश हिस्सा हटा दिया गया है यह सब zero-trust security को सर्वोच्च प्राथमिकता देकर किया गया है इस नई architecture की बदौलत dev containers को सहजता से integrate करना संभव हुआ साथ ही desktop पर development environments चलाने की क्षमता भी खुली अब Kubernetes platform का भारी बोझ उठाना नहीं पड़ता, इसलिए Gitpod Flex को self-hosted रूप में 3 मिनट के भीतर deploy किया जा सकता है और मनचाही संख्या में regions में deploy किया जा सकता है इससे compliance पर अधिक सूक्ष्म नियंत्रण और organizational boundaries तथा domains को model करने में अधिक flexibility मिलती है (मूल रूप से यह एक अलग लेख था, लेकिन लगा कि इसे साथ में रखना बेहतर होगा, इसलिए साथ लाया गया है।) Gitpod Flex zero-trust development environments के लिए पहला automation platform इसे laptops, cloud और on-premise पर चलने के लिए डिज़ाइन किया गया है, और source code, data तथा intellectual property को private network के भीतर रखता है development environments से शुरुआत करते हुए software development lifecycle automation के लिए building blocks प्रदान करता है Automations repository या API के माध्यम से परिभाषित programmable tasks और services developers को self-serve करने में सक्षम बनाता है, और developer productivity teams को development environments में सुधारों को केंद्रीकृत करने में मदद करता है साधारण script execution से आगे की क्षमताएँ देता है database provisioning और seeding, developer workflow customization, temporary clusters चलाना, LLM-आधारित agent workflows सेट करना, global/regional security और compliance को केंद्रीकृत रूप से लागू करना आदि संभव Zero-trust environments हर actor और service के लिए "never trust, always verify" malicious actors को पूरी तरह block करना, attack surface को काफ़ी कम करना, malware या code leakage के जोखिम को घटाना continuous assessment और explicit verification, verified enterprise-grade encryption, granular access control, networking पर पूर्ण नियंत्रण, और पूर्ण audit logs शामिल source code, data और intellectual property rights को private network के भीतर रखना सबसे महत्वपूर्ण है Gitpod Desktop local development environments को standardize और automate किया जा सकता है Apple Silicon से समर्थन की शुरुआत zero latency, development के लिए Docker Desktop का तेज़, हल्का और सरल विकल्प, local computing के उपयोग से cost optimization, और cloud या endpoint outages के खिलाफ disaster recovery support प्रदान करता है Development Container support Dev Container specification का पूर्ण integration मौजूदा Dev Container configurations बिना बदलाव के इस्तेमाल की जा सकती हैं VS Code और अन्य supported tools के साथ compatibility local या cloud, दोनों जगह एकसमान तरीके से काम किया जा सकता है Dev Container standard अपनाने से development environments को define, share और manage करना आसान होता है आने वाले 10 वर्षों के software development automation की नींव हमने development environment को बहुत संकीर्ण नज़रिये से देखा है development environment केवल IDE, dependencies और tools से अधिक है; यह वह मूल स्थान है जहाँ software बनाया जाता है यही वह जगह है जहाँ code prototyping, मनुष्यों और machines द्वारा निर्माण, testing, refactoring, compilation, packaging, signing और deployment होता है development context, workflows और insights तक बेजोड़ पहुँच देकर यह अन्य development platforms से अलग क्षमताएँ देता है product vision continuous integration (CI) का development environment के साथ fusion software development के लिए system of record की भूमिका अगली पीढ़ी के developer tools के लिए platform केवल coding practices को बेहतर बनाने से आगे बढ़कर, startup से लेकर Fortune 50 कंपनियों तक के लिए आने वाले 10 वर्षों में scale और success पाने का सबसे तेज़ और सुरक्षित तरीका बनाने का लक्ष्य

(gitpod.io)

11 पॉइंट द्वारा xguru 2024-11-05 | 3 टिप्पणियां | WhatsApp पर शेयर करें

GitPod ने 6 वर्षों तक Kubernetes का उपयोग करके एक "remote development environment platform" बनाया है, जो 15 लाख उपयोगकर्ताओं को सपोर्ट करता है और हर दिन हज़ारों development environments उपलब्ध कराता है
लेकिन बाद में यह समझ आया कि Kubernetes development environments बनाने के लिए उपयुक्त नहीं है
यह Kubernetes को production workloads के लिए इस्तेमाल करना चाहिए या नहीं, इस बारे में नहीं है, और न ही K8s पर applications deploy करने के लिए developer experience कैसे बनाया जाए, इस विषय पर है
→ यह cloud में development environments कैसे बनाए जाएँ (या कैसे न बनाए जाएँ), इस बारे में है

[Development environments क्यों अलग हैं]

इनमें state बहुत अधिक होती है और interaction भी बहुत सक्रिय होता है
- इन्हें nodes के बीच आसानी से move नहीं किया जा सकता
- source code, build cache, Docker containers, test data आदि की बड़ी मात्रा अक्सर बदलती रहती है और migration की लागत अधिक होती है
- production services के विपरीत, developer और environment के बीच 1:1 interaction होता है
developers source code और बदलावों से गहराई से जुड़े होते हैं
- वे source code changes खोना या system द्वारा block किया जाना पसंद नहीं करते
- development environments failures के प्रति विशेष रूप से संवेदनशील होते हैं
इनमें resource usage patterns अनुमान से बाहर होते हैं
- ज़्यादातर समय CPU bandwidth की बहुत ज़रूरत नहीं होती, लेकिन कुछ सौ ms के भीतर कई cores की ज़रूरत पड़ सकती है
- यदि यह उससे धीमा हो, तो अस्वीकार्य latency और unresponsiveness दिखाई देती है
इन्हें व्यापक permissions और capabilities चाहिए
- production workloads के विपरीत, root access और packages download/install करने की क्षमता चाहिए
- जो चीज़ें production workloads में security risk मानी जाती हैं, वे development environments में अपेक्षित व्यवहार हैं (root access, extended network capabilities, अतिरिक्त filesystem mounts आदि)
इन विशेषताओं के कारण ये सामान्य application workloads से अलग हैं, और infrastructure decisions पर इनका बड़ा असर पड़ता है

[मौजूदा system: Kubernetes]

Gitpod के शुरुआती दिनों में Kubernetes infrastructure के लिए आदर्श विकल्प जैसा लगा
- scalability, container orchestration और समृद्ध ecosystem जैसी चीज़ें cloud development environments की vision से अच्छी तरह मेल खाती थीं
लेकिन scale बढ़ने और user base के विस्तार के साथ security और state management के मोर्चे पर मुश्किलें आने लगीं
- Kubernetes को सुव्यवस्थित application workloads चलाने के लिए डिज़ाइन किया गया था, कठिन development environments के लिए नहीं
बड़े पैमाने पर Kubernetes को manage करना जटिल है
- GKE, EKS जैसी managed services कुछ समस्याएँ कम करती हैं, लेकिन उनकी अपनी constraints और limitations हैं
CDE चलाने की कोशिश करने वाली कई teams Kubernetes की जटिलता को कम आँकती हैं
- इससे Gitpod के पुराने self-managed product पर काफी support burden पड़ा

Resource management की कठिनाइयाँ

CPU और memory allocation सबसे बड़ी चुनौतियाँ हैं
एक node पर environments साझा करना आकर्षक लगता है, लेकिन व्यवहार में noisy neighbor effect काफ़ी बड़ा निकलता है
CPU समस्या
- development environments को अक्सर CPU कम चाहिए होता है, लेकिन अचानक बहुत ज़्यादा चाहिए हो सकता है
- CFS-आधारित solutions और custom controllers जैसे प्रयोग किए गए, लेकिन predict करना मुश्किल रहा
- static CPU limits लगाने पर भी कई processes के बीच contention की समस्या आती है
Memory management
- fixed memory allocate करना सरल है, लेकिन सीमित भी
- overbooking process termination का कारण बन सकती है
- swap space आने से overbooking की ज़रूरत कुछ हद तक कम हुई

Storage performance optimization

IOPS और latency development environment experience को प्रभावित करते हैं
speed, stability, cost और performance के संतुलन के लिए कई configurations पर प्रयोग किए गए
- SSD RAID 0
- EBS, persistent disks जैसे block storage
- PVC
backup/restore एक महँगा काम है

Autoscaling और startup time optimization

startup time को न्यूनतम करना सर्वोच्च लक्ष्य था
सोचा गया कि एक node पर कई workspaces चलाने से shared cache के कारण startup time बेहतर होगा, लेकिन ऐसा नहीं हुआ
Kubernetes startup time पर एक lower bound लगा देता है
scale-out तरीकों का विकास
- ghost workspaces, ballast pods आदि का उपयोग कर scale-out प्रयोग किए गए
- autoscaler plugins लाने के बाद scaling strategy में बड़ा सुधार हुआ
peak load संभालने के लिए proportional autoscaling
- खाली pods पहले से शुरू करके demand spikes पर तेज़ी से प्रतिक्रिया दी गई
image pull optimization के लिए कई प्रयास
- DaemonSet pre-pull, layer reuse maximization, pre-baked images, Stargazer और lazy pulling, Registry-facade + IPFS

Networking की जटिलता

development environment access control
- environments के बीच पूर्ण isolation होना चाहिए
- network policies मदद करती हैं, लेकिन services की संख्या बढ़ने पर reliability issues आते हैं
network bandwidth sharing
- CNI network shaping को सपोर्ट कर सकता है, लेकिन यह भी एक और control surface बन जाता है

Security और isolation: flexibility और protection के बीच संतुलन

users को flexibility देते हुए secure environment उपलब्ध कराना सबसे बड़ी चुनौती है
users को root privileges देना समस्याओं से भरा है
user namespaces अधिक सूक्ष्म समाधान हैं
- filesystem UID conversion, masked proc mounts, FUSE support, network capabilities उपलब्ध कराना, Docker सक्षम करना
user namespace implementation की कठिनाइयाँ
- performance impact, compatibility issues, complexity, Kubernetes version support

[Micro VM experiments]

Kubernetes की सीमाएँ महसूस करते हुए Firecracker, Cloud Hypervisor, QEMU जैसी micro VM (uVM) technologies को एक मध्य मार्ग के रूप में तलाशना शुरू किया गया
बेहतर resource isolation, दूसरे workloads (जैसे Kubernetes) के साथ compatibility, और बेहतर security की उम्मीद थी, साथ ही containerization के फ़ायदे बनाए रखने की भी उम्मीद थी
Micro VM के फ़ायदे
- इन्होंने cloud development environments के लक्ष्यों के साथ अच्छी तरह मेल खाने वाले आकर्षक benefits दिए
- बेहतर resource isolation: overbooking की क्षमता घटती है, लेकिन containers की तुलना में resource isolation बेहतर होती है। shared kernel resource contention खत्म हो जाती है, जिससे हर development environment के performance का अनुमान अधिक विश्वसनीय बनता है
- memory snapshots और fast resume: Firecracker की userfaultfd सुविधा memory snapshots को सपोर्ट करती है। इससे चल रहे processes सहित पूरी मशीन को लगभग तुरंत resume किया जा सकता है। developer के नज़रिये से environment startup काफ़ी तेज़ हो जाता है और काम वहीं से फिर शुरू किया जा सकता है जहाँ छोड़ा था
- बेहतर security boundary: uVM मज़बूत security boundary दे सकता है, जिससे Kubernetes में बनाए गए जटिल user namespace mechanisms की ज़रूरत नहीं रहती। इससे nested containerization (development environment के भीतर Docker या Kubernetes चलाना) सहित व्यापक workloads के साथ पूर्ण compatibility मिल सकती है
Micro VM की कठिनाइयाँ
- लेकिन micro VM experiments ने कुछ महत्वपूर्ण चुनौतियाँ भी उजागर कीं
- overhead: हल्के VM होने के बावजूद uVM containers की तुलना में अधिक overhead लाते हैं। इसका असर performance और resource utilization दोनों पर पड़ता है, जो cloud development environment platform में महत्वपूर्ण बात है
- image conversion: OCI images को uVM में इस्तेमाल योग्य filesystem में बदलने के लिए custom solutions चाहिए। इससे image management pipeline जटिल होती है और startup time पर भी संभावित असर पड़ता है
- technology-specific limitations
  - Firecracker: GPU support का अभाव (जो कुछ development workflows के लिए तेज़ी से महत्वपूर्ण हो रहा है), virtiofs support का अभाव (जिससे efficient filesystem sharing options सीमित हो जाते हैं)
  - Cloud Hypervisor: userfaultfd support का अभाव, जिससे snapshot और restore प्रक्रिया धीमी हो जाती है (uVM के मुख्य लाभों में से एक कमज़ोर पड़ जाता है)
- data movement समस्या: uVM के कारण बड़े memory snapshots संभालने पड़ते हैं, जिससे data movement और कठिन हो जाती है। इसका असर scheduling और startup time दोनों पर पड़ता है, जो cloud development environment user experience के मुख्य तत्व हैं
- storage considerations: micro VM में EBS volumes जोड़ने के प्रयोगों ने नई संभावनाएँ खोलीं, लेकिन नए सवाल भी खड़े किए
  - persistent storage: attached volumes पर workspace content रखने से S3 से बार-बार data लाने की ज़रूरत खत्म हो सकती है, जिससे startup time बेहतर होने और network usage घटने की उम्मीद है
  - performance considerations: workspaces के बीच high-throughput volumes साझा करने से I/O performance बेहतर होने की उम्मीद है, लेकिन effective quotas, latency management और scalability सुनिश्चित करने को लेकर चिंताएँ भी हैं
Micro VM experiments से मिले सबक
- micro VM आख़िरकार मुख्य infrastructure solution नहीं बने, लेकिन experiments से मूल्यवान insights मिले
- development environments के लिए full workspace backup और runtime state suspend/resume का अनुभव काफ़ी पसंद आया
- पहली बार Kubernetes से बाहर जाने पर गंभीरता से विचार हुआ। KVM और uVM को pods में integrate करने की कोशिशों के बाद Kubernetes के बाहर के विकल्पों की खोज शुरू हुई
- stable startup performance, stable workspaces (data loss की रोकथाम), और optimal machine utilization—इन तीनों को पाने में storage फिर से एक केंद्रीय तत्व के रूप में सामने आया

Kubernetes development environment platform के रूप में बहुत चुनौतीपूर्ण है

जैसा पहले कहा गया, development environments के लिए ऐसा system चाहिए जो उनकी अनूठी statefulness का सम्मान करे
developers को उत्पादक बनने के लिए ज़रूरी permissions देनी होंगी, साथ ही सुरक्षित boundaries भी सुनिश्चित करनी होंगी
और यह सब कम operational overhead तथा security से समझौता किए बिना करना होगा
आज Kubernetes के साथ यह सब हासिल करना संभव है, लेकिन इसकी लागत बहुत अधिक है
application workloads और system workloads के बीच का अंतर कठिन तरीके से सीखना पड़ा
Kubernetes अविश्वसनीय रूप से शानदार है
एक उत्साही community के समर्थन से इसने सचमुच एक समृद्ध ecosystem बनाया है
यदि आप application workloads चला रहे हैं, तो Kubernetes अब भी एक अच्छा विकल्प है
लेकिन development environments जैसे system workloads के लिए Kubernetes security और operational overhead, दोनों के लिहाज़ से बहुत बड़ी चुनौतियाँ देता है
micro VM और स्पष्ट resource budgets मदद करते हैं, लेकिन लागत और भी निर्णायक कारक बन जाती है
इसलिए कई वर्षों तक development environments को Kubernetes platform पर प्रभावी ढंग से उल्टा-डिज़ाइन करके और ज़बरदस्ती फिट करने के बाद, Gitpod ने एक कदम पीछे हटकर सोचना शुरू किया कि future development architecture कैसा होना चाहिए
जनवरी 2024 में इस पर काम शुरू हुआ और अक्टूबर में Gitpod Flex लॉन्च किया गया
इंटरनेट-स्केल पर development environments को सुरक्षित रूप से चलाने से मिली 6+ वर्षों की बेहद कठिन कमाई हुई insights इसकी architecture foundation में समाई हुई हैं

Development environments का भविष्य

Gitpod Flex में Kubernetes के मूल पहलुओं—यानी control theory का लचीला अनुप्रयोग और declarative API—को आगे बढ़ाते हुए architecture को सरल बनाया गया है और security foundation को मज़बूत किया गया है
development environments को orchestrate करने के लिए Kubernetes से गहराई से प्रेरित control plane का उपयोग किया जाता है
development environments के लिए विशेष रूप से आवश्यक abstraction layers जोड़ी गई हैं और अनावश्यक infrastructure complexity का अधिकांश हिस्सा हटा दिया गया है
यह सब zero-trust security को सर्वोच्च प्राथमिकता देकर किया गया है
इस नई architecture की बदौलत dev containers को सहजता से integrate करना संभव हुआ
साथ ही desktop पर development environments चलाने की क्षमता भी खुली
अब Kubernetes platform का भारी बोझ उठाना नहीं पड़ता, इसलिए Gitpod Flex को self-hosted रूप में 3 मिनट के भीतर deploy किया जा सकता है और मनचाही संख्या में regions में deploy किया जा सकता है
इससे compliance पर अधिक सूक्ष्म नियंत्रण और organizational boundaries तथा domains को model करने में अधिक flexibility मिलती है

(मूल रूप से यह एक अलग लेख था, लेकिन लगा कि इसे साथ में रखना बेहतर होगा, इसलिए साथ लाया गया है।)

Gitpod Flex

zero-trust development environments के लिए पहला automation platform
इसे laptops, cloud और on-premise पर चलने के लिए डिज़ाइन किया गया है, और source code, data तथा intellectual property को private network के भीतर रखता है
development environments से शुरुआत करते हुए software development lifecycle automation के लिए building blocks प्रदान करता है
Automations
- repository या API के माध्यम से परिभाषित programmable tasks और services
- developers को self-serve करने में सक्षम बनाता है, और developer productivity teams को development environments में सुधारों को केंद्रीकृत करने में मदद करता है
- साधारण script execution से आगे की क्षमताएँ देता है
- database provisioning और seeding, developer workflow customization, temporary clusters चलाना, LLM-आधारित agent workflows सेट करना, global/regional security और compliance को केंद्रीकृत रूप से लागू करना आदि संभव
Zero-trust environments
- हर actor और service के लिए "never trust, always verify"
- malicious actors को पूरी तरह block करना, attack surface को काफ़ी कम करना, malware या code leakage के जोखिम को घटाना
- continuous assessment और explicit verification, verified enterprise-grade encryption, granular access control, networking पर पूर्ण नियंत्रण, और पूर्ण audit logs शामिल
- source code, data और intellectual property rights को private network के भीतर रखना सबसे महत्वपूर्ण है
Gitpod Desktop
- local development environments को standardize और automate किया जा सकता है
- Apple Silicon से समर्थन की शुरुआत
- zero latency, development के लिए Docker Desktop का तेज़, हल्का और सरल विकल्प, local computing के उपयोग से cost optimization, और cloud या endpoint outages के खिलाफ disaster recovery support प्रदान करता है
Development Container support
- Dev Container specification का पूर्ण integration
- मौजूदा Dev Container configurations बिना बदलाव के इस्तेमाल की जा सकती हैं
- VS Code और अन्य supported tools के साथ compatibility
- local या cloud, दोनों जगह एकसमान तरीके से काम किया जा सकता है
- Dev Container standard अपनाने से development environments को define, share और manage करना आसान होता है

आने वाले 10 वर्षों के software development automation की नींव

हमने development environment को बहुत संकीर्ण नज़रिये से देखा है
development environment केवल IDE, dependencies और tools से अधिक है; यह वह मूल स्थान है जहाँ software बनाया जाता है
यही वह जगह है जहाँ code prototyping, मनुष्यों और machines द्वारा निर्माण, testing, refactoring, compilation, packaging, signing और deployment होता है
development context, workflows और insights तक बेजोड़ पहुँच देकर यह अन्य development platforms से अलग क्षमताएँ देता है
product vision
- continuous integration (CI) का development environment के साथ fusion
- software development के लिए system of record की भूमिका
- अगली पीढ़ी के developer tools के लिए platform
केवल coding practices को बेहतर बनाने से आगे बढ़कर, startup से लेकर Fortune 50 कंपनियों तक के लिए आने वाले 10 वर्षों में scale और success पाने का सबसे तेज़ और सुरक्षित तरीका बनाने का लक्ष्य

3 टिप्पणियां

ahwjdekf 2024-11-06

सुरक्षा का बहाना बनाकर 8GB मेमोरी स्पेक वाले virtual desktop को जबरन इस्तेमाल करवाने वाली देश की कंपनियां। कड़वा लगता है।

bus710 2024-11-05

Kubernetes में अच्छे लोगों को ढूंढना ही मुश्किल है, और यहाँ जो विकल्प सुझाए जा रहे हैं उन्हें समझकर आज़माने की कोशिश करने वाले लोगों को ढूंढना तो उससे भी ज़्यादा मुश्किल होगा, ऐसा लगता है।

xguru 2024-11-05

Hacker News राय

डेवलपर के पास वह डेवलपमेंट डिवाइस होना चाहिए जिसका वह उपयोग करता है। अगर एकसमान environment चाहिए, तो डेवलपर के पास अपनी डिवाइस होनी चाहिए और उसे स्थिर VM images दिए जाने चाहिए। डेवलपमेंट environment को remote host पर ले जाने की कोशिशें ज़्यादातर असफल होती हैं। डेवलपर को उपयुक्त hardware देना remote resources की तुलना में अधिक cost-effective है। local stack चलाने का समर्थन होना चाहिए, और इससे containers के जरिए consistency बनाए रखने में मदद मिलती है। local environment में data जनरेट करने वाले tools की ज़रूरत होती है, और इसे automate किया जा सकता है। data management में कमियाँ हैं, लेकिन ज़्यादातर कंपनियों में source code से ज़्यादा टीम की execution क्षमता मायने रखती है。
production workloads के लिए Kubernetes का उपयोग करना एक अलग मुद्दा है; यह cloud में डेवलपमेंट environment बनाने के तरीके पर चर्चा है। Kubernetes के जटिल engineering trade-offs पर एक दिलचस्प लेख।
यह Kubernetes की समस्याओं और आज़माए गए समाधानों को समझाता है, लेकिन अंत में चुने गए विकल्प के बारे में पर्याप्त जानकारी नहीं देता। Gitpod Flex नाम के नए solution का ज़िक्र है, लेकिन उसके बारे में जानकारी बहुत कम है।
Kubernetes stateless workloads के लिए उपयुक्त है, लेकिन stateful मामलों में LXC ज़्यादा उपयुक्त है। LXC को K8S की तरह cluster किया जा सकता है और यह data plane में tools को expose करता है। यह VM की तरह system instances देता है, और Docker containers जैसी performance रखता है। यह declarative syntax का उपयोग करता है और Kubernetes cluster की foundational layer के रूप में इस्तेमाल किया जा सकता है।
CI solution बनाते समय Kubernetes चुनना यह दिखाता है कि समस्या को ठीक से समझा नहीं गया। security उद्देश्यों के लिए Firecracker जैसे tools का उपयोग करना चाहिए।
Kubernetes डेवलपमेंट environments के लिए उपयुक्त नहीं है। डेवलपमेंट environment हमेशा बदलती हुई state में रहता है। cloud development environments की ज़रूरत समझ में नहीं आती। containerized apps का उद्देश्य टीमों के बीच डेवलपमेंट environment sync करने की ज़रूरत से बचना है।
Kubernetes paper low-latency और high-latency workflows के संयोजन को ही एकमात्र use case के रूप में बताता है। Gitpod की समस्या पर Kubernetes पर विचार करना उचित ठहराना मुश्किल है।
Gitpod जैसे एक प्रोजेक्ट पर काम किया था, और Kubernetes को बदलने के लिए micro VM का उपयोग करना समझ में नहीं आता। Kubernetes external containers को orchestrate कर सकता है और micro VM चलाने के लिए इस्तेमाल हो सकता है। सबसे बड़ी समस्या storage से जुड़ी है।
Kubernetes पर डेवलपमेंट environment बनाना फिजूलखर्ची है। अगर product ग्राहक की infrastructure पर self-hosted हो, तो debugging और support मुश्किल हो जाते हैं। network, memory, compute, और storage समस्याओं को engineers के सामने लाना प्रभावी है। बड़े teams के लिए Kubernetes एक upgrade है।