Amazon S3
वेब सर्व्हरची जागा
ऑब्जेक्ट स्टोरेज जे थेट HTTP ला उत्तर देते. तयार साइट एका बकेटमध्ये कॉपी होते आणि तिथूनच पुरवली जाते. काही चालत नाही; फाइली परत केल्या जातात.
प्रति GB साठवण आणि प्रति विनंती बिल
केस स्टडीज तांत्रिक
सर्व्हरलेसची बहुतेक स्पष्टीकरणे आकृतीवरच थांबतात. हे स्पष्टीकरण अशा यंत्रणेपर्यंत जाते जिला तुम्ही स्वतः हात लावू शकता: तीच वेबसाइट जिच्यावर तुम्ही आहात. खाली दिलेला प्रत्येक आकडा, प्रत्येक सेवा आणि प्रत्येक निर्णय खरोखर प्रॉडक्शनमध्ये आहे तोच आहे — आम्ही आधी चुकलो ते भागही.
01
सर्व्हर अजूनही आहेत. फक्त ते तुमचे नाहीत. जे बदलते ते म्हणजे तुम्ही भाड्याने घेता आणि ज्याचा विचार करता ते एकक: महिनाभर चालणाऱ्या मशीनऐवजी, तुम्ही एका फंक्शनचे एक एक्झिक्युशन भाड्याने घेता, आणि बिल तो जागा होता तितक्याच मिलिसेकंदांचे होते.
हा एक बदल आपल्यामागे बरेच काही ओढून आणतो. पॅच करण्यासाठी कोणतीही ऑपरेटिंग सिस्टीम नाही, कारण तुमच्याकडे तीच नाही. क्षमतेचे नियोजन करायची गरज नाही, कारण ठरलेली क्षमताच नाही — एक हजार एकाच वेळी आलेल्या विनंत्या एक हजार प्रती सुरू करतात. आणि रिकामे बसण्याचा खर्च नाही, कारण दोन विनंत्यांच्या दरम्यान तुमचे काहीच अस्तित्वात नसते.
चांगल्या गोष्टींपूर्वी हे सांगणे आवश्यक आहे. मशीन तुमच्या हातून जाते, त्यामुळे दीर्घकाळ चालणारी प्रक्रिया, स्थानिक डिस्क किंवा स्थिर IP हवी असलेली कोणतीही गोष्ट पुन्हा विचारात घ्यावी लागते. शांत काळानंतरची पहिली विनंती हळू असते. तुमचे आर्किटेक्चर दुसऱ्या क्लाउडवर नेणे कठीण होते. आणि डिबगिंग “ssh करून बघा” वरून लॉग आणि ट्रेस वाचण्याकडे सरकते, जे वेगळे कौशल्य आहे.
02
सर्व्हरलेस स्टॅक इन्स्टॉल केला जात नाही, जोडला जातो. हे ते भाग आहेत जे ही साइट वापरते, प्रत्येक कशाची जागा घेतो, आणि तुम्ही कशाचे पैसे देता.
वेब सर्व्हरची जागा
ऑब्जेक्ट स्टोरेज जे थेट HTTP ला उत्तर देते. तयार साइट एका बकेटमध्ये कॉपी होते आणि तिथूनच पुरवली जाते. काही चालत नाही; फाइली परत केल्या जातात.
प्रति GB साठवण आणि प्रति विनंती बिल
ॲप्लिकेशन सर्व्हरची जागा
मागणीनुसार एक फंक्शन चालवते, अशा कंटेनरमध्ये जो AWS सुरू करते आणि नष्ट करते. तुम्ही कोड आणि मेमरीचा आकार देता; त्याखालचे सर्व काही AWS देते.
प्रति मिलिसेकंद × मेमरी बिल
API गेटवेची जागा
एक HTTPS एंडपॉइंट, थेट फंक्शनला जोडलेले, स्वतःच्या CORS सेटिंगसह. एकाच एंडपॉइंटसाठी हे आकृतीतून एक संपूर्ण सेवा काढून टाकते.
कोणतेही अतिरिक्त शुल्क नाही
डेटाबेस सर्व्हरची जागा
एक व्यवस्थापित की-व्हॅल्यू स्टोअर, ज्यात आकार ठरवण्यासाठी कोणतेही इन्स्टन्स नाही. एखाद्या ओळीवर कालमर्यादा लावा आणि मुदत संपताच ती स्वतः पुसली जाते.
प्रति रीड, राइट आणि GB बिल
मेल सर्व्हरची जागा
एखाद्या विषयावर संदेश प्रकाशित करा आणि त्याला सदस्य असलेल्या सर्वांना सूचना मिळते. चौकशीच्या सूचनेसाठी एवढीच पूर्ण गरज आहे.
प्रति संदेश बिल
साठवलेल्या क्रेडेन्शियलची जागा
तैनाती पाइपलाइन GitHub कडून मिळालेल्या अल्पायुषी टोकनने स्वतःची ओळख सिद्ध करते आणि एक भूमिका घेते. लीक होण्यासाठी कोणतीही AWS ॲक्सेस किल्ली अस्तित्वातच नाही.
कोणतेही शुल्क नाही
इथे वापरलेल्या नाहीत, पण याच कुटुंबातील आहेत आणि जाणून घेण्याजोग्या आहेत: API Gateway, जेव्हा अनेक राउट, प्राधिकरण किंवा थ्रॉटलिंग हवे; Step Functions, जेव्हा काम अनेक फंक्शनांमध्ये पसरलेले असते; EventBridge, शेड्यूलिंग आणि फॅन-आउटसाठी; CloudFront, जेव्हा S3 च्या पुढे CDN आणि स्वतःचे प्रमाणपत्र हवे.
03
या साइटवर संपर्क फॉर्म भरून तुम्ही Send दाबता तेव्हा हे घडते.
साइट स्टॅटिक फाइलींमध्ये तयार होते आणि एका S3 बकेटमध्ये सिंक होते. S3 स्वतः विनंतीला उत्तर देते. त्याच्या पुढे कोणतीही प्रोसेस नाही जिची मेमरी संपेल, कोणताही कनेक्शन पूल नाही, आणि न्यूजलेटर गेल्याबरोबर कोसळेल असे काही नाही.
ब्राउझर Function URL वर JSON पाठवतो. या क्षणापर्यंत जगात कुठेही आमचे कोणतेही कंप्युट चालू नसते — ना रिकामे बसलेले, ना शून्यावर आणलेले, फक्त अनुपस्थित.
ते फंक्शनचा कोड आणते, एक रनटाइम सुरू करते, आणि हँडलरला बोलावते. उबदार कंटेनरवर ते थेट हँडलरकडे जाते. दोन्ही बाबतीत फंक्शन म्हणजे JavaScript ची एक फाइल आहे, तिच्याखाली कोणतेही फ्रेमवर्क नाही.
तीन स्वस्त तपासण्या, क्रमाने: एक लपलेला रकाना जो फक्त स्वयंचलित फॉर्म भरणाराच भरेल, पान तयार झाल्याची आणि फॉर्म पाठवल्याची वेळ यांची तुलना, आणि त्याच टेबलमध्ये ठेवलेली प्रत्येक IP ची मोजणी. कोणताही बॉट यापैकी किमान एकात सापडतो.
चौकशी DynamoDB मध्ये जाते, ओळीवर मुदतसमाप्तीचा शिक्का असतो, सूचना SNS ला जाते, आणि एक छोटे JSON उत्तर ब्राउझरकडे परत जाते, जो तुम्हाला धन्यवाद पानावर पाठवतो. मग कंटेनर गोठवला जातो, आणि थोड्याच वेळात टाकून दिला जातो.
04
तपशील, जेणेकरून तुम्ही दावे मानण्याऐवजी पडताळू शकाल.
आम्ही CORS हे Function URL वर कॉन्फिगर केले आणि त्याचबरोबर फंक्शनमधूनही हेडर परत केले. मग उत्तरात access-control-allow-origin हेडर दोनदा गेले, ब्राउझरनी ते सदोष मानून नाकारले, आणि फॉर्मवर “Load failed” दिसले — प्रत्यक्षात चौकशी साठवली गेली होती आणि ईमेलही व्यवस्थित गेला होता. यावर उपाय म्हणजे एकच जागा निवडणे. आम्ही URL निवडतो.
Function URL पानाच्या स्रोतात दिसते, आणि सहसा पहिली काळजी हीच असते. ते मुद्दामच सार्वजनिक आहे: ते फक्त एक फॉर्म पोस्ट स्वीकारते, दुसरे काही नाही, त्याच्याकडे स्वतःची कोणतीही क्रेडेन्शियल नाहीत, आणि त्याची IAM भूमिका नेमक्या एका टेबलमध्ये लिहू शकते आणि नेमक्या एका विषयावर प्रकाशित करू शकते. गुपित म्हणजे पत्ता नव्हे; गुपित म्हणजे त्या पत्त्याला काय करण्याची परवानगी आहे.
पहिल्या रचनेत तिसऱ्या पक्षाचा CAPTCHA होता. म्हणजे विनंतीच्या मार्गात आणखी एक पुरवठादार, आणखी एक गोपनीयता घोषणा, आणि प्रत्येक खऱ्या अभ्यागतासाठी एक कोडे. हनीपॉट-आणि-घड्याळाची पद्धत काहीही खर्च करत नाही, कोणाला काही सांगत नाही, आणि टिकून आहे.
05
जेव्हा कोणताही कंटेनर उबदार नसतो, तेव्हा तुमचा कोड चालण्यापूर्वी AWS ला एक तयार करावा लागतो. हाच कोल्ड स्टार्ट आहे, आणि सर्व्हरलेसवरील हाच सर्वाधिक घेतला जाणारा आक्षेप आहे. हे खरे आहे, आणि सहसा तो उद्धृत करणारे लोक तुम्ही वापरत असलेल्या रनटाइमपेक्षा वेगळ्या रनटाइमविषयी बोलत असतात.
प्रत्यक्षात हे काय ठरवते: भाषा, तैनाती पॅकेजचा आकार, आणि फंक्शनला खाजगी नेटवर्कपर्यंत पोहोचायचे आहे का. VPC जोडणी नसलेले छोटे JavaScript फंक्शन वेगवान टोकाला आहे. VPC मधील मोठे Java ॲप्लिकेशन संथ टोकाला आहे, आणि या दोन्हींची चर्चा अनेकदा ती एकच गोष्ट असल्यासारखी होते.
कोल्ड स्टार्ट कुठे येऊन पडतो हेही महत्त्वाचे आहे. या साइटवर तो फक्त फॉर्म पाठवताना येऊ शकतो, जेव्हा एखाद्या व्यक्तीने मिनिटभर टाइप केलेले असते. तो प्रत्येक पान उघडताना पडला असता, तर उत्तर वेगळे असते — आणि नेमके याचसाठी पाने S3 मधून येतात.
पॅकेज लहान ठेवा, गरज नसेल तर VPC च्या बाहेर राहा, काम मॉड्यूल स्कोपमधून काढून हँडलरमध्ये आणा, आणि मार्ग खरोखर विलंबाबाबत संवेदनशील असेल तर प्रोव्हिजन्ड कंकरन्सी वापरा आणि उबदार कंटेनरचे पैसे द्या. हा शेवटचा पर्याय एक डायल आहे, पराभव नव्हे.
06
आम्ही कोणताही मासिक आकडा छापणार नाही, कारण तुमचा आकडा वेगळा असेल आणि बनवलेला आकडा कोणाच्याही उपयोगाचा नाही. उपयोगाची गोष्ट म्हणजे बिलाचा आकार.
भाड्याचा सर्व्हर एक आयत आहे: दर महिन्याला तितकेच, हजार लोक आले असोत की कोणीच नाही. सर्व्हरलेस ही जमिनीपासून सुरू होणारी पायरी आहे. संपर्क फॉर्म असलेल्या मार्केटिंग साइटसाठी त्या पायरीचा कंप्युटचा भाग जमिनीपासून जेमतेम उठतो, कारण कंप्युट तेव्हाच चालते जेव्हा कोणी तुम्हाला लिहिते.
प्रामाणिक प्रतिवाद: सातत्याने मोठ्या प्रमाणावर, सतत व्यस्त असलेले फंक्शन तेच काम करणाऱ्या सतत व्यस्त सर्व्हरपेक्षा महाग पडते. एक बिंदू येतो जिथे दोन्ही भेटतात. त्याखाली तुम्ही रिकामे बसण्याचे पैसे देता; त्यावर तुम्ही काहीही चालवावे न लागण्याचे जास्तीचे पैसे देता. तुमची रहदारी त्या रेषेवर साधारण कुठे बसते हे जाणणे हाच बहुतांश निर्णय आहे.
07
मेन ब्रँचवरील एका पुशने GitHub Actions चा रन सुरू होतो. रन GitHub कडून एक अल्पायुषी ओळख टोकन मागतो, ते AWS ला देतो, आणि AWS बदल्यात याच एका कामापुरती मर्यादित भूमिकेसाठी तात्पुरती क्रेडेन्शियल परत देते. मग तो साइट तयार करतो आणि निकाल S3 वर सिंक करतो.
मधल्या त्या पायरीचा अर्थ असा की GitHub मध्ये कुठेही कोणतीही AWS ॲक्सेस किल्ली अस्तित्वात नाही. फिरवण्यासाठी कोणतेही गुपित नाही, लॉगमध्ये गळण्यासाठी कोणतीही किल्ली नाही, आणि रेपॉझिटरीपर्यंत वाचनाची पोहोच मिळवणाऱ्यासाठी काहीही उपयोगाचे नाही.
08
आम्ही हे तुम्हाला आताच सांगणे पसंत करू, स्थलांतराच्या मध्यावर नव्हे.
आम्ही हे बँका, NBFC, वेल्थ मॅनेजर आणि फिनटेकसाठी बांधतो आणि चालवतो — जे भाग सर्व्हरलेस होऊच शकत नाहीत त्यांच्यासह. आज तुम्ही काय चालवत आहात ते सांगा, आणि कोणते भाग हलवण्याजोगे आहेत हे आम्ही प्रामाणिकपणे सांगू.