3.16 API گیٹ ویز اور سروس میش

جائزہ اور محرکات

جس لمحے آپ ایک پروگرام کو بہت سی سروسز میں تقسیم کرتے ہیں، نیا سوال سامنے آتا ہے: ان کے درمیان ٹریفک، اور باہر سے آنے والے ٹریفک کا انچارج کون ہے؟ آپ اس سوال کا جواب برے طریقے سے دے سکتے ہیں ایک ہی معاملات (تصدیق، دوبارہ کوششیں، ٹائم آؤٹ، شرح کی حدیں، لاگنگ) کو ہاتھ سے ہر سروس میں بکھیر کر، یا اچھے طریقے سے ان معاملات کو مشترک تہہ میں دھکیل کر جسے ہر سروس مفت وراثت میں پائے۔ یہ باب ایسی دو تہوں کے بارے میں ہے۔ API گیٹ وے سامنے کے دروازے پر بیٹھتا ہے اور کلائنٹس سے آنے والا ٹریفک سنبھالتا ہے۔ سروس میش آپ کی سروسز کے بیچ بیٹھتا ہے اور ان کے درمیان بہتا ٹریفک سنبھالتا ہے۔ وہ متعلقہ مسائل مختلف جگہوں پر حل کرتے ہیں، اور دونوں کو ملانا عام اور مہنگی غلطی ہے۔

صنعت ٹریفک کی دو سمتوں کو کمپاس کی تشبیہ سے نام دیتی ہے۔ شمال-جنوب ٹریفک وہ ہے جو آپ کے نظام کی حد پار کرتا ہے: موبائل ایپ، براؤزر، یا اندر کال کرنے والا شراکت دار۔ مشرق-مغرب ٹریفک وہ ہے جو آپ کے نظام کے اندر رہتا ہے: سروس A سروس B کو کال کرتی ہے جو ایک درخواست پوری کرنے کو سروس C کو کال کرتی ہے۔ API گیٹ وے شمال-جنوب کا ماہر ہے۔ سروس میش مشرق-مغرب کا ماہر ہے۔ اس فرق کو تیز رکھنا اس باب کا سب سے مفید خیال ہے، کیونکہ یہ آپ کو بتاتا ہے کہ کون سا اوزار کس پالیسی کا مالک ہے، اور آپ کو ایک ہی کام دو بار کرنے سے روکتا ہے۔

بڑی ٹیموں کے لیے یہ تہیں وہ طریقہ ہیں جس سے آپ پالیسی سو بار کی بجائے ایک بار نافذ کرتے ہیں۔ جب تصدیق، منتقلی میں خفیہ نگاری، اور شرح کی حد مشترک تہہ میں رہتی ہیں تو سلامتی کی اصلاح اس دن ہر سروس تک پہنچتی ہے جب آپ تہہ تعینات کرتے ہیں، سو بیک لاگز کا انتظار کیے بغیر۔ انٹرپرائز اور سرکاری ترتیبوں میں وہ مرکزیت اکثر مقصد ہے: آڈیٹر ایک واحد، ثابت شدہ جگہ چاہتے ہیں جہاں رسائی جانچی جائے اور ٹریفک خفیہ ہو، اور مشترک گیٹ وے یا میش انہیں ٹھیک وہ پالیسی نافذ کرنے کا نقطہ دیتا ہے۔ یہ باب باب 3.2 کے فن تعمیری اسالیب، باب 3.3 کی تقسیم شدہ نظاموں کی حقیقتوں، اور باب 3.13 کی نیٹ ورکنگ کی بنیادوں پر بنتا ہے، اور انہیں ٹھوس رہنمائی میں بدلتا ہے کہ آپ کا ٹریفک کون سنبھالتا ہے۔

بنیادی اصول

شمال-جنوب (گیٹ وے) کو مشرق-مغرب (میش) سے الگ کریں؛ ہر ایک کو اپنی سمت کا مالک بننے دیں۔
ہمہ گیر معاملات کو مشترک تہہ میں دھکیلیں تاکہ آپ انہیں ایک بار لکھیں، فی سروس نہیں۔
سروس میش صرف تب اپنائیں جب سروسز کی تعداد فی سروس تاروں کو بڑی لاگت بنائے۔
ہر معاملے کے لیے ایک پالیسی نافذ کرنے کا نقطہ طے کریں؛ گیٹ وے اور میش دونوں کو ایک ہی کام کبھی نہ کرنے دیں۔
سروسز کو پتلا رکھیں: پلیٹ فارم ٹرانسپورٹ سنبھالتا ہے، سروس کاروباری منطق۔
نیٹ ورک کے مقام پر بھروسے کی بجائے شناخت پر مبنی، zero trust نیٹ ورکنگ کو ترجیح دیں۔
میش کی آپریشنل پیچیدگی کھلی آنکھوں سے خریدیں، اور ناپیں کہ آیا یہ ثمر دیتی ہے۔

سفارشات

سمجھیں کہ API گیٹ وے کیا کرتا ہے

API گیٹ وے واحد داخلی نقطہ ہے جو آپ کی سروسز کے سامنے بیٹھتا اور بیرونی دنیا سے ہر درخواست کی ثالثی کرتا ہے۔ سادہ ترین صورت میں یہ ذہین reverse proxy ہے (ایسا سرور جو کلائنٹ کی درخواستیں وصول کر کے درست بیک اینڈ کو بھیجتا ہے)، مگر گیٹ وے اپنا نام آگے بھیجنے سے کہیں زیادہ کر کے کماتا ہے۔ یہ ہر درخواست کو راستے، میزبان، یا ہیڈرز کی بنیاد پر درست سروس کی طرف روٹ کرتا ہے۔ یہ کال کرنے والے کی تصدیق کرتا ہے (جانچتا ہے کہ وہ کون ہے) اور درخواست کی اجازت دیتا ہے (جانچتا ہے کہ وہ کیا کر سکتا ہے)، تاکہ اس کے پیچھے سروس بھروسہ کر سکے کہ درخواست پہلے ہی سامنے کا دروازہ پاس کر چکی۔ یہ شرح کی حد (وقت کے ساتھ فی کلائنٹ درخواستوں کی حد) اور کوٹے (لمبی کھڑکی میں کل استعمال کی حد) نافذ کرتا ہے تاکہ ایک شور مچانے والا یا زیادتی کرنے والا کلائنٹ باقیوں کو بھوکا نہ مار سکے۔

گیٹ وے ٹریفک کی شکل بھی بدلتا ہے۔ درخواست کی تبدیلی ہیڈرز دوبارہ لکھتی ہے، پروٹوکولز کے درمیان ترجمہ کرتی ہے، یا پرانے کلائنٹ کے فارمیٹ کو نئی سروس کی توقعات کے مطابق ڈھالتی ہے۔ API کی ترکیب گیٹ وے کو ایک اندرونی درخواست کئی سروسز تک پھیلانے اور ان کے جوابات ایک میں سیے دیتی ہے، تاکہ کلائنٹ چھ کی بجائے ایک کال کرے۔ ورژننگ کی معاونت آپ کو API کے v1 اور v2 ساتھ ساتھ چلانے اور ہر کلائنٹ کو وہ ورژن روٹ کرنے دیتی ہے جس کی وہ توقع رکھتا ہے، جو آپ کو کسی کو توڑے بغیر ارتقا کی جگہ خریدتی ہے۔ ان معاملات کو کنارے پر مرتکز کرنا آپ کی سروسز کو کاروباری منطق پر مرکوز رکھتا ہے اور ہر اس چیز کو دیکھنے، محفوظ کرنے، اور روکنے کی ایک جگہ دیتا ہے جو داخل ہوتی ہے۔ جن APIs کے سامنے گیٹ وے ہے ان کا ڈیزائن باب 2.3 کا موضوع ہے، اور جو شناخت کی جانچیں وہ کرتا ہے وہ باب 4.7 پر کھینچتی ہیں۔

مختلف کلائنٹس کے لیے backend-for-frontend کا نمونہ استعمال کریں

واحد عمومی مقصد کا API اکثر ویب ایپ، موبائل ایپ، اور شراکت دار انضمام کو ایک ساتھ پیش کرتا ہے، اور ان سب کی ذرا بری طرح خدمت کرتا ہے۔ موبائل کلائنٹ کو چھوٹے پے لوڈ اور کم راؤنڈ ٹرپس چاہئیں کیونکہ بینڈوڈتھ اور بیٹری کم یاب ہیں؛ ویب کلائنٹ زیادہ باتونی، بھرپور جوابات سنبھال سکتا ہے؛ شراکت دار ایسا مستحکم معاہدہ چاہتا ہے جو انہیں کبھی حیران نہ کرے۔ backend for frontend (BFF) کا نمونہ ہر کلائنٹ کی قسم کو اپنا پتلا گیٹ وے دے کر یہ کھنچاؤ حل کرتا ہے، اس کلائنٹ کی ضروریات کے مطابق ڈھلا ہوا، اس کے پیچھے مشترک سروسز کے سامنے بیٹھا۔

BFF تنگ سامعین والا گیٹ وے ہے۔ موبائل BFF جوابات ملاتا اور تراشتا ہے تاکہ ایپ ایک کارآمد کال کرے؛ ویب BFF زیادہ مکمل شکل ظاہر کرتا ہے؛ شراکت دار BFF سست حرکت کرنے والا، احتیاط سے ورژن شدہ معاہدہ رکھتا ہے۔ ہر ٹیم اپنا BFF دوسروں کا انتظار کیے بغیر ارتقا دے سکتی ہے، جو اکثر حقیقی جیت ہے، کیونکہ یہ کلائنٹ ٹیموں کو ایک دوسرے سے الگ کرتا ہے۔ لاگت زیادہ حرکت کرنے والے حصے اور BFFs میں کچھ نقل شدہ منطق ہے، اس لیے نمونہ ان صورتوں کے لیے رکھیں جہاں کلائنٹ کی ضروریات واقعی مختلف ہوں۔ جب ہر کلائنٹ وہی چاہے تو ایک گیٹ وے سادہ اور بہتر ہے۔

سمجھیں کہ سروس میش کیا کرتا ہے

سروس میش آپ کی سروسز کے بیچ مشرق-مغرب ٹریفک کا انتظام کرتا ہے، اور یہ اس طرح کرتا ہے کہ ان سروسز سے اپنا کوڈ بدلنے کو نہیں کہتا۔ کلاسیکی میش ہر سروس کے انسٹینس کے ساتھ چلنے اور اس کا تمام نیٹ ورک ٹریفک روکنے والا چھوٹا پراکسی پروسیس، sidecar پراکسی تعینات کر کے کام کرتا ہے۔ آپ کی سروس سمجھتی ہے کہ وہ سیدھی دوسری سروس سے بات کر رہی ہے؛ حقیقت میں وہ اپنے مقامی sidecar سے بات کرتی ہے، جو اصل نیٹ ورک کال سنبھالتا ہے۔ چونکہ اب ہر درخواست ایسے پراکسی سے بہتی ہے جسے پلیٹ فارم کنٹرول کرتا ہے، میش ہر سروس میں، ہر زبان میں، ہم آہنگ رکھنے کو کسی مشترک لائبریری کے بغیر رویہ یکساں نافذ کر سکتا ہے۔

وہ کیا نافذ کرتا ہے؟ پہلا، باہمی TLS (mTLS)، جہاں ہر کنکشن کے دونوں فریق سرٹیفکیٹ پیش کرتے اور ٹریفک خفیہ کرتے ہیں، تاکہ سروس سے سروس کالز ڈیفالٹ سے تصدیق شدہ اور نجی ہوں۔ دوسرا، ٹریفک کا انتظام: میش کینری ریلیز کے لیے ٹریفک کا چھوٹا فیصد نئے ورژن پر منتقل کر سکتا ہے، ٹیسٹنگ کے لیے ہیڈر سے ٹریفک تقسیم کر سکتا ہے، یا ٹریفک کو سایہ سروس پر آئینہ کر سکتا ہے۔ تیسرا، لچک: دوبارہ کوششیں، ٹائم آؤٹ، اور سرکٹ بریکنگ (باب 2.20 کے نمونے) پلیٹ فارم کی تہہ پر لاگو، ہر سروس میں کوڈ کی بجائے پالیسی سے ترتیب دیے گئے۔ چوتھا، مشاہدہ پذیری: چونکہ ہر درخواست پراکسی سے گزرتی ہے، میش تمام سروس سے سروس ٹریفک کے لیے مستقل میٹرکس، لاگز، اور تقسیم شدہ ٹریسز خارج کرتا ہے، باب 9.2 کے مشاہدہ پذیری کے عمل کو کھلاتے ہوئے۔ سروس کا مصنف ان میں سے کچھ نہیں لکھتا اور سب پاتا ہے۔

sidecar کا نمونہ اور sidecarless متبادل جانیں

sidecar کا ماڈل خوبصورت ہے مگر مفت نہیں۔ ہر سروس کا انسٹینس اب اضافی پراکسی کنٹینر چلاتا ہے جو میموری اور CPU کھاتا ہے، اور ہر کال دو اضافی نیٹ ورک ہاپس (مقامی sidecar میں اور دور والے سے باہر) بناتی ہے، تھوڑی لیٹنسی جوڑتی ہوئی۔ مٹھی بھر سروسز پر یہ اضافی بوجھ غیر مرئی ہے؛ ہزاروں pods پر یہ آپ کے کمپیوٹ بل اور لیٹنسی بجٹ میں حقیقی مد بن جاتا ہے۔ اس لاگت نے sidecarless، یا proxyless، طریقوں کی لہر چلائی ہے۔

دو سمتیں اہم ہیں۔ ایک میش کے کام فی pod sidecar سے نکال کر فی نوڈ پراکسی میں لے جاتی ہے، تاکہ ایک ہی مشین پر بہت سی سروسز ہر ایک اپنا چلانے کی بجائے ایک پراکسی بانٹیں؛ یہ کچھ علیحدگی کو اضافی بوجھ میں بڑی کمی کے بدلے تجارت کرتا ہے۔ دوسرا، proxyless طریقہ، میش کی منطق براہ راست سروس میں پتلی لائبریری یا رن ٹائم کے ذریعے سمو دیتا ہے، فی زبان انحصار کی قیمت پر اضافی ہاپس مکمل ہٹاتے ہوئے۔ نیا پیش رفت کچھ میش کے کام آپریٹنگ سسٹم کے kernel میں eBPF (Linux kernel کے اندر محفوظ پروگرام چلانے کی ٹیکنالوجی) کے ذریعے دھکیلتی ہے، جو userspace پراکسی سے کم اضافی بوجھ کے ساتھ پالیسی نافذ اور ٹیلی میٹری جمع کر سکتی ہے۔ آپ کو آج کسی ایک فاتح پر شرط لگانے کی ضرورت نہیں۔ آپ کو جاننا چاہیے کہ sidecar کا محصول حقیقی ہے، متبادل موجود ہیں، اور آپ کے پلیٹ فارم کے انتخاب آپ کو بعد میں انہیں اپنانے سے باہر نہ کریں۔ یہ نمونے باب 8.3 کی کنٹینر آرکسٹریشن کی بنیاد پر بیٹھتے ہیں۔

فیصلہ کریں کہ میش اپنی پیچیدگی کب کماتا ہے

سروس میش طاقتور اور چلانے میں واقعی پیچیدہ ہے۔ یہ چلانے کو کنٹرول پلین، اپ گریڈ کرنے کو پراکسیز، گھمانے کو سرٹیفکیٹس، اور درخواست غائب ہونے پر ڈی بگ کرنے کو نئی تہہ جوڑتا ہے۔ وہ پیچیدگی تب خریدنے کے قابل ہے جب آپ کے پاس اتنی سروسز ہوں کہ یہ معاملات ہاتھ سے، فی سروس اور فی زبان، تاروں سے جوڑنا میش چلانے سے زیادہ لاگت لے۔ موٹا اشارہ پیمانہ اور کثیر زبانی تنوع ہے: درجنوں یا سینکڑوں سروسز، کئی زبانوں میں لکھی ہوئی، جہاں mTLS اور دوبارہ کوششوں کے لیے مشترک لائبریری کو ہم آہنگ رکھنا ڈراؤنا خواب ہو۔ اس پیمانے پر میش یکسانیت اور ثابت شدہ سلامتی میں اپنی ادائیگی کرتا ہے۔

میش اپنی پیچیدگی تب نہیں کماتا جب آپ کے پاس مٹھی بھر سروسز، ایک زبان، یا چھوٹی ٹیم ہو۔ معمولی نظام کے لیے اچھی لائبریری یا فریم ورک آپ کو mTLS، دوبارہ کوششیں، اور میٹرکس مکمل میش سے کہیں کم آپریشنل بوجھ سے دے سکتا ہے، اور سادہ گیٹ وے جمع معقول کلائنٹ لائبریریاں اکثر ہر چیز ڈھک لیتی ہیں جو آپ کو چاہیے۔ فیشن کی وجہ سے، اپنے پیمانے کے تقاضا کرنے سے پہلے، میش اپنانا ایسا بنیادی انفراسٹرکچر چلانے میں سال گزارنے کا عام طریقہ ہے جو ایسا مسئلہ حل کرتا ہے جو آپ کو نہیں ہے۔ گیٹ وے سے شروع کریں، لچک کے نمونے کوڈ یا لائبریریوں میں جوڑیں، اور میش تک تب پہنچیں جب سروسز اور زبانوں کی تعداد فی سروس طریقے کو زیادہ مہنگا بنائے۔ یہ وہی “کیا یہ اپنی پیچیدگی کماتا ہے” کا نظم و ضبط ہے جس پر کلاؤڈ اور تقسیم شدہ نظاموں کے ابواب (3.11 اور 3.3) بار بار لوٹتے ہیں۔

جہاں گیٹ وے اور میش کا ٹکراؤ ہو وہاں دہری ہینڈلنگ سے بچیں

گیٹ ویز اور میشز ایک دوسرے سے ملتے ہیں، اور وہ ٹکراؤ ہی وہ جگہ ہے جہاں ٹیمیں خود کو نقصان پہنچاتی ہیں۔ دونوں دوبارہ کوششیں کر سکتے ہیں، دونوں ٹائم آؤٹ نافذ کر سکتے ہیں، دونوں شناخت جانچ سکتے ہیں، دونوں ٹیلی میٹری جمع کر سکتے ہیں۔ اگر گیٹ وے درخواست کی تین بار دوبارہ کوشش کرے اور میش ہر اندرونی ہاپ پر بھی تین بار دوبارہ کوشش کرے تو ایک کلائنٹ کی دوبارہ کوشش درجنوں بیک اینڈ کالز میں پھٹ سکتی ہے اور چھوٹی ہچکی کو دوبارہ کوشش کے طوفان میں بدل سکتی ہے۔ اگر دونوں تہیں ٹائم آؤٹ نافذ کریں اور اندرونی بیرونی سے لمبا ہو تو بیرونی ہار مان لیتا ہے جبکہ اندرونی کام کرتا رہتا ہے، ایسے جواب پر محنت ضائع کرتے ہوئے جسے کوئی نہیں پڑھے گا۔

اصلاح لکھی اور متفقہ کام کی واضح تقسیم ہے۔ ہر معاملہ ٹھیک ایک تہہ کو تفویض کریں۔ گیٹ وے شمال-جنوب کے معاملات کا مالک ہے: آخری صارف کی تصدیق، بیرونی شرح کی حدیں اور کوٹے، درخواست کی تبدیلی، اور کلائنٹس کے لیے API کی ترکیب۔ میش مشرق-مغرب کے معاملات کا مالک ہے: سروس سے سروس mTLS، اندرونی دوبارہ کوششیں اور سرکٹ بریکنگ، اور سروس کے ورژنز کے درمیان ٹریفک کی منتقلی۔ جہاں معاملہ کسی ایک میں رہ سکتا ہو وہاں ایک مالک چنیں اور دوسری تہہ کو گزرنے دیں۔ دوبارہ کوشش کے بجٹ اور ٹائم آؤٹ کی درجہ بندی یوں ترتیب دیں کہ بیرونی ٹائم آؤٹ ہمیشہ اس اندرونی کام سے لمبا ہو جس کا وہ انتظار کرتا ہے۔ ہدف یہ ہے کہ ہر درخواست کے لیے ہر معاملہ سنبھالنے کی ٹھیک ایک جگہ ہو، اور کوئی درخواست حادثاً دو بار دوبارہ آزمائی، تصدیق، یا لاگ نہ ہو۔

گیٹ وے اور میش کو zero trust کے لیے پالیسی نافذ کرنے کے نقطے سمجھیں

ان تہوں کو چلانے کی سب سے گہری وجہ سلامتی کا فن تعمیر ہے۔ Zero trust اصول ہے کہ کوئی درخواست اس کے آنے کی جگہ کی وجہ سے قابل اعتماد نہیں؛ ہر درخواست کو اپنی شناخت اور اجازت ثابت کرنی ہوگی، اپنے نیٹ ورک کے اندر بھی۔ پرانا ماڈل حد کے اندر پہلے سے موجود ہر چیز پر بھروسہ کرتا تھا، جس کا مطلب تھا کہ ایک سمجھوتا شدہ سروس آزادانہ گھوم سکتی تھی۔ Zero trust نیٹ ورک کے مقام کے اعتماد کو ہر ہاپ پر شناخت پر مبنی اعتماد سے بدلتا ہے، اور گیٹ ویز اور میشز فطری نفاذ کے نقطے ہیں جہاں وہ شناخت جانچی جاتی ہے۔

گیٹ وے بیرونی شناخت کے لیے پالیسی نافذ کرنے کا نقطہ ہے: وہ آپ کی سروسز تک کچھ پہنچنے سے پہلے آخری صارف یا شراکت دار کی توثیق کرتا ہے۔ میش ورک لوڈ کی شناخت کے لیے پالیسی نافذ کرنے کا نقطہ ہے: ہر سروس کو خفیہ نگاری کی شناخت ملتی ہے، mTLS ہر کال پر اسے ثابت کرتا ہے، اور پالیسی طے کرتی ہے کہ کون سی سروسز کس سے بات کر سکتی ہیں۔ مل کر وہ آپ کو گہرائی میں دفاع دیتے ہیں، جہاں درخواست کنارے پر اور پھر سروسز کے بیچ جانچی جاتی ہے، تاکہ ایک سروس کا سمجھوتا باقیوں تک آزاد حرکت نہ دے۔ کثیر کلسٹر اور کثیر خطہ تعیناتیوں میں میش اس شناخت کے تانے بانے کو کلسٹر کی حدوں کے پار بڑھا سکتا ہے، تاکہ ایک کلسٹر کی سروس دوسرے کی سروس سے انہی mTLS کی ضمانتوں کے ساتھ تصدیق کرے جو وہ مقامی طور پر استعمال کرتی ہے، پھیلاؤ بڑھنے پر بھی مستقل zero trust نیٹ ورکنگ دیتے ہوئے۔ یہاں کی شناخت کی بنیادیں براہ راست باب 4.7 سے جڑتی ہیں۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
API گیٹ وے	تصدیق، شرح کی حدوں، ترکیب، ورژننگ کی ایک جگہ	پیمائش اور انتہائی دستیاب رکھنے کو واحد تنگ نقطہ
Backend for frontend	ہر کلائنٹ کو موزوں، آزادانہ ارتقا پذیر API ملتا ہے	چلانے کو زیادہ گیٹ ویز؛ BFFs میں نقل شدہ منطق
سروس میش (sidecar)	کوڈ کی تبدیلی کے بغیر یکساں mTLS، دوبارہ کوششیں، مشاہدہ پذیری	پراکسی کا اضافی بوجھ، لیٹنسی، اور چلانے کو کنٹرول پلین
Sidecarless / proxyless میش	فی pod sidecars سے کم اضافی بوجھ اور لیٹنسی	کم پختہ؛ کمزور علیحدگی یا فی زبان انحصار
لائبریری پر مبنی لچک	چلانے میں سادہ؛ کوئی اضافی انفراسٹرکچر نہیں	فی زبان نقل؛ پیمانے پر ہم آہنگ رکھنا مشکل
کلسٹرز کے پار میش	ہر جگہ مستقل zero-trust شناخت	نمایاں آپریشنل اور نیٹ ورکنگ پیچیدگی

مرکزی کھنچاؤ یکسانیت بمقابلہ آپریشنل لاگت ہے۔ مشترک تہہ آپ کو مستقل مزاجی، ثابت شدہ سلامتی، اور وہ پالیسی خریدتی ہے جو آپ ایک بار لکھتے ہیں، مگر یہ حقیقی نظام ہے جسے آپ کو چلانا، پیمائش کرنا، محفوظ کرنا، اور ڈی بگ کرنا ہے، اور یہ ہر درخواست کے راستے میں خود کو داخل کرتا ہے۔ پیمانے اور ضرورت سے کھنچاؤ حل کریں۔ گیٹ وے تقریباً ہمیشہ اپنی ادائیگی اس لمحے کرتا ہے جب آپ کے بیرونی کلائنٹ ہوں، کیونکہ جو معاملات یہ مرتکز کرتا ہے انہیں آپ ٹال نہیں سکتے۔ میش بعد میں ثمر دیتا ہے، جب سروسز اور زبانوں کی تعداد فی سروس تاروں کو زیادہ مہنگا راستہ بنائے۔ اس حد کے نیچے لائبریریاں اور سادہ گیٹ وے آپ کو لاگت کے ایک حصے پر زیادہ تر فائدہ دیتے ہیں۔ اس کے اوپر میش کی یکسانیت اپنا وزن رکھتی ہے۔ دونوں سمتوں میں غلطی ضرورت کی بجائے فیشن پر اپنانا ہے: بہت جلد میش ایک سال کی بیکار محنت ہے، اور بہت دیر سے چھوڑا گیا میش mTLS کے سو غیر مستقل، ہاتھ سے بنے نفاذ ہیں۔

اپنی ٹیم کے ساتھ بحث کے سوالات

ہر ہمہ گیر معاملے (تصدیق، دوبارہ کوششیں، ٹائم آؤٹ، شرح کی حد، خفیہ نگاری، ٹیلی میٹری) کے لیے، کون سی ایک تہہ اس کی مالک ہے، اور کیا ہر کوئی بغیر اندازے کے مالک کا نام لے سکتا ہے؟ یہ وہ سوال ہے جو دہری ہینڈلنگ روکتا ہے، اور زیادہ تر ٹیموں نے اسے کبھی واضح جواب نہیں دیا، جس کا مطلب ہے کہ جواب سروس اور مصنف کے حساب سے مختلف ہے۔ معاملات کی ٹھوس فہرست بائیں طرف اور اپنی تہیں (کلائنٹ لائبریری، گیٹ وے، میش، انفرادی سروس) اوپر لائیں، اور گرڈ مل کر بھریں۔ جہاں ایک معاملے کے لیے دو خانے جانچے جائیں وہ آپ کے دوبارہ کوشش کے طوفان اور ٹائم آؤٹ کے الٹاؤ ہیں جو ہونے کا انتظار کر رہے ہیں۔ خالی قطاریں وہ معاملات ہیں جنہیں کوئی بالکل نہیں سنبھال رہا۔ جو نتیجہ دینا ہے وہ ایک متفقہ ٹیبل ہے، جہاں ہر ٹیم دیکھ سکے وہاں شائع، جو کہتی ہے ٹھیک ایک تہہ ہر معاملے کی مالک ہے اور باقی گزرتی ہیں۔ وہ ٹیبل گیٹ وے یا میش کی کسی بھی ترتیب سے زیادہ قیمتی ہے، کیونکہ یہ وہ چیز ہے جو دونوں تہوں کو آپس میں لڑنے سے روکتی ہے۔
کیا ہمارے پاس میش کا جواز دینے کے لیے واقعی کافی سروسز اور زبانوں کا تنوع ہے، یا ہم ایسا مسئلہ حل کرنے کو کنٹرول پلین خریدنے والے ہیں جو ہمیں نہیں ہے؟ میش سنجیدہ آپریشنل عہد ہے، اور بہت سی ٹیموں کے لیے ایماندار جواب ہے کہ اچھی لائبریری جمع گیٹ وے آج ان کی بہتر خدمت کرے گا۔ اپنی سروسز کی حقیقی گنتی، جن زبانوں میں لکھی ہیں ان کی تعداد، اور ایماندار جائزہ لائیں کہ نقل شدہ نیٹ ورکنگ کی منطق ابھی دراصل آپ کو کتنا نقصان دیتی ہے۔ پھر دوسری طرف لائیں: میش کون چلائے گا، اس کے پراکسیز اپ گریڈ کون کرے گا، اس کے سرٹیفکیٹس کون گھمائے گا، اور جب وہ درخواست غلط روٹ کرے تو کسے پیج کیا جائے گا۔ اگر فی سروس تاروں کا درد میش چلانے کی لاگت سے چھوٹا ہے تو آپ کا جواب مل گیا، اور وہ انتظار کرنا ہے۔ اگر آپ درجنوں کثیر زبانی سروسز میں غیر مستقل mTLS اور دوبارہ کوشش کے کوڈ میں ڈوب رہے ہیں تو میش اپنی روزی کماتا ہے۔ نکتہ شہادت پر فیصلہ کرنا ہے، اس پر نہیں کہ کانفرنس کی تقریر نے میش کو کیسا دکھایا۔
آج ہماری zero-trust کی حد کہاں ہے، اور اگر ایک اندرونی سروس سمجھوتا ہو جائے تو کیا ہوتا ہے؟ بہت سے نظام اب بھی نیٹ ورک کے اندر موجود ہر چیز پر بھروسہ کرتے ہیں، جس کا مطلب ہے ایک سمجھوتا شدہ سروس پہلو بہ پہلو حرکت کر کے باقی سب تک پہنچ سکتی ہے، اور ٹیمیں اکثر یہ صرف واقعے کے دوران دریافت کرتی ہیں۔ دھماکے کے دائرے سے ایمانداری سے گزریں: اگر حملہ آور آپ کی کسی سروس کا مالک ہو جائے تو وہ کیا کال کر سکتا ہے، کیا پڑھ سکتا ہے، اور کیا اسے روکتا ہے؟ سروس سے سروس کالز کی تصدیق اور خفیہ نگاری کا اپنا موجودہ جواب لائیں، اور مخصوص رہیں کہ کون سی کالز mTLS سے محفوظ ہیں اور کون سی ایک ہی نیٹ ورک پر ہونے کی بنیاد پر سادہ متن کے اعتماد پر۔ اس کے بعد کا عمل ہر ہاپ پر شناخت پر مبنی رسائی کا جان بوجھ کر منصوبہ ہے، گیٹ وے بیرونی شناخت جانچتا اور میش یا مساوی ورک لوڈ کی شناخت، تاکہ سمجھوتا تباہ کن کی بجائے محدود ہو۔ چاہے آپ مکمل میش چلانے کو تیار نہ ہوں، یہ نام لینا کہ اعتماد کی حد دراصل کہاں ہے پہلا ایماندار قدم ہے۔
اگر ہماری API گیٹ وے کی تہہ ابھی ناکام ہو جائے تو نظام کا کتنا حصہ تاریک ہو جاتا ہے، اور کیا ہم نے اس ناکامی کو دور فرض کرنے کی بجائے ٹیسٹ کیا ہے؟ گیٹ وے اتنا کچھ مرتکز کرتا ہے کہ اس کی بندش اس کے پیچھے ہر چیز کو آف لائن لے جاتی ہے، اور بڑی ٹیمیں اس کی فالتو پن میں ٹھیک اس لیے کم سرمایہ لگاتی ہیں کہ وہ خاموشی سے کام کرتا ہے جب تک نہ کرے۔ متصادم کھنچاؤ تولیں: واحد سادہ گیٹ وے پر استدلال آسان اور چلانا سستا ہے، جبکہ افقی طور پر پیمائش شدہ، کثیر زون تہہ زیادہ لاگت لیتی ہے اور اپنی فیل اوور کی ترتیب اور پیچیدگی جوڑتی ہے۔ بحث میں حقیقی اعداد لائیں، بشمول آج کتنے انسٹینس چل رہے ہیں، کتنے دستیابی کے زونز میں، فیل اوور کا وقت کیا ہے، اور آپ نے آخری بار کب گیم ڈے چلایا جس نے گیٹ وے جان بوجھ کر مار دیا۔ اپ ٹائم کے عہد یا قانونی سروس لیولز رکھنے والے انٹرپرائز اور سرکاری پلیٹ فارمز کے لیے بندش کا معاہداتی یا ضابطے کا جرمانہ شامل کریں، کیونکہ فالتو پن کے بغیر سامنے کا دروازہ ہر سروس اور اس کے پیچھے ہر شہری کی طرف سے آپ کا خاموشی سے قبول کیا دستیابی کا خطرہ ہے۔
کیا ہم نے ناپا ہے کہ ہمارا میش دراصل کتنا sidecar کا محصول لیتا ہے، اور کیا ہمارے پاس sidecarless اور eBPF متبادلوں کا منصوبہ ہے، یا ہم اندھا دھند ادا کر رہے ہیں؟ پیمانے پر فی pod پراکسی کا کمپیوٹ اور لیٹنسی کا اضافی بوجھ غیر مرئی نہیں رہتا اور بجٹ میں حقیقی لکیر بن جاتا ہے، پھر بھی بہت سی ٹیمیں لاگت ناپے بغیر ہزاروں sidecars چلاتی ہیں۔ کھنچاؤ sidecar ماڈل کی پختگی اور علیحدگی ایک طرف اور فی نوڈ پراکسیز، proxyless لائبریریوں، یا kernel eBPF طریقوں کے کم اضافی بوجھ کے درمیان ہے، جو نئے ہیں اور کچھ علیحدگی کا سودا کرتے ہیں یا فی زبان انحصار جوڑتے ہیں۔ ناپے ہوئے اعداد لائیں: بیڑے میں پراکسیز کی کھائی میموری اور CPU، فی ہاپ جوڑی گئی دم کی لیٹنسی، اور آپ کے کمپیوٹ بل کا کتنا حصہ میش ہے۔ ہزاروں pods میں میش چلانے والے بڑے انٹرپرائز یا بجٹ کی جانچ کے تحت سرکاری پلیٹ فارم کے لیے یہ ایسا خرچ کا فیصلہ ہے جس کے بارے میں نگرانی آخرکار پوچھے گی، اس لیے محصول جاننا اور یہ کہ آپ کے پلیٹ فارم کے انتخاب سستے متبادل کھلے رکھتے ہیں بنیادی مستعدی ہے۔
کیا ہر کلائنٹ کی قسم کو واقعی اپنا backend for frontend چاہیے، یا ہم ان کلائنٹس کے لیے گیٹ ویز میں منطق نقل کرنے والے ہیں جو دراصل وہی چاہتے ہیں؟ BFF کا نمونہ کلائنٹ ٹیموں کو الگ کرتا اور ہر ایک کو موزوں معاہدہ ارتقا دینے دیتا ہے، مگر ہر نیا BFF ایک اور گیٹ وے ہے جسے چلانا، محفوظ کرنا، اور ہم آہنگ رکھنا ہے، اور ان میں نقل شدہ منطق خاموشی سے دیکھ بھال کا محصول بن جاتی ہے۔ متصادم غور ٹیم کی خود مختاری اور کلائنٹ سے مخصوص کارکردگی بمقابلہ بہت سے تقریباً یکساں گیٹ ویز کی آپریشنل لاگت اور بھٹکاؤ ہیں۔ شہادت لائیں کہ کلائنٹ کی ضروریات واقعی کتنی مختلف ہیں: پے لوڈ کے سائز، راؤنڈ ٹرپس کی گنتی، ورژننگ کی تال، اور کتنی بار ایک کلائنٹ کی تبدیلی واحد مشترک گیٹ وے کے تحت دوسرے کو روکتی۔ بہت سی کلائنٹ ٹیموں والے بڑے ادارے میں، یا عوامی ویب ایپ، موبائل ایپ، اور شراکت دار انضمام کو ایک ساتھ خدمت دینے والے سرکاری پلیٹ فارم میں، ایماندار سوال یہ ہے کہ آیا فرق پھیلاؤ کا جواز دیتا ہے، کیونکہ ہر کلائنٹ کے لیے BFF جو سب ایک ہی شکل چاہیں وہ پھیلاؤ ہے جس کی دیکھ بھال کی ادائیگی آپ برسوں کریں گے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ API گیٹ وے بھیجیں اور میش چھوڑ دیں۔ مٹھی بھر سروسز اور چھوٹی ٹیم کے ساتھ واحد گیٹ وے تصدیق، شرح کی حدیں، اور ترکیب سنبھالتا ہے، جبکہ مشترک کلائنٹ لائبریری آپ کو کنٹرول پلین کی لاگت کے ایک حصے پر mTLS اور دوبارہ کوششیں دیتی ہے۔ آپ کا کم یاب ترین وسیلہ انجینئرنگ کی توجہ ہے، اس لیے وہ میش جو آپ چلا نہ سکیں ذمہ داری ہے، خندق نہیں۔ گیٹ وے کو ایک نوڈ کے مرنے سے بچنے کے لیے کافی فالتو رکھیں، اور میش پر تب نظر ثانی کریں جب سروسز اور زبانوں کی تعداد واقعی سوال مجبور کرے۔

چھوٹا کاروبار۔ آپ کے پاس میش چلانے کو پلیٹ فارم ٹیم نہیں، اس لیے اس پر انحصار کریں جو آپ کا میزبانی پلیٹ فارم یا گیٹ وے پروڈکٹ پہلے سے دیتے ہیں: منظم TLS، اندرونی شرح کی حد، اور میزبانی والا گیٹ وے اپنا پیچ کرنے کی بجائے۔ انتخاب کو خریدنے بمقابلہ بنانے کے طور پر پیش کریں، اور خریدیں، کیونکہ منظم API گیٹ وے اپنا چلانے کے انجینئر کے گھنٹوں سے کم لاگت لیتا ہے۔ اندرونی سروس سے سروس خفیہ نگاری کو ایسا فیچر سمجھیں جو آپ کا پلیٹ فارم دیتا ہے، ایسا منصوبہ نہیں جس کا آپ عملہ دیں۔

بڑا ادارہ۔ بہت سی ٹیموں اور زبانوں میں سینکڑوں سروسز کے ساتھ میش اپنی پیچیدگی کماتا ہے، اور حقیقی کام نظم و نسق ہے: کام کی ایک تحریری تقسیم تاکہ گیٹ وے اور میش کبھی معاملہ دہری ہینڈل نہ کریں، یکساں mTLS اور ٹیلی میٹری، اور پلیٹ فارم ٹیم جو پراکسی اپ گریڈ اور سرٹیفکیٹ کی گردش کی مالک ہو۔ آڈیٹر رسائی اور خفیہ نگاری کے لیے واحد ثابت شدہ نفاذ کا نقطہ چاہتے ہیں، اس لیے انٹرفیس معیاری بنائیں اور پالیسی کو ایسی چیز بنائیں جو ٹیمیں وراثت میں پائیں، دوبارہ نافذ نہ کریں۔ sidecar کے محصول کو حقیقی بجٹ کی مد کے طور پر منظم کریں، اور sidecarless اختیارات کھلے رکھیں تاکہ آپ بعد میں سستے طریقوں سے باہر نہ ہوں۔

حکومت۔ خریداری کے قواعد، شفافیت، اور عوامی جوابدہی فن تعمیر کو شکل دیتے ہیں۔ گیٹ وے اور میش کو zero trust کی ریڑھ کی ہڈی سمجھیں جس کی ضابطہ ساز توقع رکھتے ہیں: ہر شہری اور شراکت دار سامنے کے دروازے پر تصدیق شدہ، ہر اندرونی کال ورک لوڈ کی شناخت سے تصدیق شدہ اور خفیہ، اور ہر نفاذ کے نقطے پر آڈٹ کا نشان جو ثابت کرے کہ رسائی کہاں جانچی گئی اور ٹریفک کہاں خفیہ ہوا۔ ملکیتی قید کی بجائے کھلے معیار اور منتقلی کے قابل ترتیب کو ترجیح دیں جسے خریداری کے قواعد منع کر سکتے ہیں، اور جہاں مناسب ہو شائع کریں کہ پلیٹ فارم شہری کے ڈیٹا کی ہر حد پار کرتے وقت حفاظت کیسے کرتا ہے۔

مثالیں

اسٹارٹ اپ۔ بارہ افراد کا اسٹارٹ اپ آٹھ سروسز واحد API گیٹ وے کے پیچھے چلاتا ہے۔ گیٹ وے شمال-جنوب کا سارا کام سنبھالتا ہے: ٹوکن کی جانچ سے صارفین کی تصدیق کرتا ہے، فی منصوبہ شرح کی حدیں نافذ کرتا ہے تاکہ مفت درجے کے صارفین نظام کو نہ ڈبوئیں، اور چند باتونی اینڈ پوائنٹس کو واحد موبائل دوست کالز میں ملاتا ہے۔ مشرق-مغرب ٹریفک کے لیے وہ جان بوجھ کر سروس میش چھوڑتے ہیں، کیونکہ دو زبانوں میں آٹھ سروسز کنٹرول پلین کا جواز نہیں دیتیں۔ اس کی بجائے وہ مشترک کلائنٹ لائبریری اور اپنے پلیٹ فارم کے اندرونی سرٹیفکیٹ کے انتظام سے mTLS اور دوبارہ کوششیں پاتے ہیں، اور ہلکے ایجنٹ سے ٹریسز جمع کرتے ہیں۔ جب وہ بعد میں تنگ پے لوڈ کی ضروریات والا مخصوص موبائل کلائنٹ جوڑتے ہیں تو موجودہ ویب گیٹ وے کے ساتھ موبائل backend for frontend متعارف کراتے ہیں۔ وہ ہر سال میش کے سوال پر نظر ثانی کرتے ہیں اور درست طور پر فیصلہ کرتے رہتے ہیں کہ انہوں نے ابھی وہ حد پار نہیں کی جہاں یہ ثمر دے۔

بڑا ادارہ۔ ایک کثیر قومی بینک بہت سی ٹیموں اور زبانوں میں کئی سو سروسز چلاتا ہے، اور یہاں سروس میش اپنی پیچیدگی کماتا ہے۔ ہر سروس کو ورک لوڈ کی شناخت اور ڈیفالٹ سے mTLS ملتا ہے، اس لیے تمام اندرونی ٹریفک کوئی ٹیم خفیہ نگاری کا کوڈ لکھے بغیر تصدیق شدہ اور خفیہ ہے، جو سلامتی کے ادارے اور ان آڈیٹرز دونوں کو مطمئن کرتا ہے جو واحد ثابت شدہ نفاذ کا نقطہ چاہتے ہیں۔ میش پالیسی سے یکساں دوبارہ کوششیں، ٹائم آؤٹ، اور سرکٹ بریکنگ لاگو کرتا ہے، اور کینری ریلیز کے لیے بتدریج ٹریفک منتقل کرتا ہے تاکہ خراب تعیناتی سب صارفین کو چھونے سے پہلے ایک فیصد کو چھوئے۔ API گیٹ ویز کی تہہ بیرونی اور شراکت دار ٹریفک کے سامنے ہے، تصدیق، کوٹوں، اور ورژننگ کی مالک، تحریری پکے اصول کے ساتھ کہ اندرونی دوبارہ کوششیں صرف میش میں رہتی ہیں اور بیرونی شرح کی حدیں صرف گیٹ ویز میں، تاکہ دونوں تہیں کبھی درخواست دہری ہینڈل نہ کریں۔ ہر پراکسی سے مستقل ٹیلی میٹری مرکزی مشاہدہ پذیری کے پلیٹ فارم کو کھلاتی ہے جو ایک آن کال انجینئر کو درجنوں سروس ہاپس کے پار درخواست کا سراغ لگانے دیتی ہے۔

حکومت۔ قومی ٹیکس ایجنسی شہری کی طرف والے فائلنگ کے پلیٹ فارم کو جدید کرتی ہے اور گیٹ وے اور میش کو zero-trust فن تعمیر کی ریڑھ کی ہڈی سمجھتی ہے جس کا ضابطہ ساز تقاضا کرتے ہیں۔ API گیٹ وے کنٹرول شدہ سامنے کا دروازہ ہے: ہر شہری اور ہر شراکت دار وہاں تصدیق شدہ اور مجاز ہوتا ہے، بیرونی شرح کی حدیں فائلنگ کی آخری تاریخ کے اچھال کے دوران نظام کی حفاظت کرتی ہیں، اور پرانے کلائنٹ کے فارمیٹ کنارے پر تبدیل ہوتے ہیں تاکہ پرانے انضمام کام کرتے رہیں۔ اس کے پیچھے سروس میش ہر اندرونی سروس کو خفیہ نگاری کی شناخت دیتا اور ہر کال پر mTLS نافذ کرتا ہے، اس لیے کوئی سروس محض نیٹ ورک کے اندر ہونے پر قابل اعتماد نہیں، اور رسائی کی پالیسی واضح فہرست کرتی ہے کہ کون سی سروسز کس کو کال کر سکتی ہیں۔ چونکہ پلیٹ فارم لچک کے لیے متعدد ڈیٹا سینٹرز میں پھیلا ہے، میش وہی شناخت اور خفیہ نگاری کی ضمانتیں کلسٹرز کے پار بڑھاتا ہے، ملک بھر مستقل zero-trust نیٹ ورکنگ دیتے ہوئے۔ ہر نفاذ کا نقطہ آڈٹ کا نشان خارج کرتا ہے، اس لیے ایجنسی نگران اداروں کو ثابت کر سکتی ہے کہ رسائی ٹھیک کہاں جانچی گئی اور ٹریفک کہاں خفیہ ہوا۔

کاروباری جواز: محرکات، ROI اور TCO

گیٹ وے کی واپسی دیکھنے میں آسان اور عموماً بڑی ہے۔ ہر سروس کے تصدیق، شرح کی حد، اور درخواست کی لاگنگ دوبارہ نافذ کرنے کی بجائے آپ انہیں کنارے پر ایک بار بناتے ہیں اور ہر سروس وراثت میں پاتی ہے۔ سلامتی کی اصلاح یا نئی شرح کی حد کی پالیسی سو کی بجائے ایک تعیناتی میں پہنچتی ہے، جو کمزوری بند کرنے کا وقت کم کرتی اور ہر آڈٹ کی لاگت گھٹاتی ہے، کیونکہ معائنہ کی ایک ہی جگہ ہے۔ ترکیب اور ورژننگ کے فیچرز کلائنٹ کے راؤنڈ ٹرپس کاٹتے اور آپ کو کال کرنے والوں کو توڑے بغیر APIs ارتقا دینے دیتے ہیں، جو لیٹنسی کی لاگتیں اور ٹیموں کے درمیان ہم آہنگی کا محصول دونوں کم کرتا ہے۔ بیرونی کلائنٹس والے تقریباً کسی بھی نظام کے لیے گیٹ وے جلد اپنی ادائیگی کرتا ہے۔

سروس میش کا کاروباری جواز زیادہ باریک ہے، کیونکہ اس کی ملکیت کی کل لاگت حقیقی اور جاری ہے۔ آپ پراکسیز کے کمپیوٹ اور لیٹنسی، کنٹرول پلین چلانے والے انجینئروں، اور نئی تہہ ڈی بگ کرنے کے سیکھنے کے منحنی کی ادائیگی کرتے ہیں۔ وہ لاگت تب جائز ہے جب متبادل (mTLS، دوبارہ کوششوں، اور ٹیلی میٹری کے فی سروس، فی زبان نفاذ) بڑا اور، بدتر، ایسے طریقوں سے غیر مستقل ہو جو سلامتی کے خلا اور بندشیں پیدا کریں۔ اعلیٰ پیمانے پر میش سو نازک ہاتھ سے بنے حلوں کو ایک یکساں، ثابت شدہ حل میں بدلتا ہے، اور ROI کم سلامتی کے واقعات، ٹریفک کی منتقلی کے ذریعے تیز محفوظ تعیناتیوں، اور ڈرامائی طور پر بہتر مشاہدہ پذیری کے طور پر ظاہر ہوتا ہے۔ اس پیمانے سے نیچے ایماندار حساب اکثر لائبریریوں اور گیٹ وے کے حق میں ہوتا ہے، اور نظم و ضبط والا قدم انتظار کرنا ہے۔ قیادت کے سامنے دلیل رکھنے کے لیے گیٹ وے کو ان اشاریوں سے جوڑیں جو وہ پہلے ہی ٹریک کرتی ہے (کمزوریاں ٹھیک کرنے کا وقت، آڈٹ کی لاگت، API کی ہم آہنگی کا اضافی بوجھ) اور میش کو سلامتی کے واقعے کے احاطے، تعیناتی کی حفاظت، اور اس کثیر زبانی نقل کی لاگت سے جوڑیں جسے یہ بدلتا ہے۔

ضد نمونے اور خامیاں

ضرورت سے پہلے میش: مٹھی بھر سروسز پر مکمل سروس میش اپنانا، ایسا مسئلہ حل کرنے کو کنٹرول پلین خریدنا جو آپ کو ابھی نہیں ہے۔
دہری دوبارہ کوششیں: گیٹ وے اور میش دونوں دوبارہ کوشش کرتے ہیں، تو ایک کلائنٹ کی کال بیک اینڈ دوبارہ کوشش کے طوفان میں ضرب ہو کر بندش بڑھاتی ہے۔
ٹائم آؤٹ کا الٹاؤ: اندرونی ٹائم آؤٹ بیرونی سے لمبا، تو کال کرنے والا ہار مان لیتا ہے جبکہ کال سننے والا ایسے جواب پر کام کرتا رہتا ہے جسے کوئی نہیں پڑھے گا۔
یک سنگی کے طور پر گیٹ وے: گیٹ وے میں کاروباری منطق بھرنا جب تک وہ مشترک رکاوٹ نہ بن جائے جسے بدلنے کو ہر ٹیم کو ہم آہنگ کرنا پڑے۔
ناکامی کا واحد نقطہ: فالتو پن کے بغیر ایک گیٹ وے انسٹینس چلانا، تو سامنے کے دروازے کی ناکامی اس کے پیچھے ہر سروس گرا دیتی ہے۔
نیٹ ورک پر بھروسہ: حد کے اندر ہر چیز کو محفوظ سمجھنا، تو ایک سمجھوتا شدہ سروس پہلو بہ پہلو حرکت کر کے سب تک پہنچ سکتی ہے۔
ملکیت کا ٹکراؤ: کام کی کوئی تحریری تقسیم نہیں، اس لیے وہی معاملہ دونوں تہوں میں حادثاً سنبھلتا ہے اور کوئی نہیں جانتا کون مستند ہے۔
BFF کا پھیلاؤ: ہر کلائنٹ کے لیے backend for frontend کھڑا کرنا جب کلائنٹ وہی چاہتے ہوں، فائدے کے بغیر گیٹ ویز ضرب کرنا اور منطق نقل کرنا۔
sidecar کے محصول کو نظر انداز کرنا: ہزاروں sidecars بغیر اضافی کمپیوٹ اور لیٹنسی ناپے تعینات کرنا، پھر سوچنا کہ بجٹ کہاں گیا۔

پختگی کا ماڈل

سطح 1، آغاز: سروسز کسی مشترک تہہ کے بغیر سیدھی ایک دوسرے سے بات کرتی ہیں۔ تصدیق، دوبارہ کوششیں، اور ٹائم آؤٹ فی سروس ہاتھ سے کوڈ ہیں اور غیر مستقل۔ اندرونی ٹریفک اکثر سادہ متن ہے اور نیٹ ورک پر ہونے کی بنیاد پر قابل اعتماد، اور پالیسی نافذ کرنے یا ٹریفک دیکھنے کی کوئی ایک جگہ نہیں۔ فیصلے ردعملی ہیں، سروس بہ سروس مسائل سامنے آنے پر کیے جاتے ہیں۔
سطح 2، ترقی: API گیٹ وے بیرونی ٹریفک کے سامنے ہے اور تصدیق، شرح کی حد، اور روٹنگ مرتکز کرتا ہے، مگر مشرق-مغرب کے معاملات ناہموار اپنانے والی مشترک لائبریریاں سنبھالتی ہیں۔ کچھ سروسز میں mTLS ہے؛ بہت سی میں نہیں۔ ٹیمیں شمال-جنوب بمقابلہ مشرق-مغرب کا فرق پہچانتی ہیں، پھر بھی ملکیت غیر رسمی ہے اور عمل ٹیم سے ٹیم مختلف ہیں۔
سطح 3، معیار بندی: شمال-جنوب اور مشرق-مغرب کے معاملات کام کی تحریری تقسیم کے ساتھ صاف الگ ہیں جو ادارے میں لاگو ہے۔ گیٹ وے بیرونی شناخت، کوٹوں، اور ترکیب کا مالک ہے؛ میش یا مستقل لائبریری کی تہہ اندرونی mTLS، دوبارہ کوششوں، اور ٹیلی میٹری کی مالک ہے۔ ٹکراؤ حل ہیں تاکہ کوئی معاملہ دہری ہینڈل نہ ہو، اندرونی ٹریفک ڈیفالٹ سے خفیہ اور شناخت سے جانچا جاتا ہے، اور معیار ہر ٹیم کی صوابدید پر چھوڑنے کی بجائے دستاویزی اور نافذ ہے۔
سطح 4، انتظام: ٹریفک کی تہہ بنیادی خطوط کے مقابل ناپی اور کنٹرول کی جاتی ہے۔ آپ کمپیوٹ اور فی ہاپ دم کی لیٹنسی میں sidecar کا محصول، غلطی کے بجٹ کے مقابل گیٹ وے اور میش کی دستیابی، دوبارہ کوشش کے ضرب اور ٹائم آؤٹ کے الٹاؤ کے واقعات، اندرونی کالز کے فیصد کے طور پر mTLS کی کوریج، اور پورے بیڑے میں پالیسی کی تبدیلی پھیلانے کا وقت اور غیر حل شدہ استثنا ٹریک کرتے ہیں۔ میٹرکس فیصلوں کو گیٹ کرتی ہیں: پراکسی کی اپ گریڈ، نئی دوبارہ کوشش کا بجٹ، یا کینری کا اصول وجدان کی بجائے بنیادی خط کے مقابل ڈیٹا پر پرکھا جاتا ہے، اور معیار سے کوئی بھٹکاؤ اصلاح چلاتا ہے۔
سطح 5، ہم آہنگی: گیٹ وے اور میش پختہ zero-trust فن تعمیر کے لیے پالیسی نافذ کرنے کے نقطے ہیں، شناخت کلسٹرز اور خطوں کے پار ہر ہاپ پر جانچی جاتی ہے۔ ٹریفک کی منتقلی محفوظ بتدریج ترسیل چلاتی ہے، مشاہدہ پذیری یکساں اور بھرپور ہے، اور ادارہ sidecarless، proxyless، اور eBPF طریقوں کا مسلسل جائزہ لیتا اور اپناتا ہے جہاں وہ ثمر دیں۔ ٹریفک کی تہہ سلامتی، ترسیل، اور صلاحیت کی منصوبہ بندی سے مربوط ہے، اور پیمانے، زبانوں، اور خطرے کی تصویر کے بدلنے کے ساتھ ڈھلتی ہے۔

بحث کے لیے خیالات

اگر آپ کا واحد API گیٹ وے ابھی گر جائے تو کتنی سروسز ناقابل رسائی ہو جائیں گی، اور سامنے کا دروازہ فالتو بنانے کا آپ کا منصوبہ کیا ہے؟
آپ کے نظام میں کون سا معاملہ فی الحال گیٹ وے اور سروس (یا لائبریری) دونوں میں سنبھلتا ہے، اور آپ کیسے ثابت کریں گے کہ یہ دہری ہینڈل نہیں ہو رہا؟
سروسز اور زبانوں کی کس تعداد پر آپ کی ٹیم اتفاق کرے گی کہ میش نے آخرکار اپنی پیچیدگی کمائی، اور آپ اس لکیر سے کتنے دور ہیں؟
اگر حملہ آور کل ایک اندرونی سروس سمجھوتا کر لے تو وہ کن دوسری سروسز تک پہنچ سکتا ہے، اور کون سی شناخت کی جانچ اسے روکے گی؟
کیا sidecarless یا eBPF پر مبنی میش کے طریقے آپ کے پلیٹ فارم کے لیے ابھی کافی پختہ ہیں، اور فیصلے کے لیے آپ کیا ناپیں گے؟
کیا آپ کے ہر مختلف کلائنٹ کو واقعی اپنا backend for frontend چاہیے، یا آپ وہ منطق نقل کرنے والے ہیں جو مشترک رہ سکتی ہے؟

اہم نکات

شمال-جنوب ٹریفک (API گیٹ وے سے سنبھلتا) کو مشرق-مغرب ٹریفک (سروس میش سے سنبھلتا) سے الگ کریں؛ ہر ایک اپنی سمت کا مالک ہے، اور انہیں ملانا دہری ہینڈلنگ پیدا کرتا ہے۔
گیٹ وے روٹنگ، تصدیق، اجازت، شرح کی حد، کوٹے، درخواست کی تبدیلی، ترکیب، اور ورژننگ مرتکز کرتا ہے، تاکہ سروسز پتلی رہیں اور پالیسی ایک جگہ رہے۔
سروس میش آپ کو سروس کا کوڈ بدلے بغیر mTLS، ٹریفک کی منتقلی، پلیٹ فارم کی سطح کی دوبارہ کوششیں اور سرکٹ بریکنگ، اور یکساں مشاہدہ پذیری دیتا ہے، کلاسیکی طور پر sidecar پراکسیز کے ذریعے۔
میش صرف تب اپنائیں جب سروسز اور زبانوں کی تعداد فی سروس تاروں کو زیادہ مہنگا راستہ بنائے؛ اس سے نیچے لائبریریاں جمع گیٹ وے جیتتے ہیں، اور sidecar کا محصول دیکھنے کے قابل حقیقی ہے۔
گیٹ وے اور میش کو zero-trust فن تعمیر کے پالیسی نافذ کرنے کے نقطے سمجھیں، ہر ہمہ گیر معاملہ ٹھیک ایک تہہ کو تفویض کریں، اور کلسٹرز کے پار ہر ہاپ پر شناخت جانچیں۔

حوالہ جات اور مزید مطالعہ

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote and Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer, and others; the CNCF Cloud Native Landscape and service mesh documentation
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices