प्रारंभिक चरण
<पी> एआई उत्पाद के निर्माण के शुरुआती दिनों के दौरान, सबसे बड़ी बाधा प्रदर्शन नहीं है, विशेष रूप से विलंबता स्थिरता (प्रत्येक अनुरोध कितनी तेजी से प्रतिक्रिया देता है) और थ्रूपुट (एक बार में कितने अनुरोध संभाले जाते हैं), लेकिन यह है कि आप कितनी जल्दी शिप कर सकते हैं, पुनरावृत्त कर सकते हैं और वास्तविक उपयोग से सीख सकते हैं। <पी> शुरुआती दिनों में, कार्यभार को अभी तक समझा नहीं जा सका है, ट्रैफ़िक असंगत है, मॉडल बदल रहे हैं, और उत्पाद को अभी भी आकार दिया जा रहा है। ऐसे मामलों में, सर्वर रहित प्लेटफ़ॉर्म डेवलपर की ज़रूरतों के लिए लगभग बिल्कुल सही लगता है। <पी> वे ऐसे निर्णय हटा देते हैं जो अन्यथा आपको धीमा कर देते। आपको GPU प्रावधान, स्केलिंग नीतियों या क्षमता नियोजन के बारे में सोचने की ज़रूरत नहीं है। आप कोड लिखते हैं, तैनात करते हैं, और सिस्टम जो भी मांग दिखाई देती है उसके अनुरूप ढल जाता है। प्रारंभिक चरण के अनुप्रयोगों के लिए, जैसे प्रोटोटाइप चैटबॉट, दस्तावेज़ सारांश, या आंतरिक एआई उपकरण, यह न केवल सुविधाजनक है; यह शिपिंग और शिपिंग नहीं के बीच का अंतर है। <पी> इस स्तर पर, अक्षमताएं कोई मायने नहीं रखतीं क्योंकि उपयोग स्वयं अनिश्चित है। आप पुनरावृत्ति गति के लिए अनुकूलन कर रहे हैं, बुनियादी ढांचे की दक्षता के लिए नहीं।पहली पाली:विलंबता एक उत्पाद समस्या बन जाती है
<पी> पहला संकेत यह है कि आपकी बुनियादी ढांचे की पसंद गलत तरीके से शुरू हो रही है, बिलिंग डैशबोर्ड में शायद ही कभी दिखाई देती है। यह उपयोगकर्ता अनुभव में दिखता है. जैसे-जैसे उपयोग बढ़ता है, भले ही मामूली रूप से, विलंबता एक सैद्धांतिक मीट्रिक होना बंद हो जाती है और दिखाई देने लगती है। <पी> सर्वर रहित सिस्टम लोच के आसपास बनाए जाते हैं, जो अक्सर परिवर्तनशीलता के साथ आता है। यदि वातावरण पहले से ही गर्म है तो अनुरोध तुरंत वापस आ सकता है, या यदि यह कोल्ड स्टार्ट या मॉडल लोड को ट्रिगर करता है तो इसमें काफी अधिक समय लग सकता है। अलगाव में, यह स्वीकार्य है. लेकिन उपयोगकर्ता-सामना वाली प्रणाली में, औसत प्रदर्शन की तुलना में असंगतता कहीं अधिक ध्यान देने योग्य है। <पी> ग्राहक सहायता वर्कफ़्लो में एम्बेडेड एआई सहायक, या आईडीई के अंदर एक कोड जनरेशन सुविधा पर विचार करें। दोनों ही मामलों में, उपयोगकर्ता उम्मीद करते हैं कि प्रतिक्रिया तत्काल और पूर्वानुमानित होगी। कुछ धीमी प्रतिक्रियाएँ धारणा में औसत नहीं होती हैं, लेकिन वे अलग दिखती हैं। जो कभी बुनियादी ढांचे का विवरण था वह उत्पाद दोष बन जाता है।दूसरी पाली:जब लागत बढ़ने लगती है
<पी> जैसे-जैसे आपका सिस्टम बढ़ता है, उपयोग अधिक नियमित हो जाता है। जो कभी-कभार अनुरोध हुआ करते थे वे स्थिर ट्रैफ़िक में बदल जाते हैं, और जो सुविधाएँ कभी प्रयोग थीं वे रोजमर्रा के उपयोग का हिस्सा बन जाती हैं। यह तब होता है जब सर्वर रहित मूल्य निर्धारण अलग लगने लगता है। <पी> जब उपयोग अप्रत्याशित हो तो सर्वर रहित अच्छा काम करता है, क्योंकि आप केवल तभी भुगतान करते हैं जब कुछ चलता है। लेकिन एक बार जब आपका सिस्टम हमेशा सक्रिय रहता है, निरंतर अनुरोधों को संभालता है या पृष्ठभूमि कार्य चलाता है, तो आपको एक ही काम के लिए बार-बार भुगतान करना पड़ता है। समय के साथ, वह सुविधा महंगी होने लगती है। <पी> इस बिंदु पर, समर्पित बुनियादी ढांचा, निश्चित जीपीयू पर चलने वाले मॉडल, अधिक समझ में आने लगते हैं। आपको लागतों पर अधिक नियंत्रण की आवश्यकता है, जो प्रदर्शन को अधिक स्थिर बनाता है, जब तक आप संसाधनों का कुशलतापूर्वक उपयोग करते हैं। <पी> यहां वास्तव में कुछ भी गलत नहीं हो रहा है. इसका सीधा सा मतलब है कि आपका सिस्टम उस बिंदु तक विकसित हो गया है जहां पहले वाला सेटअप अब सबसे अधिक लागत प्रभावी विकल्प नहीं रह गया है।कार्यभार का आकार, प्लेटफ़ॉर्म का चुनाव नहीं, परिणाम को प्रेरित करता है
<पी> समय के साथ जो स्पष्ट हो जाता है वह यह है कि निर्णय वास्तव में दो प्रकार के प्लेटफार्मों के बीच चयन करने के बारे में नहीं है। यह समझने के बारे में है कि आपका कार्यभार कैसा व्यवहार करता है और वह व्यवहार कैसे बदलता है। <पी> कई टीमें यह मानकर गलती करती हैं कि उनका वर्तमान कार्यभार स्थायी है। वास्तव में, अधिकांश प्रणालियाँ अनेक अवस्थाओं से होकर गुजरती हैं। एक एप्लिकेशन अत्यधिक तेज उपयोग के साथ शुरू हो सकता है, अर्ध-अनुमानित दैनिक चक्रों में परिवर्तित हो सकता है, और अंततः एक स्थिर, उच्च-थ्रूपुट पैटर्न में व्यवस्थित हो सकता है। इनमें से प्रत्येक चरण एक अलग दृष्टिकोण का समर्थन करता है।मध्य चरण
<पी> सबसे कठिन चरण शुरुआत या अंत नहीं है, बल्कि उनके बीच का संक्रमण है। यह वह जगह है जहां सिस्टम अक्सर "बंद" महसूस करते हैं, भले ही कुछ भी टूटा न हो। विलंबता के मुद्दे कभी-कभी दिखाई देते हैं, लेकिन लगातार नहीं, और लागत बढ़ने लगती है, लेकिन पूर्ण वास्तुशिल्प बदलाव को उचित ठहराने के लिए पर्याप्त नहीं है। डेवलपर्स वर्कअराउंड जोड़ना शुरू करते हैं, जैसे कैशिंग प्रतिक्रियाएं, प्री-वार्मिंग वातावरण, या चीजों को सुचारू करने के लिए समवर्तीता को ट्विक करना। ये परिवर्तन अस्थायी रूप से मदद करते हैं, लेकिन वे यह भी संकेत देते हैं कि सिस्टम को उस चीज़ से आगे बढ़ाया जा रहा है जिसके लिए इसे मूल रूप से डिज़ाइन किया गया था। <पी> यदि हम फिर से बढ़ते एआई ग्राहक सहायता सहायक का उदाहरण लें। प्रारंभिक चरण के दौरान, यह कम संख्या में प्रश्नों को संभालने में सक्षम है, लेकिन जैसे-जैसे इसकी स्वीकार्यता बढ़ती है, सिस्टम पीक आवर्स के दौरान सैकड़ों अनुरोधों को संभालना शुरू कर देता है। अधिकांश प्रतिक्रियाएँ अभी भी तेज़ हैं, लेकिन ठंड शुरू होने या स्केलिंग में देरी के कारण कुछ में काफी अधिक समय लग जाता है। टीम बार-बार पूछे जाने वाले प्रश्नों के लिए कैशिंग जोड़ती है और विलंबता स्पाइक्स को कम करने के लिए प्री-वार्मिंग का प्रयास करती है। साथ ही, उनकी मासिक लागत भी बढ़ जाती है क्योंकि सिस्टम अब अधिक लगातार चल रहा है। हालाँकि, ट्रैफ़िक अभी भी इतना स्थिर नहीं है कि समर्पित GPU पर जाने को पूरी तरह से उचित ठहराया जा सके, जो ऑफ-आवर्स के दौरान निष्क्रिय रह सकता है। यह एक निराशाजनक मध्य मार्ग बनाता है जहां सिस्टम तकनीकी रूप से काम करता है, लेकिन निरंतर ट्यूनिंग की आवश्यकता होती है, और न तो सर्वर रहित और न ही समर्पित बुनियादी ढांचा बिल्कुल उपयुक्त लगता है।पैमाने पर
<पी> कुछ बिंदु पर, आपका सिस्टम अप्रत्याशित होना बंद कर देता है। आप मोटे तौर पर जानते हैं कि कितने अनुरोध आ रहे हैं। आप जानते हैं कि व्यस्त समय कब है। अनुमान ख़त्म हो गया है.अब, आप एक ऐसे सिस्टम पर प्रति अनुरोध भुगतान कर रहे हैं जो कभी भी चलना बंद नहीं करता है। ठंड की शुरुआत जो कभी-कभार होती थी अब अस्वीकार्य लगती है। उपयोगकर्ता तेजी से, लगातार प्रतिक्रियाओं की अपेक्षा करने लगे हैं और किसी भी भिन्नता पर ध्यान दिया जाता है। जिस बुनियादी ढांचे ने आपको शुरुआत में तेजी से आगे बढ़ने में मदद की, वही अब आपको धीमा कर रही है। समर्पित अनुमान इसे स्पष्टता से हल करता है। आप एक जीपीयू आरक्षित करते हैं, आपका मॉडल लोड रहता है, और प्रत्येक अनुरोध को समान अनुभव मिलता है। कोई साझाकरण नहीं, कोई स्पिन-अप विलंब नहीं, कोई आश्चर्य नहीं।
अर्थशास्त्र भी बदल गया. जब आपका सिस्टम हमेशा सक्रिय रहता है, तो आरक्षित गणना के लिए भुगतान करना प्रति उपयोग भुगतान की तुलना में सस्ता हो जाता है। उदाहरण के लिए, एक साथ.एआई के समर्पित समापन बिंदु, H100 के लिए लगभग $3.99 प्रति घंटे से शुरू होते हैं। स्थिर ट्रैफ़िक पर, यह अक्सर सर्वर रहित पर आपके द्वारा खर्च किए जा रहे खर्च से कम होता है, इसके अलावा बेहतर प्रदर्शन के साथ। आपको जो हासिल होता है वह केवल कम लागत या तेज़ प्रतिक्रिया नहीं है। यह स्थिरता है. आप अपने बुनियादी ढांचे को व्यवस्थित करना बंद कर दें और उस पर भरोसा करना शुरू कर दें। तभी आप पूरी तरह से उत्पाद के निर्माण पर ध्यान केंद्रित कर सकते हैं, न कि उसके नीचे की परत को प्रबंधित करने पर। सर्वरलेस पूरी तरह से दूर नहीं होता है। यह अभी भी किनारे के मामलों को संभालता है:अप्रत्याशित स्पाइक्स, प्रयोगात्मक सुविधाएँ और कम आवृत्ति वाली नौकरियां। लेकिन यह अब आपके मुख्य कार्यभार को वहन नहीं कर रहा है। समर्पित बुनियादी ढांचा अब ऐसा करता है।
डेवलपर्स वास्तव में सर्वर रहित अनुमान प्लेटफ़ॉर्म का अनुभव कैसे करते हैं
<पी> यह समझने का एक अच्छा तरीका है कि ये सिस्टम कैसे व्यवहार करते हैं, यह देखना है कि डेवलपर्स आमतौर पर उपयोग किए जाने वाले दो प्लेटफार्मों:मॉडल और टुगेदर.एआई के साथ कैसे इंटरैक्ट करते हैं। दोनों एक समान विचार से शुरू होते हैं जो बुनियादी ढांचे को अमूर्त कर देता है, लेकिन जिस तरह से अमूर्तता व्यवहार में दिखाई देती है (विशेषकर मूल्य निर्धारण और स्केलिंग) उससे पता चलता है कि कहां चीजें अच्छी तरह से काम करती हैं और कहां व्यापार-बंद शुरू होता है।मोडल
<पी> मॉडल को सर्वर रहित मॉडल के आसपास डिज़ाइन किया गया है जहां आप गणना समय के लिए सख्ती से भुगतान करते हैं। उदाहरण के लिए, GPU उपयोग का बिल प्रति सेकंड, छोटे GPU (जैसे L4) के लिए लगभग $0.0002/सेकंड और H100 जैसे उच्च-स्तरीय GPU के लिए लगभग $0.0011/सेकंड तक होता है, जो हार्डवेयर के आधार पर लगभग $0.8-$4 प्रति घंटा होता है। मासिक क्रेडिट में लगभग $30 के साथ एक निःशुल्क टियर भी है, जिससे बिना किसी अग्रिम लागत के शुरुआत करना आसान हो जाता है। व्यवहार में, यह अत्यधिक कार्यभार के लिए बहुत अच्छी तरह से काम करता है, उदाहरण के लिए, एक छवि पीढ़ी एपीआई जो ट्रैफ़िक केवल तभी प्राप्त करती है जब उपयोगकर्ता इसे ट्रिगर करते हैं, या एक पृष्ठभूमि कार्य जो दिन में कुछ बार चलता है। आप निष्क्रिय जीपीयू के लिए भुगतान नहीं कर रहे हैं, और स्केलिंग स्वचालित रूप से होती है। लेकिन जैसे-जैसे उपयोग निरंतर होता जाता है, मान लीजिए, आप एक वास्तविक समय ऑब्जेक्ट डिटेक्शन मॉडल चला रहे हैं जो पूरे दिन लगातार छवियों को संभालता है, मूल्य निर्धारण मॉडल अपने ट्रेड-ऑफ को प्रकट करना शुरू कर देता है। अब आपको "केवल उपयोग होने पर भुगतान करें" से कोई लाभ नहीं होगा, क्योंकि सिस्टम का उपयोग हमेशा किया जा रहा है। इसके बजाय, आप प्रभावी ढंग से एक ही जीपीयू को बार-बार छोटे-छोटे वेतन वृद्धि में किराए पर ले रहे हैं, अक्सर एक को चालू रखने की तुलना में अधिक संचयी लागत पर। साथ ही, कोल्ड स्टार्ट और कंटेनर पुन:उपयोग जैसी प्रदर्शन विशेषताएँ परिवर्तनशीलता लाती हैं जिसे उत्पादन वातावरण में अनदेखा करना कठिन हो जाता है।Together.ai
<पी> टुगेदर.एआई एक सर्वर रहित एपीआई के साथ शुरू होता है, लेकिन जो बात इसे बढ़ते सिस्टम के लिए दिलचस्प बनाती है वह यह है कि यह आपको आपकी ज़रूरतों के अनुसार प्लेटफ़ॉर्म बदलने के लिए मजबूर नहीं करता है। आप अपना कोड बदले बिना मूल एपीआई उपयोग से समर्पित जीपीयू एंडपॉइंट पर जा सकते हैं। <पी> प्रवेश स्तर पर, आप प्रति टोकन भुगतान करते हैं। मूल्य निर्धारण मॉडल के अनुसार भिन्न-भिन्न होता है, लगभग $0.10 से $3 प्रति मिलियन टोकन, जो ट्रैफ़िक कम या अप्रत्याशित होने पर अच्छी तरह से काम करता है। आपको ऑटो-स्केलिंग मिलती है और प्रबंधन के लिए कोई बुनियादी ढांचा नहीं है। अधिकांश उपयोग के मामलों के लिए यह एक उचित प्रारंभिक बिंदु है। <पी> जैसे-जैसे ट्रैफ़िक बढ़ता है और विलंबता मायने रखने लगती है, टुगेदर.एआई आपको समर्पित समापन बिंदुओं पर जाने की सुविधा देता है। आप अपना हार्डवेयर चुनें:एक H100 लगभग $3.99 प्रति घंटे पर या एक H200 लगभग $5.49 प्रति घंटे पर, और वह GPU आपका है। कोई साझा गणना नहीं, अन्य कार्यभार से कोई हस्तक्षेप नहीं। मॉडल लोड रहता है, और आपकी विलंबता प्रोफ़ाइल सुसंगत हो जाती है। <पी> ट्रेड-ऑफ़ वही है जिसका सामना आप किसी भी समर्पित सेटअप के साथ करते हैं। यदि ऑफ-आवर्स के दौरान आपका ट्रैफ़िक गिरता है, तो वह GPU अभी भी चल रहा है। आप क्षमता के लिए भुगतान कर रहे हैं चाहे आप इसका उपयोग करें या नहीं। जब आपका कार्यभार स्थिर हो तो यह ठीक है। <पी> जो टीमें स्केलिंग कर रही हैं, उनके लिए टुगेदर.एआई का व्यावहारिक लाभ यह है कि माइग्रेशन पथ आंतरिक है। आप समर्पित प्रदर्शन पाने के लिए अपने एकीकरण का पुनर्निर्माण नहीं करते हैं। आप समापनबिंदु कॉन्फ़िगरेशन परिवर्तित करें। यह सही समय पर बदलाव करने में एक वास्तविक बाधा को हटा देता है, न कि इसमें देरी करने के कारण क्योंकि स्विच बहुत विघटनकारी लगता है। <पी> उदाहरण के लिए, एक मध्यम आकार के मॉडल को चलाने में लगभग $0.10-$0.60 प्रति मिलियन इनपुट टोकन की लागत आ सकती है, आउटपुट टोकन कभी-कभी मॉडल के आधार पर अधिक हो जाते हैं। यह इसे चैटबॉट्स या टेक्स्ट जेनरेशन एपीआई जैसे उपयोग के मामलों के लिए सहज बनाता है, जहां उपयोग के साथ लागत बढ़ती है। उदाहरण के लिए, प्रति दिन कुछ मिलियन टोकन उत्पन्न करने वाले ग्राहक सहायता बॉट की लागत मात्रा के आधार पर प्रति माह दसियों से सैकड़ों डॉलर हो सकती है। उसी समय, जब कार्यभार स्थिर हो जाता है, तो टुगेदर.एआई H100 के लिए लगभग $3.99/घंटा से शुरू होने वाले समर्पित जीपीयू एंडपॉइंट प्रदान करता है। यह एक सामान्य पैटर्न को दर्शाता है:डेवलपर्स सरल एपीआई-आधारित उपयोग से शुरू करते हैं, लेकिन जैसे-जैसे ट्रैफ़िक स्थिर होता है और विलंबता अपेक्षाएं बढ़ती हैं, वे अक्सर अधिक पूर्वानुमानित प्रदर्शन और लागत के लिए समर्पित सेटअप की ओर बढ़ते हैं। <पी> महत्वपूर्ण बदलाव प्लेटफ़ॉर्म नहीं है—यह है कि आप समय के साथ इसका उपयोग कैसे करते हैं :- प्रारंभिक चरण → आप इसे एक साधारण एपीआई की तरह उपयोग करते हैं
- विकास चरण → आप विलंबता और लागत के बारे में चिंता करना शुरू कर देते हैं
- स्केल → आप उसी प्लेटफॉर्म के भीतर समर्पित एंडपॉइंट पर जाते हैं
निर्णय लेने से पहले विचार करने योग्य बातें
- लागत का पैमाना आपकी अपेक्षा से भिन्न है: सर्वर रहित प्लेटफ़ॉर्म प्रत्येक सेकंड की गणना के लिए एक निश्चित ऑन-डिमांड दर चार्ज करते हैं। जब आपका सिस्टम निष्क्रिय होता है, तो वह मॉडल कुशल होता है। जब आपका सिस्टम लगातार चलता है, तो वही दर चौबीसों घंटे बिना किसी राहत के चलती रहती है। आरक्षित क्षमता का समर्थन करने वाला बुनियादी ढांचा प्रभावी प्रति घंटा लागत को काफी कम कर सकता है, कभी-कभी आधे से भी अधिक। जितना अधिक समय तक आपका कार्यभार पूर्वानुमानित रहेगा, अंतर उतना ही अधिक बढ़ेगा।
- प्रबंधित डिफ़ॉल्ट समय के साथ बाधा बन जाते हैं :प्रबंधित अनुमान प्लेटफ़ॉर्म, कभी-कभी, आपकी ओर से कॉन्फ़िगरेशन निर्णय लेते हैं। कौन से अनुकूलन चलते हैं, मेमोरी को कैसे प्रबंधित किया जाता है, और अनुरोधों को कैसे बैच किया जाता है। शुरुआती चरणों में, उन डिफ़ॉल्टों से समय की बचत होती है। बाद में, जब आपको अपने विशिष्ट कार्यभार के लिए अपनी अनुमान परत को ट्यून करने की आवश्यकता होती है, तो वही डिफ़ॉल्ट रास्ते में आ जाते हैं। यदि आप कॉन्फ़िगरेशन तक नहीं पहुंच सकते हैं, तो आप इसे बदल नहीं सकते हैं। बुनियादी ढांचे के मालिक होने का मतलब है कि वे सेटिंग्स आपकी हैं।
- आपकी दृश्यता उसी तक सीमित है जो प्लेटफ़ॉर्म आपको दिखाता है :एक प्रबंधित प्लेटफ़ॉर्म पर, जब कुछ गलत होता है या लागत अप्रत्याशित रूप से बढ़ जाती है, तो जांच करने की आपकी क्षमता उस डैशबोर्ड तक सीमित होती है जिसे प्लेटफ़ॉर्म ने आपके लिए बनाया है। आप देख सकते हैं कि कुछ धीमा या महंगा है, लेकिन जब बुनियादी ढांचा स्तर पहुंच से बाहर हो तो इसका सटीक कारण पता लगाना कठिन होता है। समर्पित बुनियादी ढांचा आपको गणना, नेटवर्किंग और भंडारण में पूर्ण अवलोकन प्रदान करता है। आप सब कुछ देखते हैं, और आप उस पर कार्य कर सकते हैं।
- अधिक नियंत्रण का अर्थ है अधिक जिम्मेदारी: अपने बुनियादी ढांचे का मालिक होने से आपको कम लागत, गहरा नियंत्रण और पूर्ण दृश्यता मिलती है। लेकिन इसका मतलब यह भी है कि आप सेटअप और परिचालन कार्य संभालते हैं जो प्रबंधित प्लेटफ़ॉर्म आपके लिए संभालते हैं। यह हमेशा सही निर्णय नहीं होता है, खासकर यदि आपकी टीम छोटी है या आपका कार्यभार अभी भी बदल रहा है। उन्होंने कहा, एक सही मंच हमेशा प्रबंधित और स्व-प्रबंधित प्लेटफार्मों के बीच अंतर को कम करने के लिए सही संतुलन बनाता है। कुछ इंफ्रास्ट्रक्चर प्लेटफ़ॉर्म अब पूर्व-कॉन्फ़िगर किए गए अनुमान छवियों, एक-क्लिक जीपीयू परिनियोजन और बॉक्स से बाहर कुबेरनेट्स समर्थन के साथ शिप करते हैं, जिसका अर्थ है कि आप शून्य से शुरू नहीं कर रहे हैं। परिचालन ओवरहेड वास्तविक है, लेकिन यह पहले की तुलना में बहुत हल्का है।
निष्कर्ष
<पी> सर्वर रहित अनुमान आपको आरंभ करने, प्रयोग करने और बिना किसी घर्षण के जहाज चलाने की गति देता है। लेकिन जैसे-जैसे आपका सिस्टम बढ़ता है, वही अमूर्तता जिसने एक बार आपको तेजी से आगे बढ़ने में मदद की थी, वह उन चीजों को छिपाना शुरू कर सकती है जो सबसे ज्यादा मायने रखती हैं:विलंबता स्थिरता, थ्रूपुट और लागत दक्षता। मोडल और टुगेदर.एआई जैसे प्लेटफॉर्म जल्दी निर्माण और स्केल करना आसान बनाते हैं, और कई मामलों में, वे बाद में भी वास्तुकला का हिस्सा बने रहते हैं। लेकिन जैसे-जैसे काम का बोझ पूर्वानुमानित होता जाता है और उम्मीदें बढ़ती जाती हैं, अधिक नियंत्रण की आवश्यकता अपरिहार्य हो जाती है। वास्तविक दुनिया की प्रणालियाँ स्थिर नहीं रहती हैं; वे अनिश्चितता से पूर्वानुमेयता की ओर, प्रयोग से उत्पादन की ओर बढ़ते हैं। और जैसे ही वे ऐसा करते हैं, "सही" बुनियादी ढांचे का विकल्प उनके साथ बदल जाता है। टीमों द्वारा की जाने वाली वास्तविक गलती सर्वर रहित को एक दीर्घकालिक डिफ़ॉल्ट के रूप में मानना है, बजाय इसके कि यह वास्तव में एक चरण है। एक बार जब आपका कार्यभार स्थिर हो जाता है तो आप समर्पित बुनियादी ढांचे में जाने में जितनी देर करेंगे, आपको लागत, प्रदर्शन या दोनों में उतना ही अधिक भुगतान करना पड़ेगा। <पी>
यह कार्य क्रिएटिव कॉमन्स एट्रिब्यूशन-नॉन-कमर्शियल- के तहत लाइसेंस प्राप्त है शेयरअलाइक 4.0 अंतर्राष्ट्रीय लाइसेंस। 
