Serverless म्हणजे काय? Serverless computing सोप्या भाषेत

Serverless म्हणजे कोड चालवण्याची अशी पद्धत जिथे तुम्ही स्वतः कोणतेही सर्व्हर सेट किंवा व्यवस्थापित करत नाही. तुम्ही तुमचा कोड क्लाउड प्रदात्याकडे देता, आणि एखादी गोष्ट त्याला चालना देते — वेब विनंती, अपलोड केलेली फाइल, पेमेंटची सूचना — तेव्हाच तो चालतो, मग थांबतो. सहसा तुमचा कोड प्रत्यक्ष चालतो तो वेळच तुम्ही भरता, निष्क्रिय बसलेल्या मशीनचा नाही.

AI सोबत बनवताना serverless का महत्त्वाचे आहे

AI सोबत अ‍ॅप बनवताना आणि होस्टिंग पर्याय किंवा कोड पाहताना तुम्हाला "serverless functions," "edge functions" किंवा "cloud functions" दिसतील. अनेक होस्टिंग प्लॅटफॉर्म्स त्या देतात, आणि काही AI बिल्डर्स बॅकएंड्स अशा प्रकारे डिप्लॉय करतात. हे मॉडेल समजल्याने तीन व्यावहारिक प्रश्न सुटतात:

• खर्च. कोणी वापरत नसतानाही तुमच्या अ‍ॅपला पैसे लागतील का?
• वेग. शांत कालावधीनंतरची पहिली विनंती का हळू आहे?
• मर्यादा. एखादे लांब काम — मोठा रिपोर्ट बनवणे, मोठा व्हिडिओ प्रक्रिया करणे — का टाइम आउट झाले?

Serverless नाही हे देखील समजून घेणे उपयोगी आहे: त्याचा अर्थ बॅकएंड नसणे असा नाही. तुमच्याकडे अजूनही सर्व्हर-साइड कोड असतो; फक्त मशीन्स दुसरे कोणीतरी चालवते. मूलभूत माहितीसाठी सर्व्हर म्हणजे काय पहा.

दैनंदिन उदाहरण

पारंपरिक सर्व्हर म्हणजे कार बाळगण्यासारखे आहे. ती नेहमी तयार असते आणि लगेच जाऊ शकते, पण तुम्ही तिच्यासाठी पैसे देता — विमा, पार्किंग, देखभाल — ती वापरो किंवा न वापरो.

Serverless म्हणजे टॅक्सी बोलावण्यासारखे आहे. तुम्ही फक्त केलेल्या प्रवासाचे पैसे देता, आणि शंभर लोकांना एकाच वेळी गाडी हवी असेल तर शंभर टॅक्सी येतात. पण गाडी येण्यासाठी थोडी वाट पाहावी लागू शकते (cold start), प्रत्येक प्रवासाला जास्तीत जास्त लांबी असते, आणि ड्रायव्हरला तुमची मागील राइड आठवत नाही (functions stateless असतात).

Serverless functions कसे काम करतात

सर्वात सामान्य रूपात, ज्याला functions as a service म्हणतात:

1. तुम्ही एक function लिहिता — एका प्रकारच्या घटनेला हाताळणारा छोटा कोड, जसे "/api/bookings वर POST हाताळा."
2. तुम्ही डिप्लॉय करता. प्रदाता तो साठवतो आणि एका ट्रिगरशी जोडतो: URL, वेळापत्रक, स्टोरेजमध्ये नवी फाइल, किंवा queue मधील संदेश.
3. घटना येते. प्रदाता तुमच्या function ची प्रत सुरू करतो (किंवा उबदार प्रत वापरतो), ती चालवतो आणि निकाल परत देतो.
4. ती स्वतः वाढते. एकाच वेळी हजार विनंत्या आल्या तर प्रदाता अनेक प्रती समांतर चालवतो, तुमच्या खात्याच्या मर्यादांपर्यंत.
5. ती निष्क्रिय होते. ट्रॅफिक थांबले की प्रती बंद होतात. काहीच चालत नसताना compute साठी तुम्ही काहीही भरत नाही.

JavaScript मधील एक छोटा serverless function असा दिसू शकतो:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

सर्व्हर सुरू करण्याचा, पोर्ट उघडण्याचा किंवा प्रोसेस चालू ठेवण्याचा कोड इथे नाही. ते सर्व प्लॅटफॉर्म सांभाळते.

"Serverless" हा शब्द आपोआप स्केल होणाऱ्या आणि वापरानुसार बिल होणाऱ्या इतर व्यवस्थापित सेवांसाठीही सैलपणे वापरला जातो — उदाहरणार्थ serverless डेटाबेस, जे निष्क्रिय असताना थांबतात.

मुख्य संज्ञा

एक कृतीशील उदाहरण: छोटी बुकिंग साइट

एका योगा स्टुडिओच्या बुकिंग साइटवर दर रविवारी संध्याकाळी नवीन वेळापत्रक जाहीर होताना भेटींची लाट येते, आणि उरलेल्या आठवड्यात फारच कमी.

• नेहमी चालू सर्व्हरवर, स्टुडिओ 24/7 मशीनसाठी पैसे देतो, रविवारी संध्याकाळच्या शिखरासाठी आकारलेले, आणि उरलेल्या वेळेत बहुतेक निष्क्रिय.
• Serverless functions सह, GET /api/classes आणि POST /api/bookings हे functions आहेत. रविवारची गर्दी आपोआप अनेक प्रती सुरू करते; मंगळवार सकाळी शांत असताना जवळजवळ काहीच चालत नाही आणि बिल जवळजवळ शून्य असते.

तडजोडीही दिसतात. मंगळवार सकाळी साइट उघडणाऱ्या पहिल्या व्यक्तीला cold start मुळे थोडी जास्त वाट पाहावी लागू शकते. डेटाबेसला अनेक function प्रतींकडून अनेक अल्पायुषी कनेक्शन्स हाताळावी लागतात, ज्यासाठी connection pooler लागू शकतो. आणि स्टुडिओने नंतर "सर्वांचा वार्षिक उपस्थिती PDF बनवा" हे काम मागितले, तर ते function च्या वेळ मर्यादेपेक्षा जास्त होऊ शकते आणि दुसरीकडे चालवावे लागू शकते.

Serverless कधी योग्य आहे — आणि कधी नाही

सामान्य गैरसमज

• "Serverless म्हणजे बॅकएंड नाही." म्हणजे सांभाळायचे सर्व्हर नाहीत. तुम्ही तरीही बॅकएंड कोड लिहिता आणि सुरक्षित करता.
• "Serverless नेहमी स्वस्त असते." कमी प्रमाणात स्वस्त, पण सतत आणि मोठ्या प्रमाणात प्रति-विनंती किंमत वाढू शकते.
• "Serverless अमर्याद स्केल होते." प्लॅटफॉर्म्सना concurrency मर्यादा असतात, आणि तुमचा डेटाबेस functions आधी अडथळा ठरू शकतो.
• "Function मध्ये सेव्ह केलेल्या फाइल्स पुढच्या वेळी असतील." लोकल स्टोरेज तात्पुरते असते. डेटाबेस किंवा फाइल स्टोरेज वापरा.
• "Scale-to-zero म्हणजेच serverless." संबंधित आहेत, पण एकसारखे नाहीत. काही प्लॅटफॉर्म्स तुमचे अ‍ॅप सामान्य सर्व्हरसारखे चालवतात, जे निष्क्रिय असताना झोपते आणि पुढच्या विनंतीला जागे होते — तशीच बचत आणि तशीच पहिल्या विनंतीची वाट, पण प्रति-विनंती function वेळ मर्यादेशिवाय.

तुमच्या AI बिल्डरकडे काय विचारायचे

• "हा बॅकएंड serverless functions म्हणून चालेल, की नेहमी चालू किंवा झोपणारा सर्व्हर म्हणून? त्याचा खर्चावर काय परिणाम होतो?"
• "कोणतीही कामे प्लॅटफॉर्मच्या वेळ मर्यादेपेक्षा जास्त वेळ घेतील का? असल्यास ती कशी हाताळावीत?"
• "जे टिकायला हवे ते सर्व डेटाबेस किंवा फाइल स्टोरेजमध्ये ठेवा, मेमरी किंवा लोकल फाइल्समध्ये नाही."
• "अनेक प्रती एकाच वेळी चालल्यास डेटाबेस कनेक्शन्स कसे व्यवस्थापित करावेत?"
• "अ‍ॅप निष्क्रिय राहिल्यानंतर पहिल्या विनंतीला किती विलंब होतो?"

Mythex अ‍ॅप्स कशी होस्ट करते

Mythex आपल्या होस्टिंगला serverless functions म्हणून वर्णन करत नाही. तुम्ही प्रकाशित करता तेव्हा तुमचे अ‍ॅप एक सामान्य वेब अ‍ॅप किंवा कंटेनर म्हणून चालते, जे Mythex तुमच्यासाठी व्यवस्थापित करते — होस्टिंग सेट करण्याची गरज नाही. हे scale-to-zero आहे: प्रकाशित अ‍ॅप्स आणि त्यांचे डेटाबेस निष्क्रिय असताना झोपतात आणि पुढच्या भेटीला जागे होतात, झोपलेले अ‍ॅप compute साठी काहीच खर्च करत नाही, आणि जास्त ट्रॅफिक असताना फक्त तेव्हाच अतिरिक्त मशीन्स सुरू होतात (Pro मध्ये प्रति सेवा 3 पर्यंत). जोडलेला Postgres डेटाबेस 5 मिनिटे निष्क्रिय राहिल्यावर झोपतो आणि जागा असलेल्या वेळेसाठी बिल होतो. म्हणजे "वापरा तेवढे पैसे द्या" या फायद्याचा बराचसा भाग तुम्हाला मिळतो, आणि शांत कालावधीनंतर पहिल्या विनंतीला त्याच प्रकारचा विलंब होतो. डॉक्समध्ये होस्टिंग मर्यादा पहा, आणि आमची मार्गदर्शक वेब होस्टिंग म्हणजे काय आणि होस्टिंग खर्च कसा कमी करावा वाचा.

प्रश्न