مائیکرو سروسز: وہ کیا ہیں، کیوں ہیں اور انہیں کب نافذ کرنا ہے۔

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

کانوے کا قانون اور کاروبار، تنظیم اور معلوماتی نظام کے درمیان تعلق

ایک بار پھر میں اپنے آپ کو حوالہ دینے کی اجازت دوں گا:

"کوئی بھی تنظیم جو نظام کو ڈیزائن کرتی ہے (وسیع معنوں میں) ایک ایسا ڈیزائن حاصل کرے گا جس کا ڈھانچہ اس تنظیم میں ٹیموں کے ڈھانچے کو نقل کرتا ہے۔"
میلوین کونوے، 1967

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

انفارمیشن سسٹم کی کاروباری واقفیت

میں ایک مثال سے سمجھاتا ہوں۔ ہم کہتے ہیں کہ پیزا فروخت کرنے والے کاروبار کو منظم کرنے کا ایک کاروباری موقع ہے۔ V1 ورژن میں (آئیے اسے پری انفارمیشن کہتے ہیں)، کمپنی ایک پزیریا، ایک کیش رجسٹر، اور ڈیلیوری سروس تھی۔ یہ ورژن کم ماحولیاتی تغیر کے حالات میں طویل عرصے تک زندہ رہا۔ پھر ورژن 2 اسے تبدیل کرنے کے لیے آیا - زیادہ جدید اور ایک یک سنگی فن تعمیر کے ساتھ کاروبار کے لیے معلوماتی نظام کو استعمال کرنے کے قابل۔ اور یہاں، میری رائے میں، یکجہتی کے سلسلے میں صرف ایک خوفناک ناانصافی ہے - مبینہ طور پر یک سنگی فن تعمیر ڈومین بزنس ماڈل سے مطابقت نہیں رکھتا. ہاں، اگر ایسا ہوتا تو یہ نظام بالکل کام نہیں کر سکے گا - اسی کانوے کے قانون اور عقل کے خلاف۔ نہیں۔ یہ بالکل حیرت انگیز حقیقت ہے کہ تعمیراتی نقطہ نظر سے قطع نظر، سروس پر مبنی آرکیٹیکچر ورژن 3 اور مائیکرو سروسز آرکیٹیکچر ورژن N دونوں یکساں طور پر کام کریں گے۔ کیچ کیا ہے؟

سب کچھ بہتا ہے، سب کچھ بدل جاتا ہے، یا کیا مائیکرو سروسز پیچیدگی سے نمٹنے کا ذریعہ ہیں؟

اس سے پہلے کہ ہم جاری رکھیں، آئیے مائیکرو سروس فن تعمیر کے بارے میں کچھ غلط فہمیوں کو دیکھتے ہیں۔

مائیکرو سرویس اپروچ استعمال کرنے کے حامی اکثر یہ بحث کرتے ہیں کہ مائیکرو سروسز میں یک سنگی کو توڑنا انفرادی خدمات کے کوڈ بیس کو کم کرکے ترقیاتی طریقہ کار کو آسان بناتا ہے۔ میرے خیال میں یہ بیان مکمل بکواس ہے۔ سنجیدگی سے، یک سنگی اور یکساں کوڈ کے اندر واضح تعامل پیچیدہ لگتا ہے؟ اگر واقعی ایسا ہوتا تو، تمام پروجیکٹ ابتدائی طور پر مائیکرو سروسز کے طور پر بنائے جائیں گے، جبکہ پریکٹس سے پتہ چلتا ہے کہ یک سنگی سے مائیکرو سروسز میں منتقلی بہت زیادہ عام ہے۔ پیچیدگی دور نہیں ہوتی؛ یہ صرف انفرادی ماڈیولز سے انٹرفیسز (چاہے ڈیٹا بسیں، RPC، APIs، یا دیگر پروٹوکولز) اور آرکیسٹریٹنگ سسٹمز میں منتقل ہوتی ہیں۔ اور یہ مشکل ہے!

متفاوت اسٹیک استعمال کرنے کا فائدہ بھی قابل اعتراض ہے۔ میں یہ بحث نہیں کروں گا کہ یہ بھی ممکن ہے، لیکن حقیقت میں یہ شاذ و نادر ہی ہوتا ہے (آگے دیکھنا - ایسا ہونا چاہئے - بلکہ فائدہ کے بجائے نتیجہ کے طور پر)۔

پروڈکٹ لائف سائیکل اور سروس لائف سائیکل

اوپر دیے گئے خاکے پر ایک اور نظر ڈالیں۔ یہ کوئی اتفاق نہیں ہے کہ میں نے کاروبار کے ایک الگ ورژن کے گھٹتے ہوئے زندگی کے چکر کو نوٹ کیا - جدید حالات میں، یہ ورژن کے درمیان کاروبار کی منتقلی کی رفتار ہے جو اس کی کامیابی کے لیے فیصلہ کن ہے۔ کسی پروڈکٹ کی کامیابی کا تعین اس میں کاروباری مفروضوں کی جانچ کی رفتار سے ہوتا ہے۔. اور یہاں، میری رائے میں، مائیکرو سروس فن تعمیر کا کلیدی فائدہ ہے۔ لیکن آئیے ترتیب سے چلتے ہیں۔

آئیے انفارمیشن سسٹمز کے ارتقاء کے اگلے مرحلے پر چلتے ہیں - SOA کے سروس پر مبنی فن تعمیر کی طرف۔ لہذا، کسی خاص نقطہ پر ہم نے اپنی مصنوعات میں روشنی ڈالی دیرپا خدمات - طویل عرصے تک اس معنی میں کہ جب کسی پروڈکٹ کے ورژن کے درمیان منتقل ہوتا ہے، تو اس بات کا امکان ہوتا ہے کہ سروس کا لائف سائیکل پروڈکٹ کے اگلے ورژن کے لائف سائیکل سے زیادہ طویل ہو۔ یہ منطقی ہو گا کہ انہیں بالکل تبدیل نہ کیا جائے - ہم اہم بات اگلے ورژن میں منتقلی کی رفتار ہے۔. لیکن افسوس، ہم سروسز میں مسلسل تبدیلیاں کرنے پر مجبور ہیں - اور یہاں سب کچھ ہمارے لیے کام کرتا ہے، DevOps پریکٹس، کنٹینرائزیشن، اور اسی طرح - ہر وہ چیز جو ذہن میں آتی ہے۔ لیکن یہ اب بھی مائیکرو سروسز نہیں ہیں!

پیچیدگی سے نمٹنے کے لیے مائیکرو سروسز... کنفیگریشن مینجمنٹ

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

نتائج

• نظام کے فن تعمیر کا تعین اس کے اجزاء کے لائف سائیکل سے کیا جانا چاہیے۔ اگر کوئی جزو پروڈکٹ ورژن کے اندر رہتا ہے، تو مائیکرو سروس اپروچ استعمال کرکے سسٹم کی پیچیدگی کو بڑھانے کا کوئی فائدہ نہیں ہے۔
• مائیکرو سرویس آرکیٹیکچر ڈومین ماڈل پر مبنی ہونا چاہئے - کیونکہ کاروباری موقع سب سے طویل عرصے تک رہنے والا ڈومین ہے
• ڈیلیوری کے طریقے (DevOps پریکٹسز) اور آرکیسٹریشن مائیکرو سرویس فن تعمیر کے لیے سب سے اہم ہیں - اس وجہ سے کہ اجزاء کی تبدیلی کی شرح میں اضافہ ڈیلیوری کی رفتار اور معیار پر مطالبات میں اضافہ کرتا ہے۔

ماخذ: www.habr.com