نوٹ. ترجمہ: سروس میش ایک ایسا رجحان ہے جس کا روسی میں ابھی تک کوئی مستحکم ترجمہ نہیں ہے (2 سال سے زیادہ پہلے ہم نے "سروسز کے لیے میش" کا آپشن پیش کیا تھا، اور تھوڑی دیر بعد، کچھ ساتھیوں نے "سروس چھلنی" کے امتزاج کو فعال طور پر فروغ دینا شروع کر دیا) . اس ٹیکنالوجی کے بارے میں مسلسل بات چیت نے ایک ایسی صورتحال پیدا کی ہے جس میں مارکیٹنگ اور تکنیکی اجزاء بہت قریب سے جڑے ہوئے ہیں۔ اصل اصطلاح کے مصنفین میں سے ایک کی طرف سے اس شاندار مواد کا مقصد صرف انجینئرز کو ہی نہیں بلکہ واضح کرنا ہے۔
سے مزاحیہ
تعارف
اگر آپ بیک اینڈ سسٹمز کے شعبے میں کہیں کام کرنے والے سافٹ ویئر انجینئر ہیں تو، "سروس میش" کی اصطلاح شاید پچھلے کچھ سالوں میں آپ کے ذہن میں مضبوطی سے جم چکی ہے۔ ایک عجیب اتفاق کی بدولت، یہ جملہ صنعت کو زیادہ سے زیادہ اپنی لپیٹ میں لے رہا ہے، اور ہائپ اور متعلقہ پروموشنل پیشکشیں برف کے گولے کی طرح بڑھ رہی ہیں، پہاڑی سے نیچے اڑ رہی ہیں اور سست ہونے کے کوئی آثار نہیں دکھا رہے ہیں۔
سروس میش بادل کے آبائی ماحولیاتی نظام کے گندے، متضاد پانیوں میں پیدا ہوا تھا۔ بدقسمتی سے، اس کا مطلب یہ ہے کہ اس کے ارد گرد کا زیادہ تر تنازعہ "کم کیلوری والی بات چیت" سے لے کر تکنیکی اصطلاح استعمال کرنے کے لیے - صریح بکواس ہے۔ لیکن اگر آپ تمام شور کو فلٹر کرتے ہیں، تو آپ دیکھ سکتے ہیں کہ سروس میش کا ایک بہت ہی حقیقی، یقینی اور اہم کام ہے۔
اس پوسٹ میں، میں صرف یہ کرنے کی کوشش کروں گا: سروس میش کے لیے ایک ایماندار، گہرائی سے، انجینئر پر مبنی گائیڈ فراہم کریں۔ میں صرف سوال سے زیادہ جواب دینے جا رہا ہوں: "یہ کیا ہے؟", - لیکن یہ بھی "کیوں؟"اور "اب کیوں؟". آخر میں، میں اس بات کا خاکہ پیش کرنے کی کوشش کروں گا کہ (میری رائے میں) اس مخصوص ٹکنالوجی نے ایسا پاگل پن کیوں پیدا کیا، جو کہ بذات خود ایک دلچسپ کہانی ہے۔
Кто я؟
سب کو سلام! میرا نام ہے . میں تخلیق کاروں میں سے ایک ہوں۔ - سب سے پہلے سروس میش پروجیکٹ اور وہ پروجیکٹ جو اصطلاح کی ظاہری شکل کے لئے ذمہ دار ہے۔ سروس میش جیسا کہ (افسوس لوگو!) (ترجمہ نوٹ کریں۔: ویسے، اس اصطلاح کے ظہور کے آغاز پر، 2,5 سال سے زیادہ پہلے، ہم نے پہلے ہی اسی مصنف کے ابتدائی مواد کا ترجمہ کیا تھا جسے "".) میں بھی قیادت کرتا ہوں۔ ایک اسٹارٹ اپ ہے جو لنکرڈ اور جیسی ٹھنڈی سروس میش چیزیں بناتا ہے۔ .
آپ شاید اندازہ لگا سکتے ہیں کہ میں اس معاملے پر بہت متعصب اور موضوعی رائے رکھتا ہوں۔ تاہم، میں تعصب کو کم سے کم رکھنے کی کوشش کروں گا (ایک سیکشن کو چھوڑ کر: "سروس میش کے بارے میں اتنی باتیں کیوں ہو رہی ہیں؟", - جس میں میں اس کے باوجود اپنے پہلے سے تصور شدہ خیالات کا اشتراک کروں گا)۔ میں اس گائیڈ کو ہر ممکن حد تک مقصد بنانے کی بھی پوری کوشش کروں گا۔ مخصوص مثالوں میں، میں بنیادی طور پر Linkerd کے تجربے پر بھروسہ کروں گا، جبکہ دیگر اقسام کی سروس میش کے نفاذ میں ان فرقوں (اگر کوئی ہے) کی نشاندہی کرتا ہوں۔
ٹھیک ہے، یہ علاج پر جانے کا وقت ہے.
سروس میش کیا ہے؟
تمام ہائپ کے باوجود، سروس میش ساختی طور پر کافی آسان ہے۔ یہ صرف یوزر اسپیس پراکسیز کا ایک گروپ ہے جو "سروسز کے آگے" واقع ہے (ہم بعد میں "قریب" کے بارے میں تھوڑی بات کریں گے)، نیز کنٹرول کے عمل کا ایک سیٹ۔ پراکسیوں کو اجتماعی طور پر کہا جاتا ہے۔ ڈیٹا ہوائی جہاز، اور کنٹرول کے عمل کو کہا جاتا ہے۔ کنٹرول ہوائی جہاز. ڈیٹا طیارہ خدمات کے درمیان کالوں کو روکتا ہے اور ان کے ساتھ "کچھ مختلف" کرتا ہے۔ کنٹرول طیارہ بالترتیب پراکسی کے رویے کو مربوط کرتا ہے اور آپ کے لیے رسائی فراہم کرتا ہے، یعنی آپریٹر، API کو، نیٹ ورک کو مجموعی طور پر ہیرا پھیری اور پیمائش کرنے کی اجازت دیتا ہے۔
یہ پراکسی کیا ہے؟ یہ "Layer 7-Aware" زمرہ کا TCP پراکسی ہے۔ (یعنی OSI ماڈل کی ساتویں پرت کو "منظر میں رکھنا") جیسے HAProxy اور NGINX۔ آپ اپنی پسند کے مطابق پراکسی کا انتخاب کر سکتے ہیں۔ Linkerd ایک Rust پراکسی استعمال کرتا ہے، جس کا نام غیر پیچیدہ ہے۔ . ہم نے اسے خاص طور پر سروس میش کے لیے مرتب کیا ہے۔ دیگر میش دیگر پراکسیوں کو ترجیح دیتے ہیں (ایلچی ایک عام انتخاب ہے)۔ تاہم، پراکسی کا انتخاب صرف عمل درآمد کا معاملہ ہے۔
یہ پراکسی سرورز کیا کرتے ہیں؟ ظاہر ہے، وہ سروسز پر اور ان سے پراکسی کالز کرتے ہیں (سختی سے بات کرتے ہوئے، وہ پراکسی اور ریورس پراکسی کے طور پر کام کرتے ہیں، آنے والی اور جانے والی دونوں کالوں کو ہینڈل کرتے ہیں)۔ اور وہ ایک فیچر سیٹ کو نافذ کرتے ہیں جو کالز پر فوکس کرتا ہے۔ کے درمیان خدمات خدمات کے درمیان ٹریفک پر یہ توجہ وہی ہے جو سروس میش پراکسی کو API گیٹ ویز یا انگریس پراکسی سے ممتاز کرتی ہے (مؤخر الذکر بیرونی دنیا سے کلسٹر میں آنے والی کالوں پر توجہ مرکوز کرتا ہے)۔ (نوٹ. ترجمہ: موجودہ Kubernetes Ingress کنٹرولرز کے مقابلے کے لیے، جن میں سے بہت سے پہلے سے ذکر کردہ ایلچی کا استعمال کرتے ہیں، دیکھیں .)
تو، ہم نے ڈیٹا ہوائی جہاز کا پتہ لگایا۔ کنٹرول ہوائی جہاز آسان ہے: یہ اجزاء کا ایک مجموعہ ہے جو تمام میکانکس فراہم کرتا ہے جو ڈیٹا ہوائی جہاز کو مربوط طریقے سے کام کرنے کی ضرورت ہے، بشمول سروس کی دریافت، TLS سرٹیفکیٹ کا اجراء، میٹرکس ایگریگیشن وغیرہ۔ اس کے رویے؛ بدلے میں، کنٹرول طیارہ ایک API فراہم کرتا ہے جو آپ کو مجموعی طور پر ڈیٹا جہاز کے رویے کو تبدیل کرنے اور ٹریک کرنے کی اجازت دیتا ہے۔
ذیل میں لنکرڈ میں کنٹرول ہوائی جہاز اور ڈیٹا ہوائی جہاز کا خاکہ ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، کنٹرول ہوائی جہاز میں کئی مختلف اجزاء شامل ہوتے ہیں، بشمول ایک Prometheus مثال جو پراکسی سرورز سے میٹرکس جمع کرتا ہے، نیز دیگر اجزاء جیسے destination (خدمت کی دریافت) identity (سرٹیفکیٹ اتھارٹی، CA) اور public-api (ویب اور CLI کے لیے اختتامی نکات)۔ اس کے برعکس، ڈیٹا پلین ایپلیکیشن مثال کے آگے ایک سادہ لنکرڈ پراکسی ہے۔ یہ صرف ایک منطقی خاکہ ہے۔ حقیقی دنیا کی تعیناتی میں، آپ کے پاس ہر کنٹرول طیارے کے جزو کی تین نقلیں اور ڈیٹا جہاز میں سینکڑوں یا ہزاروں پراکسیز ہو سکتی ہیں۔
(اس خاکہ میں نیلے رنگ کے خانے Kubernetes pods کی سرحدوں کی نمائندگی کرتے ہیں۔ آپ دیکھ سکتے ہیں کہ Linkerd-proxy والے کنٹینرز اسی پوڈ میں ہیں جیسے کہ ایپلی کیشن کنٹینرز۔ اس سکیم کے نام سے جانا جاتا ہے۔ سائڈ کار کنٹینر.)
سروس میش فن تعمیر کے کئی اہم اثرات ہیں۔ سب سے پہلے، چونکہ پراکسی کا کام خدمات کے درمیان کالوں کو روکنا ہے، سروس میش صرف اس صورت میں معنی رکھتا ہے جب آپ کی درخواست خدمات کے ایک سیٹ کے لیے بنائی گئی ہو۔ میش ایک کر سکتے ہیں monoliths کے ساتھ استعمال کریں، لیکن یہ ایک واحد پراکسی کی خاطر واضح طور پر بے کار ہے، اور اس کی فعالیت کی طلب میں ہونے کا امکان نہیں ہے۔
ایک اور اہم نتیجہ یہ ہے کہ سروس میش کی ضرورت ہوتی ہے۔ بہت بڑا پراکسیوں کی تعداد درحقیقت، Linkerd ہر سروس کی ہر مثال کے لیے ایک لنکرڈ پراکسی کو زنجیروں میں ڈالتا ہے (دیگر نفاذ ہر میزبان/میزبان/VM میں ایک پراکسی شامل کرتے ہیں۔ بہرحال یہ بہت زیادہ ہے)۔ پراکسی کا ایسا فعال استعمال اپنے آپ میں کئی اضافی پیچیدگیاں پیدا کرتا ہے:
- ڈیٹا جہاز میں پراکسی ہونا چاہئے تیزکیونکہ ہر کال کے لیے پراکسی کو دو کالیں ہوتی ہیں: ایک کلائنٹ کی طرف، ایک سرور کی طرف۔
- اس کے علاوہ، پراکسی ہونا ضروری ہے چھوٹا и ہلکا پھلکا. ہر ایک میموری اور سی پی یو وسائل استعمال کرے گا، اور یہ کھپت ایپلی کیشن کے ساتھ یکساں طور پر بڑھے گی۔
- آپ کو پراکسیوں کی ایک بڑی تعداد کو تعینات اور اپ ڈیٹ کرنے کے لیے ایک طریقہ کار کی ضرورت ہوگی۔ اسے دستی طور پر کرنا کوئی آپشن نہیں ہے۔
عام طور پر، سروس میش اس طرح نظر آتی ہے (کم از کم پرندوں کی نظر سے): آپ یوزر اسپیس پراکسیوں کا ایک گروپ تعینات کرتے ہیں جو اندرونی، انٹر سروس ٹریفک کے ساتھ "کچھ" کرتے ہیں، اور ان کی نگرانی اور انتظام کرنے کے لیے کنٹرول ہوائی جہاز کا استعمال کرتے ہیں۔
یہ سوال کا وقت ہے "کیوں؟"
سروس میش کس کے لیے ہے؟
ان لوگوں کے لیے جنہوں نے سب سے پہلے سروس میش کے خیال کا سامنا کیا، تھوڑا سا خوف میں رہنا قابل معافی ہے۔ سروس میش ڈیزائن کا مطلب یہ ہے کہ اس سے نہ صرف ایپلی کیشن میں تاخیر ہو گی بلکہ یہ بھی ہو گی۔ کھاؤ وسائل اور شامل کریں گے بنیادی ڈھانچے میں نئے میکانزم کا ایک گروپ۔ پہلے آپ نے ایک سروس میش ترتیب دیا، اور پھر آپ کو اچانک اپنے آپ کو سینکڑوں (اگر ہزاروں نہیں) پراکسی پیش کرنے کی ضرورت محسوس ہوئی۔ سوال یہ ہے کہ اس کے لیے کون رضاکارانہ خدمات انجام دے گا؟
اس سوال کے جواب کے دو حصے ہیں۔ سب سے پہلے، ان پراکسیوں کی تعیناتی سے منسلک لین دین کے اخراجات ماحولیاتی نظام میں ہونے والی کچھ تبدیلیوں کی وجہ سے نمایاں طور پر کم ہو سکتے ہیں (اس پر بعد میں مزید)۔
دوم، ایسا آلہ دراصل سسٹم میں اضافی منطق متعارف کرانے کا ایک بہترین طریقہ ہے۔ اور نہ صرف اس لیے کہ سروس میش کا استعمال کرتے ہوئے بہت ساری نئی خصوصیات شامل کی جا سکتی ہیں، بلکہ اس لیے بھی کہ یہ ماحولیاتی نظام میں مداخلت کیے بغیر کیا جا سکتا ہے۔ درحقیقت، پورا سروس میش ماڈل اس پوسٹولٹ پر مبنی ہے: ملٹی سروس سسٹم میں، چاہے کچھ بھی ہو۔ کر رہے ہیں انفرادی خدمات، ٹریفک انکے درمیان فعالیت کو شامل کرنے کا ایک مثالی نقطہ ہے۔
مثال کے طور پر، Linkerd میں (جیسا کہ زیادہ تر میشوں میں) فعالیت بنیادی طور پر HTTP کالز پر مرکوز ہوتی ہے، بشمول HTTP/2 اور gRPC*۔ فعالیت کافی امیر ہے - اسے تین طبقات میں تقسیم کیا جا سکتا ہے:
- متعلقہ خصوصیات اعتبار. دوبارہ کوشش کی درخواستیں، ٹائم آؤٹ، کینری اپروچ (ٹریفک اسپلٹ/ری ڈائریکٹ) وغیرہ۔
- متعلقہ خصوصیات نگرانی. کامیابی کی شرح، تاخیر اور ہر سروس یا انفرادی منزلوں کے لیے درخواست کے حجم کا مجموعہ؛ خدمات کے ٹاپولوجیکل نقشے بنانا وغیرہ
- متعلقہ خصوصیات سیکورٹی. باہمی TLS، رسائی کنٹرول، وغیرہ
* Linkerd کے نقطہ نظر سے، gRPC عملی طور پر HTTP/2 سے مختلف نہیں ہے: یہ صرف پے لوڈ میں پروٹوبف کا استعمال کرتا ہے۔ ڈویلپر کے نقطہ نظر سے، یہ دونوں چیزیں، بلاشبہ، مختلف ہیں۔
ان میں سے بہت سے میکانزم درخواست کی سطح پر کام کرتے ہیں (اس لیے "L7 پراکسی")۔ مثال کے طور پر، اگر سروس Foo سروس بار کو ایک HTTP کال کرتی ہے، تو Foo کی طرف سے لنکرڈ پراکسی ذہانت سے لوڈ بیلنس کر سکتی ہے اور مشاہدہ شدہ تاخیر کی بنیاد پر Foo سے بار تک کالوں کو روٹ کر سکتی ہے۔ اگر ضروری ہو تو یہ درخواست کو دہرا سکتا ہے (اور اگر یہ ناکارہ ہے)؛ وہ رسپانس کوڈ اور ٹائم آؤٹ وغیرہ کو ریکارڈ کر سکتا ہے۔ اسی طرح، بار سائیڈ پر لنکرڈ پراکسی کسی درخواست کو مسترد کر سکتا ہے اگر اس کی اجازت نہ ہو یا درخواست کی حد سے تجاوز کر جائے۔ اپنی طرف سے تاخیر کو ٹھیک کر سکتا ہے، وغیرہ۔
پراکسی کنکشن کی سطح پر بھی "کچھ کر سکتے ہیں"۔ مثال کے طور پر، فو سائیڈ پر ایک لنکرڈ پراکسی TLS کنکشن شروع کر سکتی ہے، اور بار سائیڈ پر ایک لنکرڈ پراکسی اسے ختم کر سکتی ہے، اور دونوں فریق ایک دوسرے کے TLS سرٹیفکیٹس کی تصدیق کر سکتے ہیں۔ یہ نہ صرف خدمات کے درمیان خفیہ کاری فراہم کرتا ہے، بلکہ خدمات کی شناخت کا ایک خفیہ طریقہ بھی فراہم کرتا ہے: Foo اور Bar "ثابت" کر سکتے ہیں کہ وہ وہی ہیں جو وہ کہتے ہیں کہ وہ ہیں۔
* "دوست کا دوست" کا مطلب ہے کہ کلائنٹ کا سرٹیفکیٹ بھی تصدیق شدہ ہے (باہمی TLS)۔ "کلاسک" TLS میں، مثال کے طور پر، ایک براؤزر اور سرور کے درمیان، عام طور پر صرف ایک طرف (سرور) کے سرٹیفکیٹ کی تصدیق کی جاتی ہے۔
چاہے وہ درخواست یا کنکشن کی سطح پر کام کرتے ہیں، اس بات پر زور دینا ضروری ہے کہ تمام سروس میش خصوصیات ہیں۔ آپریشنل کردار Linkerd پے لوڈ کے سیمنٹکس کو تبدیل کرنے سے قاصر ہے، جیسے JSON ٹکڑے میں فیلڈز شامل کرنا یا پروٹوبف میں تبدیلیاں کرنا۔ ہم اس اہم خصوصیت کے بارے میں بعد میں بات کریں گے جب ہم ESB اور مڈل ویئر کے بارے میں بات کریں گے۔
یہ ان خصوصیات کا مجموعہ ہے جو سروس میش پیش کرتا ہے۔ سوال یہ پیدا ہوتا ہے کہ انہیں براہ راست درخواست میں لاگو کیوں نہیں کیا جاتا؟ اور کسی پراکسی کے ساتھ کیوں گڑبڑ؟
کیوں ایک سروس میش ایک اچھا خیال ہے
اگرچہ سروس میش کی صلاحیتیں دلکش ہیں، لیکن اس کی اصل قدر فیچرز میں نہیں ہے۔ آخر میں ہم کر سکتے ہیں۔ انہیں براہ راست درخواست میں لاگو کریں (بعد میں ہم دیکھیں گے کہ یہ سروس میش کی اصل تھی)۔ اسے ایک جملے میں ڈالنے کے لئے، سروس میش کی قدر یہ ہے: یہ جدید سرور سافٹ ویئر کو مسلسل، اسٹیک-وائیڈ، ایپلیکیشن-کوڈ-ایگنوسٹک انداز میں چلانے کے لیے اہم فعالیت فراہم کرتا ہے۔.
آئیے اس تجویز کا تجزیہ کرتے ہیں۔
«جدید سرور سافٹ ویئر کو چلانے کے لیے اہم افعال" اگر آپ عوامی انٹرنیٹ سے منسلک ایک ٹرانزیکشنل سرور ایپلیکیشن بنا رہے ہیں جو بیرونی دنیا سے درخواستیں قبول کرتی ہے اور ان کا جواب مختصر وقت میں دیتی ہے - مثال کے طور پر، ایک ویب ایپلیکیشن، ایک API سرور، اور دیگر جدید ایپلی کیشنز کی اکثریت - اور اگر آپ اسے خدمات کے ایک سیٹ کے طور پر لاگو کرتے ہیں جو ایک دوسرے کے ساتھ ہم آہنگی کے ساتھ تعامل کرتے ہیں، اور اگر آپ اس سافٹ ویئر کو مسلسل اپ گریڈ کر رہے ہیں، نئی خصوصیات شامل کر رہے ہیں، اور اگر آپ ترمیم کے دوران اس سسٹم کو کام کرنے کی حالت میں رکھنے پر مجبور ہیں تو - اس صورت میں، مبارکباد آپ جدید سرور سافٹ ویئر بنا رہے ہیں۔ اور اوپر دی گئی وہ تمام عمدہ خصوصیات دراصل آپ کے لیے اہم ثابت ہوتی ہیں۔ ایپلیکیشن قابل اعتماد، محفوظ ہونی چاہیے، اور آپ کو یہ دیکھنے کے قابل ہونا چاہیے کہ یہ کیا کر رہی ہے۔ یہ وہ سوالات ہیں جن کو حل کرنے میں سروس میش مدد کرتا ہے۔
(ٹھیک ہے، میرا یقین کہ یہ طریقہ سرور سافٹ ویئر بنانے کا جدید طریقہ ہے پچھلے پیراگراف میں آ گیا ہے۔ دوسرے لوگ مونولیتھس، "ری ایکٹیو مائیکرو سروسز" اور دوسری چیزیں تیار کرنے کو ترجیح دیتے ہیں جو اوپر دی گئی تعریف کے تحت نہیں آتی ہیں۔ رائے جو میری رائے سے مختلف ہے، اور بدلے میں، مجھے یقین ہے کہ وہ "غلط" ہیں - حالانکہ کسی بھی صورت میں، سروس میش ان کے لیے زیادہ مفید نہیں ہے)۔
«پورے اسٹیک کے لیے یونیفارم" سروس میش کے ذریعہ فراہم کردہ خصوصیات صرف اہم نہیں ہیں۔ وہ درخواست میں تمام خدمات پر لاگو ہوتے ہیں، قطع نظر اس کے کہ وہ کس زبان میں لکھے گئے ہیں، وہ کون سا فریم ورک استعمال کرتے ہیں، انہیں کس نے لکھا، انہیں کیسے تعینات کیا گیا، اور ان کی ترقی اور استعمال کی دیگر تمام باریکیاں۔
«درخواست کوڈ آزاد" آخر میں، سروس میش نہ صرف پورے اسٹیک میں مستقل فعالیت فراہم کرتا ہے، بلکہ یہ اس طرح سے کرتا ہے جس میں ایپلیکیشن میں ترمیم کی ضرورت نہیں ہوتی ہے۔ سروس میش کی فعالیت کی بنیادی بنیاد، بشمول ترتیب، اپ ڈیٹ، آپریٹنگ، برقرار رکھنے، وغیرہ کے کام، خالصتاً پلیٹ فارم کی سطح پر ہیں اور اطلاق سے آزاد ہیں۔ ایپلیکیشن سروس میش کو متاثر کیے بغیر تبدیل کر سکتی ہے۔ بدلے میں، سروس میش بغیر کسی درخواست کی مداخلت کے تبدیل ہو سکتی ہے۔
مختصراً، سروس میش نہ صرف اہم فعالیت فراہم کرتا ہے، بلکہ یہ ایسا عالمی، یکساں، اور درخواست سے آزاد طریقے سے کرتا ہے۔ اور اس طرح، جب کہ سروس میش کی فعالیت کو سروس کے کوڈ میں لاگو کیا جا سکتا ہے (مثال کے طور پر، ہر سروس کے ساتھ ایک لائبریری شامل ہے)، یہ نقطہ نظر وہ یکسانیت اور خود مختاری فراہم نہیں کرے گا جو کہ اس معاملے میں بہت قیمتی ہے۔ سروس میش.
اور آپ کو بس پراکسیوں کا ایک گروپ شامل کرنے کی ضرورت ہے! میں وعدہ کرتا ہوں، بہت جلد ہم ان پراکسیوں کو شامل کرنے سے منسلک آپریشنل اخراجات کو دیکھیں گے۔ لیکن پہلے، آئیے رکتے ہیں اور آزادی کے اس خیال کو مختلف نقطہ نظر سے دیکھتے ہیں۔ لوگوں کی.
سروس میش کس کی مدد کرتا ہے؟
یہ جتنا بھی تکلیف دہ ہو، کسی ٹیکنالوجی کو ماحولیاتی نظام کا ایک اہم حصہ بننے کے لیے، اسے لوگوں کو قبول کرنا چاہیے۔ تو سروس میش میں کون دلچسپی رکھتا ہے؟ اس کے استعمال سے کس کو فائدہ ہوتا ہے؟
اگر آپ جدید سرور سافٹ ویئر تیار کرتے ہیں، تو آپ اپنی ٹیم کا ایک گروپ کے طور پر تقریباً تصور کر سکتے ہیں۔ سروس کے مالکانجو ایک ساتھ مل کر کاروباری منطق کو تیار اور نافذ کرتے ہیں، اور پلیٹ فارم کے مالکانداخلی پلیٹ فارم کی ترقی میں شامل ہے جس پر یہ خدمات چلتی ہیں۔ چھوٹی تنظیموں میں، یہ وہی لوگ ہو سکتے ہیں، لیکن جیسے جیسے کمپنی بڑھتی ہے، یہ کردار زیادہ واضح ہوتے جاتے ہیں اور یہاں تک کہ ذیلی کرداروں میں تقسیم ہو جاتے ہیں... مائیکرو سروسز وغیرہ کے تنظیمی اثرات) n. لیکن فی الحال، آئیے ان وضاحتوں کو قدرے مان لیتے ہیں)۔
اس نقطہ نظر سے، سروس میش کے واضح فائدہ اٹھانے والے پلیٹ فارم کے مالک ہیں۔ بہر حال، پلیٹ فارم ٹیم کا حتمی مقصد ایک داخلی پلیٹ فارم بنانا ہے جس پر سروس مالکان کاروباری منطق کو لاگو کر سکیں اور اسے اس طریقے سے کر سکیں جو اس کے آپریشن کی سنگین تفصیلات سے ان کی زیادہ سے زیادہ آزادی کی ضمانت دیتا ہو۔ سروس میش نہ صرف اس مقصد کو حاصل کرنے کے لیے اہم صلاحیتوں کو پیش کرتا ہے، بلکہ یہ اس طرح کرتا ہے کہ اس کے نتیجے میں، سروس مالکان پر کوئی انحصار نہیں ہوتا ہے۔
سروس مالکان بھی فائدہ اٹھاتے ہیں، اگرچہ زیادہ بالواسطہ طریقے سے۔ سروس کے مالک کا مقصد کاروباری عمل کی منطق کو لاگو کرنے میں زیادہ سے زیادہ نتیجہ خیز ہونا ہے، اور اسے آپریشنل مسائل کے بارے میں جتنا کم فکر کرنا پڑے گا، اتنا ہی بہتر ہے۔ پالیسیوں یا TLS کو نافذ کرنے کے بجائے، وہ مکمل طور پر کاروبار پر توجہ مرکوز کر سکتے ہیں اور امید کرتے ہیں کہ پلیٹ فارم باقی چیزوں کا خیال رکھے گا۔ ان کے لیے یہ ایک بڑا فائدہ ہے۔
پلیٹ فارمز اور خدمات کے مالکان کے درمیان اس طرح کی تقسیم کی تنظیمی قدر کو زیادہ نہیں سمجھا جا سکتا۔ مجھے لگتا ہے کہ وہ حصہ ڈالتی ہے۔ اہم سروس میش کی قدر میں شراکت۔
ہم نے یہ سبق اس وقت سیکھا جب لنکرڈ کے ایک ابتدائی پرستار نے ہمیں بتایا کہ انہوں نے سروس میش کا انتخاب کیوں کیا: کیونکہ اس نے انہیں "کم سے کم بات کرتے رہنے" کی اجازت دی۔ یہاں کچھ تفصیلات ہیں: ایک بڑی کمپنی کے لڑکوں نے اپنا پلیٹ فارم Kubernetes میں منتقل کیا۔ چونکہ ایپلیکیشن نے حساس معلومات کے ساتھ کام کیا، اس لیے وہ کلسٹرز میں موجود تمام مواصلات کو خفیہ کرنا چاہتے تھے۔ تاہم، سینکڑوں سروسز اور سینکڑوں ترقیاتی ٹیموں کی موجودگی کی وجہ سے صورتحال پیچیدہ تھی۔ سب سے رابطہ کرنے اور انہیں اپنے منصوبوں میں TLS کے لیے تعاون شامل کرنے کے لیے راضی کرنے کا امکان انہیں بالکل بھی خوش نہیں کرتا تھا۔ Linkerd انسٹال کرکے، انہوں نے ہجرت کی۔ ذمہ داری ڈویلپرز (جن کے نقطہ نظر سے یہ غیر ضروری پریشانی تھی) سے پلیٹ فارمرز تک، جن کے لیے یہ ایک اعلیٰ سطحی ترجیح تھی۔ دوسرے لفظوں میں، Linkerd ان کے لیے اتنا تکنیکی مسئلہ نہیں حل کر رہا تھا جتنا کہ ایک تنظیمی مسئلہ۔
مختصر میں، سروس میش، بلکہ، ایک تکنیکی حل نہیں ہے، لیکن سماجی تکنیکی مسائل. (شکریہ اس اصطلاح کو متعارف کرانے کے لیے۔
کیا سروس میش میرے تمام مسائل حل کردے گا؟
جی ہاں. میرا مطلب ہے، نہیں!
اوپر بیان کردہ خصوصیات کی تین کلاسوں کو دیکھ کر - وشوسنییتا، سیکورٹی، اور مشاہداتی - یہ واضح ہو جاتا ہے کہ سروس میش ان مسائل میں سے کسی کا مکمل حل نہیں ہے۔ اگرچہ Linkerd بار بار درخواستیں بھیج سکتا ہے (اگر یہ جانتا ہے کہ وہ بے ضمیر ہیں)، یہ اس پوزیشن میں نہیں ہے کہ صارف کو واپس کیا جائے اگر سروس آخر کار بند ہو گئی ہے - ایسے فیصلے درخواست کے ذریعے کیے جانے چاہییں۔ Linkerd کامیاب درخواستوں کے اعداد و شمار رکھ سکتا ہے، لیکن یہ سروس کو دیکھنے اور اس کے اندرونی میٹرکس فراہم کرنے کے قابل نہیں ہے - ایک درخواست میں ایسی ٹول کٹ ہونی چاہیے۔ اور جب کہ Linkerd mTLS کی میزبانی کرنے کے قابل ہے، مکمل حفاظتی حل کے لیے بہت کچھ درکار ہے۔
سروس میش کے ذریعہ پیش کردہ ان علاقوں میں خصوصیات کا ایک ذیلی سیٹ سے متعلق ہے۔ پلیٹ فارم کی خصوصیات. اس سے میرا مطلب ہے افعال جو:
- کاروباری منطق سے آزاد. Foo اور بار کے درمیان جس طرح سے کال ہسٹوگرام بنائے جاتے ہیں وہ اس بات سے مکمل طور پر آزاد ہے کہ آیا کیوں فو کو بار کہتے ہیں۔
- صحیح طریقے سے نافذ کرنا مشکل ہے۔. Linkerd میں، دوبارہ کوششوں کو ہر طرح کی فینسی چیزوں کے ساتھ پیرامیٹرائز کیا جاتا ہے جیسے دوبارہ کوشش کرنے والے بجٹ۔ (بجٹ کی دوبارہ کوشش کریں)چونکہ اس طرح کی چیزوں پر عمل درآمد کے لیے ایک سادہ طرز عمل یقیناً نام نہاد "درخواستوں کے برفانی تودے" کے ظہور کا باعث بنے گا۔ (طوفان کی دوبارہ کوشش کریں) اور تقسیم شدہ نظاموں کے لیے مخصوص دیگر مسائل۔
- مسلسل لاگو ہونے پر سب سے زیادہ مؤثر. TLS میکانزم صرف اس صورت میں معنی رکھتا ہے جب ہر جگہ لاگو ہو۔
چونکہ یہ خصوصیات پراکسی پرت پر لاگو ہوتی ہیں (اور ایپلیکیشن لیئر پر نہیں)، سروس میش انہیں پلیٹ فارم، درخواستیں نہیں۔ اس طرح، اس سے کوئی فرق نہیں پڑتا کہ خدمات کس زبان میں لکھی جاتی ہیں، وہ کون سا فریم ورک استعمال کرتی ہیں، انہیں کس نے لکھا اور کیوں لکھا۔ پراکسی ان تمام تفصیلات سے ہٹ کر کام کرتی ہیں، اور اس فعالیت کی بنیادی بنیاد، بشمول ترتیب، اپ ڈیٹ، آپریٹنگ، برقرار رکھنے، وغیرہ کے کام مکمل طور پر پلیٹ فارم کی سطح پر ہیں۔
سروس میش صلاحیتوں کی مثالیں۔
خلاصہ طور پر، سروس میش قابل اعتماد، مشاہداتی، یا سیکورٹی کے لئے ایک مکمل حل نہیں ہے. ان شعبوں کا دائرہ خدمت کے مالکان، Ops/SRE ٹیموں اور کمپنی کے دیگر اسٹیک ہولڈرز کی لازمی شرکت کو ظاہر کرتا ہے۔ سروس میش ان علاقوں میں سے ہر ایک کے لیے پلیٹ فارم کی سطح پر صرف ایک "ٹکڑا" فراہم کرتا ہے۔
سروس میش ابھی کیوں مقبول ہو گیا ہے؟
آپ شاید ابھی سوچ رہے ہوں گے: ٹھیک ہے، اگر سروس میش اتنی اچھی ہے، تو ہم نے دس سال پہلے اسٹیک پر لاکھوں پراکسیوں کی تعیناتی کیوں شروع نہیں کی؟
اس سوال کا ایک سادہ سا جواب ہے: دس سال پہلے سب نے یک سنگی تعمیر کی تھی، اور کسی کو سروس میش کی ضرورت نہیں تھی۔ یہ سچ ہے، لیکن میری رائے میں، یہ جواب اس نکتے سے محروم ہے۔ یہاں تک کہ دس سال پہلے، بڑے پیمانے پر نظام بنانے کے لیے ایک امید افزا طریقہ کے طور پر مائیکرو سروسز کے تصور پر ٹویٹر، فیس بک، گوگل اور نیٹ فلکس جیسی کمپنیوں میں بڑے پیمانے پر بحث کی گئی اور اس کا اطلاق کیا گیا۔ عام تاثر - کم از کم انڈسٹری کے ان حصوں میں جن سے میرا رابطہ رہا ہے - یہ تھا کہ مائیکرو سروسز بڑے سسٹم بنانے کا "صحیح طریقہ" ہیں، چاہے یہ بہت مشکل کیوں نہ ہو۔
یقیناً، اگرچہ دس سال پہلے مائیکرو سروسز کا استحصال کرنے والی کمپنیاں تھیں، لیکن انہوں نے سروس میش بنانے کے لیے ہر جگہ پراکسی نہیں لگائی۔ تاہم، اگر آپ قریب سے دیکھیں، تو انھوں نے کچھ ایسا ہی کیا: ان میں سے بہت سی کمپنیوں نے نیٹ ورکنگ کے لیے ایک خصوصی اندرونی لائبریری کے استعمال کو لازمی قرار دیا ہے (جسے بعض اوقات موٹی کلائنٹ لائبریری بھی کہا جاتا ہے، موٹی کلائنٹ لائبریری).
Netflix میں Hysterix تھا، گوگل میں Stubby تھا، ٹویٹر کے پاس Finagle لائبریری تھی۔ مثال کے طور پر، ٹوئٹر پر ہر نئی سروس کے لیے Finagle کو لازمی قرار دیا گیا ہے۔ اس نے کنکشن کے کلائنٹ اور سرور دونوں کو ہینڈل کیا، بار بار درخواستوں کی اجازت دی گئی، درخواست کی حمایت کی روٹنگ، لوڈ بیلنسنگ، اور میٹرنگ۔ اس نے پورے ٹویٹر اسٹیک میں قابل اعتمادی اور مشاہدے کی ایک مستقل پرت فراہم کی، چاہے سروس کچھ بھی کر رہی ہو۔ بلاشبہ، یہ صرف JVM زبانوں کے لیے کام کرتا تھا اور ایک پروگرامنگ ماڈل پر مبنی تھا جسے پوری ایپلیکیشن کے لیے استعمال کرنا تھا۔ تاہم، اس کی فعالیت تقریباً سروس میش جیسی ہی تھی۔ (دراصل، Linkerd کا پہلا ورژن صرف Finagle پراکسی شکل میں لپٹا ہوا تھا۔)
اس طرح، دس سال پہلے نہ صرف مائیکرو سروسز، بلکہ خصوصی پروٹو سروس میش لائبریریاں بھی تھیں جو وہی مسائل حل کرتی تھیں جو آج سروس میش حل کرتی ہے۔ تاہم، سروس میش خود اس وقت موجود نہیں تھا. اس کے ظاہر ہونے سے پہلے ایک اور شفٹ ہونا تھا۔
اور یہ وہ جگہ ہے جہاں گہرا جواب پوشیدہ ہے، پچھلے 10 سالوں میں ہونے والی ایک اور تبدیلی میں چھپا ہوا ہے: مائیکرو سروسز کی تعیناتی کی لاگت میں زبردست کمی آئی ہے۔ مذکورہ کمپنیاں جو ایک دہائی قبل مائیکرو سروسز استعمال کرتی تھیں — ٹویٹر، نیٹ فلکس، فیس بک، گوگل — بڑے پیمانے پر اور بڑے وسائل کی کمپنیاں تھیں۔ ان کے پاس نہ صرف ضرورت تھی بلکہ مائیکرو سروسز پر مبنی بڑی ایپلی کیشنز بنانے، تعینات کرنے اور چلانے کی صلاحیت بھی تھی۔ ٹویٹر انجینئرز نے یک سنگی سے مائیکرو سروسز کے نقطہ نظر کی طرف جانے میں جو توانائی اور کوشش ڈالی ہے وہ حیرت انگیز ہے۔ (ایمانداری سے، جیسا کہ حقیقت یہ تھی کہ اس نے کام کیا۔) اس طرح کے بنیادی ڈھانچے کی تدبیریں اس وقت چھوٹی کمپنیوں کے لیے ناممکن تھیں۔
آئیے حال کی طرف چلتے ہیں۔ آج ایسے اسٹارٹ اپس ہیں جہاں مائیکرو سروسز کا ڈویلپرز کا تناسب 5:1 ہے (یا اس سے بھی )، اور اس کے علاوہ، وہ کامیابی سے ان کا مقابلہ کرتے ہیں! اگر 5 افراد پر مشتمل ایک سٹارٹ اپ 50 مائیکرو سروسز کو بغیر کسی دباؤ کے چلانے کے قابل ہے، تو کسی چیز نے ان کے نفاذ کی لاگت کو واضح طور پر کم کر دیا۔
مونزو میں 1500 مائیکرو سروسز؛ ہر لائن ایک مقررہ نیٹ ورک اصول ہے جو ٹریفک کی اجازت دیتا ہے۔
آپریٹنگ مائیکرو سروسز کی لاگت میں ڈرامائی کمی ایک ہی عمل کا نتیجہ ہے: کنٹینرز کی بڑھتی ہوئی مقبولیت и آرکیسٹریٹرز. یہ خاص طور پر اس سوال کا گہرا جواب ہے کہ سروس میش کے ظہور میں کیا کردار ہے۔ اسی ٹیکنالوجی نے سروس میش اور مائیکرو سروسز دونوں کو پرکشش بنایا: Kubernetes اور Docker۔
کیوں؟ ٹھیک ہے، ڈوکر ایک بڑا مسئلہ حل کرتا ہے - پیکیجنگ کا مسئلہ۔ کسی ایپلیکیشن اور اس کے (نان نیٹ ورک) رن ٹائم انحصار کو کنٹینر میں پیک کرکے، ڈوکر ایپلیکیشن کو ایک فنجیبل یونٹ میں بدل دیتا ہے جسے ہوسٹ کیا جا سکتا ہے اور کہیں بھی چلایا جا سکتا ہے۔ ایک ہی وقت میں، یہ آپریشن کو بہت آسان بناتا ہے. کثیر لسانی stack: چونکہ ایک کنٹینر عملدرآمد کی ایک ایٹمی اکائی ہے، اس سے کوئی فرق نہیں پڑتا کہ اندر کیا ہے، چاہے یہ JVM، Node، Go، Python، یا Ruby ایپلی کیشن ہو، تعیناتی اور آپریشنل مقاصد کے لیے۔ تم بس چلاؤ اور بس۔
Kubernetes ہر چیز کو اگلی سطح پر لے جاتا ہے۔ اب جب کہ "قابل عمل چیزوں" کا ایک گروپ ہے اور ان کو چلانے کے لیے بہت سی مشینیں ہیں، ایک ایسے آلے کی ضرورت ہے جو انہیں ایک دوسرے کے خلاف میچ کر سکے۔ وسیع معنوں میں، آپ Kubernetes کو بہت سے کنٹینرز اور بہت سی مشینیں دیتے ہیں، اور یہ ان کا ایک دوسرے سے میل کھاتا ہے (یقیناً، یہ ایک متحرک اور مسلسل بدلتا ہوا عمل ہے: نئے کنٹینرز سسٹم کے گرد گھومتے ہیں، مشینیں شروع ہوتی ہیں اور رک جاتی ہیں، وغیرہ۔ تاہم، Kubernetes اس سب کو مدنظر رکھتا ہے)۔
ایک بار جب Kubernetes سیٹ ہو جاتا ہے، تو ایک سروس کو تعینات کرنے اور چلانے میں جو وقت لگتا ہے وہ دس سروسز کو تعینات کرنے اور چلانے کی لاگت سے زیادہ مختلف نہیں ہوتا ہے (حقیقت میں، یہ تقریباً 100 سروسز کے لیے ایک جیسا ہے)۔ اس کنٹینرز میں ایک پیکیجنگ میکانزم کے طور پر شامل کریں جو کثیر لسانی نفاذ کی حوصلہ افزائی کرتا ہے، اور آپ کے پاس ایک سے زیادہ زبانوں میں لکھی گئی مائیکرو سروسز کے طور پر لاگو کی گئی نئی ایپلی کیشنز ہیں، بالکل اسی طرح کا ماحول جس کے لیے سروس میش بہت موزوں ہے۔
لہذا، ہم اس سوال کے جواب کی طرف آتے ہیں کہ سروس میش کا آئیڈیا اس وقت کیوں مقبول ہوا ہے: Kubernetes خدمات کے لیے جو یکسانیت فراہم کرتا ہے وہ براہ راست سروس میش کو درپیش آپریشنل کاموں پر لاگو ہوتا ہے۔ آپ کنٹینرز میں پراکسی پیک کرتے ہیں، کبرنیٹس کو جہاں بھی ممکن ہو انہیں چپکانے کا کام دیتے ہیں، اور وویلا! نتیجے کے طور پر، آپ کو ایک سروس میش ملتا ہے، جبکہ Kubernetes اس کی تعیناتی کے تمام میکانکس کو کنٹرول کرتا ہے۔ (کم از کم پرندوں کی نظر سے۔ یقینا، اس عمل میں بہت سی باریکیاں ہیں۔)
خلاصہ یہ کہ سروس میش کے اب مقبول ہونے کی وجہ دس سال پہلے نہیں بلکہ یہ ہے کہ کبرنیٹس اور ڈوکر نے نہ صرف نمایاں اضافہ کیا ضرورت اس میں، کثیر لسانی مائیکرو سروسز کے سیٹ کے طور پر ایپلی کیشنز کے نفاذ کو آسان بنانا، بلکہ نمایاں طور پر کم بھی اخراجات سائڈ کار پراکسی پارکس کی تعیناتی اور دیکھ بھال کے لیے میکانزم فراہم کرکے اس کے آپریشن کے لیے۔
سروس میش کے بارے میں اتنا چرچا کیوں ہے؟
انتباہ: اس حصے میں، میں ہر طرح کے مفروضوں، قیاس آرائیوں، من گھڑت اور اندرونی معلومات کا سہارا لیتا ہوں۔
"سروس میش" کو تلاش کرنے سے ری سائیکل شدہ، کم کیلوری والے مواد، عجیب و غریب پروجیکٹس، اور ایکو چیمبر کے لائق تحریف کا کلیڈوسکوپ سامنے آجائے گا۔ کسی بھی جدید نئی ٹیکنالوجی میں یہ ہے، لیکن سروس میش کے معاملے میں، مسئلہ خاص طور پر شدید ہے. کیوں؟
ٹھیک ہے، یہ جزوی طور پر میری غلطی ہے. میں نے ہر موقع پر Linkerd اور سروس میش کو فروغ دینے کی پوری کوشش کی ہے، اس طرح کے لاتعداد بلاگ پوسٹس اور مضامین کے ذریعے۔ لیکن میں اتنا طاقتور نہیں ہوں۔ واقعی اس سوال کا جواب دینے کے لیے، ہمیں عمومی صورت حال کے بارے میں تھوڑی بات کرنے کی ضرورت ہے۔ اور ایک منصوبے کا ذکر کیے بغیر اس کے بارے میں بات کرنا ناممکن ہے: ایک اوپن سورس سروس میش ہے جسے گوگل، آئی بی ایم اور لیفٹ نے مشترکہ طور پر تیار کیا ہے۔
(ان تینوں کمپنیوں کے بہت مختلف کردار ہیں: لیفٹ کی شمولیت صرف نام تک محدود دکھائی دیتی ہے؛ وہ ایلچی لکھتی ہیں لیکن استعمال نہیں کرتی ہیں یا اسٹیو کی ترقی میں شامل ہیں۔ IBM اسٹیو کی ترقی میں شامل ہے اور اسے استعمال کرتا ہے۔ گوگل بہت زیادہ ہے۔ Istio کی ترقی میں ملوث ہے، لیکن جہاں تک میں بتا سکتا ہوں، اصل میں اسے استعمال نہیں کرتا ہے۔)
اسٹیو پروجیکٹ دو چیزوں کے لیے قابل ذکر ہے۔ سب سے پہلے، یہ بہت بڑی مارکیٹنگ کی کوشش ہے جسے گوگل، خاص طور پر، اس کی تشہیر میں لگاتا ہے۔ میرا اندازہ ہے کہ سروس میش کے تصور سے واقف زیادہ تر لوگ سب سے پہلے اسٹیو کی بدولت اس کے بارے میں سیکھ چکے ہیں۔ دوسری خصوصیت یہ ہے کہ اسٹیو کو کتنی بری طرح سے موصول ہوا۔ اس معاملے میں، میں، ظاہر ہے، ایک دلچسپی رکھنے والا فریق ہوں، لیکن ہر ممکن حد تک مقصد پر رہنے کی کوشش کرتا ہوں، میں پھر بھی مدد نہیں کرسکتا لیکن ، بہت مخصوص نہیں (اگرچہ منفرد نہیں: systemd ذہن میں آتا ہے، ...) ایک اوپن سورس پروجیکٹ کے لیے۔
(عملی طور پر، ایسا لگتا ہے کہ اسٹیو کو نہ صرف پیچیدگی اور UX، بلکہ کارکردگی کے ساتھ بھی مسائل ہیں۔ تیسرے فریق کے ذریعہ کئے گئے، ماہرین نے ایسے حالات پائے جن میں اسٹیو کی ٹیل لیٹینسی Linkerd کے مقابلے میں 100 گنا زیادہ تھی، اور ساتھ ہی وسائل کی کمی کے ساتھ حالات، جب Linkerd کامیابی سے کام کرتا رہا، اور Istio نے مکمل طور پر کام کرنا چھوڑ دیا۔)
ایسا کیوں ہوا اس بارے میں اپنے نظریات کو ایک طرف رکھتے ہوئے، مجھے یقین ہے کہ سروس میش کے ارد گرد آف سکیل ہائپ گوگل کی شمولیت کی وجہ سے ہے۔ یعنی درج ذیل تین عوامل کا مجموعہ:
- گوگل کی طرف سے Istio کی جنونی فروغ؛
- مناسب نامنظور، منصوبے کے بارے میں تنقیدی رویہ؛
- Kubernetes کی حالیہ آسمان چھوتی مقبولیت، جس کی یاد ابھی تک تازہ ہے۔
یہ عوامل ایک ساتھ مل کر ایک طرح کے نشہ آور، غیر زہریلا ماحول میں مل جاتے ہیں جس میں عقلی فیصلے کی صلاحیت کمزور پڑ جاتی ہے، اور صرف ایک شاندار قسم باقی رہ جاتی ہے۔ .
لنکرڈ کے نقطہ نظر سے، یہ ہے… میں اسے ایک ملی جلی نعمت کے طور پر بیان کروں گا۔ میرا مطلب ہے، یہ بہت اچھا ہے کہ سروس میش مرکزی دھارے میں داخل ہو گیا ہے - جو کہ 2016 میں ایسا نہیں تھا جب Linkerd پہلی بار ظاہر ہوا تھا اور اس منصوبے پر لوگوں کی توجہ حاصل کرنا واقعی مشکل تھا۔ اب ایسا کوئی مسئلہ نہیں ہے! لیکن بری خبر یہ ہے کہ آج سروس میش کی صورتحال اتنی الجھی ہوئی ہے کہ یہ جاننا تقریباً ناممکن ہے کہ کون سے پروجیکٹس واقعی سروس میش کے زمرے میں آتے ہیں (یہ معلوم کرنے دیں کہ کسی خاص استعمال کے معاملے کے لیے کون سا بہترین ہے)۔ یہ یقینی طور پر ہر ایک کے راستے میں آجاتا ہے (اور یقینی طور پر کچھ معاملات میں اسٹیو یا کوئی اور پروجیکٹ Linkerd سے بہتر ہے، کیونکہ مؤخر الذکر ایک سائز میں فٹ ہونے والا حل نہیں ہے)۔
Linkerd کی طرف سے، ہماری حکمت عملی شور کو نظر انداز کرنے، کمیونٹی میں حقیقی مسائل کو حل کرنے پر توجہ مرکوز کرنا، اور بنیادی طور پر ہائپ کے کم ہونے کا انتظار کرنا ہے۔ آخر کار ہائپ کم ہو جائے گا اور ہم امن کے ساتھ کام جاری رکھ سکتے ہیں۔
تب تک ہم سب کو صبر کرنا پڑے گا۔
کیا سروس میش میرے لیے مفید ہو گی، ایک معمولی سافٹ ویئر انجینئر؟
درج ذیل سوالنامہ اس سوال کے جواب میں مدد کرے گا:
کیا آپ کاروباری منطق کے نفاذ کے ساتھ خصوصی طور پر کام کرتے ہیں؟ اس صورت میں، سروس میش آپ کے لئے مفید نہیں ہو گا. یہ یقیناً آپ کو اس میں دلچسپی ہو سکتی ہے، لیکن مثالی طور پر، سروس میش کو آپ کے ماحول میں کسی بھی چیز کو براہ راست متاثر نہیں کرنا چاہیے۔ آپ کو جس چیز کی ادائیگی کی جاتی ہے اس پر کام کرتے رہیں۔
کیا آپ کسی کمپنی میں پلیٹ فارم کو برقرار رکھتے ہیں جو Kubernetes استعمال کرتی ہے؟ ہاں، اس معاملے میں آپ کو سروس میش کی ضرورت ہے (یقیناً، اگر آپ K8s کا استعمال صرف یک سنگی یا بیچ پروسیسنگ کے لیے نہیں کر رہے ہیں - لیکن پھر میں پوچھنا چاہوں گا کہ آپ کو K8s کی ضرورت کیوں ہے)۔ زیادہ تر امکان ہے کہ، آپ خود کو ایسی صورتحال میں پائیں گے جس میں مختلف لوگوں کے لکھے ہوئے بہت سے مائیکرو سروسز ہیں۔ وہ سب ایک دوسرے کے ساتھ تعامل کرتے ہیں اور رن ٹائم انحصار کے ایک الجھ سے بندھے ہوئے ہیں، اور آپ کو ان سب سے نمٹنے کے لیے کوئی راستہ تلاش کرنے کی ضرورت ہے۔ Kubernetes کا استعمال آپ کو "اپنے لئے" سروس میش کا انتخاب کرنے کی اجازت دیتا ہے۔ ایسا کرنے کے لیے، ان کی صلاحیتوں اور خصوصیات سے اپنے آپ کو آشنا کریں اور اس سوال کا جواب دیں کہ آیا دستیاب پروجیکٹس میں سے کوئی آپ کے لیے بالکل مناسب ہے یا نہیں (میں تجویز کرتا ہوں کہ لنکرڈ کے ساتھ اپنی تحقیق شروع کریں)۔
کیا آپ ایسی کمپنی کے لیے پلیٹ فارم چلا رہے ہیں جو Kubernetes استعمال نہیں کرتی بلکہ مائیکرو سروسز استعمال کرتی ہے؟ اس صورت میں، سروس میش آپ کے لئے مفید ہو گا، لیکن اس کا استعمال غیر معمولی ہو گا. یقیناً آپ کر سکتے ہیں۔ نقل کرنا پراکسیوں کے ایک گروپ کی میزبانی کرکے سروس میش، لیکن Kubernetes کا ایک اہم فائدہ قطعی طور پر تعیناتی ماڈل ہے: ان پراکسیوں کو دستی طور پر برقرار رکھنے کے لیے بہت زیادہ وقت، محنت اور لاگت درکار ہوگی۔
کیا آپ کسی کمپنی میں پلیٹ فارم کے انچارج ہیں جو یک سنگی کے ساتھ کام کرتی ہے؟ اس صورت میں، آپ کو شاید سروس میش کی ضرورت نہیں ہے۔ اگر آپ یک سنگی (یا یہاں تک کہ یک سنگی کے سیٹ) کے ساتھ کام کر رہے ہیں جو اچھی طرح سے متعین اور شاذ و نادر ہی تعامل کے نمونوں کو تبدیل کرتے ہیں، تو سروس میش آپ کو پیش کرنے کے لیے بہت کم ہے۔ لہذا آپ اسے نظر انداز کر سکتے ہیں اور امید کرتے ہیں کہ یہ ایک برے خواب کی طرح غائب ہو جائے گا...
حاصل يہ ہوا
شاید، سروس میش کو اب بھی "دنیا کی سب سے زیادہ ہائپڈ ٹیکنالوجی" نہیں کہا جانا چاہئے - یہ مشکوک اعزاز شاید بٹ کوائن یا AI کا ہے۔ شاید وہ ٹاپ فائیو میں ہے۔ لیکن اگر آپ شور و غل کی تہوں کو توڑتے ہیں، تو یہ واضح ہو جاتا ہے کہ سروس میش ان لوگوں کو حقیقی فائدے پہنچاتی ہے جو کبرنیٹس میں ایپلی کیشنز بناتے ہیں۔
میں چاہتا ہوں کہ آپ Linkerd کو آزمائیں - اسے Kubernetes کلسٹر میں انسٹال کرنا (یا یہاں تک کہ ایک لیپ ٹاپ پر Minikube) اور آپ خود دیکھ سکتے ہیں کہ میں کس کے بارے میں بات کر رہا ہوں۔
اکثر پوچھے جانے والے سوالات
- اگر میں سروس میش کو نظر انداز کرتا ہوں تو کیا یہ غائب ہو جائے گا؟
- مجھے آپ کو مایوس کرنا ہوگا: سروس میش طویل عرصے سے ہمارے ساتھ ہے۔
لیکن میں سروس میش استعمال نہیں کرنا چاہتا!
- ٹھیک ہے، یہ ضروری نہیں ہے! یہ دیکھنے کے لیے کہ کیا آپ کو کم از کم اس کی بنیادی باتوں سے خود کو واقف کرانا چاہیے، بس اوپر میرا سوالنامہ پڑھیں۔
— کیا یہ ایک نئی چٹنی کے ساتھ اچھا پرانا ESB/مڈل ویئر نہیں ہے؟
- سروس میش آپریشنل منطق سے متعلق ہے، سیمنٹک نہیں۔ انٹرپرائز سروس بس ()۔ اس علیحدگی کو برقرار رکھنے سے سروس میش کو اسی قسمت سے بچنے میں مدد ملتی ہے۔
- سروس میش API گیٹ ویز سے کیسے مختلف ہے؟
اس موضوع پر ایک ملین مضامین ہیں۔ بس گوگل کریں۔
کیا ایلچی ایک سروس میش ہے؟
- نہیں، ایلچی کوئی سروس میش نہیں ہے، یہ ایک پراکسی سرور ہے۔ اسے سروس میش کو منظم کرنے کے لیے استعمال کیا جا سکتا ہے (اور بہت کچھ - یہ ایک عام مقصد کی پراکسی ہے)۔ لیکن بذات خود، یہ سروس میش نہیں ہے۔
- نیٹ ورک سروس میش - کیا یہ سروس میش ہے؟
- نہیں. نام کے باوجود، یہ سروس میش نہیں ہے (آپ کو مارکیٹنگ کے کمالات کیسے پسند ہیں؟)۔
- کیا سروس میش پیغام کی قطار کی بنیاد پر میرے رد عمل والے غیر مطابقت پذیر نظام میں مدد کرے گی؟
- نہیں، سروس میش آپ کی مدد نہیں کرے گی۔
- مجھے کون سا سروس میش استعمال کرنا چاہئے؟
- ، کوئی رکاوٹ نہیں.
- مضمون بیکار ہے! / مصنف - صابن پر!
- براہ کرم اس کا لنک اپنے تمام دوستوں کے ساتھ شیئر کریں تاکہ وہ اس بات پر قائل ہو سکیں!
اعترافات
جیسا کہ آپ عنوان سے اندازہ لگا سکتے ہیں، یہ مضمون جے کریپس کے لاجواب مقالے سے متاثر ہوا تھا۔" میں جے سے دس سال پہلے لنکڈ اِن پر ایک انٹرویو کے دوران ملا تھا اور تب سے وہ میرے لیے ایک تحریک ہے۔
جب کہ میں اپنے آپ کو "Linkerd ڈویلپر" کہنا پسند کرتا ہوں، حقیقت یہ ہے کہ میں ایک پروجیکٹ میں README.md فائل کا زیادہ مینٹینر ہوں۔ Linkerd پر آج کام کر رہے ہیں۔ , , لوگ، اور یہ پروجیکٹ شراکت داروں اور صارفین کی حیرت انگیز کمیونٹی کے بغیر ممکن نہیں تھا۔
اور آخر میں، Linkerd کے خالق کا خصوصی شکریہ، (پرائمس انٹر پیرس), جنہوں نے کئی سال پہلے میرے ساتھ مل کر سروس میش کے ساتھ اس سارے ہنگامے میں سر جھکا دیا تھا۔
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com