Amazon EC2، Amazon ECS، Amazon EKS، AWS Fargate، AWS Lambda، اور AWS Batch کے درمیان انتخاب دراصل اس بات کا فیصلہ ہے کہ کوڈ کہاں چلے گا اور آپریشنل ذمہ داری کس کی ہوگی۔ اس کورس میں، ہم ایک ایسا قابلِ اعادہ (repeatable) فریم ورک تشکیل دیں گے جو ورک لوڈ کی ضروریات کو اسکیلنگ کے رویے، ناکامی کی حدود (failure boundaries)، آپریشنل ملکیت، اور کل لاگت کے عوامل (cost drivers) کے ساتھ مربوط کرتا ہے۔ ہم ‘سروس کیٹلاگ’ والی سوچ سے گریز کریں گے اور اس کے بجائے ہر انتخاب کو حدود (constraints) اور شواہد کی بنیاد پر قابلِ جواز بنائیں گے۔
آئیے سب سے پہلے ملکیت کے محور (ownership axis) کی وضاحت کریں، کیونکہ یہ زیادہ تر متبادل انتخاب کے درمیان توازن (tradeoffs) کی وضاحت کرتا ہے۔ آپریشنل ملکیت سے مراد یہ ہے کہ کون آپریٹنگ سسٹم کو پیچ (patch) کرتا ہے، صلاحیت (capacity) کا انتظام کرتا ہے، اور اس شیڈولر کو چلاتا ہے جو کام کو کمپیوٹ وسائل پر تفویض کرتا ہے۔
Amazon EC2 پر، ہم ورچوئل مشینیں چلاتے ہیں، لہذا ہم AMI، پیچنگ کی حکمت عملی، اور اسکیلنگ کے طریقہ کار کا انتخاب خود کرتے ہیں۔ Amazon ECS یا Amazon EKS پر، ہم ایک آرکسٹریٹر (orchestrator) چلاتے ہیں جو کنٹینرز کو شیڈول کرتا ہے، اور ہمیں یہ فیصلہ کرنا ہوتا ہے کہ بنیادی صلاحیت (underlying capacity) کون فراہم کرے گا۔ AWS Fargate پر، کنٹینر کی صلاحیت کی تہہ (layer) کا انتظام AWS کرتا ہے، لہذا ہم نوڈ فلیٹس (node fleets) کے بجائے ٹاسک کی تعریفوں اور سروس کی اسکیلنگ پر توجہ مرکوز کرتے ہیں۔ AWS Lambda پر، AWS کمپیوٹ انفراسٹرکچر اور اسکیلنگ کو چلاتا ہے، اور ہم فنکشن کوڈ اور اس کے انووکیشن ماڈل (invocation model) پر توجہ مرکوز کرتے ہیں۔ AWS Batch پر، AWS بیچ ورک (batch work) کے لیے جاب کیوئنگ (job queuing) اور شیڈولنگ کا انتظام کرتا ہے، اور یہ جابز کو ECS، EKS، Fargate، یا EC2 کی صلاحیت (capacity) پر منتقل کر سکتا ہے۔
آئیے مجموعی سطح پر ان آپشنز کے درمیان ملکیت کی تبدیلیوں کا جائزہ لیں۔
اب ہم کمپیوٹ (compute) کے انتخاب کو محض ترجیحات کی بحث کے بجائے، مختلف حدود اور تقاضوں (constraints) سے مطابقت پیدا کرنے کے عمل کے طور پر دیکھ سکتے ہیں۔ ایگزیکیوشن ماڈل (Execution model) سے مراد یہ ہے کہ آیا کام ایک دیرپا سروس کے طور پر چلتا ہے، کسی ایونٹ (event) کے ذریعے متحرک ہونے والے فنکشن کے طور پر، یا پھر قطار میں لگے (queued) ایسے کام کے طور پر جس کے شروع اور ختم ہونے کا وقت واضح ہو۔
ٹریفک کا انداز (Traffic shape) اکثر وہ پہلی رکاوٹ یا حد ہوتی ہے جو اہم کردار ادا کرتی ہے۔ ایسی ٹریفک جس میں اچانک اتار چڑھاؤ (spikes) ہوں اور درمیان میں کام نہ ہونے کے طویل وقفے ہوں، وہاں ‘فی درخواست’ (per-request) ماڈل بہتر رہتے ہیں؛ جبکہ مستقل ٹریفک کی صورت میں ‘ہمیشہ فعال’ (always-on) صلاحیت زیادہ موزوں ہوتی ہے جہاں وسائل کا استعمال (utilization) زیادہ رہتا ہے۔
کام کا دورانیہ اور ‘اسٹیٹ’ (state) کا تقاضا انتخاب کے دائرہ کار کو تیزی سے محدود کر دیتے ہیں۔ AWS Lambda میں زیادہ سے زیادہ ٹائم آؤٹ (timeout) کی حد فی الحال 900 سیکنڈز ہے، لہذا زیادہ دیر تک چلنے والے کاموں کو عام طور پر کنٹینرز (containers) یا بیچ پروسیسنگ (batch processing) کی طرف منتقل کر دیا جاتا ہے۔ ایسے ‘اسٹیٹ فل’ (stateful) ورک لوڈز جو مقامی سطح پر ڈیٹا یا حالت (state) کو برقرار رکھتے ہیں یا جنہیں ہوسٹ (host) کی خصوصی ٹیوننگ درکار ہوتی ہے، وہ اکثر Amazon EC2 یا EC2 کی صلاحیت پر چلنے والے کنٹینرز کے لیے زیادہ موزوں ہوتے ہیں۔
لیٹنسی (latency) یا تاخیر کے حوالے سے حساسیت کے بھی آپریشنل اثرات ہوتے ہیں۔ درخواست اور جواب (request-response) کے راستوں کے لیے، ہمیں ‘کولڈ اسٹارٹ’ (cold start) کے خطرے، نیٹ ورک پر مقام (network placement)، اور اس بات کی فکر ہوتی ہے کہ پلیٹ فارم کتنی تیزی سے متوازی (parallel) صلاحیت کا اضافہ کر سکتا ہے۔ غیر مطابقت پذیر (async) راستوں کے لیے، ہمیں بیک لاگ (backlog) میں اضافے، دوبارہ کوشش (retry) کے طریقہ کار، اور اس بات پر توجہ دینی پڑتی ہے کہ ناکامیوں کو کس طرح الگ تھلگ (isolate) کیا جاتا ہے اور دوبارہ کوشش کیسے کی جاتی ہے۔
آئیے دیکھتے ہیں کہ یہ تقاضے (requirement cards) کمپیوٹ کی حدود اور شرائط (constraints) کے ساتھ کس طرح مطابقت رکھتے ہیں۔