ایسا لگتا ہے کہ مائیکرو سروسز کے لیے ہائپ کی چوٹی ہمارے پیچھے ہے۔ اب ہم ہفتے میں کئی بار پوسٹس نہیں پڑھتے ہیں "کیسے میں نے اپنے یک سنگی کو 150 سروسز میں منتقل کیا۔" اب میں زیادہ عام فہم خیالات سنتا ہوں: "میں یک سنگی سے نفرت نہیں کرتا، مجھے صرف کارکردگی کی پرواہ ہے۔" یہاں تک کہ ہم نے متعدد نقل مکانی کا مشاہدہ کیا۔ . ایک بڑی ایپلیکیشن سے متعدد چھوٹی سروسز میں منتقل ہونے پر، آپ کو کئی نئے مسائل حل کرنے ہوں گے۔ آئیے جتنا ممکن ہو ان کی مختصر فہرست بنائیں۔
ترتیب: بنیادی کیمسٹری سے کوانٹم میکینکس تک
بیک گراؤنڈ پروسیس کے ساتھ ایک بنیادی ڈیٹا بیس اور ایپلیکیشن ترتیب دینا کافی سیدھا عمل تھا۔ میں گیتھب پر ریڈمی شائع کرتا ہوں - اور اکثر ایک گھنٹے کے بعد، زیادہ سے زیادہ دو گھنٹے، سب کچھ کام کرتا ہے، اور میں ایک نیا پروجیکٹ شروع کرتا ہوں۔ کوڈ شامل کرنا اور چلانا، کم از کم ابتدائی ماحول کے لیے، پہلے دن کیا جاتا ہے۔ لیکن اگر ہم مائیکرو سروسز میں قدم رکھتے ہیں تو ابتدائی لانچ کا وقت آسمان کو چھوتا ہے۔ ہاں، اب ہمارے پاس آرکیسٹریشن کے ساتھ ڈوکر اور K8 مشینوں کا ایک کلسٹر ہے، لیکن ایک نوسکھئیے پروگرامر کے لیے یہ سب کچھ زیادہ پیچیدہ ہے۔ بہت سے جونیئرز کے لیے، یہ ایک ایسا بوجھ ہے جو واقعی ایک غیر ضروری پیچیدگی ہے۔
نظام کو سمجھنا آسان نہیں ہے۔
آئیے ایک لمحے کے لیے اپنے جونیئر پر توجہ مرکوز کریں۔ یک سنگی ایپلی کیشنز کے ساتھ، اگر کوئی خرابی واقع ہو جاتی ہے، تو اسے ٹریک کرنا اور فوری طور پر ڈیبگنگ پر جانا آسان تھا۔ اب ہمارے پاس ایک سروس ہے جو کسی دوسری سروس سے بات کر رہی ہے جو ایک میسج بس پر کچھ قطار میں کھڑی ہے جو دوسری سروس پر کارروائی کر رہی ہے - اور پھر ایک خرابی پیدا ہو جاتی ہے۔ ہمیں آخر کار یہ معلوم کرنے کے لیے ان تمام ٹکڑوں کو ایک ساتھ رکھنا ہوگا کہ سروس A ورژن 11 چلا رہا ہے، اور سروس E پہلے ہی ورژن 12 کا انتظار کر رہی ہے۔ یہ میرے معیاری کنسولیڈیٹڈ لاگ سے بہت مختلف ہے: چلنے کے لیے ایک انٹرایکٹو ٹرمینل/ڈیبگر استعمال کرنا پڑتا ہے۔ مرحلہ وار عمل کے ذریعے۔ ڈیبگنگ اور سمجھنا فطری طور پر زیادہ مشکل ہو گیا ہے۔
اگر اسے ڈیبگ نہیں کیا جا سکتا ہے، تو شاید ہم ان کی جانچ کریں گے۔
مسلسل انضمام اور مسلسل ترقی اب عام ہوتی جا رہی ہے۔ زیادہ تر نئی ایپس جو میں دیکھتا ہوں کہ ہر نئی ریلیز کے ساتھ خود بخود ٹیسٹ بناتے اور چلاتے ہیں اور رجسٹریشن سے پہلے ٹیسٹ لینے اور ان کا جائزہ لینے کی ضرورت ہوتی ہے۔ یہ عظیم عمل ہیں جنہیں ترک نہیں کیا جانا چاہیے اور یہ بہت سی کمپنیوں کے لیے ایک بڑی تبدیلی ہے۔ لیکن اب، واقعی خدمت کی جانچ کرنے کے لیے، مجھے اپنی درخواست کا مکمل ورکنگ ورژن تیار کرنا ہوگا۔ 8 سروسز کے K150 کلسٹر کے ساتھ وہ نیا انجینئر یاد ہے؟ ٹھیک ہے، اب ہم اپنے CI سسٹم کو سکھائیں گے کہ ان تمام سسٹمز کو کیسے لایا جائے تاکہ اس بات کی تصدیق کی جا سکے کہ سب کچھ واقعی کام کرتا ہے۔ یہ شاید بہت زیادہ کوشش ہے، لہذا ہم صرف ہر ایک حصے کو تنہائی میں جانچیں گے: مجھے یقین ہے کہ ہمارے چشمی کافی اچھے ہیں، APIs صاف ہیں، اور سروس کی ناکامی الگ تھلگ ہے اور دوسروں کو متاثر نہیں کرے گی۔
تمام سمجھوتوں کی ایک اچھی وجہ ہوتی ہے۔ ٹھیک ہے؟
مائیکرو سروسز میں جانے کی بہت سی وجوہات ہیں۔ میں نے اسے زیادہ لچک، اسکیلنگ ٹیموں، کارکردگی، بہتر پائیداری فراہم کرنے کے لیے کیا ہوا دیکھا ہے۔ لیکن حقیقت میں، ہم نے کئی دہائیوں سے ایسے آلات اور طریقوں میں سرمایہ کاری کی ہے جو یک سنگی تیار کرنے کے لیے تیار ہوتے رہتے ہیں۔ میں مختلف ٹیکنالوجیز میں پیشہ ور افراد کے ساتھ کام کرتا ہوں۔ ہم عام طور پر اسکیلنگ کے بارے میں بات کرتے ہیں کیونکہ وہ ایک پوسٹگریس ڈیٹا بیس نوڈ کی حدود میں چلتے ہیں۔ زیادہ تر گفتگو اس بارے میں ہوتی ہے۔ .
لیکن میں ہمیشہ ان کے فن تعمیر کے بارے میں جاننے میں دلچسپی رکھتا ہوں۔ وہ مائیکرو سروسز میں منتقلی کے کس مرحلے پر ہیں؟ مزید انجینئرز کو یہ کہتے ہوئے دیکھنا دلچسپ ہے کہ وہ اپنے یک سنگی استعمال سے خوش ہیں۔ بہت سے لوگ مائیکرو سروسز سے مستفید ہوں گے، اور فوائد ہجرت کے راستے میں آنے والی رکاوٹوں سے کہیں زیادہ ہوں گے۔ لیکن ذاتی طور پر، براہ کرم مجھے میری یک سنگی درخواست، ساحل سمندر پر ایک جگہ دیں - اور میں پوری طرح خوش ہوں۔
ماخذ: www.habr.com