سب کو سلام! ہمارے پاس اچھی خبر ہے، OTUS جون میں دوبارہ کورس شروع کر رہا ہے۔ ، جس کے سلسلے میں ہم روایتی طور پر آپ کے ساتھ مفید مواد کا اشتراک کرتے ہیں۔
اگر آپ بغیر کسی سیاق و سباق کے اس ساری مائیکرو سروسز چیز کو دیکھ چکے ہیں، تو آپ کو یہ سوچ کر معاف کر دیا جائے گا کہ یہ تھوڑا سا عجیب ہے۔ کسی ایپلیکیشن کو نیٹ ورک کے ذریعے منسلک ٹکڑوں میں تقسیم کرنے کا مطلب لازمی طور پر نتیجے میں تقسیم شدہ نظام میں پیچیدہ غلطی برداشت کرنے کے طریقوں کو شامل کرنا ہے۔
اگرچہ اس نقطہ نظر میں اسے بہت سی آزاد خدمات میں تقسیم کرنا شامل ہے، لیکن آخری مقصد ان خدمات کو مختلف مشینوں پر چلانے سے کہیں زیادہ ہے۔ ہم یہاں بیرونی دنیا کے ساتھ تعامل کے بارے میں بات کر رہے ہیں، جو اپنے جوہر میں بھی تقسیم ہے۔ تکنیکی معنوں میں نہیں، بلکہ ایک ماحولیاتی نظام کے معنی میں جو بہت سے لوگوں، ٹیموں، پروگراموں، اور ان حصوں میں سے ہر ایک کو کسی نہ کسی طرح اپنا کام کرنے کی ضرورت ہے۔
کمپنیاں، مثال کے طور پر، تقسیم شدہ نظاموں کا مجموعہ ہیں جو اجتماعی طور پر کسی مقصد کے حصول میں حصہ ڈالتے ہیں۔ ہم نے کئی دہائیوں سے اس حقیقت کو نظر انداز کیا ہے، FTP پر فائلوں کی منتقلی یا انٹرپرائز انٹیگریشن ٹولز کا استعمال کرتے ہوئے اپنے الگ الگ اہداف پر توجہ مرکوز کرتے ہوئے اتحاد حاصل کرنے کی کوشش کر رہے ہیں۔ لیکن خدمات کی آمد کے ساتھ، سب کچھ بدل گیا. خدمات نے ہمیں افق سے باہر دیکھنے اور ایک دوسرے پر منحصر پروگراموں کی دنیا دیکھنے میں مدد کی ہے جو مل کر کام کرتے ہیں۔ تاہم، کامیابی سے کام کرنے کے لیے، دو بنیادی طور پر مختلف دنیاؤں کو پہچاننا اور ڈیزائن کرنا ضروری ہے: بیرونی دنیا، جہاں ہم بہت سی دوسری خدمات کے ایکو سسٹم میں رہتے ہیں، اور ہماری ذاتی، اندرونی دنیا، جہاں ہم اکیلے حکومت کرتے ہیں۔
یہ تقسیم شدہ دنیا اس سے مختلف ہے جس میں ہم پلے بڑھے ہیں اور جس کے ہم عادی ہیں۔ روایتی یک سنگی فن تعمیر کے اصول تنقید کا مقابلہ نہیں کرتے۔ لہذا ان سسٹمز کو درست کرنا ایک ٹھنڈی وائٹ بورڈ ڈایاگرام یا تصور کا ٹھنڈا ثبوت بنانے سے کہیں زیادہ ہے۔ نقطہ یہ یقینی بنانا ہے کہ اس طرح کا نظام طویل عرصے تک کامیابی سے چلتا ہے۔ خوش قسمتی سے، خدمات کافی عرصے سے موجود ہیں، حالانکہ وہ مختلف نظر آتی ہیں۔ اب بھی متعلقہ ہیں، یہاں تک کہ ڈوکر، کبرنیٹس اور قدرے جھرجھری والی ہپسٹر داڑھیوں کے ساتھ بھی۔
لہٰذا آج ہم دیکھیں گے کہ قوانین کیسے بدلے ہیں، ہمیں سروسز تک پہنچنے کے طریقہ پر نظر ثانی کرنے کی ضرورت کیوں ہے اور وہ ڈیٹا جو وہ ایک دوسرے کو دیتے ہیں، اور ہمیں ایسا کرنے کے لیے بالکل مختلف ٹولز کی ضرورت کیوں پڑے گی۔
Encapsulation ہمیشہ آپ کا دوست نہیں ہوگا۔
مائیکرو سروسز ایک دوسرے سے آزادانہ طور پر کام کر سکتی ہیں۔ یہ وہ پراپرٹی ہے جو انہیں سب سے بڑی قیمت دیتی ہے۔ یہی خاصیت خدمات کو پیمانے اور بڑھنے کی اجازت دیتی ہے۔ اتنا زیادہ نہیں کہ صارفین کے quadrillions یا ڈیٹا کے پیٹا بائٹس (اگرچہ وہ وہاں بھی مدد کر سکتے ہیں) تک پیمانہ کرنے کے معنی میں ہے، لیکن ٹیموں اور تنظیموں کے مسلسل بڑھتے ہوئے لوگوں کے لحاظ سے اسکیلنگ کے معنی میں۔
تاہم آزادی دو دھاری تلوار ہے۔ یعنی سروس خود آسانی اور قدرتی طور پر چل سکتی ہے۔ لیکن اگر کسی سروس کے اندر کوئی فنکشن لاگو کیا جاتا ہے جس کے لیے دوسری سروس کے استعمال کی ضرورت ہوتی ہے، تو ہمیں تقریباً ایک ساتھ دونوں سروسز میں تبدیلیاں کرنا پڑتی ہیں۔ یک سنگی میں یہ کرنا آسان ہے، آپ صرف ایک تبدیلی کرتے ہیں اور اسے ریلیز کے لیے بھیج دیتے ہیں، لیکن آزاد خدمات کو ہم آہنگ کرنے کی صورت میں مزید مسائل پیدا ہوں گے۔ ٹیموں اور رہائی کے چکروں کے درمیان ہم آہنگی چستی کو ختم کر دیتی ہے۔
معیاری نقطہ نظر کے حصے کے طور پر، وہ صرف پریشان کن اختتام سے آخر تک تبدیلیوں سے بچنے کی کوشش کرتے ہیں، واضح طور پر خدمات کے درمیان فعالیت کو تقسیم کرتے ہیں۔ سنگل سائن آن سروس یہاں ایک اچھی مثال ہو سکتی ہے۔ اس کا واضح طور پر بیان کردہ کردار ہے جو اسے دوسری خدمات سے ممتاز کرتا ہے۔ اس واضح علیحدگی کا مطلب یہ ہے کہ اس کے آس پاس کی خدمات پر تیزی سے بدلتے ہوئے مطالبات کی دنیا میں، واحد سائن آن سروس کے تبدیل ہونے کا امکان نہیں ہے۔ یہ ایک سختی سے محدود سیاق و سباق کے اندر موجود ہے۔
مسئلہ یہ ہے کہ حقیقی دنیا میں، کاروباری خدمات ہر وقت کرداروں کی ایک ہی خالص علیحدگی کو برقرار نہیں رکھ سکتیں۔ مثال کے طور پر، وہی کاروباری خدمات دوسری اسی طرح کی خدمات سے آنے والے ڈیٹا کے ساتھ زیادہ حد تک کام کرتی ہیں۔ اگر آپ آن لائن ریٹیل میں شامل ہیں، تو آپ کی بہت سی خدمات کے لیے آرڈر فلو، پروڈکٹ کیٹلاگ یا صارف کی معلومات پر کارروائی کرنا ایک ضرورت بن جائے گی۔ خدمات میں سے ہر ایک کو کام کرنے کے لیے اس ڈیٹا تک رسائی کی ضرورت ہوگی۔
زیادہ تر کاروباری خدمات ایک ہی ڈیٹا اسٹریم کا اشتراک کرتی ہیں، اس لیے ان کا کام ہمیشہ ایک دوسرے سے جڑا رہتا ہے۔
اس طرح ہم ایک اہم نکتے پر آتے ہیں جس کے بارے میں بات کرنا ضروری ہے۔ اگرچہ خدمات بنیادی ڈھانچے کے اجزاء کے لیے اچھی طرح سے کام کرتی ہیں جو بڑے پیمانے پر تنہائی میں کام کرتے ہیں، زیادہ تر کاروباری خدمات آپس میں بہت زیادہ قریب سے جڑی ہوتی ہیں۔
ڈیٹا ڈیکوٹومی
سروس پر مبنی نقطہ نظر پہلے سے موجود ہو سکتے ہیں، لیکن ان میں اب بھی بصیرت کا فقدان ہے کہ خدمات کے درمیان ڈیٹا کی بڑی مقدار کو کس طرح بانٹنا ہے۔
بنیادی مسئلہ یہ ہے کہ ڈیٹا اور خدمات لازم و ملزوم ہیں۔ ایک طرف، encapsulation ہمیں ڈیٹا چھپانے کی ترغیب دیتا ہے تاکہ خدمات کو ایک دوسرے سے الگ کیا جا سکے اور ان کی ترقی اور مزید تبدیلیوں کو آسان بنایا جا سکے۔ دوسری طرف، ہمیں کسی دوسرے ڈیٹا کی طرح، مشترکہ ڈیٹا کو آزادانہ طور پر تقسیم اور فتح کرنے کے قابل ہونے کی ضرورت ہے۔ نقطہ یہ ہے کہ کسی دوسرے انفارمیشن سسٹم کی طرح آزادانہ طور پر فوری طور پر کام شروع کرنے کے قابل ہو۔
تاہم، انفارمیشن سسٹم کا encapsulation سے بہت کم تعلق ہے۔ اصل میں، یہ بالکل برعکس ہے. ڈیٹا بیس اپنے ذخیرہ کردہ ڈیٹا تک رسائی فراہم کرنے کے لیے ہر ممکن کوشش کرتے ہیں۔ وہ ایک طاقتور اعلانیہ انٹرفیس کے ساتھ آتے ہیں جو آپ کو اپنی ضرورت کے مطابق ڈیٹا میں ترمیم کرنے کی اجازت دیتا ہے۔ اس طرح کی فعالیت ابتدائی تحقیقی مرحلے میں اہم ہے، لیکن مسلسل ترقی پذیر سروس کی بڑھتی ہوئی پیچیدگی کو سنبھالنے کے لیے نہیں۔
اور یہاں ایک مخمصہ پیدا ہوتا ہے۔ تضاد. Dichotomy. بہر حال، انفارمیشن سسٹم ڈیٹا فراہم کرنے کے بارے میں ہیں، اور خدمات چھپانے کے بارے میں ہیں۔
یہ دونوں قوتیں بنیادی ہیں۔ وہ ہمارے زیادہ تر کام کو زیر کرتے ہیں، جو ہمارے بنائے ہوئے نظاموں میں عمدگی کے لیے مسلسل جدوجہد کرتے ہیں۔
جیسے جیسے سروس سسٹم بڑھتا اور تیار ہوتا ہے، ہم ڈیٹا ڈیکوٹومی کے نتائج کو کئی طریقوں سے دیکھتے ہیں۔ یا تو سروس انٹرفیس بڑھے گا، فعالیت کی مسلسل بڑھتی ہوئی رینج فراہم کرے گا اور ایک بہت ہی فینسی گھریلو ڈیٹا بیس کی طرح نظر آنا شروع ہو جائے گا، یا ہم مایوس ہو جائیں گے اور ڈیٹا کے پورے سیٹ کو سروس سے سروس تک لے جانے یا منتقل کرنے کا کوئی طریقہ اپنائیں گے۔
بدلے میں، کوئی ایسی چیز بنانا جو کہ ایک فینسی ہوم گراونڈ ڈیٹا بیس کی طرح نظر آئے، مسائل کی ایک پوری میزبانی کا باعث بنے گا۔ ہم اس بارے میں تفصیلات میں نہیں جائیں گے کہ یہ خطرناک کیوں ہے۔ مشترکہ ڈیٹا بیس، آئیے صرف یہ کہتے ہیں کہ یہ اہم مہنگی انجینئرنگ اور آپریشنل کی نمائندگی کرتا ہے۔ اس کمپنی کے لیے جو اسے استعمال کرنے کی کوشش کر رہی ہے۔
سب سے بری بات یہ ہے کہ ڈیٹا والیوم سروس باؤنڈری کے مسائل کو بڑھا دیتے ہیں۔ سروس کے اندر جتنا زیادہ ڈیٹا شیئر کیا جائے گا، انٹرفیس اتنا ہی پیچیدہ ہوتا جائے گا اور مختلف سروسز سے آنے والے ڈیٹا سیٹس کو جوڑنا اتنا ہی مشکل ہوگا۔
پورے ڈیٹا سیٹ کو نکالنے اور منتقل کرنے کے متبادل نقطہ نظر میں بھی اپنے مسائل ہیں۔ اس سوال کا ایک عام نقطہ نظر ایسا لگتا ہے جیسے پورے ڈیٹاسیٹ کو صرف بازیافت اور ذخیرہ کرنا، اور پھر اسے ہر استعمال کرنے والی خدمت میں مقامی طور پر اسٹور کرنا۔
مسئلہ یہ ہے کہ مختلف سروسز اپنے استعمال کردہ ڈیٹا کی مختلف انداز میں تشریح کرتی ہیں۔ یہ ڈیٹا ہمیشہ ہاتھ میں ہوتا ہے۔ ان میں ترمیم اور مقامی طور پر کارروائی کی جاتی ہے۔ بہت جلد وہ ماخذ میں موجود ڈیٹا کے ساتھ کچھ بھی مشترک نہیں رکھتے۔
کاپیاں جتنی زیادہ متغیر ہوں گی، وقت کے ساتھ ڈیٹا میں اتنا ہی فرق ہوگا۔
معاملات کو مزید خراب کرنے کے لیے، ماضی میں اس طرح کے ڈیٹا کو درست کرنا مشکل ہے ( یہ وہ جگہ ہے جہاں یہ واقعی بچ سکتا ہے)۔ درحقیقت، کچھ پیچیدہ ٹیکنالوجی کے مسائل جن کا کاروباروں کو سامنا ہوتا ہے وہ مختلف اعداد و شمار سے پیدا ہوتے ہیں جو اطلاق سے دوسرے اطلاق تک بڑھتے ہیں۔
اس مسئلے کا حل تلاش کرنے کے لیے، ہمیں مشترکہ ڈیٹا کے بارے میں مختلف طریقے سے سوچنے کی ضرورت ہے۔ وہ ہمارے بنائے ہوئے فن تعمیر میں فرسٹ کلاس اشیاء بن جائیں۔ ایسے ڈیٹا کو "بیرونی" کہتے ہیں، اور یہ ایک بہت اہم خصوصیت ہے۔ ہمیں انکیپسولیشن کی ضرورت ہے تاکہ ہم کسی سروس کے اندرونی کام کو بے نقاب نہ کریں، لیکن ہمیں سروسز کے لیے مشترکہ ڈیٹا تک رسائی آسان بنانے کی ضرورت ہے تاکہ وہ اپنے کام صحیح طریقے سے کر سکیں۔
مسئلہ یہ ہے کہ آج نہ تو کوئی نقطہ نظر متعلقہ ہے، کیونکہ نہ تو سروس انٹرفیس، نہ ہی میسجنگ، اور نہ ہی مشترکہ ڈیٹا بیس بیرونی ڈیٹا کے ساتھ کام کرنے کے لیے ایک اچھا حل پیش کرتے ہیں۔ سروس انٹرفیس کسی بھی پیمانے پر ڈیٹا کے تبادلے کے لیے موزوں نہیں ہیں۔ پیغام رسانی ڈیٹا کو منتقل کرتی ہے لیکن اس کی تاریخ کو محفوظ نہیں کرتی، اس لیے وقت کے ساتھ ساتھ ڈیٹا کرپٹ ہو جاتا ہے۔ مشترکہ ڈیٹا بیس ایک نقطہ پر بہت زیادہ توجہ مرکوز کرتا ہے، جو ترقی کو روکتا ہے۔ ہم لامحالہ ڈیٹا کی ناکامی کے چکر میں پھنس جاتے ہیں:
ڈیٹا کی ناکامی کا چکر
اسٹریمز: ڈیٹا اور سروسز کے لیے ایک وکندریقرت نقطہ نظر
مثالی طور پر، ہمیں مشترکہ ڈیٹا کے ساتھ خدمات کے کام کرنے کے طریقے کو تبدیل کرنے کی ضرورت ہے۔ اس مقام پر، یا تو نقطہ نظر کو مذکورہ بالا اختلاف کا سامنا کرنا پڑتا ہے، کیوں کہ اس پر کوئی جادوئی دھول نہیں ہے جو اسے غائب کرنے کے لیے اس پر چھڑک سکے۔ تاہم، ہم مسئلے پر دوبارہ غور کر سکتے ہیں اور سمجھوتہ کر سکتے ہیں۔
اس سمجھوتہ میں ایک خاص حد تک مرکزیت شامل ہے۔ ہم تقسیم شدہ لاگ میکانزم کا استعمال کر سکتے ہیں کیونکہ یہ قابل اعتماد، توسیع پذیر سلسلے فراہم کرتا ہے۔ اب ہم چاہتے ہیں کہ سروسز ان مشترکہ دھاگوں میں شامل ہونے اور کام کرنے کے قابل ہوں، لیکن ہم ان پیچیدہ مرکزی خدمات سے بچنا چاہتے ہیں جو یہ پروسیسنگ کرتی ہیں۔ لہذا، بہترین آپشن یہ ہے کہ ہر صارف کی خدمت میں اسٹریم پروسیسنگ کی تعمیر کی جائے۔ اس طرح، خدمات مختلف ذرائع سے ڈیٹا سیٹس کو یکجا کرنے اور ان کے ساتھ اپنی ضرورت کے مطابق کام کرنے کے قابل ہو جائیں گی۔
اس نقطہ نظر کو حاصل کرنے کا ایک طریقہ اسٹریمنگ پلیٹ فارم کا استعمال ہے۔ بہت سارے اختیارات ہیں، لیکن آج ہم کافکا پر نظر ڈالیں گے، کیونکہ اس کی اسٹیٹفول اسٹریم پروسیسنگ کا استعمال ہمیں پیش کردہ مسئلے کو مؤثر طریقے سے حل کرنے کی اجازت دیتا ہے۔
تقسیم شدہ لاگنگ میکانزم کا استعمال ہمیں اچھی طرح سے چلنے والے راستے پر چلنے اور پیغام رسانی کا استعمال کرنے کی اجازت دیتا ہے . اس نقطہ نظر کو درخواست کے جواب کے طریقہ کار سے بہتر اسکیلنگ اور تقسیم فراہم کرنے کے لئے سمجھا جاتا ہے کیونکہ یہ بھیجنے والے کے بجائے وصول کنندہ کو بہاؤ کا کنٹرول دیتا ہے۔ تاہم، اس زندگی میں ہر چیز کے لیے آپ کو ادائیگی کرنی ہوگی، اور یہاں آپ کو ایک بروکر کی ضرورت ہے۔ لیکن بڑے سسٹمز کے لیے، ٹریڈ آف اس کے قابل ہے (جو آپ کی اوسط ویب ایپلیکیشن کے لیے نہیں ہو سکتا)۔
اگر کوئی بروکر روایتی پیغام رسانی کے نظام کے بجائے تقسیم شدہ لاگنگ کا ذمہ دار ہے، تو آپ اضافی خصوصیات سے فائدہ اٹھا سکتے ہیں۔ نقل و حمل تقریباً ایک تقسیم شدہ فائل سسٹم کے ساتھ ساتھ لکیری طور پر پیمانہ کر سکتا ہے۔ ڈیٹا کو لاگز میں کافی دیر تک محفوظ کیا جا سکتا ہے، اس لیے ہمیں نہ صرف پیغامات کا تبادلہ، بلکہ معلومات کا ذخیرہ بھی ملتا ہے۔ تغیر پذیر مشترکہ حالت کے خوف کے بغیر توسیع پذیر اسٹوریج۔
اس کے بعد آپ استعمال کرنے والی خدمات میں اعلانیہ ڈیٹا بیس ٹولز کو شامل کرنے کے لیے اسٹیٹفول اسٹریم پروسیسنگ استعمال کرسکتے ہیں۔ یہ ایک بہت اہم خیال ہے۔ جبکہ ڈیٹا مشترکہ اسٹریمز میں محفوظ کیا جاتا ہے جس تک تمام سروسز رسائی حاصل کر سکتی ہیں، لیکن سروس جو جمع اور پروسیسنگ کرتی ہے وہ نجی ہے۔ وہ خود کو سختی سے محدود تناظر میں الگ تھلگ پاتے ہیں۔
غیر منقولہ اسٹیٹ اسٹریم کو الگ کرکے ڈیٹا ڈیکوٹومی کو ختم کریں۔ پھر اسٹیٹفول اسٹریم پروسیسنگ کا استعمال کرتے ہوئے اس فعالیت کو ہر سروس میں شامل کریں۔
اس طرح، اگر آپ کی سروس کو آرڈرز، پروڈکٹ کیٹلاگ، ایک گودام کے ساتھ کام کرنے کی ضرورت ہے، تو اسے مکمل رسائی حاصل ہوگی: صرف آپ فیصلہ کریں گے کہ کون سا ڈیٹا اکٹھا کرنا ہے، اسے کہاں پروسیس کرنا ہے اور وقت کے ساتھ اسے کیسے تبدیل ہونا چاہیے۔ اس حقیقت کے باوجود کہ ڈیٹا کا اشتراک کیا جاتا ہے، اس کے ساتھ کام مکمل طور پر وکندریقرت ہے۔ یہ ہر سروس کے اندر تیار کیا جاتا ہے، ایک ایسی دنیا میں جہاں سب کچھ آپ کے اصولوں کے مطابق ہوتا ہے۔
ڈیٹا کی سالمیت پر سمجھوتہ کیے بغیر شیئر کریں۔ فنکشن کو انکیپسول کریں، ذریعہ نہیں، ہر اس سروس میں جس کی ضرورت ہے۔
ایسا ہوتا ہے کہ ڈیٹا کو بڑے پیمانے پر منتقل کرنے کی ضرورت ہے۔ بعض اوقات کسی سروس کو منتخب ڈیٹا بیس انجن میں مقامی تاریخی ڈیٹاسیٹ کی ضرورت ہوتی ہے۔ چال یہ ہے کہ آپ اس بات کی ضمانت دے سکتے ہیں کہ، اگر ضروری ہو تو، تقسیم شدہ لاگنگ میکانزم تک رسائی حاصل کرکے ماخذ سے ایک کاپی بحال کی جاسکتی ہے۔ کافکا میں کنیکٹر اس کا بہت اچھا کام کرتے ہیں۔
لہذا، آج جس نقطہ نظر پر تبادلہ خیال کیا گیا ہے اس کے کئی فوائد ہیں:
- ڈیٹا کو عام اسٹریمز کی شکل میں استعمال کیا جاتا ہے، جسے لاگز میں طویل عرصے تک محفوظ کیا جا سکتا ہے، اور مشترکہ ڈیٹا کے ساتھ کام کرنے کا طریقہ کار ہر انفرادی تناظر میں سخت وائرڈ ہوتا ہے، جو سروسز کو آسانی اور تیزی سے کام کرنے کی اجازت دیتا ہے۔ اس طرح، اعداد و شمار کے dichotomy متوازن کیا جا سکتا ہے.
- مختلف سروسز سے آنے والے ڈیٹا کو آسانی سے سیٹوں میں ملایا جا سکتا ہے۔ یہ مشترکہ ڈیٹا کے ساتھ تعامل کو آسان بناتا ہے اور ڈیٹا بیس میں مقامی ڈیٹا سیٹس کو برقرار رکھنے کی ضرورت کو ختم کرتا ہے۔
- اسٹیٹفول اسٹریم پروسیسنگ صرف ڈیٹا کو محفوظ کرتی ہے، اور سچائی کا ماخذ عام لاگ ہی رہتا ہے، اس لیے وقت کے ساتھ ساتھ ڈیٹا کرپٹ ہونے کا مسئلہ اتنا شدید نہیں ہوتا۔
- ان کے بنیادی طور پر، خدمات ڈیٹا پر مبنی ہیں، مطلب یہ ہے کہ ڈیٹا کی مسلسل بڑھتی ہوئی مقدار کے باوجود، خدمات اب بھی کاروباری واقعات کا فوری جواب دے سکتی ہیں۔
- توسیع پذیری کے مسائل بروکر پر آتے ہیں، خدمات پر نہیں۔ یہ تحریری خدمات کی پیچیدگی کو نمایاں طور پر کم کرتا ہے، کیونکہ توسیع پذیری کے بارے میں سوچنے کی ضرورت نہیں ہے۔
- نئی سروسز کو شامل کرنے کے لیے پرانی کو تبدیل کرنے کی ضرورت نہیں ہے، اس لیے نئی سروسز کو جوڑنا آسان ہو جاتا ہے۔
جیسا کہ آپ دیکھ سکتے ہیں، یہ صرف آرام سے زیادہ ہے۔ ہمیں ٹولز کا ایک سیٹ موصول ہوا ہے جو آپ کو مشترکہ ڈیٹا کے ساتھ وکندریقرت انداز میں کام کرنے کی اجازت دیتا ہے۔
آج کے مضمون میں تمام پہلوؤں کا احاطہ نہیں کیا گیا۔ ہمیں ابھی بھی یہ معلوم کرنے کی ضرورت ہے کہ درخواست کے جواب کے پیراڈائم اور ایونٹ سے چلنے والے پیراڈائم کے درمیان توازن کیسے رکھا جائے۔ لیکن ہم اگلی بار اس سے نمٹ لیں گے۔ ایسے عنوانات ہیں جن کے بارے میں آپ کو بہتر طور پر جاننے کی ضرورت ہے، مثال کے طور پر، اسٹیٹفول اسٹریم پروسیسنگ اتنی اچھی کیوں ہے۔ اس بارے میں ہم تیسرے مضمون میں بات کریں گے۔ اور دیگر طاقتور تعمیرات ہیں جن سے ہم فائدہ اٹھا سکتے ہیں اگر ہم ان کا سہارا لیں، مثال کے طور پر، . یہ تقسیم شدہ کاروباری نظاموں کے لیے گیم چینجر ہے کیونکہ یہ لین دین کی ضمانت فراہم کرتا ہے۔ توسیع پذیر شکل میں۔ اس پر چوتھے مضمون میں بحث کی جائے گی۔ آخر میں، ہمیں ان اصولوں کے نفاذ کی تفصیلات پر جانے کی ضرورت ہوگی۔
لیکن ابھی کے لیے، صرف یہ یاد رکھیں: ڈیٹا ڈیکوٹومی ایک ایسی قوت ہے جس کا ہمیں کاروباری خدمات کی تعمیر کے وقت سامنا کرنا پڑتا ہے۔ اور ہمیں یہ یاد رکھنا چاہیے۔ چال یہ ہے کہ ہر چیز کو اس کے سر پر موڑ دیا جائے اور مشترکہ ڈیٹا کو فرسٹ کلاس اشیاء کے طور پر علاج کرنا شروع کیا جائے۔ اسٹیٹفول اسٹریم پروسیسنگ اس کے لیے ایک منفرد سمجھوتہ فراہم کرتی ہے۔ یہ مرکزی "خدا کے اجزاء" سے گریز کرتا ہے جو ترقی کو روکتے ہیں۔ مزید یہ کہ یہ ڈیٹا اسٹریمنگ پائپ لائنز کی چستی، اسکیل ایبلٹی اور لچک کو یقینی بناتا ہے اور انہیں ہر سروس میں شامل کرتا ہے۔ لہذا، ہم شعور کے عمومی دھارے پر توجہ مرکوز کر سکتے ہیں جس سے کوئی بھی سروس اپنے ڈیٹا کے ساتھ منسلک اور کام کر سکتی ہے۔ یہ خدمات کو مزید توسیع پذیر، قابل تبادلہ اور خود مختار بناتا ہے۔ لہٰذا وہ نہ صرف وائٹ بورڈز اور مفروضے کے ٹیسٹوں پر اچھے لگیں گے، بلکہ وہ کئی دہائیوں تک کام کریں گے اور تیار بھی ہوں گے۔
ماخذ: www.habr.com