هيلو، حبر! مان توهان جي ڌيان ڏانهن پيش ڪريان ٿو ليکڪ جي مضمون جو ترجمو .
هڪ دفعي جڏهن آئي ٽي دنيا آهستي آهستي مائڪرو سروسز ۽ اوزار جهڙوڪ ڪبرنيٽس ڏانهن وڌي رهي آهي، صرف هڪ مسئلو وڌيڪ ۽ وڌيڪ قابل ذڪر ٿي رهيو آهي. هي مسئلو - microservice ورجن. اڃا تائين، آئي ٽي ڪميونٽي کي يقين آهي ته موجوده صورتحال کان گهڻو بهتر آهي ٽيڪنالاجي جي اڳوڻي نسل. بهرحال، مائڪرو سروسز جو نسخو هڪ تمام پيچيده مسئلو آهي. ان جو هڪ ثبوت مضمون ٿي سگهي ٿو جهڙوڪ .
جيڪڏهن توهان اڃا تائين هن متن کي پڙهڻ سان مسئلو نه سمجهي، مون کي وضاحت ڪرڻ ڏيو. اچو ته توهان جي پيداوار تي مشتمل آهي 10 microservices. هاڻي اچو ته فرض ڪريون ته 1 نئون ورزن انهن مان هر هڪ مائڪرو سروسز لاءِ جاري ڪيو ويو آهي. صرف 1 نسخو - مون کي اميد آهي ته اسان سڀ ان ڳالهه تي متفق ٿي سگهون ٿا ته هي هڪ تمام معمولي ۽ غير معمولي حقيقت آهي. هاڻي، بهرحال، اچو ته اسان جي پيداوار تي هڪ ٻيو نظر وٺو. هر جزو جي صرف هڪ نئين ورزن سان، اسان وٽ هاڻي 2^10 - يا 1024 اجازتون آهن ته اسان جي پيداوار ڪيئن ٺاهي سگهجي ٿي.
جيڪڏهن اڃا تائين ڪا غلط فهمي آهي، مون کي رياضي کي ٽوڙڻ ڏيو. تنهن ڪري اسان وٽ 10 microservices آهن، هر هڪ کي هڪ تازه ڪاري ملي ٿي. اهو آهي، اسان حاصل ڪندا آهيون 2 ممڪن نسخو هر مائڪرو سروس لاءِ (يا ته پراڻي يا نئين). هاڻي، هر هڪ پيداوار جي اجزاء لاء، اسان انهن ٻنهي نسخن مان ڪنهن کي استعمال ڪري سگهون ٿا. رياضياتي طور تي، اهو ساڳيو آهي ڄڻ ته اسان وٽ 10 عددن جو بائنري نمبر هجي. مثال طور، اچو ته چئون ته 1 نئون ورزن آهي، ۽ 0 پراڻو ورزن آهي - پوءِ هڪ ممڪن اجازت ڏئي سگهجي ٿو 1001000000 - جتي 1st ۽ 4th جزا اپڊيٽ ٿيل آهن، ۽ ٻيا سڀئي نه آهن. رياضي مان اسان ڄاڻون ٿا ته هڪ 10-عددي بائنري نمبر 2^10 يا 1024 قدر ٿي سگهي ٿو. اھو آھي، اسان تصديق ڪيو آھي تعداد جي پيماني تي جيڪو اسان ڊيل ڪري رھيا آھيون.
اچو ته اسان جي استدلال کي وڌيڪ جاري رکون - ڇا ٿيندو جيڪڏهن اسان وٽ 100 مائڪرو سروسز آهن ۽ هر هڪ 10 ممڪن نسخو آهي؟ سڄي صورتحال ڪافي ناخوشگوار ٿي وڃي ٿي - اسان وٽ هاڻي 10^100 اجازتون آهن - جيڪو هڪ وڏو انگ آهي. بهرحال، مان هن صورتحال کي هن طريقي سان ليبل ڪرڻ کي ترجيح ڏيان ٿو، ڇاڪاڻ ته هاڻي اسان لفظن جي پويان نه لڪائي رهيا آهيون جهڙوڪ "kubernetes"، بلڪه ان مسئلي کي منهن ڏئي رهيا آهيون جيئن اهو آهي.
مان هن مسئلي کان ايترو متوجه ڇو آهيان؟ جزوي طور تي ڇاڪاڻ ته، اڳ ۾ NLP ۽ AI جي دنيا ۾ ڪم ڪري چڪو آهي، اسان تقريبا 5-6 سال اڳ گڏيل ڌماڪي جي مسئلي تي بحث ڪيو. صرف نسخن جي بدران اسان وٽ انفرادي لفظ هئا، ۽ مصنوعات جي بدران اسان وٽ جملا ۽ پيراگراف هئا. ۽ جيتوڻيڪ NLP ۽ AI جا مسئلا گهڻو ڪري حل نه ٿيا آهن، اهو تسليم ڪرڻ گهرجي ته گذريل ڪجهه سالن ۾ اهم ترقي ڪئي وئي آهي. (منهنجي خيال ۾، ترقي ٿي سگهي ٿيоاهو بهتر ٿيندو جيڪڏهن صنعت ۾ ماڻهو مشين سکيا ڏانهن ٿورو گهٽ ڌيان ڏين ۽ ٻين ٽيڪنالاجي ڏانهن ٿورو وڌيڪ - پر اهو اڳ ۾ ئي موضوع کان ٻاهر آهي).
اچو ته واپس وڃو DevOps ۽ microservices جي دنيا ۾. اسان کي هڪ وڏي مسئلي سان منهن ڏيڻو پوي ٿو، ڪنسٽڪاميرا ۾ هڪ هاٿي وانگر نقاب پوش - ڇاڪاڻ ته جيڪو آئون اڪثر ٻڌندو آهيان اهو آهي "بس ڪبرنيٽس ۽ هيلم وٺو، ۽ سڀ ڪجهه ٺيڪ ٿي ويندو!" پر نه، سڀ ڪجهه ٺيڪ نه ٿيندو جيڪڏهن سڀ ڪجهه ائين ئي رهجي وڃي. ان کان سواء، هن مسئلي جو هڪ تجزياتي حل ان جي پيچيدگي جي ڪري قابل قبول نه ٿو لڳي. جيئن ته اين ايل پي ۾، اسان کي پهريون ڀيرو هن مسئلي کي ڳولڻ گهرجي ڳولا جي دائري کي تنگ ڪندي- هن صورت ۾، پراڻي اجازتن کي ختم ڪندي.
انهن شين مان هڪ آهي جيڪا مدد ڪري سگهي ٿي جيڪا مون گذريل سال لکي هئي . اهو پڻ نوٽ ڪرڻ ضروري آهي ته هڪ چڱي طرح ٺهيل CI/CD پروسيس تمام گهڻي تبديلي کي گهٽائڻ ۾ مدد ڪري ٿي. بهرحال، CI/CD سان معاملن جي موجوده حالت ايتري سٺي ناهي ته اجازتن جي مسئلي کي حل ڪرڻ لاءِ اضافي اوزارن کان سواءِ اڪائونٽنگ ۽ ٽريڪنگ حصن لاءِ.
جيڪو اسان کي ضرورت آهي انٽيگريشن اسٽيج تي تجربو جو هڪ نظام آهي، جتي اسان هر جزو لاءِ خطري جي عنصر جو تعين ڪري سگهون ٿا، ۽ پڻ مختلف حصن کي اپڊيٽ ڪرڻ ۽ آپريٽر جي مداخلت کان سواءِ ٽيسٽ ڪرڻ لاءِ هڪ خودڪار عمل آهي - ڏسڻ لاءِ ته ڇا ڪم ڪري ٿو ۽ ڇا نٿو ڪري.
تجربن جي اهڙي نظام هن طرح نظر اچي سگهي ٿو:
- ڊولپر ٽيسٽ لکندا آهن (هي هڪ نازڪ مرحلو آهي - ڇاڪاڻ ته ٻي صورت ۾ اسان وٽ ڪو به تشخيصي معيار ناهي - اهو مشين جي سکيا ۾ ڊيٽا کي ليبل ڪرڻ وانگر آهي).
- هر جزو (پروجيڪٽ) پنهنجو پنهنجو سي آءِ سسٽم حاصل ڪري ٿو - اهو عمل هاڻي بهتر طور تي ترقي يافته آهي، ۽ هڪ واحد جزو لاءِ CI سسٽم ٺاهڻ جو مسئلو گهڻو ڪري حل ڪيو ويو آهي.
- "سمارٽ انٽيگريشن سسٽم" مختلف CI سسٽم جا نتيجا گڏ ڪري ٿو ۽ اجزاء جي منصوبن کي حتمي پراڊڪٽ ۾ گڏ ڪري ٿو، ٽيسٽ کي هلائي ٿو ۽ آخرڪار موجوده اجزاء ۽ خطري جي فڪر جي بنياد تي گهربل پيداوار جي ڪارڪردگي حاصل ڪرڻ لاء ننڍو رستو حساب ڪري ٿو. جيڪڏهن هڪ تازه ڪاري ممڪن نه آهي، اهو سسٽم ڊولپرز کي موجوده اجزاء جي باري ۾ مطلع ڪري ٿو ۽ انهن مان ڪهڙو مسئلو آهي. هڪ ڀيرو ٻيهر، ٽيسٽ سسٽم هتي اهم اهميت رکي ٿو - ڇاڪاڻ ته انضمام سسٽم ٽيسٽ کي هڪ تشخيصي معيار طور استعمال ڪري ٿو.
- سي ڊي سسٽم، جيڪو پوءِ سمارٽ انٽيگريشن سسٽم مان ڊيٽا وصول ڪري ٿو ۽ سڌو سنئون تازه ڪاري ڪري ٿو. هي مرحلو چڪر کي ختم ڪري ٿو.
اختصار ڪرڻ لاءِ، مون لاءِ هاڻي سڀ کان وڏو مسئلو هڪ اهڙي ”سمارٽ انٽيگريشن سسٽم“ جو نه هجڻ آهي جيڪو مختلف حصن کي هڪ پراڊڪٽ ۾ ڳنڍيندو ۽ اهڙي طرح توهان کي اهو معلوم ڪرڻ جي اجازت ڏيندو ته مجموعي طور پراڊڪٽ کي ڪيئن گڏ ڪيو ويو آهي. مان هن تي ڪميونٽي جي خيالن ۾ دلچسپي وٺندس (اسپائلر - مان هن وقت هڪ منصوبي تي ڪم ڪري رهيو آهيان ، جيڪو اهڙي سمارٽ انٽيگريشن سسٽم بڻجي سگهي ٿو).
هڪ آخري شيءِ جنهن جو مان ذڪر ڪرڻ چاهيان ٿو، اهو آهي ته، مون لاءِ، ڪنهن به پراجيڪٽ جي وچولي سائيز لاءِ مونولٿ قابل قبول ناهي. مون لاءِ، ڪوششون تيزيءَ سان عمل درآمد جي وقت ۽ ترقيءَ جي معيار کي ھڪ اڪيلائي ڏانھن موٽڻ سان وڏي شڪ جو سبب بڻجندي آھي. پهرين، هڪ monolith اجزاء کي منظم ڪرڻ جو ساڳيو مسئلو آهي - مختلف لائبريرين جي وچ ۾، جنهن تي مشتمل آهي، جڏهن ته، اهو سڀ ڪجهه قابل ذڪر نه آهي ۽ پاڻ کي ظاهر ڪري ٿو بنيادي طور تي ڊولپر پاران خرچ ڪيل وقت ۾. monolith مسئلي جو نتيجو ڪوڊ ۾ تبديليون ڪرڻ جي مجازي ناممڪن آهي - ۽ انتهائي سست ترقي جي رفتار.
Microservices صورتحال کي بهتر بڻائي ٿو، پر پوء microservice فن تعمير کي انضمام واري مرحلي تي گڏيل ڌماڪي جي مسئلي کي منهن ڏيڻو پوي ٿو. ها، عام طور تي، اسان ساڳئي مسئلي کي ترقي واري مرحلي کان انضمام واري مرحلي ڏانهن منتقل ڪيو آهي. بهرحال، منهنجي خيال ۾، مائڪرو سروسز جو طريقو اڃا تائين بهتر نتيجا ڏئي ٿو، ۽ ٽيمون تيزيءَ سان نتيجا حاصل ڪن ٿيون (شايد بنيادي طور تي ڊولپمينٽ يونٽ جي سائيز ۾ گهٽتائي جي ڪري - يا بيچ جي ماپ). بهرحال، monolith کان microservices ڏانهن منتقل ٿيڻ اڃا تائين عمل کي ڪافي بهتر نه ڪيو آهي - microservice نسخن جو گڏيل ڌماڪو هڪ وڏو مسئلو آهي، ۽ اسان وٽ صورتحال کي بهتر ڪرڻ جي تمام گهڻي صلاحيت آهي جيئن اسان ان کي حل ڪريون.
جو ذريعو: www.habr.com