Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, AWS Lambda, और AWS Batch के बीच चुनाव करना इस बात का फ़ैसला है कि कोड कहाँ चलेगा और ऑपरेशनल काम की ज़िम्मेदारी किसकी होगी। इस कोर्स में, हम एक ऐसा दोहराने योग्य (repeatable) फ्रेमवर्क बनाते हैं जो वर्कलोड की ज़रूरतों को स्केलिंग व्यवहार, फ़ेलियर बाउंड्री, ऑपरेशनल ओनरशिप और कुल लागत के कारकों (cost drivers) से जोड़ता है। हम ‘सर्विस कैटलॉग’ वाली सोच से बचेंगे और इसके बजाय सीमाओं (constraints) और सबूतों के आधार पर हर चुनाव को सही ठहराएँगे।
आइए सबसे पहले ओनरशिप एक्सिस (ownership axis) को परिभाषित करें, क्योंकि यह ज़्यादातर ट्रेड-ऑफ़ (समझौतों) को समझाता है। ऑपरेशनल ओनरशिप का मतलब है कि ऑपरेटिंग सिस्टम को कौन पैच करता है, कैपेसिटी को कौन मैनेज करता है, और उस शेड्यूलर को कौन चलाता है जो कंप्यूट पर काम को व्यवस्थित करता है।
Amazon EC2 पर, हम वर्चुअल मशीन चलाते हैं, इसलिए हम AMI, पैच स्ट्रैटेजी और स्केलिंग अप्रोच चुनते हैं। Amazon ECS या Amazon EKS पर, हम एक ऑर्केस्ट्रेटर चलाते हैं जो कंटेनर को शेड्यूल करता है, और हमें अभी भी यह तय करना होता है कि अंडरलाइंग कैपेसिटी (आधारभूत क्षमता) कौन प्रदान करेगा। AWS Fargate पर, कंटेनर कैपेसिटी लेयर को AWS मैनेज करता है, इसलिए हम नोड फ़्लीट के बजाय टास्क डेफ़िनिशन और सर्विस स्केलिंग पर ध्यान केंद्रित करते हैं। AWS Lambda पर, AWS कंप्यूट इंफ्रास्ट्रक्चर और स्केलिंग को चलाता है, और हम फ़ंक्शन कोड और उसके इनवोकेशन मॉडल पर ध्यान केंद्रित करते हैं। AWS Batch पर, AWS बैच वर्क के लिए जॉब की कतार (queuing) और शेड्यूलिंग को मैनेज करता है, और यह जॉब्स को ECS, EKS, Fargate, या EC2 कैपेसिटी पर डाल सकता है।
आइए, इन विकल्पों में ओनरशिप (ownership) में होने वाले बदलावों को मोटे तौर पर समझते हैं।
अब हम कंप्यूट चुनने को पसंद-नापसंद की बहस के बजाय, ज़रूरतों और सीमाओं (constraints) के हिसाब से सही विकल्प चुनने की प्रक्रिया मान सकते हैं। एक्ज़ीक्यूशन मॉडल का मतलब है कि काम कैसे चलता है: लंबे समय तक चलने वाली सर्विस के तौर पर, किसी इवेंट से शुरू होने वाले फ़ंक्शन के तौर पर, या एक कतार (queue) वाले जॉब के तौर पर जिसका शुरू और खत्म होने का समय तय हो।
ट्रैफ़िक का पैटर्न अक्सर सबसे पहली चुनौती या सीमा होती है जिसका सामना करना पड़ता है। जब ट्रैफ़िक में अचानक तेज़ी और फिर लंबे समय तक शांति (idle period) हो, तो ‘प्रति-अनुरोध’ (per-request) मॉडल बेहतर होते हैं; और जब ट्रैफ़िक स्थिर हो, तो ‘हमेशा चालू’ (always-on) क्षमता बेहतर होती है क्योंकि इसमें संसाधनों का इस्तेमाल ज़्यादा होता है। काम की अवधि और स्टेट (state) के आधार पर विकल्पों का दायरा तेज़ी से सीमित हो जाता है। AWS Lambda में अधिकतम टाइमआउट अभी 900 सेकंड है, इसलिए ज़्यादा देर तक चलने वाले काम आमतौर पर कंटेनर या बैच प्रोसेसिंग में ले जाए जाते हैं। स्टेटफ़ुल वर्कलोड (जो लोकल स्टेट बनाए रखते हैं या जिन्हें खास होस्ट ट्यूनिंग की ज़रूरत होती है) अक्सर Amazon EC2 या EC2 क्षमता पर चलने वाले कंटेनर के लिए ज़्यादा उपयुक्त होते हैं।
लेटेंसी (देरी) के प्रति संवेदनशीलता का भी ऑपरेशनल महत्व होता है। रिक्वेस्ट-रिस्पॉन्स पाथ के लिए, हम कोल्ड स्टार्ट के जोखिम, नेटवर्क प्लेसमेंट और इस बात पर ध्यान देते हैं कि प्लेटफ़ॉर्म कितनी तेज़ी से पैरेलल क्षमता जोड़ सकता है। एसिंक्रोनस (async) पाथ के लिए, हम बैकलॉग बढ़ने, दोबारा कोशिश करने (retry) के व्यवहार और इस बात पर ध्यान देते हैं कि फ़ेलियर को कैसे अलग किया जाता है और दोबारा कोशिश कैसे की जाती है।
आइए देखें कि ये ज़रूरतें कंप्यूट की सीमाओं के साथ कैसे मेल खाती हैं।