25 اپریل کو، ہم نے Mail.ru گروپ میں بادلوں اور اردگرد کے بارے میں ایک کانفرنس منعقد کی۔ . چند جھلکیاں:
- مین — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center اور Yandex.Cloud نے ہماری کلاؤڈ مارکیٹ کی تفصیلات اور ان کی خدمات کے بارے میں بات کی۔
- Bitrix24 کے ساتھیوں نے بتایا کہ وہ کیسے ;
- Leroy Merlin، Otkritie، Burger King اور Schneider Electric نے دلچسپ معلومات فراہم کیں۔ — ان کا کاروبار IT کے لیے کون سے کام کرتا ہے اور کون سی ٹیکنالوجیز، بشمول کلاؤڈ والے، وہ سب سے زیادہ امید افزا دیکھتے ہیں۔
آپ میلٹو:کلاؤڈ کانفرنس سے تمام ویڈیوز دیکھ سکتے ہیں۔ ، اور یہاں آپ پڑھ سکتے ہیں کہ مائیکرو سروسز کے بارے میں بحث کیسے ہوئی۔ MegaFon بزنس سسٹمز ریسرچ اینڈ ڈیولپمنٹ سینٹر کے سربراہ الیگزینڈر ڈیولن اور M.Video-Eldorado گروپ کے انفارمیشن ٹیکنالوجی ڈائریکٹر سرگئی سرگیف نے یک سنگی سے چھٹکارا پانے کے اپنے کامیاب کیسز کا اشتراک کیا۔ ہم نے آئی ٹی حکمت عملی، عمل اور یہاں تک کہ HR کے متعلقہ مسائل پر بھی تبادلہ خیال کیا۔
پینلسٹس
- سرگئی سرگئیف۔، گروپ سی آئی او "M.Video-Eldorado";
- الیگزینڈر ڈیولن، کاروباری نظام کی تحقیق اور ترقی کے مرکز کے سربراہ میگا فون;
- ناظم - دمتری لازارینکو، PaaS سمت کے سربراہ Mail.ru کلاؤڈ سلوشنز.
الیگزینڈر ڈیولن کی تقریر کے بعد M.Video-Eldorado سے Sergey Sergeev اور ڈسکشن ماڈریٹر Dmitry Lazarenko, Mail.ru Cloud Solutions کے ساتھ بحث کے لیے ان کے ساتھ شامل ہوئے۔
ذیل میں ہم نے آپ کے لیے بحث کا ایک ٹرانسکرپٹ تیار کیا ہے، لیکن آپ ویڈیو بھی دیکھ سکتے ہیں:
مائیکرو سروسز میں منتقلی مارکیٹ کی ضروریات کا جواب ہے۔
دمتری:
کیا آپ کو مائیکرو سروسز میں منتقل ہونے کا کوئی کامیاب تجربہ ہوا ہے؟ اور عام طور پر: آپ کو مائیکرو سروسز استعمال کرنے یا یک سنگی سے مائیکرو سروسز کی طرف جانے سے سب سے زیادہ کاروباری فائدہ کہاں نظر آتا ہے؟
سرجی:
ہم مائیکرو سروسز کی منتقلی میں پہلے ہی کچھ راستے پر آ چکے ہیں اور تین سال سے زیادہ عرصے سے اس طریقہ کار کو استعمال کر رہے ہیں۔ پہلی ضرورت جس نے مائیکرو سروسز کی ضرورت کو جواز بنایا وہ بیک آفس کے ساتھ فرنٹ اینڈ پروڈکٹس کا لامتناہی انضمام تھا۔ اور ہر بار ہمیں اس یا اس سروس کے آپریشن کے لیے اپنے قوانین کو لاگو کرتے ہوئے اضافی انضمام اور ترقی کرنے پر مجبور کیا گیا۔
کسی وقت، ہم نے محسوس کیا کہ ہمیں اپنے سسٹمز کے آپریشن اور فعالیت کے آؤٹ پٹ کو تیز کرنے کی ضرورت ہے۔ اس وقت، مائیکرو سروسز اور مائیکرو سروس اپروچ جیسے تصورات مارکیٹ میں پہلے سے موجود تھے، اور ہم نے اسے آزمانے کا فیصلہ کیا۔ یہ 2016 میں شروع ہوا۔ پھر پلیٹ فارم بچھایا گیا اور پہلی 10 خدمات ایک الگ ٹیم کے ذریعہ نافذ کی گئیں۔
پہلی خدمات میں سے ایک، سب سے زیادہ بھاری بھرکم، قیمت کے حساب کتاب کی خدمت تھی۔ جب بھی آپ کسی بھی چینل پر آتے ہیں، M.Video-Eldorado گروپ آف کمپنیوں میں، خواہ وہ ویب سائٹ ہو یا ریٹیل اسٹور، وہاں کوئی پروڈکٹ منتخب کریں، ویب سائٹ پر یا "باسکٹ" میں قیمت دیکھیں، قیمت خود بخود ہو جاتی ہے۔ ایک سروس کے ذریعہ شمار کیا جاتا ہے۔ یہ کیوں ضروری ہے: اس سے پہلے، پروموشنز کے ساتھ کام کرنے کے لیے ہر سسٹم کے اپنے اصول تھے - ڈسکاؤنٹ وغیرہ کے ساتھ۔ ہمارا بیک آفس قیمتوں کا تعین کرتا ہے؛ رعایتی فعالیت کو دوسرے نظام میں لاگو کیا جاتا ہے۔ اس کو مرکزی بنانے کی ضرورت ہے اور ایک منفرد، الگ ہونے والی سروس کو ایک کاروباری عمل کی شکل میں بنایا گیا ہے جو ہمیں اس پر عمل درآمد کرنے کی اجازت دے گی۔ یہ بہت زیادہ ہے کہ ہم نے کیسے شروع کیا.
پہلے نتائج کی قدر بہت اچھی تھی۔ سب سے پہلے، ہم الگ کرنے کے قابل ادارے بنانے کے قابل تھے جو ہمیں الگ الگ اور مجموعی طور پر کام کرنے کی اجازت دیتے ہیں۔ دوم، ہم نے مزید سسٹمز کے ساتھ انضمام کے معاملے میں ملکیت کی لاگت کو کم کیا ہے۔
پچھلے تین سالوں میں، ہم نے تین فرنٹ لائن سسٹمز شامل کیے ہیں۔ ان کو اتنے ہی وسائل سے برقرار رکھنا مشکل تھا جو کمپنی برداشت کر سکتی تھی۔ لہذا، کام نئے آؤٹ لیٹس کو تلاش کرنے کے لئے پیدا ہوا، رفتار کے لحاظ سے، اندرونی اخراجات اور کارکردگی کے لحاظ سے مارکیٹ کو جواب دینا.
مائیکرو سروسز میں منتقلی کی کامیابی کی پیمائش کیسے کی جائے۔
دمتری:
مائیکرو سروسز میں منتقلی میں کامیابی کا تعین کیسے کیا جاتا ہے؟ ہر کمپنی میں "پہلے" کیا تھا؟ منتقلی کی کامیابی کا تعین کرنے کے لیے آپ نے کون سا میٹرک استعمال کیا، اور اصل میں اس کا تعین کس نے کیا؟
سرجی:
سب سے پہلے، یہ آئی ٹی کے اندر ایک فعال کے طور پر پیدا ہوا تھا - نئی صلاحیتوں کو "ان لاک کرنا"۔ ہمیں مارکیٹ کے چیلنجوں کا جواب دیتے ہوئے نسبتاً ایک ہی رقم کے لیے سب کچھ تیزی سے کرنے کی ضرورت تھی۔ اب کامیابی کا اظہار مختلف نظاموں کے ذریعے دوبارہ استعمال کی جانے والی خدمات کی تعداد، آپس میں عمل کے اتحاد سے ہوتا ہے۔ اب یہ ہے، لیکن اس وقت یہ ایک پلیٹ فارم بنانے اور اس مفروضے کی تصدیق کرنے کا موقع تھا کہ ہم یہ کر سکتے ہیں، یہ اثر دے گا اور کاروباری معاملے کا حساب لگائے گا۔
:
کامیابی بلکہ ایک اندرونی احساس ہے۔ کاروبار ہمیشہ زیادہ چاہتا ہے، اور ہمارے بیک لاگ کی گہرائی کامیابی کا ثبوت ہے۔ ایسا لگتا ہے مجھے۔
سرجی:
جی ہاں، میں اتفاق کرتا ہوں. تین سالوں میں، ہمارے پاس پہلے ہی دو سو سے زیادہ سروسز اور بیک لاگ ہیں۔ ٹیم کے اندر وسائل کی ضرورت صرف بڑھ رہی ہے - 30% سالانہ۔ یہ اس لیے ہو رہا ہے کہ لوگوں نے محسوس کیا: یہ تیز ہے، یہ مختلف ہے، مختلف ٹیکنالوجیز ہیں، یہ سب ترقی کر رہا ہے۔
مائیکرو سروسز آئیں گی، لیکن کور رہے گا۔
دمتری:
یہ ایک نہ ختم ہونے والے عمل کی طرح ہے جہاں آپ ترقی میں سرمایہ کاری کرتے ہیں۔ کیا کاروبار کے لیے مائیکرو سروسز کی منتقلی پہلے ہی ختم ہو چکی ہے یا نہیں؟
سرجی:
جواب دینا بہت آسان ہے۔ آپ کا کیا خیال ہے: فون کو تبدیل کرنا ایک نہ ختم ہونے والا عمل ہے؟ ہم خود ہر سال فون خریدتے ہیں۔ اور یہ ہے: جب تک رفتار کی ضرورت ہے، مارکیٹ میں موافقت کے لیے، کچھ تبدیلیاں درکار ہوں گی۔ اس کا یہ مطلب نہیں کہ ہم معیاری چیزوں کو چھوڑ دیں۔
لیکن ہم ایک ساتھ ہر چیز کو کور اور دوبارہ نہیں کر سکتے۔ ہمارے پاس میراثی، معیاری انضمام کی خدمات ہیں جو پہلے موجود تھیں: انٹرپرائز بسیں وغیرہ۔ لیکن ایک بیک لاگ ہے، اور ضرورت بھی ہے۔ موبائل ایپلی کیشنز کی تعداد اور ان کی فعالیت بڑھ رہی ہے۔ ساتھ ہی، کوئی یہ نہیں کہتا کہ آپ کو 30% زیادہ رقم دی جائے گی۔ یعنی ایک طرف ہمیشہ ضرورتیں ہوتی ہیں اور دوسری طرف کارکردگی کی تلاش۔
دمتری:
زندگی اچھی حالت میں ہے۔ (ہنستا ہے)
:
عام طور پر، ہاں۔ ہمارے پاس زمین کی تزئین سے بنیادی حصے کو ہٹانے کے لئے انقلابی نقطہ نظر نہیں ہے۔ نظاموں کو گلنے کے لیے منظم کام جاری ہے تاکہ وہ مائیکرو سروس فن تعمیر کے ساتھ زیادہ مطابقت رکھتے ہوں، تاکہ ایک دوسرے پر نظام کے اثر کو کم کیا جا سکے۔
لیکن ہم بنیادی حصے کو برقرار رکھنے کا ارادہ رکھتے ہیں، کیونکہ آپریٹر کے منظر نامے میں ہمیشہ کچھ پلیٹ فارمز ہوں گے جنہیں ہم خریدتے ہیں۔ ایک بار پھر، ہمیں صحت مند توازن کی ضرورت ہے: ہمیں بنیادی کو کاٹنے میں جلدی نہیں کرنی چاہیے۔ ہم سسٹمز کو ساتھ ساتھ رکھتے ہیں، اور اب پتہ چلا ہے کہ ہم پہلے ہی بہت سے بنیادی حصوں میں سب سے اوپر ہیں۔ مزید، فعالیت کو فروغ دیتے ہوئے، ہم ان تمام چینلز کے لیے ضروری نمائندگی بناتے ہیں جو ہماری مواصلاتی خدمات کے ساتھ کام کرتے ہیں۔
کاروباروں کو مائیکرو سروسز کیسے بیچیں۔
دمتری:
مجھے بھی دلچسپی ہے - ان لوگوں کے لیے جنہوں نے تبدیل نہیں کیا ہے، لیکن وہ منصوبہ بنا رہے ہیں: اس آئیڈیا کو کاروبار کو بیچنا کتنا آسان تھا اور کیا یہ ایک ایڈونچر، سرمایہ کاری کا منصوبہ تھا؟ یا یہ ایک شعوری حکمت عملی تھی: اب ہم مائیکرو سروسز پر جا رہے ہیں اور بس، ہمیں کوئی چیز نہیں روکے گی۔ یہ آپ کے لیے کیسا رہا؟
سرجی:
ہم ایک نقطہ نظر فروخت نہیں کر رہے تھے، لیکن ایک کاروباری فائدہ. کاروبار میں ایک مسئلہ تھا، اور ہم نے اسے حل کرنے کی کوشش کی۔ اس وقت، اس حقیقت کا اظہار کیا گیا تھا کہ مختلف چینلز نے قیمتوں کا حساب لگانے کے لئے مختلف اصولوں کا استعمال کیا - پروموشنز کے لئے الگ الگ، پروموشنز کے لئے، اور اسی طرح. اسے برقرار رکھنا مشکل تھا، غلطیاں ہوئیں، اور ہم نے صارفین کی شکایات سنیں۔ یعنی، ہم کسی مسئلے کا حل بیچ رہے تھے، لیکن ہم اس حقیقت کے ساتھ آئے کہ ہمیں پلیٹ فارم بنانے کے لیے پیسے کی ضرورت تھی۔ اور انہوں نے سرمایہ کاری کے پہلے مرحلے کی مثال کا استعمال کرتے ہوئے ایک کاروباری معاملہ دکھایا: ہم اسے کیسے دوبارہ حاصل کرتے رہیں گے اور یہ ہمیں کیا کرنے کی اجازت دے گا۔
دمتری:
کیا آپ نے کسی طرح پہلے مرحلے کا وقت ریکارڈ کیا؟
سرجی:
ہاں بالکل. ہم نے کور کو پلیٹ فارم کے طور پر بنانے اور پائلٹ کی جانچ کے لیے 6 ماہ مختص کیے ہیں۔ اس وقت کے دوران، ہم نے ایک پلیٹ فارم بنانے کی کوشش کی جس پر پائلٹ سکیٹنگ کر سکیں۔ پھر مفروضے کی تصدیق ہوئی، اور چونکہ یہ کام کرتا ہے، اس کا مطلب ہے کہ ہم جاری رکھ سکتے ہیں۔ انہوں نے ٹیم کو نقل کرنا اور مضبوط کرنا شروع کیا - انہوں نے اسے ایک الگ ڈویژن میں منتقل کیا جو کہ ایسا ہی کرتا ہے۔
اس کے بعد کاروبار کی ضروریات، مواقع، وسائل کی دستیابی اور ہر وہ چیز جو اس وقت کام جاری ہے پر مبنی منظم کام آتا ہے۔
دمتری:
ٹھیک ہے. سکندر، تم کیا کہتے ہو؟
:
ہماری مائیکرو سروسز "سمندر کے جھاگ" سے پیدا ہوئیں - وسائل کی بچت کی وجہ سے، سرور کی صلاحیت کی صورت میں کچھ بچا ہوا اور ٹیم کے اندر فورسز کی دوبارہ تقسیم کی وجہ سے۔ ابتدائی طور پر، ہم نے اس منصوبے کو کاروبار کو فروخت نہیں کیا. یہ ایک ایسا منصوبہ تھا جہاں ہم دونوں نے تحقیق کی اور اس کے مطابق ترقی کی۔ ہم نے 2018 کے آغاز میں آغاز کیا اور جوش و خروش کے ساتھ اس سمت کو تیار کیا۔ فروخت ابھی شروع ہوئی ہے اور ہم اس عمل میں ہیں۔
دمتری:
کیا ایسا ہوتا ہے کہ کوئی کاروبار آپ کو گوگل جیسے کام کرنے کی اجازت دیتا ہے - ہفتے میں ایک مفت دن؟ کیا آپ کے پاس ایسی سمت ہے؟
:
تحقیق کے ساتھ ساتھ، ہم نے کاروباری مسائل سے بھی نمٹا، اس لیے ہماری تمام مائیکرو سروسز کاروباری مسائل کا حل ہیں۔ صرف شروع میں ہم نے مائیکرو سروسز بنائی جس میں سبسکرائبر بیس کا ایک چھوٹا سا حصہ شامل تھا، اور اب ہم تقریباً تمام فلیگ شپ پروڈکٹس میں موجود ہیں۔
اور مادی اثرات پہلے ہی واضح ہیں - ہم پہلے ہی شمار کیے جاسکتے ہیں، اگر ہم پرانے راستے پر چلتے تو پروڈکٹ لانچ کی رفتار اور کھوئی ہوئی آمدنی کا اندازہ لگایا جاسکتا ہے۔ یہ وہی ہے جس پر ہم کیس بنا رہے ہیں۔
مائیکرو سروسز: ہائپ یا ضرورت؟
دمتری:
نمبر نمبر ہوتے ہیں۔ اور آمدنی یا رقم کی بچت بہت اہم ہے۔ دوسری طرف دیکھیں تو کیا ہوگا؟ ایسا لگتا ہے کہ مائیکرو سروسز ایک ٹرینڈ، ایک ہائپ ہے اور بہت سی کمپنیاں اس کا غلط استعمال کر رہی ہیں؟ مائیکرو سروسز میں آپ جو کچھ کرتے ہیں اور کیا نہیں کرتے اس میں آپ کس حد تک واضح طور پر فرق کرتے ہیں؟ اگر اب میراث ہے تو کیا 5 سال میں بھی آپ کے پاس میراث باقی رہے گی؟ M.Video-Eldorado اور MegaFon میں 5 سال میں کام کرنے والے انفارمیشن سسٹمز کی عمر کیا ہوگی؟ کیا دس سال، پندرہ سال پرانا انفارمیشن سسٹم ہوگا یا یہ نئی نسل ہوگی؟ آپ اسے کیسے دیکھتے ہیں؟
سرجی:
مجھے ایسا لگتا ہے کہ بہت دور سوچنا مشکل ہے۔ اگر ہم پیچھے مڑ کر دیکھیں تو کس نے سوچا تھا کہ ٹیکنالوجی کی مارکیٹ اس طرح ترقی کرے گی، بشمول مشین لرننگ اور چہرے کے ذریعے صارف کی شناخت؟ لیکن اگر آپ آنے والے سالوں پر نظر ڈالیں تو مجھے لگتا ہے کہ بنیادی نظام، کمپنیوں میں انٹرپرائز ERP کلاس سسٹمز - وہ کافی عرصے سے کام کر رہے ہیں۔
ہماری کمپنیاں مجموعی طور پر 25 سال پرانی ہیں، کلاسک ERP کے ساتھ سسٹمز کے منظر نامے میں بہت گہرا ہے۔ یہ واضح ہے کہ ہم وہاں سے کچھ ٹکڑوں کو نکال رہے ہیں اور انہیں مائیکرو سروسز میں جمع کرنے کی کوشش کر رہے ہیں، لیکن بنیادی بات باقی رہے گی۔ میرے لیے اب یہ تصور کرنا مشکل ہے کہ ہم وہاں کے تمام بنیادی نظاموں کو بدل دیں گے اور تیزی سے نئے نظاموں کے دوسرے روشن پہلو پر چلے جائیں گے۔
میں اس حقیقت کا حامی ہوں کہ ہر وہ چیز جو کلائنٹ اور صارف کے قریب ہوتی ہے جہاں سب سے بڑا کاروباری فائدہ اور قدر ہوتی ہے، جہاں موافقت اور رفتار پر توجہ مرکوز ہوتی ہے، تبدیلی پر، "کوشش، منسوخ، دوبارہ استعمال، کچھ مختلف کرنا" پر ہوتا ہے۔ ضرورت ہے "- یہ وہ جگہ ہے جہاں زمین کی تزئین کی تبدیلی ہوگی۔ اور باکسڈ پروڈکٹس وہاں بہت اچھی طرح سے فٹ نہیں ہوتے ہیں۔ کم از کم ہم اسے نہیں دیکھتے۔ وہاں سب سے آسان، آسان حل درکار ہیں۔
ہم اس ترقی کو دیکھتے ہیں:
- بنیادی معلوماتی نظام (زیادہ تر بیک آفس)؛
- مائیکرو سروسز کی شکل میں درمیانی پرتیں کور کو جوڑتی ہیں، جمع کرتی ہیں، کیش بناتی ہیں، وغیرہ۔
- فرنٹ لائن سسٹمز کا مقصد صارفین پر ہوتا ہے۔
- ایک انضمام کی تہہ جو عام طور پر بازاروں، دیگر نظاموں اور ماحولیاتی نظاموں میں ضم ہوتی ہے۔ یہ تہہ ممکنہ حد تک ہلکی، سادہ، اور کم از کم کاروباری منطق پر مشتمل ہے۔
لیکن اس کے ساتھ ساتھ میں پرانے اصولوں کا استعمال جاری رکھنے کا حامی ہوں اگر ان کا مناسب استعمال کیا جائے۔
ہم کہتے ہیں کہ آپ کے پاس ایک کلاسک انٹرپرائز سسٹم ہے۔ یہ ایک وینڈر کی زمین کی تزئین میں واقع ہے اور دو ماڈیولز پر مشتمل ہے جو ایک دوسرے کے ساتھ کام کرتے ہیں۔ ایک معیاری انضمام انٹرفیس بھی ہے۔ اسے دوبارہ کیوں کریں اور وہاں مائیکرو سروس کیوں لائیں؟
لیکن جب بیک آفس میں 5 ماڈیولز ہوتے ہیں، جن سے معلومات کے ٹکڑوں کو کاروباری عمل میں جمع کیا جاتا ہے، جسے پھر 8-10 فرنٹ لائن سسٹمز کے ذریعے استعمال کیا جاتا ہے، فائدہ فوری طور پر قابل دید ہوتا ہے۔ آپ پانچ بیک آفس سسٹمز سے لیتے ہیں اور ایک سروس بناتے ہیں، ایک الگ تھلگ، جو کہ کاروباری عمل پر مرکوز ہو۔ سروس کو تکنیکی طور پر جدید بنائیں - تاکہ یہ معلومات کو محفوظ کرے اور غلطی کو برداشت کرے، اور دستاویزات یا کاروباری اداروں کے ساتھ بھی کام کرے۔ اور آپ اسے تمام فرنٹ لائن پروڈکٹس کے ساتھ ایک اصول کے مطابق مربوط کرتے ہیں۔ انہوں نے فرنٹ لائن پروڈکٹ کو منسوخ کر دیا - انہوں نے صرف انضمام کو بند کر دیا۔ کل آپ کو ایک موبائل ایپلیکیشن لکھنے یا ایک چھوٹی سی ویب سائٹ بنانے کی ضرورت ہے اور صرف ایک حصہ کو فعالیت میں ڈالنا ہوگا - سب کچھ آسان ہے: آپ نے اسے کنسٹرکٹر کی طرح جمع کیا ہے۔ میں اس سمت میں زیادہ ترقی دیکھ رہا ہوں - کم از کم ہمارے ملک میں۔
:
سرجی نے ہمارے نقطہ نظر کو مکمل طور پر بیان کیا، شکریہ۔ میں صرف یہ کہوں گا کہ ہم یقینی طور پر کہاں نہیں جائیں گے - بنیادی حصے میں، آن لائن بلنگ کے موضوع پر۔ یعنی، ریٹنگ اور چارجنگ، درحقیقت، ایک "بڑا" تھریشر رہے گا جو قابل اعتماد طریقے سے پیسے کو ختم کر دے گا۔ اور یہ نظام ہماری ریگولیٹری اتھارٹیز سے تصدیق شدہ ہوتا رہے گا۔ ہر وہ چیز جو کلائنٹس کی طرف دیکھتی ہے، یقیناً مائیکرو سروسز ہیں۔
دمتری:
یہاں سرٹیفیکیشن ایک کہانی ہے۔ شاید زیادہ سپورٹ۔ اگر آپ سپورٹ پر بہت کم خرچ کرتے ہیں یا سسٹم کو سپورٹ اور ترمیم کی ضرورت نہیں ہے تو بہتر ہے کہ اسے ہاتھ نہ لگائیں۔ ایک معقول سمجھوتہ۔
قابل اعتماد مائیکرو سروسز کیسے تیار کریں۔
دمتری:
ٹھیک. لیکن مجھے اب بھی دلچسپی ہے۔ اب آپ ایک کامیابی کی کہانی سنا رہے ہیں: سب کچھ ٹھیک تھا، ہم نے مائیکرو سروسز کی طرف رخ کیا، کاروبار کے خیال کا دفاع کیا، اور سب کچھ کام کر گیا۔ لیکن میں نے دوسری کہانیاں سنی ہیں۔
کچھ سال پہلے، ایک سوئس کمپنی جس نے بینکوں کے لیے ایک نیا مائیکرو سروس پلیٹ فارم تیار کرنے میں دو سال کی سرمایہ کاری کی تھی بالآخر اس منصوبے کو بند کر دیا۔ مکمل طور پر منہدم ہو گیا۔ کئی ملین سوئس فرانک خرچ کیے گئے، اور آخر کار ٹیم منتشر ہو گئی - یہ کام نہیں کر سکا۔
کیا آپ کے پاس بھی ایسی ہی کہانیاں ہیں؟ کیا کوئی مشکلات تھیں یا ہیں؟ مثال کے طور پر، مائیکرو سروسز کو برقرار رکھنا اور نگرانی کرنا بھی کمپنی کی آپریشنل سرگرمیوں میں درد سر ہے۔ سب کے بعد، اجزاء کی تعداد دسیوں گنا بڑھ جاتی ہے. آپ اسے کیسے دیکھتے ہیں، کیا یہاں سرمایہ کاری کی ناکام مثالیں موجود ہیں؟ اور آپ لوگوں کو کیا نصیحت کر سکتے ہیں تاکہ وہ اس طرح کے مسائل کا سامنا نہ کریں؟
:
ناکام مثالوں میں کاروبار کی ترجیحات کو تبدیل کرنا اور منصوبوں کو منسوخ کرنا شامل ہے۔ جب تیاری کے اچھے مرحلے پر (حقیقت میں، MVP تیار ہے)، کاروبار نے کہا: "ہماری نئی ترجیحات ہیں، ہم ایک اور پروجیکٹ کی طرف بڑھ رہے ہیں، اور ہم اسے بند کر رہے ہیں۔"
ہمارے پاس مائیکرو سروسز کے ساتھ کوئی عالمی ناکامی نہیں ہے۔ ہم سکون سے سوتے ہیں، ہمارے پاس 24/7 ڈیوٹی شفٹ ہے جو پورے BSS [بزنس سپورٹ سسٹم] کی خدمت کرتی ہے۔
اور ایک چیز - ہم مائیکرو سروسز کو ان اصولوں کے مطابق کرائے پر دیتے ہیں جو باکسڈ مصنوعات پر لاگو ہوتے ہیں۔ کامیابی کی کلید یہ ہے کہ آپ کو، سب سے پہلے، ایک ایسی ٹیم کو جمع کرنے کی ضرورت ہے جو پیداوار کے لیے مائیکرو سروس کو مکمل طور پر تیار کرے۔ ترقی خود، مشروط طور پر، 40٪ ہے. باقی تجزیات، DevSecOps طریقہ کار، صحیح انضمام اور صحیح فن تعمیر ہے۔ ہم محفوظ ایپلی کیشنز بنانے کے اصولوں پر خصوصی توجہ دیتے ہیں۔ انفارمیشن سیکیورٹی کے نمائندے فن تعمیر کی منصوبہ بندی کے مرحلے اور عمل درآمد کے عمل کے دوران ہر منصوبے میں حصہ لیتے ہیں۔ وہ کمزوریوں کے لیے کوڈ کا تجزیہ کرنے کے نظام کا بھی انتظام کرتے ہیں۔
ہم کہتے ہیں کہ ہم اپنی بے وطن خدمات تعینات کرتے ہیں - ہمارے پاس وہ Kubernetes میں ہیں۔ یہ آٹو اسکیلنگ اور سروسز کی خود بخود اضافہ کی وجہ سے ہر ایک کو سکون سے سونے دیتا ہے، اور ڈیوٹی شفٹ واقعات کو اٹھاتا ہے۔
ہماری مائیکرو سروسز کے پورے وجود میں، صرف ایک یا دو واقعات ہوئے ہیں جو ہماری لائن تک پہنچے ہیں۔ اب آپریشن میں کوئی پریشانی نہیں ہے۔ یقیناً ہمارے پاس 200 نہیں بلکہ تقریباً 50 مائیکرو سروسز ہیں، لیکن وہ فلیگ شپ مصنوعات میں استعمال ہوتی ہیں۔ اگر وہ ناکام ہوئے تو ہم سب سے پہلے اس کے بارے میں جانیں گے۔
مائیکرو سروسز اور HR
سرجی:
میں اپنے ساتھی سے تعاون کی منتقلی کے بارے میں متفق ہوں - کہ کام کو صحیح طریقے سے منظم کرنے کی ضرورت ہے۔ لیکن میں آپ کو ان مسائل کے بارے میں بتاؤں گا جو یقیناً موجود ہیں۔
سب سے پہلے، ٹیکنالوجی نئی ہے. یہ ایک اچھے طریقے سے ہائپ ہے، اور ایک ایسے ماہر کو تلاش کرنا جو اسے سمجھے اور اسے تخلیق کر سکے، ایک بڑا چیلنج ہے۔ وسائل کے لئے مقابلہ پاگل ہے، لہذا ماہرین سونے میں ان کے وزن کے قابل ہیں.
دوم، بعض مناظر کی تخلیق اور خدمات کی بڑھتی ہوئی تعداد کے ساتھ، دوبارہ استعمال کا مسئلہ مسلسل حل ہونا چاہیے۔ جیسا کہ ڈویلپرز یہ کرنا پسند کرتے ہیں: "آئیے اب یہاں بہت سی دلچسپ چیزیں لکھتے ہیں..." اس کی وجہ سے، نظام رقم، ملکیت کی لاگت، وغیرہ کے لحاظ سے بڑھتا اور اپنی تاثیر کھو دیتا ہے۔ یعنی سسٹم آرکیٹیکچر میں دوبارہ استعمال کو شامل کرنا، سروسز کو متعارف کرانے اور میراث کو نئے فن تعمیر میں منتقل کرنے کے لیے روڈ میپ میں شامل کرنا ضروری ہے۔
ایک اور مسئلہ - اگرچہ یہ اپنے طریقے سے اچھا ہے - اندرونی مقابلہ ہے۔ "اوہ، یہاں نئے فیشن والے لوگ نمودار ہوئے ہیں، وہ ایک نئی زبان بولتے ہیں۔" لوگ، یقینا، مختلف ہیں. وہ لوگ ہیں جو جاوا میں لکھنے کے عادی ہیں، اور وہ لوگ جو لکھتے اور استعمال کرتے ہیں Docker اور Kubernetes۔ یہ بالکل مختلف لوگ ہیں، وہ مختلف طریقے سے بولتے ہیں، مختلف اصطلاحات استعمال کرتے ہیں اور بعض اوقات ایک دوسرے کو نہیں سمجھتے۔ اس لحاظ سے پریکٹس، نالج شیئرنگ کی قابلیت یا نا اہلی بھی ایک مسئلہ ہے۔
ٹھیک ہے، وسائل کی پیمائش۔ "بہت اچھا، چلو! اور اب ہم تیزی سے، مزید چاہتے ہیں۔ کیا، آپ نہیں کر سکتے؟ کیا سال میں دوگنا ڈیلیور کرنا ممکن نہیں؟ اور کیوں؟" اس طرح کے بڑھتے ہوئے درد شاید بہت سی چیزوں، بہت سے طریقوں کے لیے معیاری ہیں، اور آپ انہیں محسوس کر سکتے ہیں۔
نگرانی کے حوالے سے۔ مجھے ایسا لگتا ہے کہ خدمات یا صنعتی نگرانی کے اوزار پہلے ہی سیکھ رہے ہیں یا وہ Docker اور Kubernetes دونوں کے ساتھ مختلف، غیر معیاری وضع میں کام کرنے کے قابل ہیں۔ لہذا، مثال کے طور پر، آپ 500 جاوا مشینوں کے ساتھ ختم نہیں ہوتے ہیں جن کے تحت یہ سب چل رہا ہے، یعنی، یہ جمع ہوتا ہے۔ لیکن ان مصنوعات میں اب بھی پختگی کی کمی ہے؛ انہیں اس سے گزرنا ہوگا۔ موضوع واقعی نیا ہے، یہ ترقی کرتا رہے گا۔
دمتری:
جی ہاں، بہت دلچسپ. اور یہ HR پر لاگو ہوتا ہے۔ شاید آپ کا HR عمل اور HR برانڈ ان 3 سالوں میں تھوڑا بدل گیا ہے۔ آپ نے دوسرے لوگوں کو مختلف صلاحیتوں کے ساتھ بھرتی کرنا شروع کیا۔ اور غالباً نفع و نقصان دونوں ہیں۔ اس سے پہلے، بلاک چین اور ڈیٹا سائنس کا چرچا تھا، اور ان میں ماہرین کی مالیت لاکھوں میں تھی۔ اب لاگت گر رہی ہے، مارکیٹ سیر ہو رہی ہے، اور مائیکرو سروسز میں بھی ایسا ہی رجحان ہے۔
سرجی:
ہاں ضرور.
:
HR سوال پوچھتا ہے: "آپ کا گلابی ایک تنگاوالا بیک اینڈ اور فرنٹ اینڈ کے درمیان کہاں ہے؟" HR سمجھ نہیں پاتا کہ مائیکرو سروس کیا ہے۔ ہم نے انہیں راز بتایا اور بتایا کہ بیک اینڈ نے سب کچھ کیا، اور کوئی ایک تنگاوالا نہیں ہے۔ لیکن HR بدل رہا ہے، تیزی سے سیکھ رہا ہے اور ایسے لوگوں کو بھرتی کر رہا ہے جن کے پاس IT کا بنیادی علم ہے۔
مائیکرو سروسز کا ارتقاء
دمتری:
اگر آپ ٹارگٹ فن تعمیر کو دیکھیں تو مائیکرو سروسز اس طرح کے عفریت کی طرح نظر آتی ہیں۔ آپ کے سفر میں کئی سال لگے۔ دوسروں کے پاس ایک سال، دوسروں کے پاس تین سال۔ کیا آپ نے تمام مسائل، ہدف کے فن تعمیر کا اندازہ لگایا، کیا کچھ بدلا؟ مثال کے طور پر، مائیکرو سروسز کے معاملے میں، گیٹ ویز اور سروس میش اب دوبارہ نمودار ہو رہے ہیں۔ کیا آپ نے انہیں شروع میں استعمال کیا یا آپ نے خود فن تعمیر کو تبدیل کیا؟ کیا آپ کو ایسے چیلنجز ہیں؟
سرجی:
ہم نے پہلے ہی متعدد مواصلاتی پروٹوکول کو دوبارہ لکھا ہے۔ پہلے ایک پروٹوکول تھا، اب ہم دوسرے پر چلے گئے۔ ہم حفاظت اور وشوسنییتا کو بڑھاتے ہیں۔ ہم نے انٹرپرائز ٹیکنالوجیز - اوریکل، ویب لاجک کے ساتھ شروعات کی۔ اب ہم مائیکرو سروسز میں تکنیکی انٹرپرائز مصنوعات سے ہٹ کر اوپن سورس یا مکمل طور پر اوپن ٹیکنالوجیز کی طرف بڑھ رہے ہیں۔ ہم ڈیٹابیس کو چھوڑ دیتے ہیں اور اس ماڈل میں ہمارے لیے زیادہ مؤثر طریقے سے کام کرنے والے کی طرف چلے جاتے ہیں۔ ہمیں اب اوریکل ٹیکنالوجیز کی ضرورت نہیں ہے۔
ہم نے محض ایک سروس کے طور پر شروع کیا، یہ سوچے بغیر کہ ہمیں کیش کی کتنی ضرورت ہے، جب مائیکرو سروس کے ساتھ کوئی تعلق نہیں تھا، لیکن ڈیٹا کی ضرورت تھی، تو ہم کیا کریں گے۔ اب ہم ایک پلیٹ فارم تیار کر رہے ہیں تاکہ فن تعمیر کو بیان کیا جا سکے۔ خدمات کی زبان میں نہیں، اور کاروباری زبان میں، کاروباری منطق کو اگلے درجے تک لے جائیں جب ہم الفاظ میں بات کرنا شروع کریں۔ اب ہم نے حروف میں بولنا سیکھ لیا ہے، اور اگلی سطح وہ ہے جب خدمات کو کسی قسم کی مجموعی میں جمع کیا جائے گا، جب یہ پہلے سے ہی ایک لفظ ہے - مثال کے طور پر، ایک پورا پروڈکٹ کارڈ۔ اسے مائیکرو سروسز سے جمع کیا گیا ہے، لیکن یہ ایک API ہے جو اس کے اوپر بنایا گیا ہے۔
حفاظت بہت اہم ہے۔ جیسے ہی آپ قابل رسائی ہونا شروع کریں اور آپ کے پاس ایک سروس ہے جس کے ذریعے آپ بہت ساری دلچسپ چیزیں حاصل کر سکتے ہیں، اور بہت جلد، ایک الگ سیکنڈ میں، پھر اس کو حاصل کرنے کی خواہش پیدا ہوتی ہے جو کہ سب سے زیادہ محفوظ نہیں ہے۔ اس سے دور ہونے کے لیے، ہمیں جانچ اور نگرانی کے طریقوں کو تبدیل کرنا پڑا۔ ہمیں ٹیم، ڈیلیوری مینجمنٹ سٹرکچر، CI/CD کو تبدیل کرنا پڑا۔
یہ ایک ارتقاء ہے - فون کی طرح، صرف بہت تیز: پہلے پش بٹن والے فون تھے، پھر اسمارٹ فونز نمودار ہوئے۔ انہوں نے پروڈکٹ کو دوبارہ لکھا اور دوبارہ ڈیزائن کیا کیونکہ مارکیٹ کی ضرورت مختلف تھی۔ ہم اس طرح تیار ہوتے ہیں: پہلی جماعت، دسویں جماعت، کام۔
تکراری طور پر، ٹیکنالوجی کے نقطہ نظر سے ہر سال کچھ رکھا جاتا ہے، کچھ اور بیک لاگ اور ضروریات کے نقطہ نظر سے۔ ہم ایک چیز کو دوسری چیز سے جوڑتے ہیں۔ ٹیم ٹیم کے لیے 20% تکنیکی قرض اور تکنیکی مدد پر خرچ کرتی ہے، 80% کاروباری ادارے پر۔ اور ہم اس بات کی سمجھ کے ساتھ آگے بڑھتے ہیں کہ ہم یہ کیوں کر رہے ہیں، ہم یہ تکنیکی بہتری کیوں کر رہے ہیں، ان سے کیا حاصل ہو گا۔ اس کی طرح.
دمتری:
ٹھنڈا MegaFon میں کیا ہے؟
:
جب ہم مائیکرو سروسز پر آئے تو سب سے بڑا چیلنج افراتفری میں نہ پڑنا تھا۔ MegaFon کے آرکیٹیکچرل آفس نے فوری طور پر ہمارے ساتھ شمولیت اختیار کی، یہاں تک کہ ایک ابتدائی اور ڈرائیور بن گیا - اب ہمارے پاس ایک بہت مضبوط فن تعمیر ہے۔ اس کا کام یہ سمجھنا تھا کہ ہم کس ٹارگٹ ماڈل پر جا رہے ہیں اور کن ٹیکنالوجیز کو پائلٹ کرنے کی ضرورت ہے۔ فن تعمیر کے ساتھ، ہم نے خود ان پائلٹوں کا انعقاد کیا۔
اگلا سوال یہ تھا: "تو پھر اس سب کا فائدہ کیسے اٹھایا جائے؟" اور ایک اور: "مائیکرو سروسز کے درمیان شفاف تعامل کو کیسے یقینی بنایا جائے؟" سروس میش نے آخری سوال کا جواب دینے میں ہماری مدد کی۔ ہم نے Istio کو پائلٹ کیا اور نتائج کو پسند کیا۔ اب ہم پیداواری زونز میں داخل ہونے کے مرحلے پر ہیں۔ ہم تمام چیلنجوں کے بارے میں مثبت رویہ رکھتے ہیں - حقیقت یہ ہے کہ ہمیں اسٹیک کو مسلسل تبدیل کرنے، کچھ نیا سیکھنے کی ضرورت ہے۔ ہم ترقی کرنے میں دلچسپی رکھتے ہیں، پرانے حلوں کا استحصال کرنے میں نہیں۔
دمتری:
سنہری الفاظ! اس طرح کے چیلنجز ٹیم اور کاروبار کو اپنی انگلیوں پر رکھتے ہیں اور مستقبل بناتے ہیں۔ GDPR نے چیف ڈیٹا پروٹیکشن آفیسرز بنائے، اور موجودہ چیلنجز نے چیف مائیکرو سروسز اور آرکیٹیکچر آفیسرز بنائے۔ اور یہ راضی ہے۔
ہم نے بہت بحث کی۔ اہم بات یہ ہے کہ مائیکرو سروسز کا ایک اچھا ڈیزائن اور فن تعمیر ہی آپ کو بہت سی غلطیوں سے بچنے کی اجازت دیتا ہے۔ بلاشبہ یہ عمل تکراری اور ارتقائی ہے، لیکن یہ مستقبل ہے۔
تمام شرکاء کا شکریہ، سرگئی اور الیگزینڈر کا شکریہ!
سامعین کے سوالات
سامعین سے سوال (1):
سرجی، آپ کی کمپنی میں آئی ٹی مینجمنٹ کیسے بدلی ہے؟ میں سمجھتا ہوں کہ جب کئی سسٹمز کا ایک بڑا ڈھیر ہوتا ہے، تو اس کا انتظام کیسے کیا جاتا ہے یہ کافی واضح اور منطقی عمل ہے۔ اتنے کم وقت میں بہت بڑی تعداد میں مائیکرو سروسز کے ضم ہونے کے بعد آپ نے IT جزو کے انتظام کو دوبارہ کیسے بنایا؟
سرجی:
میں اپنے ساتھی سے اتفاق کرتا ہوں کہ تبدیلی کے ڈرائیور کے طور پر فن تعمیر بہت اہم ہے۔ ہم نے ایک آرکیٹیکچرل ڈویژن رکھنے سے آغاز کیا۔ معمار بیک وقت فعالیت کی تقسیم اور زمین کی تزئین میں اس کے ظاہر ہونے کی ضروریات کے مالک ہوتے ہیں۔ چنانچہ وہ ان تبدیلیوں کے کوآرڈینیٹر کے طور پر بھی کام کرتے ہیں۔ نتیجے کے طور پر، جب ہم نے CI/CD پلیٹ فارم بنایا تو ایک مخصوص ترسیل کے عمل میں خاص تبدیلیاں ہوئیں۔
لیکن ترقی کے معیاری، بنیادی اصول، کاروباری تجزیہ، جانچ اور ترقی کو منسوخ نہیں کیا گیا ہے۔ ہم نے صرف رفتار شامل کی ہے۔ اس سے پہلے، سائیکل نے اتنا زیادہ لیا، ٹیسٹ کے ماحول پر انسٹالیشن میں بہت زیادہ وقت لگا۔ اب کاروبار فائدہ دیکھتا ہے اور کہتا ہے: "ہم دوسری جگہوں پر ایسا کیوں نہیں کر سکتے؟"
یہ ایک اچھے طریقے سے، ایک ویکسین کی شکل میں ایک انجیکشن کی طرح ہے جس نے دکھایا: آپ اسے اس طرح کر سکتے ہیں، لیکن آپ اسے دوسرے طریقے سے کر سکتے ہیں۔ بلاشبہ، اہلکاروں میں، اہلیت میں، علم میں، مزاحمت میں ایک مسئلہ ہے۔
سامعین سے سوال (2):
مائیکرو سروس فن تعمیر کے ناقدین کا کہنا ہے کہ جانچ اور ترقی مشکل ہے۔ یہ منطقی ہے جہاں چیزیں پیچیدہ ہوجاتی ہیں۔ آپ کی ٹیم کو کن چیلنجوں کا سامنا کرنا پڑا اور آپ نے ان پر کیسے قابو پایا؟ سب کے لیے سوال۔
:
مائیکرو سروسز سے پلیٹ فارم پر جاتے وقت مشکلات ہوتی ہیں، لیکن انہیں حل کیا جا سکتا ہے۔
مثال کے طور پر، ہم ایک پروڈکٹ بنا رہے ہیں جو 5-7 مائیکرو سروسز پر مشتمل ہے۔ ہمیں ماسٹر برانچ میں جانے کے لیے گرین لائٹ دینے کے لیے پورے مائیکرو سروسز اسٹیک پر انضمام کے ٹیسٹ فراہم کرنے کی ضرورت ہے۔ یہ کام ہمارے لیے نیا نہیں تھا: ہم یہ کام طویل عرصے سے بی ایس ایس میں کر رہے تھے، جب وینڈر نے ہمیں پہلے سے بھیجے گئے حل فراہم کیے تھے۔
اور ہمارا مسئلہ صرف چھوٹی ٹیم میں ہے۔ ایک مشروط پروڈکٹ کے لیے ایک QA انجینئر کی ضرورت ہے۔ اور اس طرح، ہم 5-7 مائیکرو سروسز کا ایک پروڈکٹ بھیجتے ہیں، جن میں سے 2-3 تیسرے فریق تیار کر سکتے ہیں۔ مثال کے طور پر، ہمارے پاس ایک پروڈکٹ ہے جس میں ہمارا بلنگ سسٹم وینڈر، Mail.ru گروپ اور MegaFon R&D حصہ لیتے ہیں۔ ہمیں اسے پروڈکشن میں بھیجنے سے پہلے ٹیسٹ کے ساتھ احاطہ کرنے کی ضرورت ہے۔ QA انجینئر ڈیڑھ ماہ سے اس پروڈکٹ پر کام کر رہا ہے، اور باقی ٹیم اس کے تعاون کے بغیر رہ گئی ہے۔
یہ پیچیدگی صرف اسکیلنگ کی وجہ سے ہوتی ہے۔ ہم سمجھتے ہیں کہ مائیکرو سروسز خلا میں موجود نہیں ہوسکتی ہیں؛ مطلق تنہائی موجود نہیں ہے۔ ایک سروس کو تبدیل کرتے وقت، ہم ہمیشہ API معاہدے کو محفوظ رکھنے کی کوشش کرتے ہیں۔ اگر ہڈ کے نیچے کچھ بدل جاتا ہے، تو سامنے کی خدمت باقی رہتی ہے۔ اگر تبدیلیاں مہلک ہیں تو، کسی قسم کی تعمیراتی تبدیلی رونما ہوتی ہے اور ہم بالکل مختلف ڈیٹا میٹا ماڈل پر چلے جاتے ہیں، جو کہ مکمل طور پر مطابقت نہیں رکھتا ہے - تب ہی ہم v2 سروس API کی تفصیلات ظاہر ہونے کے بارے میں بات کرتے ہیں۔ ہم پہلے اور دوسرے ورژن کو بیک وقت سپورٹ کرتے ہیں، اور تمام صارفین کے دوسرے ورژن پر جانے کے بعد، ہم صرف پہلا ورژن بند کر دیتے ہیں۔
سرجی:
میں شامل کرنا چاہتا ہوں۔ میں پیچیدگیوں کے بارے میں بالکل متفق ہوں - وہ ہوتے ہیں۔ زمین کی تزئین مزید پیچیدہ ہوتی جا رہی ہے، اور اوور ہیڈ اخراجات بڑھ رہے ہیں، خاص طور پر جانچ کے لیے۔ اس سے کیسے نمٹا جائے: خودکار ٹیسٹنگ پر جائیں۔ جی ہاں، آپ کو آٹو ٹیسٹ اور یونٹ ٹیسٹ لکھنے میں اضافی سرمایہ کاری کرنا ہوگی۔ تاکہ ڈویلپرز ٹیسٹ پاس کیے بغیر ارتکاب نہ کر سکیں، وہ کوڈ کو تبدیل نہیں کر سکتے۔ تاکہ پش بٹن بھی آٹو ٹیسٹ، یونٹ ٹیسٹ کے بغیر کام نہ کرے۔
پچھلی فعالیت کو برقرار رکھنا ضروری ہے، اور یہ اضافی اوور ہیڈ ہے۔ اگر آپ کسی ٹیکنالوجی کو دوسرے پروٹوکول میں دوبارہ لکھتے ہیں، تو آپ اسے دوبارہ لکھتے ہیں جب تک کہ آپ سب کچھ مکمل طور پر بند نہ کر دیں۔
ہم بعض اوقات جان بوجھ کر اینڈ ٹو اینڈ ٹیسٹنگ نہیں کرتے، کیونکہ ہم ترقی کو روکنا نہیں چاہتے، حالانکہ ہمارے پاس بھی ایک کے بعد ایک چیز ہوتی ہے۔ زمین کی تزئین کی بہت بڑی، پیچیدہ ہے، بہت سے نظام ہیں. کبھی کبھی یہ صرف سٹبس ہوتا ہے - ہاں، آپ حفاظتی مارجن کو کم کرتے ہیں، مزید خطرات ظاہر ہوتے ہیں۔ لیکن اسی وقت آپ سپلائی جاری کرتے ہیں۔
:
ہاں، آٹو ٹیسٹس اور یونٹ ٹیسٹ آپ کو اعلیٰ معیار کی سروس بنانے کی اجازت دیتے ہیں۔ ہم ایک پائپ لائن کے لیے ہیں جو یونٹ اور انضمام کے ٹیسٹ کے بغیر نہیں گزر سکتی۔ ہمیں اکثر ایمولیٹرز اور کمرشل سسٹمز کو ٹیسٹ زونز اور ڈیولپمنٹ ماحول میں گھسیٹنا پڑتا ہے، کیونکہ تمام سسٹمز کو ٹیسٹ زون میں نہیں رکھا جا سکتا۔ مزید یہ کہ، وہ صرف گیلے نہیں ہوتے ہیں - ہم سسٹم کی طرف سے ایک مکمل ردعمل پیدا کرتے ہیں۔ یہ مائیکرو سروسز کے ساتھ کام کرنے کا ایک سنجیدہ حصہ ہے، اور ہم اس میں سرمایہ کاری بھی کر رہے ہیں۔ اس کے بغیر افراتفری پھیلے گی۔
سامعین سے سوال (3):
جہاں تک میں سمجھتا ہوں، مائیکرو سروسز شروع میں ایک الگ ٹیم سے بڑھی تھیں اور اب اس ماڈل میں موجود ہیں۔ اس کے فوائد اور نقصانات کیا ہیں؟
ہمارے پاس ابھی ایک ایسی ہی کہانی ہے: ایک قسم کی مائیکرو سروسز فیکٹری پیدا ہوئی۔ اب ہم تصوراتی طور پر اس مقام پر پہنچ چکے ہیں کہ ہم اس نقطہ نظر کو ندیوں اور نظاموں کے ذریعے پیداوار تک بڑھا رہے ہیں۔ دوسرے لفظوں میں، ہم مائیکرو سروسز، مائیکرو سرویس ماڈلز کی مرکزی ترقی سے دور ہو رہے ہیں، اور سسٹمز کے قریب تر ہوتے جا رہے ہیں۔
اس کے مطابق، ہمارا آپریشن سسٹمز پر بھی جاتا ہے، یعنی ہم اس موضوع کو ڈی سینٹرلائز کر رہے ہیں۔ آپ کا نقطہ نظر کیا ہے اور آپ کی ٹارگٹ اسٹوری کیا ہے؟
:
آپ نے "مائیکرو سروسز فیکٹری" کا نام اپنے منہ سے نکال دیا - ہم بھی پیمانہ کرنا چاہتے ہیں۔ سب سے پہلے، اب ہمارے پاس واقعی ایک ٹیم ہے۔ ہم تمام ترقیاتی ٹیموں کو فراہم کرنا چاہتے ہیں جو MegaFon کے پاس ایک مشترکہ ماحولیاتی نظام میں کام کرنے کا موقع ہے۔ ہم ان تمام ترقیاتی فعالیتوں پر مکمل طور پر قبضہ نہیں کرنا چاہتے جو اب ہمارے پاس ہے۔ مقامی کام پیمانہ بنانا ہے، عالمی کام مائیکرو سروس پرت میں تمام ٹیموں کی ترقی کی رہنمائی کرنا ہے۔
سرجی:
میں آپ کو بتاؤں گا کہ ہم نے جو راستہ اختیار کیا ہے۔ ہم نے واقعی ایک ٹیم کے طور پر کام کرنا شروع کیا، لیکن اب ہم اکیلے نہیں ہیں۔ میں مندرجہ ذیل کا حامی ہوں: عمل کا ایک مالک ہونا چاہیے۔ کسی کو مائیکرو سروسز کی ترقی کے عمل کو سمجھنے، ان کا نظم کرنے، کنٹرول کرنے اور اسے بنانے کی ضرورت ہے۔ اسے وسائل کا مالک ہونا چاہیے اور وسائل کے انتظام میں مشغول ہونا چاہیے۔
یہ وسائل، جو ٹیکنالوجی، تفصیلات جانتے ہیں اور مائیکرو سروسز بنانے کا طریقہ سمجھتے ہیں، پروڈکٹ ٹیموں میں موجود ہو سکتے ہیں۔ ہمارے پاس ایک مرکب ہے جہاں مائیکرو سروس پلیٹ فارم کے لوگ موبائل ایپلیکیشن بنانے والی مصنوعات کی ٹیم میں شامل ہیں۔ وہ وہاں موجود ہیں، لیکن وہ اپنے ڈویلپمنٹ مینیجر کے ساتھ مائیکرو سروس پلیٹ فارم مینجمنٹ ڈیپارٹمنٹ کے عمل کے مطابق کام کرتے ہیں۔ اس ڈویژن کے اندر ایک الگ ٹیم ہے جو ٹیکنالوجی سے نمٹتی ہے۔ یعنی، ہم وسائل کے ایک مشترکہ پول کو اپنے درمیان ملاتے ہیں اور انہیں تقسیم کرتے ہیں، ٹیموں کو دیتے ہیں۔
ایک ہی وقت میں، عمل عام رہتا ہے، کنٹرول ہوتا ہے، یہ عام تکنیکی اصولوں کے مطابق آگے بڑھتا ہے، یونٹ ٹیسٹنگ کے ساتھ اور اسی طرح - ہر وہ چیز جو سب سے اوپر بنائی گئی ہے۔ مصنوعات کے نقطہ نظر کے مختلف محکموں سے جمع کردہ وسائل کی شکل میں کالم ہوسکتے ہیں۔
:
سرجی، آپ اصل میں اس عمل کے مالک ہیں، ٹھیک ہے؟ کیا ٹاسک بیک لاگ شیئر کیا گیا ہے؟ اس کی تقسیم کا ذمہ دار کون ہے؟
سرجی:
دیکھو: یہاں ایک بار پھر مرکب ہے۔ ایک بیک لاگ ہے جو تکنیکی بہتری پر مبنی ہے - یہ ایک کہانی ہے۔ ایک بیک لاگ ہے، جو پراجیکٹس سے تیار کیا جاتا ہے، اور پروڈکٹس کا بیک لاگ ہے۔ لیکن ہر ایک سروس پروڈکٹس میں تعارف یا اس سروس کی تخلیق کا سلسلہ ایک پروڈکٹ ماہر تیار کرتا ہے۔ وہ آئی ٹی ڈائریکٹوریٹ میں نہیں ہیں، انہیں خصوصی طور پر اس سے ہٹا دیا گیا ہے۔ لیکن میرے لوگ اسی عمل کے مطابق کام ضرور کرتے ہیں۔
مختلف سمتوں میں بیک لاگ کے مالک - تبدیلیوں کا بیک لاگ - مختلف لوگ ہوں گے۔ تکنیکی خدمات کا تعلق، ان کے تنظیمی اصول - یہ سب آئی ٹی میں ہوگا۔ میں پلیٹ فارم اور وسائل کا بھی مالک ہوں۔ سب سے اوپر وہی ہے جو بیک لاگ اور فعال تبدیلیوں، اور اس معنی میں فن تعمیر سے متعلق ہے۔
ہم کہتے ہیں کہ ایک کاروبار کہتا ہے: "ہم یہ فنکشن چاہتے ہیں، ہم ایک نئی پروڈکٹ بنانا چاہتے ہیں - ایک قرض دوبارہ بنائیں۔" ہم جواب دیتے ہیں: "ہاں، ہم اسے دوبارہ کریں گے۔" معمار کہتے ہیں: "آئیے سوچتے ہیں: ہم قرض میں مائیکرو سروسز کہاں لکھیں گے اور ہم اسے کیسے کریں گے؟" پھر ہم اسے پراجیکٹس، پروڈکٹس یا ٹیکنالوجی کے ڈھیر میں توڑ دیتے ہیں، اسے ٹیموں میں ڈالتے ہیں اور اسے نافذ کرتے ہیں۔ کیا آپ نے اندرونی طور پر کوئی پروڈکٹ بنایا ہے اور اس پروڈکٹ میں مائیکرو سروسز استعمال کرنے کا فیصلہ کیا ہے؟ ہم کہتے ہیں: "اب ہمارے پاس موجود میراثی نظام، یا فرنٹ لائن سسٹمز کو ان مائیکرو سروسز میں تبدیل ہونا چاہیے۔" معمار کہتے ہیں: "تو: فرنٹ لائن پروڈکٹس کے اندر تکنیکی بیک لاگ میں - مائیکرو سروسز میں منتقلی۔ جاؤ". اور مصنوعات کے ماہرین یا کاروباری مالکان سمجھتے ہیں کہ کتنی گنجائش مختص کی گئی ہے، یہ کب اور کیوں کی جائے گی۔
بحث کا اختتام، لیکن تمام نہیں
میلٹو:کلاؤڈ کانفرنس کا اہتمام کیا گیا۔ .
ہم دیگر تقریبات بھی کرتے ہیں - جیسے @Kubernetes میٹ اپ، جہاں ہم ہمیشہ بہترین مقررین کی تلاش میں رہتے ہیں:
- ہمارے ٹیلیگرام چینل میں @Kubernetes اور دیگر @Meetup خبروں کو فالو کریں۔
- @Meetups میں سے کسی ایک پر بات کرنے میں دلچسپی ہے؟ کے لیے ایک درخواست چھوڑیں۔
ماخذ: www.habr.com