Serverless के झांसे में मत आइए
(world.hey.com)- RoR बनाने वाले DHH का लेख
- cloud समर्थकों का कहना है कि cost, performance, complexity आदि सब कुछ "serverless" पर जाते ही मानो जादू की तरह हल हो जाता है
- cloud/VPS बड़े पैमाने पर खरीदकर अलग-अलग बेचने के सिद्धांत पर काम करते हैं
- $1000 में एक बड़ा server खरीदकर उसे 7 लोगों को $200 पर किराये पर देकर हर महीने $400 का मुनाफ़ा कमाना
- अगर वे 7 लोग server पर बहुत बड़ा load न डालें, या अलग-अलग समय पर उसका इस्तेमाल करें, तो यह अच्छी तरह काम करता है
- अगर आपको पूरे server की capacity चाहिए, तो आप $1000 के computer के लिए $1400 चुकाते हैं
- अगर 1 साल की प्रतिबद्धता के साथ इस्तेमाल करें, तो इसे छूट देकर $1250 प्रति माह तक किया जा सकता है (असल में यह 25% वार्षिक ब्याज वाला credit contract है)
- serverless भी ऐसा ही है, लेकिन इसमें server को और भी बारीक हिस्सों में बांटना संभव है
- एक बड़े server को 7 लोगों को $200 प्रति माह पर देने के बजाय, हर function execution वाले 100 ग्राहकों को $20 प्रति माह पर देना
- अब $400 प्रति माह का नहीं बल्कि $1000 का मुनाफ़ा होता है
- इसमें हैरानी की बात नहीं कि cloud कंपनियों को serverless पसंद है
- अगर आपको सिर्फ कुछ ऐसे functions चाहिए जो कभी-कभी चलें, तो यह अच्छा है (कम से कम अल्पकाल में)
- लेकिन अगर आपको पूरे computer की क्षमता इस्तेमाल करने के स्तर की ज़रूरत है, तो यह भयानक है
- क्योंकि आप उसी clock speed के लिए ज़्यादा भुगतान करते हैं, और lock-in भी बहुत बढ़ जाता है
- serverless में जितना ज़्यादा आप "cloud native" services का उपयोग करेंगे, बाहर निकलना उतना ही कठिन होगा
-
"Serverless के झांसे में मत आइए। अगर आपको किसी computer के पूरे computing cycle की ज़रूरत है, तो यह सच नहीं बदलता कि आपको वह computer खरीदना ही चाहिए। अगर आप proprietary serverless configuration से शुरुआत करते हैं, तो अंत में आपको पता चलेगा कि lock-in से निकलना संभव नहीं है"
-
"Cloud उन कंपनियों के लिए है जिनकी usage में बहुत बड़ा उतार-चढ़ाव होता है, जैसे Amazon जहां Black Friday/Christmas पर भारी demand होती है और बाकी समय बहुत-सी capacity की ज़रूरत नहीं पड़ती,
या ऐसे व्यवसाय जो पूरे computer के मालिक बनने लायक नहीं हैं, या शुरुआती startups जिनका cloud खर्च इतना कम है कि वह समस्या नहीं बनता। Serverless इससे कुछ नहीं बदलता।"
8 टिप्पणियां
यह इस बात पर भी निर्भर करता है कि सेवा में burst time है या नहीं। डिलीवरी ऐप जैसे मामलों में निश्चित रूप से कुछ समय ऐसे होते हैं जब लोड बहुत बढ़ जाता है, इसलिए ऐसा cloud जो सिर्फ उसी समय scale-out कर सके, आकर्षक लगता है। लेकिन IoT जैसे क्षेत्रों में, जहाँ 99% ट्रैफ़िक स्थिर रहता है, physical server चलाना बेहतर हो सकता है।
मुझे लगता है कि serverless की वास्तविक उपयोगिता से आगे बढ़कर उसके आसपास कुछ ज़्यादा ही hype बन गया है, इसलिए यह सोचने लायक एक नज़रिया देता है.
अगर इन दो मुद्दों पर विचार करके फ़ैसला लिया जाए, तो बड़ी विफलता की संभावना कम होगी.
व्यक्तिगत रूप से मुझे यह जिज्ञासा है कि क्या serverless सही abstraction है; मेरा मानना है कि इसका जवाब समय देगा. और serverless lock-in की समस्या लगातार सिरदर्द बनी रहेगी, और यह ऐसा मुद्दा है जिसे पूरे उद्योग को मिलकर सुलझाना होगा, हालांकि इसमें सफल होना आसान नहीं होगा.
पैसे तो नहीं हैं, लेकिन जिन startups के पास लोग और समय उससे भी ज़्यादा कम हैं, उनके लिए serverless एक बेहद आकर्षक विकल्प लगता है।
आख़िरकार यह मांग और आपूर्ति के बारे में तर्कसंगत चुनाव किए जा सकने वाला क्षेत्र है, इसलिए मुझे नहीं लगता कि इसमें किसी के ठगे जाने या ठगने जैसी बात है.
बाज़ार में कंपनी के आकार, काम के स्वरूप और सेवा के प्रकार के अनुसार cloud, on-premise और serverless की उचित ज़रूरत रखने वाली कंपनियाँ और लोग स्वाभाविक रूप से मौजूद होते हैं.
एक server की कीमत 200 डॉलर उचित है या function को 20 डॉलर देकर इस्तेमाल करना बेहतर है, यह आख़िरकार हर कंपनी के CEO/CTO को सोचकर तर्कसंगत रूप से तय करने वाली बात है. अगर तुरंत लागत और समय की दिक्कत हो तो 20 डॉलर बेहतर हो सकते हैं, और अगर थोड़ी गुंजाइश हो तो 200 डॉलर या 1000 डॉलर वाला विकल्प तर्कसंगत निर्णय बन सकता है. बल्कि उपभोक्ता के नज़रिए से देखें तो अलग-अलग परिस्थितियों के लिए विकल्प बढ़ना शायद और बेहतर ही है. ऊपर से यह कोई एकाधिकार वाली तकनीक भी नहीं है, और बड़े खिलाड़ी जिस बाज़ार में जमकर प्रतिस्पर्धा कर रहे हों वहाँ कीमतें लगातार नीचे ही जाती हैं.
समर्पित इन्फ्रास्ट्रक्चर इंजीनियर (deops, sre, platform engineer or else) के बिना, लगता है कि aws fargate या gcp cloud run तक ही सीमा है। container as a service.
बेशक, उसके भी यह-वह फायदे और नुकसान होंगे...
इस संदर्भ में, AWS पर यह आलोचना करने वाली एक पोस्ट भी है कि Lambda से इतना ज़्यादा पैसा लेने के बावजूद, वह वास्तव में runtime सुधार नहीं कर रहा है.
https://www.lastweekinaws.com/blog/aws-is-asleep-at-the-lambda-wheel/
मैं सहमत हूँ.
Lambda या दूसरी AWS services के platform upgrade cycle को देखें तो यह नहीं लगता कि वे बहुत फुर्तीले हैं; बल्कि ऐसा प्रभाव मिलता है कि वे काफ़ी conservative तरीके से काम करते हैं या इस पर बहुत अधिक resources नहीं लगाते। शायद ऐसा इसलिए हो कि platform version जोड़ने के लिए बहुत testing की ज़रूरत होती है, और उन्हें जोड़ने से support cost भी काफ़ी बढ़ जाती होगी, इसलिए वे स्थिरता को प्राथमिकता देते हैं और platform versions की संख्या को एक तय सीमा के भीतर manage करते हैं... बस मेरा यही अनुमान है।
हमेशा की तरह, DHH थोड़ी तीखी भाषा में बात करने वाले व्यक्ति हैं। इसे ध्यान में रखकर पढ़िए ha