केस स्टडीज तांत्रिक

AWS सर्व्हरलेस आर्किटेक्चर, पुराव्यासह

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

01

सर्व्हरलेस खरे तर काय आहे

सर्व्हर अजूनही आहेत. फक्त ते तुमचे नाहीत. जे बदलते ते म्हणजे तुम्ही भाड्याने घेता आणि ज्याचा विचार करता ते एकक: महिनाभर चालणाऱ्या मशीनऐवजी, तुम्ही एका फंक्शनचे एक एक्झिक्युशन भाड्याने घेता, आणि बिल तो जागा होता तितक्याच मिलिसेकंदांचे होते.

हा एक बदल आपल्यामागे बरेच काही ओढून आणतो. पॅच करण्यासाठी कोणतीही ऑपरेटिंग सिस्टीम नाही, कारण तुमच्याकडे तीच नाही. क्षमतेचे नियोजन करायची गरज नाही, कारण ठरलेली क्षमताच नाही — एक हजार एकाच वेळी आलेल्या विनंत्या एक हजार प्रती सुरू करतात. आणि रिकामे बसण्याचा खर्च नाही, कारण दोन विनंत्यांच्या दरम्यान तुमचे काहीच अस्तित्वात नसते.

What a rented server bills for, against what a function bills for One day on a single timeline. Four requests arrive at the same four moments in both rows. The rented server is billed across the whole day, shown as one unbroken band. The function is billed only at those four moments, shown as four narrow marks with nothing between them. One day. The same four requests. What each one bills you for. 00:00 06:00 12:00 18:00 24:00 Four requests arrive A rented server billed all day BILLED — 24 hours, whether or not anything happens A function billed per request four narrow marks — nothing billed in between Server: paid for 24 hours. Used a few seconds of it. Function: paid for a few seconds. The bill follows the work.
संपूर्ण कल्पना एका चित्रात: ज्या वेळेचे पैसे मोजले जातात तो आयत राहत नाही आणि कामाशी जुळू लागतो.

तुम्ही काय सोडता

चांगल्या गोष्टींपूर्वी हे सांगणे आवश्यक आहे. मशीन तुमच्या हातून जाते, त्यामुळे दीर्घकाळ चालणारी प्रक्रिया, स्थानिक डिस्क किंवा स्थिर IP हवी असलेली कोणतीही गोष्ट पुन्हा विचारात घ्यावी लागते. शांत काळानंतरची पहिली विनंती हळू असते. तुमचे आर्किटेक्चर दुसऱ्या क्लाउडवर नेणे कठीण होते. आणि डिबगिंग “ssh करून बघा” वरून लॉग आणि ट्रेस वाचण्याकडे सरकते, जे वेगळे कौशल्य आहे.

02

यात कोणत्या सेवा लागतात

सर्व्हरलेस स्टॅक इन्स्टॉल केला जात नाही, जोडला जातो. हे ते भाग आहेत जे ही साइट वापरते, प्रत्येक कशाची जागा घेतो, आणि तुम्ही कशाचे पैसे देता.

Amazon S3

वेब सर्व्हरची जागा

ऑब्जेक्ट स्टोरेज जे थेट HTTP ला उत्तर देते. तयार साइट एका बकेटमध्ये कॉपी होते आणि तिथूनच पुरवली जाते. काही चालत नाही; फाइली परत केल्या जातात.

प्रति GB साठवण आणि प्रति विनंती बिल

AWS Lambda

ॲप्लिकेशन सर्व्हरची जागा

मागणीनुसार एक फंक्शन चालवते, अशा कंटेनरमध्ये जो AWS सुरू करते आणि नष्ट करते. तुम्ही कोड आणि मेमरीचा आकार देता; त्याखालचे सर्व काही AWS देते.

प्रति मिलिसेकंद × मेमरी बिल

Lambda Function URL

API गेटवेची जागा

एक HTTPS एंडपॉइंट, थेट फंक्शनला जोडलेले, स्वतःच्या CORS सेटिंगसह. एकाच एंडपॉइंटसाठी हे आकृतीतून एक संपूर्ण सेवा काढून टाकते.

कोणतेही अतिरिक्त शुल्क नाही

Amazon DynamoDB

डेटाबेस सर्व्हरची जागा

एक व्यवस्थापित की-व्हॅल्यू स्टोअर, ज्यात आकार ठरवण्यासाठी कोणतेही इन्स्टन्स नाही. एखाद्या ओळीवर कालमर्यादा लावा आणि मुदत संपताच ती स्वतः पुसली जाते.

प्रति रीड, राइट आणि GB बिल

Amazon SNS

मेल सर्व्हरची जागा

एखाद्या विषयावर संदेश प्रकाशित करा आणि त्याला सदस्य असलेल्या सर्वांना सूचना मिळते. चौकशीच्या सूचनेसाठी एवढीच पूर्ण गरज आहे.

प्रति संदेश बिल

OIDC सह IAM

साठवलेल्या क्रेडेन्शियलची जागा

तैनाती पाइपलाइन GitHub कडून मिळालेल्या अल्पायुषी टोकनने स्वतःची ओळख सिद्ध करते आणि एक भूमिका घेते. लीक होण्यासाठी कोणतीही AWS ॲक्सेस किल्ली अस्तित्वातच नाही.

कोणतेही शुल्क नाही

इथे वापरलेल्या नाहीत, पण याच कुटुंबातील आहेत आणि जाणून घेण्याजोग्या आहेत: API Gateway, जेव्हा अनेक राउट, प्राधिकरण किंवा थ्रॉटलिंग हवे; Step Functions, जेव्हा काम अनेक फंक्शनांमध्ये पसरलेले असते; EventBridge, शेड्यूलिंग आणि फॅन-आउटसाठी; CloudFront, जेव्हा S3 च्या पुढे CDN आणि स्वतःचे प्रमाणपत्र हवे.

03

एक विनंती, सुरुवातीपासून शेवटपर्यंत

या साइटवर संपर्क फॉर्म भरून तुम्ही Send दाबता तेव्हा हे घडते.

The path a form submission takes through the architecture The browser loads pages from Amazon S3. On submit it posts to a Lambda Function URL, which invokes a Lambda function. The function writes the enquiry to DynamoDB with a time-to-live and publishes a notification to SNS, which emails the team. The function then returns a JSON reply to the browser, which shows the thank-you page. Browser the visitor fills the form Amazon S3 the pages themselves GET / Function URL one HTTPS door CORS lives here POST AWS Lambda starts, runs, stops checks the honeypot DynamoDB the enquiry, with a TTL Amazon SNS emails the team 200 { ok: true } → thank-you page
या आकृतीच्या मधले काहीही POST येईपर्यंत अस्तित्वात नसते, आणि उत्तर गेल्यानंतर एका सेकंदात त्यातले काहीही उरत नाही.
  1. पाने स्टोरेजमधून येतात

    साइट स्टॅटिक फाइलींमध्ये तयार होते आणि एका S3 बकेटमध्ये सिंक होते. S3 स्वतः विनंतीला उत्तर देते. त्याच्या पुढे कोणतीही प्रोसेस नाही जिची मेमरी संपेल, कोणताही कनेक्शन पूल नाही, आणि न्यूजलेटर गेल्याबरोबर कोसळेल असे काही नाही.

  2. तुम्ही Send दाबता

    ब्राउझर Function URL वर JSON पाठवतो. या क्षणापर्यंत जगात कुठेही आमचे कोणतेही कंप्युट चालू नसते — ना रिकामे बसलेले, ना शून्यावर आणलेले, फक्त अनुपस्थित.

  3. AWS एक कंटेनर सुरू करते

    ते फंक्शनचा कोड आणते, एक रनटाइम सुरू करते, आणि हँडलरला बोलावते. उबदार कंटेनरवर ते थेट हँडलरकडे जाते. दोन्ही बाबतीत फंक्शन म्हणजे JavaScript ची एक फाइल आहे, तिच्याखाली कोणतेही फ्रेमवर्क नाही.

  4. फंक्शन ठरवते की ही व्यक्ती आहे की नाही

    तीन स्वस्त तपासण्या, क्रमाने: एक लपलेला रकाना जो फक्त स्वयंचलित फॉर्म भरणाराच भरेल, पान तयार झाल्याची आणि फॉर्म पाठवल्याची वेळ यांची तुलना, आणि त्याच टेबलमध्ये ठेवलेली प्रत्येक IP ची मोजणी. कोणताही बॉट यापैकी किमान एकात सापडतो.

  5. ते लिहिते, सांगते, आणि उत्तर देते

    चौकशी DynamoDB मध्ये जाते, ओळीवर मुदतसमाप्तीचा शिक्का असतो, सूचना SNS ला जाते, आणि एक छोटे JSON उत्तर ब्राउझरकडे परत जाते, जो तुम्हाला धन्यवाद पानावर पाठवतो. मग कंटेनर गोठवला जातो, आणि थोड्याच वेळात टाकून दिला जातो.

04

ही वेबसाइट, तपशिलात

तपशील, जेणेकरून तुम्ही दावे मानण्याऐवजी पडताळू शकाल.

फ्रंट एंड
Vite मल्टी-पेज बिल्ड, Three.js दृश्ये, कोणताही फ्रेमवर्क रनटाइम नाही
होस्टिंग
Amazon S3 स्टॅटिक वेबसाइट होस्टिंग
प्रदेश
ap-south-1 (मुंबई) — डेटा भारतातच राहतो
कंप्युट
एक AWS Lambda फंक्शन, Node.js, एकच फाइल
प्रवेश बिंदू
Lambda Function URL, CORS त्याच URL वर कॉन्फिगर
साठा
DynamoDB, एक टेबल, प्रत्येक ओळीवर TTL गुणधर्म
सूचना
Amazon SNS विषय, ईमेल सदस्यत्व
बॉटपासून बचाव
हनीपॉट रकाना, रेंडर-वेळेचे घड्याळ, प्रति-IP मोजणी
तैनाती
GitHub Actions, OIDC द्वारे एक IAM भूमिका घेऊन
भाषा
इंग्रजी, हिंदी आणि मराठी, संपूर्ण पाने म्हणून तयार

तीन गोष्टी ज्या आम्ही आधी चुकलो

CORS दोन ठिकाणी सेट केले

आम्ही CORS हे Function URL वर कॉन्फिगर केले आणि त्याचबरोबर फंक्शनमधूनही हेडर परत केले. मग उत्तरात access-control-allow-origin हेडर दोनदा गेले, ब्राउझरनी ते सदोष मानून नाकारले, आणि फॉर्मवर “Load failed” दिसले — प्रत्यक्षात चौकशी साठवली गेली होती आणि ईमेलही व्यवस्थित गेला होता. यावर उपाय म्हणजे एकच जागा निवडणे. आम्ही URL निवडतो.

एक सार्वजनिक एंडपॉइंट जो भीतीदायक वाटला

Function URL पानाच्या स्रोतात दिसते, आणि सहसा पहिली काळजी हीच असते. ते मुद्दामच सार्वजनिक आहे: ते फक्त एक फॉर्म पोस्ट स्वीकारते, दुसरे काही नाही, त्याच्याकडे स्वतःची कोणतीही क्रेडेन्शियल नाहीत, आणि त्याची IAM भूमिका नेमक्या एका टेबलमध्ये लिहू शकते आणि नेमक्या एका विषयावर प्रकाशित करू शकते. गुपित म्हणजे पत्ता नव्हे; गुपित म्हणजे त्या पत्त्याला काय करण्याची परवानगी आहे.

एक CAPTCHA ज्याची गरज नव्हती

पहिल्या रचनेत तिसऱ्या पक्षाचा CAPTCHA होता. म्हणजे विनंतीच्या मार्गात आणखी एक पुरवठादार, आणखी एक गोपनीयता घोषणा, आणि प्रत्येक खऱ्या अभ्यागतासाठी एक कोडे. हनीपॉट-आणि-घड्याळाची पद्धत काहीही खर्च करत नाही, कोणाला काही सांगत नाही, आणि टिकून आहे.

05

कोल्ड स्टार्ट, प्रामाणिकपणे

जेव्हा कोणताही कंटेनर उबदार नसतो, तेव्हा तुमचा कोड चालण्यापूर्वी AWS ला एक तयार करावा लागतो. हाच कोल्ड स्टार्ट आहे, आणि सर्व्हरलेसवरील हाच सर्वाधिक घेतला जाणारा आक्षेप आहे. हे खरे आहे, आणि सहसा तो उद्धृत करणारे लोक तुम्ही वापरत असलेल्या रनटाइमपेक्षा वेगळ्या रनटाइमविषयी बोलत असतात.

प्रत्यक्षात हे काय ठरवते: भाषा, तैनाती पॅकेजचा आकार, आणि फंक्शनला खाजगी नेटवर्कपर्यंत पोहोचायचे आहे का. VPC जोडणी नसलेले छोटे JavaScript फंक्शन वेगवान टोकाला आहे. VPC मधील मोठे Java ॲप्लिकेशन संथ टोकाला आहे, आणि या दोन्हींची चर्चा अनेकदा ती एकच गोष्ट असल्यासारखी होते.

कोल्ड स्टार्ट कुठे येऊन पडतो हेही महत्त्वाचे आहे. या साइटवर तो फक्त फॉर्म पाठवताना येऊ शकतो, जेव्हा एखाद्या व्यक्तीने मिनिटभर टाइप केलेले असते. तो प्रत्येक पान उघडताना पडला असता, तर उत्तर वेगळे असते — आणि नेमके याचसाठी पाने S3 मधून येतात.

जर तुमच्या कामासाठी कोल्ड स्टार्ट खरोखर महत्त्वाचे असतील

पॅकेज लहान ठेवा, गरज नसेल तर VPC च्या बाहेर राहा, काम मॉड्यूल स्कोपमधून काढून हँडलरमध्ये आणा, आणि मार्ग खरोखर विलंबाबाबत संवेदनशील असेल तर प्रोव्हिजन्ड कंकरन्सी वापरा आणि उबदार कंटेनरचे पैसे द्या. हा शेवटचा पर्याय एक डायल आहे, पराभव नव्हे.

06

याचा खर्च

आम्ही कोणताही मासिक आकडा छापणार नाही, कारण तुमचा आकडा वेगळा असेल आणि बनवलेला आकडा कोणाच्याही उपयोगाचा नाही. उपयोगाची गोष्ट म्हणजे बिलाचा आकार.

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

प्रामाणिक प्रतिवाद: सातत्याने मोठ्या प्रमाणावर, सतत व्यस्त असलेले फंक्शन तेच काम करणाऱ्या सतत व्यस्त सर्व्हरपेक्षा महाग पडते. एक बिंदू येतो जिथे दोन्ही भेटतात. त्याखाली तुम्ही रिकामे बसण्याचे पैसे देता; त्यावर तुम्ही काहीही चालवावे न लागण्याचे जास्तीचे पैसे देता. तुमची रहदारी त्या रेषेवर साधारण कुठे बसते हे जाणणे हाच बहुतांश निर्णय आहे.

How the two cost models compare as traffic grows A server's cost is a flat horizontal line that does not change with traffic. A serverless cost starts near zero and rises with traffic, crossing the server line at a point where sustained traffic becomes high. Below the crossing, serverless is cheaper; above it, the server is. traffic → cost → a rented server — the same every month serverless — follows the work the crossover cheaper here dearer here
अक्षांवर आकडे मुद्दाम दिलेले नाहीत: तो बिंदू कुठे पडतो हे पूर्णपणे तुमच्या कामावर अवलंबून आहे, आणि काढलेला आकडा म्हणजे तथ्याच्या वेषातील अंदाज ठरला असता.

07

ते तैनात करणे

मेन ब्रँचवरील एका पुशने GitHub Actions चा रन सुरू होतो. रन GitHub कडून एक अल्पायुषी ओळख टोकन मागतो, ते AWS ला देतो, आणि AWS बदल्यात याच एका कामापुरती मर्यादित भूमिकेसाठी तात्पुरती क्रेडेन्शियल परत देते. मग तो साइट तयार करतो आणि निकाल S3 वर सिंक करतो.

मधल्या त्या पायरीचा अर्थ असा की GitHub मध्ये कुठेही कोणतीही AWS ॲक्सेस किल्ली अस्तित्वात नाही. फिरवण्यासाठी कोणतेही गुपित नाही, लॉगमध्ये गळण्यासाठी कोणतीही किल्ली नाही, आणि रेपॉझिटरीपर्यंत वाचनाची पोहोच मिळवणाऱ्यासाठी काहीही उपयोगाचे नाही.

The deploy pipeline A push to the main branch triggers GitHub Actions, which requests an OIDC token, exchanges it with AWS IAM for temporary credentials, builds the site, and syncs it to the S3 bucket, which serves visitors. git pushto main GitHub Actionsbuilds the site IAM via OIDCno stored keys S3 synctwo passes liveunder a minute
दोन टप्प्यांचे सिंक आधी फिंगरप्रिंट केलेल्या मालमत्ता पाठवते आणि HTML नंतर, जेणेकरून कोणतेही पान त्याला लागणाऱ्या फाइलींच्या आधी कधीही लाइव्ह होणार नाही.

08

सर्व्हरलेस कधी चुकीचे उत्तर आहे

आम्ही हे तुम्हाला आताच सांगणे पसंत करू, स्थलांतराच्या मध्यावर नव्हे.

  • स्थिर, जड, अंदाज करण्याजोगा भार. जर काम कधी थांबतच नसेल, तर तुम्ही वापरत नसलेल्या लवचिकतेसाठी जास्त पैसे देत आहात.
  • दीर्घकाळ चालणारी कामे. फंक्शनची एक्झिक्युशन मर्यादा ठरलेली असते. तासनतास चालणारे काम कंटेनर किंवा बॅच सेवेत असावे.
  • एका अंकातील मिलिसेकंदांच्या विलंब मर्यादा. ट्रेडिंगचे मार्ग आणि तत्सम यंत्रणांना तुमच्या नियंत्रणातील उबदार प्रक्रिया हवी असते.
  • जड, वारंवार संवाद साधणारे डेटाबेस काम. पारंपरिक रिलेशनल डेटाबेससमोर अनेक अल्पायुषी फंक्शनांना कनेक्शन पूलिंग लागते, ज्याचा तुम्ही एरवी विचारही केला नसता.
  • तुम्ही न लिहिलेले सॉफ्टवेअर. होस्टची अपेक्षा करणारे परवानाधारक ॲप्लिकेशन तुम्हाला हवे म्हणून फंक्शन बनणार नाही.
  • पोर्टेबल राहण्याची कडक अट. सर्व्हरलेस तुम्हाला एखाद्या पुरवठादाराच्या मूलभूत घटकांशी कंटेनरपेक्षा अधिक घट्ट बांधते. ही देवाणघेवाण स्वीकारार्ह असू शकते — पण तो निर्णय असावा, आश्चर्य नव्हे.

तुमच्या स्वतःच्या स्टॅकसाठी याचा विचार करत आहात?

आम्ही हे बँका, NBFC, वेल्थ मॅनेजर आणि फिनटेकसाठी बांधतो आणि चालवतो — जे भाग सर्व्हरलेस होऊच शकत नाहीत त्यांच्यासह. आज तुम्ही काय चालवत आहात ते सांगा, आणि कोणते भाग हलवण्याजोगे आहेत हे आम्ही प्रामाणिकपणे सांगू.

केस स्टडीजकडे परत