अभी Kubernetes का इस्तेमाल न करें
(matt-rickard.com)शुरुआती चरण के startup को Kubernetes जल्दबाज़ी में नहीं अपनाना चाहिए.
ज़्यादातर मामलों में यह अभी समय से पहले होता है.
छोटी टीमों (1~10 लोग) के लिए Serverless container service का उपयोग करना बेहतर है.
(AWS ECS - Fargate, GCP का Google Cloud Run)
13 टिप्पणियां
क्या अब k8s पसंद-नापसंद का मुद्दा नहीं, बल्कि सर्वाइवल का मुद्दा बन चुका है?
मुझे लगता है कि AWS हो या न हो, k8s जानना अब ज़रूरी हो गया है.
मैं इस राय से सहमत नहीं हूँ.
k8s की एकमात्र कमी, मेरे हिसाब से, सिर्फ इसकी learning curve है.
भले ही टीम में लगभग 5 लोग ही हों, शुरुआत में यह मुश्किल लग सकता है, लेकिन एक बार k8s की समझ एक निश्चित स्तर से ऊपर पहुँच जाए, तो फिर पहले वाली स्थिति में लौटना संभव नहीं रहता. इससे होने वाली productivity में बढ़ोतरी की तुलना ही नहीं की जा सकती.
ci/cd, gitops, canary deployment वगैरह k8s के बिना भी किए जा सकते हैं, लेकिन इन्हें k8s के ऊपर साथ में करना समझने में आसान और manage करने में अधिक सुविधाजनक है.
जिसने खुद migration का दौर अनुभव किया है, उसके नाते मेरे लिए यह कहना कि अभी समय नहीं आया है,
कुछ वैसा ही लगता है जैसे on-premise के दौर में लोग सिर्फ इसलिए AWS cloud अपनाने में हिचकिचाते थे क्योंकि वह उन्हें नया और अपरिचित लगता था.
"बिज़नेस पर फोकस करो" जैसी सिर्फ़ सैद्धांतिक बात नहीं, बल्कि किसी खास तकनीक में lock-in होने वाले फ़ैसलों से सहमत होना मेरे लिए मुश्किल है.
अगर यह लेख beanstalk/app engine/heroku जैसे PaaS का सक्रिय रूप से उपयोग करने की बात करता, तो मैं पूरी तरह सहमत होता, लेकिन आजकल छोटे टीमों के लिए ECS/cloud run/docker swarm चुनकर मिलने वाले फायदे लगभग न के बराबर हैं. हाँ, 4~5 साल पहले की बात अलग हो सकती थी.
लागत के लिहाज़ से देखें तो serverless जबरदस्त रूप से फ़ायदेमंद है।
मैं भी सहमत हूँ। ज़्यादातर मामलों में docker-swarm या docker-compose काफ़ी से भी ज़्यादा होते हैं
यह Hacker News की टिप्पणियों में भी बहुत ज़्यादा आने वाली राय है..... [1]
लेख में "Kubernetes मुश्किल है" यह मान्यता पहले से रखी गई है, इसलिए थोड़ा भ्रमित करने वाला लगता है।
आजकल Kubernetes ecosystem काफ़ी विकसित हो चुका है, इसलिए जब तक आप on-prem पर Kubernetes को सीधे खुद install नहीं कर रहे, यह उतना मुश्किल नहीं है।
साथ ही Kubernetes operations में आप जटिलता को एक हद तक खुद तय कर सकते हैं; बुनियादी configuration बनाना मुश्किल नहीं है। बाद में इसमें तरह-तरह के add-on जोड़ेंगे तो स्वाभाविक रूप से मुश्किल हो जाएगा।
मेरी तरह ऐसे लोगों की संख्या भी काफ़ी बढ़ी है जिन्होंने नए करियर की शुरुआत में ही EKS से deployment environment का अनुभव किया है.
सीधे कहूँ तो, बुनियादी k8s Deployment और Ingress को configure करना (बेशक DB एक अलग managed service हो) वहाँ लेख में बताई गई AWS ECS Fargate को सीधे configure करने से ख़ास तौर पर ज़्यादा मुश्किल है, यह बात मेरी समझ में नहीं आती।
दोनों में ही VPC, cluster, CDN और load balancer configuration करनी पड़ती है... टिप्पणियों में तो ऐसे कई पोस्ट भी हैं जिनमें कहा गया है कि ECS उल्टा ज़्यादा असुविधाजनक था।
[1] https://news.ycombinator.com/item?id=31795160
मैं सहमत हूँ। मुझे नहीं लगता कि बेसिक सेटअप इतना मुश्किल है, और न ही इसका maintenance level इतना ज़्यादा है। cloud में एक complex setup को Kubernetes yml setup में ले जाने से क्या खास बेहतर हो जाता है, यह मैं साफ़ तौर पर नहीं कह सकता।
हमारी कंपनी में डेवलपर 100 से ज़्यादा हो गए, इसलिए ज़रूरत महसूस हुई और हम ECS -> EKS माइग्रेशन कर रहे हैं, लेकिन कभी-कभी इसका थोड़ा पछतावा भी होता है.
आप कहते हैं कि "Kubernetes ऑपरेशन में जटिलता को किसी हद तक खुद तय किया जा सकता है", लेकिन जो लोग इसे अच्छी तरह नहीं जानते, उनके नज़रिए से Kubernetes ecosystem में जिस भी चीज़ की चर्चा होती है, वह सब ज़रूरी होगी ऐसा लगने लगता है, और फिर सब कुछ जोड़ देने की प्रवृत्ति बन जाती है.
आपने कहा कि load balancer configuration करनी ही पड़ती है, यह सही है, लेकिन मेरा मानना है कि सिर्फ ALB जानना और ALB + Ingress दोनों जानना — इन दोनों में फर्क है.
जैसे छोटे scale पर MSA की ज़रूरत नहीं होती, वैसे ही Kubernetes में सोच से ज़्यादा चीज़ें जाननी पड़ती हैं, इसलिए जिस scale पर 'application पर फ़ोकस करना' ज़्यादा महत्वपूर्ण हो, वहाँ यह over-spec होना सही बात लगती है.
हालाँकि, अगर किसी ने Kubernetes environment को बहुत अच्छी तरह सेटअप कर रखा हो, तो उसके ऊपर application deploy करना cloud-independent expression में define हो जाता है, इसलिए lock-in effect कम हो सकता है — ऐसा मुझे लगा.
आपकी बात सुनकर लगता है कि वाकई ऐसे पहलू हो सकते हैं। Kubernetes इस्तेमाल करते हुए जो बातें मैंने सीखी हैं, शायद उन्हें मैंने कुछ ज़्यादा ही स्वाभाविक मान लिया था।
और यह भी मानता हूँ कि आजकल Kubernetes ecosystem में इतने ज़्यादा add-ons आ रहे हैं कि उनमें से क्या चुनें और क्या छोड़ें, यह तय करना मुश्किल हो जाता है.
मुझे ECS -> EKS जैसी migration का अनुभव नहीं है, इसलिए... lock-in effect जैसी बातों के अलावा, क्या migration के बाद कुछ चीज़ें बेहतर हुईं, यह जानने की उत्सुकता है।
आह, संदर्भ के लिए बता दूँ कि मेरा अनुभव EKS के आधार पर है। on-prem पर सीधे k8s इंस्टॉल करके
etcd,Control Planeको खुद ऑपरेट करना इससे काफ़ी अलग होता है, हा।k8s से ही शुरुआत करने वाले व्यक्ति के नज़रिए से, यह लेख पढ़ते हुए मेरे मन में उल्टा यही विचार आया कि फिर क्या सच में ECS को समय लगाकर अलग से पढ़ने की ज़रूरत है...?
खैर, मुझे लगता है कि उसे ज़रूर इस तरह आधिकारिक रूप से तय करने की आवश्यकता नहीं है; पहले टीम को जो तरीका सुविधाजनक लगे, उसी तरह इस्तेमाल करना सही नहीं होगा क्या?
मैं k8s शुरू करने वाले इस दृष्टिकोण से सहमत हूँ.
मैं इससे पूरी तरह सहमत हूँ.
सिर्फ 10 लोगों की टीम ही नहीं, बल्कि ठीक-ठाक आकार की कंपनियों में भी k8s अपनाने को लेकर मैं नकारात्मक हूँ.
मुझे लगता है कि इसका मतलब तभी बनता है जब cloud vendor lock-in बहुत ही critical स्तर का मुद्दा बन जाए, या on-prem जैसी infrastructure भी साथ में इस्तेमाल की जा रही हो.
मुझे हमेशा लगता था कि enterprise-स्तर की कंपनियों के tech stack को हम कुछ हद तक जड़ता में आकर फॉलो करते हैं।
संयोग से इसी बारे में अच्छी तरह व्यवस्थित एक पोस्ट Hacker News पर दिखी, इसलिए शेयर कर रहा/रही हूँ