مائیکرو سروسز بمقابلہ مونو لیتھک آرکیٹیکچر: آپ کو کیا بنانا چاہیے؟
ایک بانی (founder) نے ایک بار مجھ سے آرکیٹیکچر کے ایک پچ (pitch) کا جائزہ لینے کو کہا۔
ایجنسی نے گیارہ سروسز، ایک میسج کیو (message queue) اور ایک سروس میش (service mesh) کی تجویز دی۔ یہ ایک سادہ سے بکنگ ٹول کے لیے تھا جس کے زیرو صارفین تھے۔
یہ ایک جال ہے۔
آرکیٹیکچر کے فیصلے آپ کے ہوسٹنگ بلز، آپ کی شپنگ کی رفتار، اور آپ کے بھرتی کے منصوبے کا تعین کرتے ہیں۔ کسی ڈویلپر کو بجٹ دینے سے پہلے آپ کو اس کی لاگت کا علم ہونا چاہیے۔
دی مونو لیتھ (The Monolith) ایک مونو لیتھ میں ایک ہی کوڈ بیس، ایک ہی ڈیپلائمنٹ اور ایک ہی ڈیٹا بیس استعمال ہوتا ہے۔ یہ سادہ ہے۔
پہلے دن، آپ کو اپنے ڈومین کی حدود (domain boundaries) کا علم نہیں ہوتا۔ اگر آپ سروسز کو بہت جلد الگ کر دیتے ہیں، تو آپ اپنا وقت ایسی دیواریں ہٹانے میں ضائع کرتے ہیں جن کا ہونا ہی نہیں چاہیے تھا۔ جب آپ کی ٹیم چھوٹی ہو تو مونو لیتھ کو سنبھالنا آسان ہوتا ہے۔ آپ API سیٹ اپ کرنے کے بجائے ایک فنکشن کال کرتے ہیں۔ جب رات کے 2 بجے کوئی بگ (bug) آتا ہے، تو غلطی کوڈ کی طرف اشارہ کرتی ہے، نہ کہ نیٹ ورک کی ناکامی کی طرف۔
مائیکرو سروسز (Microservices) مائیکرو سروسز تنظیمی مسائل کو حل کرتی ہیں۔ یہ مختلف ٹیموں کو اپنے مقررہ شیڈول کے مطابق کوڈ شپ کرنے کی اجازت دیتی ہیں۔ Netflix انہیں اس لیے استعمال کرتا ہے تاکہ ایک خرابی پورے جہاز کو ڈوبنے سے بچا سکے۔
تاہم، آپ کو اس کی قیمت روزانہ چکانی پڑتی ہے۔ نیٹ ورک کالز سے لیٹنسی (latency) بڑھ جاتی ہے۔ ڈیٹا کی ہم آہنگی (data consistency) مشکل ہو جاتی ہے۔ لاگز (logs) اور ٹریسنگ (tracing) کو سنبھالنے کے لیے آپ کو مخصوص ٹولز اور ایک بڑی ٹیم کی ضرورت ہوتی ہے۔ صحیح افرادی قوت کے بغیر، آپ کا نتیجہ ایک ڈسٹری بیوٹڈ مونو لیتھ (distributed monolith) کی صورت میں نکلتا ہے۔ یہ آپ کو نیٹ ورک کی تمام پیچیدگیاں تو دیتا ہے لیکن آزادی بالکل نہیں دیتا۔
دی ماڈیولر مونو لیتھ (The Modular Monolith) یہ درمیانی راستہ ہے۔ یہ ایک ہی ایپ ہے جس میں کوڈ کے مختلف حصوں کے درمیان مضبوط دیواریں ہوتی ہیں۔ بلنگ (Billing) آپ کے آرڈرز کے بنیادی ڈھانچے (guts) کو متاثر نہیں کر سکتی۔
Shopify اور GitHub اسی طریقہ کار کو استعمال کرتے ہیں۔ آپ کو صاف ستھری حدود ملتی ہیں اور آپ نیٹ ورک ٹیکس (network tax) سے بچ جاتے ہیں۔ جب آپ کی ایپ کے کسی حصے کو آخر کار اکیلے اسکیل (scale) کرنے کی ضرورت پڑتی ہے، تو آپ اسے آسانی سے الگ کر سکتے ہیں کیونکہ اس کے کنارے پہلے سے ہی متعین ہوتے ہیں۔
فیصلہ کیسے کریں:
- ٹیم کا سائز: اگر آپ کے پاس تین لوگ ہیں، تو آپ الگ الگ سروسز اور مطلوبہ آن کال روٹیشن (on-call rotation) کو نہیں سنبھال سکتے۔
- پروڈکٹ کا استحکام: اگر آپ کی پروڈکٹ ہر ہفتے بدلتی ہے، تو اگلے مہینے تک آپ کی سروس کی حدود غلط ہو جائیں گی۔
- آپریشنز: کیا آپ کے پاس خودکار رول بیکس (automated rollbacks) اور لاگ ایگریگیشن (log aggregation) موجود ہے؟ اگر نہیں، تو مائیکرو سروسز تکلیف کا باعث بنیں گی۔
- اسکیل: فرضی ترقی کے لیے کچھ نہ بنائیں۔ اس ٹھوس راستے کے لیے بنائیں جسے آپ دیکھ سکتے ہیں۔
اگر آپ کے جوابات "ابھی نہیں" ہیں، تو ایک ماڈیولر مونو لیتھ بنائیں۔
مائیکرو سروسز کا مطالبہ صرف اس لیے نہ کریں کیونکہ یہ لفظ جدید لگتا ہے۔ اپنے پارٹنر کو بتائیں کہ پروڈکٹ کیا کرتی ہے اور اسے کون برقرار رکھے گا۔
مصنوعات اس لیے ناکام ہو جاتی ہیں کیونکہ وہ کبھی لانچ ہی نہیں ہو پاتیں۔ ایک صاف ستھرا monolith صارفین تک پہنچنے کا تیز ترین طریقہ ہے۔ پہلے اسے بنائیں۔ اپنے ٹریفک کو یہ بتانے دیں کہ کب چیزوں کو الگ کرنے کا وقت آیا ہے۔
اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi