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

مونو لیتھس کا کوآرڈینیشن ٹیکس

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

جیسے جیسے آپ کی ٹیم بڑھتی ہے، یہ ٹیکس بھی اس کے ساتھ بڑھتا جاتا ہے۔ کوڈ ریویو کی رکاوٹیں تکنیکی مسائل سے ہٹ کر سماجی مسائل کی طرف منتقل ہو جاتی ہیں۔ دو سو کنٹریبیوٹرز والی ایک واحد ریپوزٹری لینیئر طریقے سے نہیں بڑھتی؛ بلکہ یہ کمبینٹوریل (combinatorial) طریقے سے بڑھتی ہے۔ مرج کیوز (merge queues) پیچھے رہ جاتی ہیں۔ ریلیز ٹرینز کئی دنوں تک کھنچ جاتی ہیں۔ ڈیزائن سسٹم ایک سیاسی اکائی بن جاتا ہے جسے بٹن کے نئے ورژن کی منظوری کے لیے ایک گورننگ کونسل کی ضرورت ہوتی ہے۔ مونو لیتھ بدنیتی کی وجہ سے تبدیلی کی مزاحمت نہیں کرتا۔ یہ تبدیلی کی مزاحمت اس لیے کرتا ہے کیونکہ ہر سطح مشترکہ ہے، اور ہر تبدیلی کے لیے اتفاق رائے کی ضرورت ہوتی ہے۔

حدود کا تعین کرنا

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

نظریہ بالکل واضح ہے۔ اگر ٹیم Shipping اپنی روٹنگ لیئر کو ریفیکٹر کرتی ہے، تو ٹیم Billing کو اس سے فرق نہیں پڑنا چاہیے۔ اگر سرچ انٹرفیس کو دن میں پانچ بار تعینات کرنے کی ضرورت ہے، تو اسے اکاؤنٹ سیٹنگز پیج کے اینڈ ٹو اینڈ ٹیسٹ مکمل ہونے کا انتظار نہیں کرنا چاہیے۔ حدود تنظیمی رگڑ کو تکنیکی انٹرفیسز میں بدل دیتی ہیں۔ لیکن وہ لکیر کھینچنا کبھی مفت نہیں ہوتا۔

انفراسٹرکچر کا بل

مائیکرو فرنٹ اینڈز پلیٹ فارم کے اخراجات پیدا کرتے ہیں۔ آپ کو ایک شیل ایپلی کیشن کی ضرورت ہوتی ہے جو رن ٹائم پر ٹکڑوں کو جوڑنے کے قابل ہو۔ آپ کو ایک ڈیپلائمنٹ پائپ لائن کی ضرورت ہوتی ہے جو یہ سمجھ سکے کہ متعدد بلڈ جابز سے آرٹفیکٹس کو ایک مربوط صفحے میں کیسے اسمبل کیا جائے۔ اگر آپ Webpack Module Federation استعمال کر رہے ہیں، تو اب آپ آزادانہ طور پر بنائے گئے بنڈلز میں مشترکہ ڈیپینڈینسی ورژنز کا انتظام کر رہے ہیں۔ اگر آپ iframes استعمال کر رہے ہیں، تو آپ کراس اوریجن میسجنگ کو ڈی بگ کر رہے ہیں اور لے آؤٹ شفٹس سے لڑ رہے ہیں۔ اگر آپ web components استعمال کر رہے ہیں، تو آپ ایک تقسیم شدہ گراف میں کسٹم ایلیمنٹس کی ورژننگ کر رہے ہیں جہاں ایک ٹیم کی اپ گریڈ دوسری ٹیم کے کام پر اثر انداز ہو سکتی ہے۔

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

جب اخراجات منتقل ہوتے ہیں

ایک درمیانے درجے کی SaaS کمپنی پر غور کریں جس کی چار فرنٹ اینڈ ٹیمیں ایک ہی Next.js ایپلی کیشن شیئر کر رہی ہیں۔ تین گھنٹے کے CI رن کے بعد دن میں دو بار ڈیپلائمنٹ ہوتی ہے۔ جب شپنگ ٹیم نیویگیشن کو ریفیکٹر کرنا چاہتی ہے، تو وہ کمنٹس کے لیے درخواست دیتی ہے، پورے ٹری میں امپورٹ پاتھ کو اپ ڈیٹ کرتی ہے، اور بلنگ ٹیم کے اپنے انٹیگریشن ٹیسٹ کو ایڈجسٹ کرنے کے لیے دو ہفتے انتظار کرتی ہے۔ لاگت کوآرڈینیشن ہے، سادہ اور صاف۔

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

اسکیلنگ کی ریاضی

کوئی بھی ماڈل مفت نہیں ہے۔ پندرہ افراد پر مشتمل اسٹارٹ اپ کو پلیٹ فارم ٹیم کی ضرورت نہیں ہوتی۔ module federation، آزادانہ deployment pipelines، اور distributed contract testing کا بوجھ ان کی تمام تر رفتار (velocity) کو ختم کر دے گا۔ انہیں کوآرڈینیشن (coordination) کی صورت میں قیمت ادا کرنی چاہیے کیونکہ کوآرڈینیشن سستی ہے۔ وہ دس منٹ کی گفتگو میں state management pattern پر اتفاق کر سکتے ہیں اور اسی دوپہر اسے ریلیز کر سکتے ہیں۔

پانچ سو افراد پر مشتمل ایک ایسا ادارہ (enterprise) جس کے ایک درجن کاروباری یونٹس مختلف سہ ماہی سائیکلز (quarterly cycles) پر کام کر رہے ہوں، اسے اس کے برعکس مسئلے کا سامنا ہوتا ہے۔ کوآرڈینیشن ٹیکس (coordination tax) اب غیر معمولی حد تک بڑھ چکا ہے۔ ریلیز ٹرینز (release trains) میں ہفتوں لگ جاتے ہیں۔ پلیٹ فارم انجینئرنگ کے لیے عملے کی تعداد پہلے ہی بجٹ کا حصہ ہے، اس لیے microfrontend انفراسٹرکچر کا اضافہ ایک معمولی خرچ ہے، نہ کہ کوئی نیا بجٹ آئٹم۔ ان کے لیے، الائنمنٹ میٹنگز (alignment meetings) کے بدلے ڈیپلائمنٹ گراف (deployment graphs) کا انتخاب کرنا ایک منطقی حساب کتاب ہے۔

اصل سوال یہ ہے کہ آپ کی ٹیم کے لیے کون سا بل بہتر طریقے سے اسکیل (scale) ہوتا ہے۔ Monoliths آپ پر انسانی کوآرڈینیشن کی حد پر ٹیکس لگاتے ہیں۔ Microfrontends آپ پر پلیٹ فارم انجینئرنگ کی بنیاد پر ٹیکس لگاتے ہیں۔

اپنی کرنسی کا انتخاب کرنا

اگر آپ microfrontends کا انتخاب کرتے ہیں، تو اس بارے میں واضح رہیں کہ آپ کیا خرید رہے ہیں۔ آپ ٹیم کی خود مختاری (autonomy) اور آزادانہ ڈیپلائبلٹی (deployability) خرید رہے ہیں۔ درج ذیل چیزوں کے لیے فنڈز فراہم کرنے کے لیے تیار رہیں:

  • ایک runtime shell جو مختلف حصوں (fragments) کے درمیان composition، routing، اور error boundaries کو سنبھالتا ہو۔
  • ایک مشترکہ dependency policy جو shared implementation logic کے بجائے deduplication strategy پر مرکوز ہو۔
  • ہر integration surface کے لیے کراس ٹیم contract testing۔
  • ایک مربوط observability جو تقسیم شدہ بنڈلز (distributed bundles) میں صارف کے کلک کے درمیان تعلق قائم کر سکے۔
  • ایک performance governance ماڈل، کیونکہ کوئی بھی ایک ٹیم اس فائنل پے لوڈ (payload) کی مالک نہیں ہوتی جسے براؤزر ڈاؤن لوڈ کرتا ہے۔

اگر آپ monolith کا انتخاب کرتے ہیں، تو انوائس (invoice) کے بارے میں ایماندار رہیں۔ آپ ہم آہنگی (synchronization) کے بدلے سادگی خرید رہے ہیں۔ ان چیزوں کے لیے ادائیگی کی توقع رکھیں:

  • مشترکہ کوڈ کی ملکیت اور اسے مربوط رکھنے کے لیے ضروری گورننس کے طریقے (rituals)۔
  • ریلیز کی رفتار (cadence) جو پائپ لائن میں سب سے سست انٹیگریشن ٹیسٹ سے طے ہوتی ہو۔
  • لائبریری اپ گریڈز پر وسیع اثر (blast radius)۔
  • یہ بڑھتی ہوئی حقیقت کہ آپ کے تیز ترین انجینئرز بھی آپ کے سب سے زیادہ محتاط انجینئرز کی رفتار سے کام کریں گے۔

اصل حاصل

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