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