Serverless एक धोखा है: बस Container इस्तेमाल करें

• Serverless आसान दिखता है, लेकिन वास्तव में जटिलता, सीमाएँ और ऊँची लागत पैदा करने वाली संरचना है
• Container portability, state बनाए रखना, और स्पष्ट control देते हैं और अधिकांश use cases के लिए अधिक उपयुक्त हैं
• Serverless की cost structure अपारदर्शी और अप्रत्याशित होती है, और components के बीच अनावश्यक जटिलता पैदा करती है
• Serverless की scalability और सरलता सीमित use cases के लिए ही उपयुक्त है
• वास्तविक production environment में container-आधारित deployment अधिक सरल, scalable और cost-efficient होता है

---

Serverless Is a Scam. Just Use a Container.

Serverless क्या है?

• Serverless वह तरीका है जिसमें code को individual function units में deploy किया जाता है, और cloud platform execution व scaling को अपने-आप संभालता है
• लेकिन व्यवहार में, इसमें निम्न समस्याएँ मौजूद हैं
  • execution time limit (उदाहरण: AWS Lambda में 15 मिनट की सीमा)
  • state बनाए नहीं रख सकते (हर execution पर initialization)
  • cold start समस्या
  • debug न कर पाने वाला environment
  • platform-specific settings और configuration
  • YAML का अत्यधिक उपयोग
• यह सरल दिखता है, लेकिन जटिल कार्यों के लिए उपयुक्त नहीं है

Container: सरल, शक्तिशाली, और अच्छे अर्थ में नीरस

• Container के निम्न फायदे हैं
  • तेज़ startup
  • किसी भी environment में चल सकता है
  • state बनाए रख सकता है (Docker volume का उपयोग)
  • execution time limit नहीं
  • debugging, local development, और production environment में switch करना आसान
• उदाहरण code:
  docker run -v my-data:/data my-app
• परिणामस्वरूप stateful workloads को कहीं भी एकसमान तरीके से चलाया जा सकता है
• vendor lock-in नहीं, hidden cost नहीं, और architecture में अनावश्यक बदलाव नहीं

Serverless pricing: उपयोगकर्ता को भ्रमित करने वाला

• Serverless की लागत बहुत जटिल तरीके से बनाई जाती है
  • प्रति invocation लागत
  • memory usage
  • execution time
  • transferred data की मात्रा
  • region के अनुसार अंतर
  • secret key access cost आदि
• भ्रम पैदा करने वाले terms के उदाहरण:
  • Provisioned Concurrency Units
  • GB-seconds
  • Requests Tier 1/2/3
• अप्रत्याशित billing structure के कारण अनपेक्षित bill आ सकता है
• तुलना: $5 VPS में अनुमानित flat fee पर सभी resources का control संभव है

“Serverless scalable है” के दावे पर आपत्ति

• Serverless तकनीकी रूप से scalable है, लेकिन व्यवहार में अधिकांश apps को इसकी आवश्यकता नहीं होती
• अधिकांश applications को वास्तव में इन चीज़ों की ज़रूरत होती है
  • predictability
  • monitorability
  • उचित resource limits
  • development और staging environments
• Container-आधारित setup में scaling भी सरल है
  replicas: 5
• या load balancer का उपयोग करके horizontal scaling की जा सकती है

Stateless design कृत्रिम समस्याएँ बनाता है

• Serverless हर हाल में stateless design थोपता है
  • cache, session, temporary files, persistent connection संभव नहीं
• परिणामस्वरूप इन चीज़ों की आवश्यकता पड़ती है
  • external database
  • distributed cache
  • file storage
  • event bus
  • state machine
• अंततः एक “सरल” serverless app में 6 से अधिक SaaS dependencies हो जाती हैं
• इसके विपरीत, container में यह संभव है
  • in-memory cache
  • disk writes
  • session बनाए रखना
  • असीमित runtime

“मैं server manage नहीं करना चाहता” का जवाब

• server management के बिना container-आधारित platform इस्तेमाल करने के तरीके मौजूद हैं
  • Sliplane, Railway, Coolify जैसे platforms का उपयोग
  • या सिर्फ VPS पर Docker + systemd से भी काम हो सकता है
• Git-आधारित deployment, rollback, logging, metrics जैसी operational convenience उपलब्ध रहती है
• पूरे system पर समझ और control बना रहता है

“Serverless सस्ता है” के दावे पर आपत्ति

• बहुत कम invocation frequency पर यह सस्ता हो सकता है
• लेकिन नीचे की स्थितियों में लागत तेज़ी से बढ़ती है
  • जब traffic एक स्तर से ऊपर चला जाए
  • जब अधिक memory की ज़रूरत हो
  • जब वास्तविक computation ज़्यादा हो
  • जब data transfer अधिक हो
• Serverless में platform सब कुछ छिपा देता है, इसलिए optimization कठिन होती है
• जबकि container में
  • सस्ते hardware पर भी लगातार चलाया जा सकता है
  • cache और storage के साथ जोड़ा जा सकता है
  • benchmarking और tuning आसान है
  • millisecond-आधारित billing नहीं

Serverless वास्तव में कब उपयुक्त है

• यह निम्न प्रकार के intermittent और stateless tasks के लिए उपयुक्त है
  • event-driven functions (उदाहरण: image resizing)
  • कम ही चलने वाले jobs या webhook
  • internal tools
  • POC
  • जब तेज़ scale up/down की ज़रूरत हो
• लेकिन वास्तविक applications में यह सीमाओं से टकराता है, और
  • समय, लागत और जटिलता के रूप में बड़ी कीमत चुकानी पड़ती है

Container बेहतर विकल्प क्यों हैं

• Container निम्न चीज़ें प्रदान करते हैं
  • portability
  • control
  • simplicity
  • transparency
  • flexibility
• single या multi-container deployment, scaling, state management, background jobs, और DB integration सब संभव है
• code दोबारा लिखे बिना platform migration भी संभव है

सारांश (TL;DR)

• सिद्धांत में Serverless आकर्षक लगता है
• वास्तविकता में यह है:
  • अपारदर्शी
  • महँगा
  • अत्यधिक जटिल
  • ज़रूरत से ज़्यादा प्रचारित
    > शुरू करने से पहले खुद से पूछें:
    > “क्या इसे बस container के रूप में नहीं बनाया जा सकता?”
• अगर जवाब ‘हाँ’ है, तो container से शुरुआत करना बेहतर विकल्प है

आगे क्या करें

• Serverless के कारण हुए अनपेक्षित खर्च या अक्षम workflow के अपने अनुभव साझा करने की सलाह
• सरल समस्याओं को अनावश्यक रूप से जटिल न बनाएँ

[nullvana]

xfaas भी है.. cf workers भी हैं। लगता है यह एक पक्षपाती लेख है।

[softer]

जब मैं GPU किराये पर लेते समय उसे थोड़ी देर के लिए serverless function के रूप में चलाने के बारे में सोच रहा था,
क्या वह container में भी संभव है?

[nemorize]

पुरानी PHP web hosting सेवाओं में, अगर PHP निकालकर उसकी जगह vendor lock-in से भरा हुआ JS डाल दें....
तो मुझे यह सोचना बंद नहीं होता कि इसे प्रमुख serverless FaaS प्लेटफ़ॉर्म्स से अलग पहचानना मुश्किल होगा।

बेशक, PHP और JS/TS को मुख्य रूप से इस्तेमाल करने वाला एक self-proclaimed 똥1믈리에 होने के नाते मैं इसे संतोषजनक ढंग से इस्तेमाल कर रहा हूँ,
लेकिन फिर भी मुझे ठीक-ठीक समझ नहीं आता कि इतने लोग इसे स्वादिष्ट क्यों मानते हैं।

[elbanic]

मेरी निजी राय में vendor की serverless service का उपयोग करना जोखिमभरा है, लेकिन containers का उपयोग करके कंपनी द्वारा खुद serverless environment उपलब्ध कराना अच्छा लगता है। अगर serverless को service नहीं बल्कि एक concept के रूप में इस्तेमाल किया जाए, तो यह अच्छा हो सकता है।

[pedogunu]

कुछ समय पहले vercel की Edge rendering को छोड़ देने वाले ट्वीट और वीडियो[1], और serverless server (haha)[2] पर लिखा गया लेख काफ़ी चर्चा में थे। मुझे लगता है कि मेरी राय भी उस समय आए लेखों जैसी ही है.

यह मेरी व्यक्तिगत राय है, लेकिन frontend developer के नज़रिए से देखें तो user के request के साथ serverless function जोड़ना अभी भी काफ़ी दूर की बात है (जब तक कि आप जो application बना रहे हैं वह MVP न हो).

[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…

[pedogunu]

बेशक, जैसा कि इस पोस्ट पर भी लिखा गया है, यह कुछ ज़्यादा ही attention खींचने के लिए लिखा गया लेख लगता है :(

[unknowncyder]

कंटेनर-आधारित environment (ECS Fargate केंद्रित, Kubernetes cluster) और serverless environment (AWS) — दोनों का अनुभव होने के नाते, यह बात मुझे उतनी प्रभावशाली नहीं लगी।

कंटेनर-आधारित environment के फ़ायदों के रूप में जो बातें गिनाई गई हैं, वे फ़ायदे होने के साथ-साथ एक ही समय में नुकसान भी बन सकती हैं।

'सीधे control किया जा सकता है और state रखा जा सकता है' कहकर जिन बातों का ज़िक्र किया गया है, वे सब management point बन जाती हैं, इसलिए क्या operational complexity बढ़ जाती है।

मुझे लगता है कि छोटे संगठनों में, और खासकर उन संगठनों में जहाँ specialized server management team नहीं है, मैं serverless की ज़ोरदार सिफारिश करूँगा।

हाँ, cost calculation का जटिल होना या उसका अनुमान लगाना मुश्किल होना, और vendor lock-in की समस्या — इस बात से मैं सहमत हूँ।

[unknowncyder]

डेवलपर experience और observability की बात करने वाले कुछ लोग हैं, तो उसमें यह जोड़ना चाहूँगा,

अगर शुरुआती integration environment अच्छी तरह सेट कर दिया जाए, तो container-आधारित तरीके से कम नहीं, बल्कि शायद उससे भी ज़्यादा native के करीब developer experience हासिल किया जा सकता है। (इसके लिए तरह-तरह के tools भी हैं.)

जहाँ तक observability की बात है, अगर उसे गहराई से करना हो तो serverless हो या container-based, दोनों में ही यह कोई आसान समस्या नहीं है। log centralization, तरह-तरह के metrics visualization, APM, CPU/memory usage visualization, और उसके आधार पर scaling strategy बनाना वगैरह...

अगर बात उस स्तर तक नहीं पहुँची है, तो cloud vendor द्वारा मूल रूप से दिए जाने वाले metrics/log integration काफ़ी शक्तिशाली होते हैं, इसलिए दोनों लगभग बराबर ही हैं.

थोड़ा आक्रामक ढंग से कहूँ तो, मैं पूछना चाहूँगा, 'आपने serverless को ठीक-ठाक स्तर तक वास्तव में कितना करके देखा है?' 😅

[aer0700]

मुझे भी लगता है कि क्या केवल कुछ ज़रूरी endpoints को ही Lambda पर चलाना बेहतर नहीं होगा। वैसे शुरुआत से ही मुझे serverless development का अनुभव नहीं है, इसलिए मैं पक्के तौर पर कुछ कह नहीं सकता, लेकिन ऐसा ज़रूर लगता है कि कुछ खास मामलों में यह अच्छा हो सकता है।

[skageektp]

क्या यह लेख उस कंपनी ने लिखा है जो एक container hosting platform कंपनी है, इसलिए शायद इसे पक्षपाती नज़रिये से लिखा गया होगा, हा हा

[preserde]

पहले भी फ्रंटएंड पक्ष में nextjs(vercel) को लेकर चिंता जताने वाले netlify (प्रतिस्पर्धी) डेवलपर की पोस्ट पर शक करने वाले लोग थे। टिप्पणियाँ देखें तो वह पक्षपाती नहीं लगती।
मैं फ्रंटएंड तरफ का हूँ... इसलिए इस क्षेत्र से ज़्यादा नज़दीकी नहीं है, लेकिन serverless(서버있음) वाला मीम काफ़ी बार देखा है haha

[asheswook]

Native की तुलना में development experience काफ़ी कमजोर होना बहुत बड़ा pain point है, और software खुद infrastructure provider पर निर्भर हो जाता है, इसलिए एक बार सेट हो जाने के बाद उससे बाहर निकलना मुश्किल हो जाता है। Reference स्पष्ट रूप से कम हैं, और observability भी बहुत कमजोर है.

Cloudflare शायद दूसरी कंपनियों की तुलना में serverless को बेहतर तरीके से करने की कोशिश कर रहा है। Database भी serverless, key-value storage भी serverless, यहाँ तक कि message queue भी serverless है...
(बेशक, ऐसा होते-होते यह भी लगता है कि हम platform पर पूरी तरह निर्भर और बंधे जा रहे हैं)

फिर भी, अगर debugging, observability और development experience में सुधार नहीं होता, तो यह अब भी वहीं का वहीं रहेगा।

[hilft]

Cloud Run चलाइए

[bbulbum]

Serverless के साथ service चलाना गलत tool चुनने जैसा है.
ऐसी कुछ specific problems होती हैं जहाँ serverless की ज़रूरत पड़ती है. रुक-रुककर इस्तेमाल होने वाले use cases के लिए यह उपयुक्त है.

[tolluset]

क्या serverless container services पर भी यही राय लागू होगी?

मौजूदा serverless services (lambda जैसी) की समस्याओं की वजह से AWS ने Fargate बनाया और उसे और आसान बनाने के लिए App Runner तक बना दिया 🤔

यहाँ तक कि Google Cloud का Cloud Run भी है, जो scale to zero वाला कमाल का serverless container service है

इनमें से मुझे व्यक्तिगत तौर पर Cloud Run का developer experience सबसे अच्छा लगा

[ndrgrd]

सर्वरलेस (सर्वर है)

[GN⁺]

Hacker News राय

• serverless छोटे शुरुआती प्रोजेक्ट्स के लिए अच्छा था, लेकिन AWS Lambda बड़े applications में maintenance hell है (build, dependencies, debugging, deployment धीमे होना आदि)
  • फिर भी यह प्रभावशाली है कि 2019 में deploy किया गया Lambda-आधारित React webapp आज भी बिना किसी बदलाव के चल रहा है
  • इसका एक प्रतिवाद यह भी है कि maintenance की समस्या framework की वजह से है, और modular design व local development साथ में अपनाने पर ज़्यादातर समस्याएँ हल हो सकती हैं
  • Lambda में अक्सर runtime updates की ज़रूरत पड़ती है, और यह लंबे समय तक बिना समस्या के चलने के बाद अचानक रुक जाने के रूप में सामने आ सकता है
  • अगर dependencies कम हों तो updates आसान हैं, लेकिन अगर पुरानी runtime पर निर्भरता हो तो पहले से तैयारी करना ज़रूरी है
• serverless रुक-रुक कर चलने वाले और stateless workloads के लिए उपयुक्त है, और internal/external JSON API के साथ अच्छी तरह फिट बैठता है
  • लेकिन एक राय यह भी थी कि ज़रूरत से ज़्यादा भावनात्मक वर्णन के बजाय यह साफ़ बताना बेहतर होता कि serverless कोई रामबाण नहीं है
  • serverless में self-healing क्षमता अच्छी होती है, और stateful systems (containers आदि) की तुलना में operational burden कम होता है
  • फिर भी कुछ लोगों की राय है कि containers का development model बेहतर है — यह कहीं भी चल सकता है, लेकिन state management और scalability में सीमाएँ हैं
• containers मूल रूप से stateless होते हैं, बस उनमें state जोड़ी जा सकती है
  • बड़ी organizations में आखिरकार Kubernetes(K8s) standard बन जाता है, और यह containers की सरलता से काफ़ी दूर है
  • यह भी कहा गया कि अगर platform team हो तो K8s को सरलता से चलाया जा सकता है, लेकिन ऐसा environment कम ही मिलता है
• GCP Cloud Run को एक कम आंका गया serverless platform माना गया, जो सिर्फ़ उपयोग के समय के आधार पर charge करता है, इसलिए किफ़ायती है
• AWS Lambda में Postgres connection या bcrypt का उपयोग संभव है, लेकिन feedback यह था कि setup और execution बहुत झंझटभरे थे
  • drivers को manually build करना पड़ा, और libc version difference से समस्याएँ आईं
  • local test environment भी स्पष्ट नहीं था, इसलिए trial and error बहुत हुआ
• कुछ लोगों ने कहा कि यह लेख मानो Sliplane का प्रचार करने वाला लेख लगता है
  • यह राय भी थी कि "business logic को Lambda में डालने के बजाय, इसे cloud environment को program करने के लिए इस्तेमाल करना चाहिए"
  • serverless की वजह से छोटी teams बड़े scale की services चला सकती हैं, लेकिन complexity की समस्या अब भी बनी रहती है
  • यह आलोचना भी हुई कि container technology सीखने वाला व्यक्ति अपनी market value बढ़ाने के लिए सबको containers इस्तेमाल करने पर मजबूर करता हुआ लगता है
• पहली पीढ़ी के serverless platforms (AWS Lambda आदि) में scalability और state management की मुश्किलें हैं
  • दूसरी पीढ़ी के platforms container-based serverless की दिशा में विकसित हो रहे हैं, लेकिन containers में state जोड़ना scaling के समय बड़ी समस्या पैदा करता है
  • उदाहरण: "Docker volume जोड़कर state बनाए रखना" scalability को ध्यान में रखे बिना दी गई खतरनाक सलाह है
  • लेख में बताए गए “10 containers तक scale करना + अपना DB चलाना” जैसे दावे व्यवहारिक रूप से असंभव या अक्षम माने गए
• कुछ लोगों ने इस लेख को "fair assessment" कहा, जबकि दूसरों का मानना था कि यह बहुत ज़्यादा भावनात्मक है या इसमें व्यावसायिक मंशा ज़्यादा दिखती है

[iolothebard]

शुरुआत से ही यह Serverless नहीं, बल्कि Serverlease था।

[kaydash]

हाहाहाहा