بغير سرور ايپليڪيشنن جي تعمير لاء طريقا ۽ وسيلا

بغير سرور ايپليڪيشنن جي تعمير لاء طريقا ۽ وسيلا
جيتوڻيڪ سرور بيس ٽيڪنالاجيز تيزي سان مقبوليت حاصل ڪئي آهي تازن سالن ۾، اڃا تائين ڪيتريون ئي غلط فهميون ۽ خوف انهن سان لاڳاپيل آهن. وينڊر انحصار، ٽولنگ، قيمت جو انتظام، ٿڌي شروعات، مانيٽرنگ، ۽ ترقي جي زندگي تمام گرم موضوع آهن جڏهن اهو سرور کان سواء ٽيڪنالاجيون اچي ٿو. هن آرٽيڪل ۾، اسان ذڪر ڪيل ڪجهه عنوانن کي ڳوليندا سين، انهي سان گڏ معلومات جي مددگار ذريعن جا ٽوٽڪا ۽ لنڪ شيئر ڪندا سين ته جيئن نئين سکندڙن کي طاقتور، لچڪدار، ۽ قيمتي سرور کان سواءِ ايپليڪيشنون ٺاهڻ ۾ مدد ملي سگهي.

سرور بيس ٽيڪنالاجيز بابت غلط فڪر

گھڻن ماڻھن جو خيال آھي ته بي سرور ۽ بي سرور پروسيسنگ (خدمت جي طور تي ڪم، FaaS) لڳ ڀڳ ساڳي شيءِ آهن. هن جو مطلب اهو آهي ته فرق تمام وڏو نه آهي ۽ اهو هڪ ناول کي متعارف ڪرائڻ جي قابل آهي. جيتوڻيڪ AWS Lambda هڪ ستارن مان هڪ هو سرور لیس هيڊ ڊي ۽ هڪ تمام مشهور عنصرن مان هڪ سرور لیس فن تعمير، جڏهن ته، هي فن تعمير FaaS کان گهڻو وڌيڪ آهي.

بي سرور ٽيڪنالاجيز جي پويان بنيادي اصول اهو آهي ته توهان کي پنهنجي انفراسٽرڪچر جي انتظام ۽ اسڪيلنگ بابت پريشان ٿيڻ جي ضرورت ناهي، توهان صرف ان لاءِ ادا ڪندا آهيو جيڪي توهان استعمال ڪندا آهيو. ڪيتريون ئي خدمتون انهن معيارن کي پورو ڪن ٿيون - AWS DynamoDB، S3، SNS يا SQS، Graphcool، Auth0، Now، Netlify، Firebase ۽ ٻيا ڪيترائي. عام طور تي، بي سرور جو مطلب آهي ڪلائوڊ ڪمپيوٽنگ جي مڪمل طاقت استعمال ڪرڻ بغير انفراسٽرڪچر کي منظم ڪرڻ ۽ ان کي اسڪيلنگ لاءِ بهتر ڪرڻ. ان جو مطلب اهو پڻ آهي ته بنيادي ڍانچي جي سطح تي سيڪيورٽي هاڻي توهان جي ڳڻتي ناهي، جيڪا سيڪيورٽي معيارن کي ملڻ جي مشڪل ۽ پيچيدگي جي ڪري هڪ وڏو فائدو آهي. آخرڪار، توهان کي فراهم ڪيل زيربنا خريد ڪرڻ جي ضرورت ناهي.

بي سرور سمجهي سگهجي ٿو "دماغ جي حالت": هڪ خاص ذهنيت جڏهن حل ٺاهيندي. طريقن کان پاسو ڪريو جيڪي ڪنهن به انفراسٽرڪچر جي سار سنڀال جي ضرورت هونديون آهن. بي سرور طريقي سان، اسان ڪمن کي حل ڪرڻ ۾ وقت گذاريون ٿا جيڪي سڌو سنئون پروجيڪٽ تي اثرانداز ٿين ٿا ۽ اسان جي استعمال ڪندڙن لاءِ فائدا آڻين ٿا: اسان پائيدار ڪاروباري منطق ٺاهي، يوزر انٽرفيس کي ترقي ڪريون، ۽ موافقت ۽ قابل اعتماد APIs ٺاهي.

مثال طور، جيڪڏهن اهو ممڪن آهي ته هڪ مفت ٽيڪسٽ سرچ پليٽ فارم کي منظم ۽ برقرار رکڻ کان بچڻ، پوء اهو ئي آهي جيڪو اسان ڪنداسين. ايپليڪيشنن کي تعمير ڪرڻ لاء اهو طريقو تمام گهڻو تيز ڪري سگهي ٿو مارڪيٽ ۾ وقت، ڇو ته توهان کي هاڻي پيچيده انفراسٽرڪچر کي منظم ڪرڻ بابت سوچڻ جي ضرورت ناهي. ذميدارين ۽ انفراسٽرڪچر مينيجمينٽ جي قيمتن کي ختم ڪريو ۽ ايپليڪيشنن ۽ خدمتن جي تعمير تي ڌيان ڏيو جيڪي توهان جي گراهڪن کي گهربل آهن. پيٽرڪ ڊيبوس هن طريقي کي سڏيو 'خدمتگار'، اصطلاح سرور بيس ڪميونٽي ۾ قبول ڪيو ويو آهي. ڪمن کي سوچڻ گهرجي ته خدمتن جي لنڪ جي طور تي ترتيب ڏيڻ جي قابل ماڊل طور (هڪ پوري لائبريري يا ويب ايپليڪيشن کي ترتيب ڏيڻ جي بدران). هي ترتيب ڏيڻ ۽ ايپليڪيشن ۾ تبديلين کي منظم ڪرڻ لاءِ ناقابل اعتماد گرينولرٽي فراهم ڪري ٿو. جيڪڏهن توهان هن طريقي سان ڪم نه ٿا ڪري سگهو، پوء اهو ظاهر ڪري سگھي ٿو ته فنڪشن تمام گهڻا ڪم انجام ڏين ٿا ۽ ريفڪٽر ٿيڻ جي ضرورت آهي.

ڪجهه پريشان آهن وينڊر تي انحصار ڪندي جڏهن ڪلائوڊ ايپليڪيشنون ٺاهي رهيا آهن. ساڳيو ئي سرور بيس ٽيڪنالاجي سان سچو آهي، ۽ اهو مشڪل سان غلط فڪر آهي. اسان جي تجربي ۾، AWS تي بي سرور ايپليڪيشنون ٺاهڻ، AWS Lambda جي ٻين AWS خدمتن کي گڏ ڪرڻ جي صلاحيت سان گڏ، بي سرور آرڪيٽيڪچر جي قوت جو حصو آهي. هي مطابقت جو هڪ سٺو مثال آهي، جڏهن ميلاپ جو نتيجو صرف اصطلاحن جي مجموعن کان وڌيڪ آهي. وينڊر انحصار کان بچڻ جي ڪوشش ڪري سگھي ٿو وڌيڪ مسئلن ۾. جڏهن ڪنٽينرز سان ڪم ڪندي، ڪلائوڊ فراهم ڪندڙن جي وچ ۾ توهان جي پنهنجي تجريدي پرت کي منظم ڪرڻ آسان آهي. پر جڏهن اهو سرور کان سواءِ حلن تي اچي ٿو، ڪوشش ادا نه ٿيندي، خاص طور تي جيڪڏهن قيمت جي اثرائتي کي شروعات کان حساب ۾ ورتو وڃي. معلوم ڪرڻ جي پڪ ڪريو ته ڪيئن وينڊرز خدمتون مهيا ڪن ٿا. ڪجهه خاص خدمتون ٻين وينڊرز سان انٽيگريشن پوائنٽس تي ڀاڙين ٿيون ۽ شايد دٻي کان ٻاهر پلگ ۽ راند ڪنيڪشن فراهم ڪن ٿيون. ڪجهه ڪنٽينر يا EC2 مثال جي درخواست کي پراکسي ڪرڻ جي ڀيٽ ۾ گيٽ وي API جي آخري پوائنٽ کان Lambda ڪال مهيا ڪرڻ آسان آهي. Graphcool Auth0 سان آسان ٺاھ جوڙ مهيا ڪري ٿو، جيڪو ٽئين پارٽي جي تصديق ڪندڙ اوزار استعمال ڪرڻ کان وڌيڪ آسان آھي.

توهان جي بي سرور ايپليڪيشن لاءِ صحيح وينڊر چونڊڻ هڪ تعميراتي فيصلو آهي. جڏهن توهان هڪ ايپليڪيشن ٺاهيندا آهيو، توهان کي اميد نه آهي ته هڪ ڏينهن سرور جي انتظام ڏانهن واپسي. ڪلائوڊ وينڊر چونڊڻ ڪنٽينر يا ڊيٽابيس استعمال ڪرڻ، يا پروگرامنگ ٻولي پڻ استعمال ڪرڻ کان مختلف ناهي.

غور ڪريو:

  • توهان کي ڪهڙي خدمتن جي ضرورت آهي ۽ ڇو.
  • ڪلائوڊ فراهم ڪندڙ ڪهڙيون خدمتون مهيا ڪن ٿا ۽ توهان انهن کي پنهنجي چونڊيل FaaS حل سان ڪيئن گڏ ڪري سگهو ٿا.
  • ڪھڙي پروگرامنگ ٻولين کي سپورٽ ڪيو ويو آھي (متحرڪ يا جامد ٽائپنگ سان، مرتب ڪيل يا تشريح ٿيل، معيار ڇا آھن، سرد شروعات تي ڪارڪردگي ڇا آھي، اوپن سورس ايڪو سسٽم ڇا آھي، وغيره).
  • توهان جي حفاظتي گهرجون ڇا آهن (SLA، 2FA، OAuth، HTTPS، SSL، وغيره).
  • توهان جي CI/CD ۽ سافٽ ويئر ڊولپمينٽ سائيڪل کي ڪيئن منظم ڪجي.
  • ڪهڙو انفراسٽرڪچر-جيئن-ڪوڊ حل توهان فائدو وٺي سگهو ٿا.

جيڪڏهن توهان هڪ موجوده ايپليڪيشن کي وڌايو ۽ وڌ ۾ وڌ سرور جي بغير ڪارڪردگي شامل ڪريو، اهو شايد موجود صلاحيتن کي ڪجهه حد تائين محدود ڪري سگهي ٿو. بهرحال، تقريبن سڀئي سرور بيس ٽيڪنالاجيون مهيا ڪن ٿيون ڪجهه قسم جي API (ذريعي REST يا پيغام جي قطارن ذريعي) جيڪا توهان کي ايڪسٽينشن ٺاهڻ جي اجازت ڏئي ٿي ايپليڪيشن ڪور کان آزاد ۽ آسان انضمام سان. صاف APIs، سٺي دستاويز، ۽ مضبوط ڪميونٽي سان خدمتون ڳوليو، ۽ توهان غلط نه ٿي سگهو. انضمام جي آساني اڪثر ڪري هڪ اهم ميٽرڪ ٿي سگهي ٿي، ۽ شايد اهو هڪ اهم سبب آهي ڇو ته AWS ايترو ڪامياب ٿي چڪو آهي جڏهن کان 2015 ۾ Lambda کي آزاد ڪيو ويو.

جڏهن بي سرور سٺو آهي

بي سرور ٽيڪنالاجيون لڳ ڀڳ هر هنڌ لاڳو ٿي سگهن ٿيون. تنهن هوندي، انهن جا فائدا صرف ايپليڪيشن جي هڪ طريقي تائين محدود نه آهن. ڪلائوڊ ڪمپيوٽنگ لاءِ داخلا ۾ رڪاوٽ اڄ تمام گهٽ آهي مهرباني ڪري بي سرور ٽيڪنالاجيز جي مهرباني. جيڪڏهن ڊولپرز وٽ هڪ خيال آهي، پر انهن کي خبر ناهي ته ڪلائوڊ انفراسٽرڪچر کي ڪيئن منظم ڪجي ۽ قيمتن کي بهتر ڪجي، پوءِ انهن کي اهو ڪرڻ لاءِ ڪنهن قسم جو انجنيئر ڳولڻ جي ضرورت ناهي. جيڪڏهن هڪ شروعاتي پليٽ فارم ٺاهڻ چاهي ٿو پر خوف آهي ته قيمتون ڪنٽرول کان ٻاهر ٿي سگهن ٿيون، اهي آساني سان بغير سرور حلن ڏانهن رخ ڪري سگهن ٿا.

قيمت جي بچت ۽ اسڪيلنگ جي آسانيءَ جي ڪري، بي سرور حل هڪجهڙائي سان لاڳو آهن ٻنهي اندروني ۽ بيروني سسٽم لاءِ، هڪ ويب ايپليڪيشن تائين ملٽي ملين سامعين سان. اڪائونٽون ماپي وينديون آهن بلڪه يورو ۾، پر سينٽ ۾. هڪ مهيني لاءِ AWS EC2 (t1.micro) جو آسان ترين مثال ڪرائي تي ڏيڻ جي قيمت €15 هوندي، جيتوڻيڪ توهان ان سان ڪجهه به نه ڪيو (جيڪو ڪڏهن به ان کي بند ڪرڻ نه وساريو؟!). مقابلي ۾، ساڳئي عرصي دوران خرچن جي هن سطح تائين پهچڻ لاءِ، توهان کي 512 MB Lambda هلائڻو پوندو 1 سيڪنڊن لاءِ اٽڪل 3 ملين ڀيرا. ۽ جيڪڏھن توھان ھن خصوصيت کي استعمال نٿا ڪريو، پوء توھان ڪجھ به ادا نه ڪندا.

ڇاڪاڻ ته بي سرور بنيادي طور تي واقعن تي مبني آهي، پراڻن سسٽمن ۾ بي سرور انفراسٽرڪچر شامل ڪرڻ بلڪل آسان آهي. مثال طور، AWS S3، Lambda، ۽ Kinesis استعمال ڪندي، توهان هڪ پراڻي پرچون سسٽم لاءِ هڪ تجزياتي خدمت ٺاهي سگهو ٿا جيڪا API ذريعي ڊيٽا حاصل ڪري سگهي ٿي.

گهڻن سرور کان سواء پليٽ فارم ڪيترن ئي ٻولين جي حمايت ڪن ٿا. گهڻو ڪري اهو Python، JavaScript، C#، Java ۽ Go آهي. عام طور تي سڀني ٻولين ۾ لائبريرين جي استعمال تي ڪابه پابنديون نه هونديون آهن، تنهنڪري توهان پنهنجي پسنديده اوپن سورس لائبريريون استعمال ڪري سگهو ٿا. بهرحال، اهو مشورو ڏنو ويو آهي ته انحصار کي غلط استعمال نه ڪيو وڃي ته جيئن توهان جا ڪم بهتر نموني انجام ڏين ۽ توهان جي بي سرور ايپليڪيشنن جي وڏي پيماني تي فائدن کي رد نه ڪن. وڌيڪ پيڪيجز جن کي ڪنٽينر ۾ لوڊ ڪرڻ جي ضرورت آهي، اوترو ٿڌو شروع ٿيندو.

هڪ ٿڌي شروعات آهي جڏهن توهان کي استعمال ڪرڻ کان پهريان پهرين ڪنٽينر، رن ٽائم، ۽ غلطي سنڀاليندڙ کي شروع ڪرڻ جي ضرورت آهي. انهي جي ڪري، ڪارڪردگي جي عمل ۾ دير ٿي سگهي ٿي 3 سيڪنڊن تائين، ۽ اهو بي صبر استعمال ڪندڙن لاء بهترين اختيار ناهي. بهرحال، سردي شروع ٿئي ٿي پهرين ڪال تي ڪجهه منٽن جي بيڪار ڪم کان پوءِ. تنهن ڪري ڪيترائي هن کي هڪ معمولي ناراضگي سمجهن ٿا جنهن کي ڪم ڪري سگهجي ٿو باقاعدي طور تي پنگ ڪندي فنڪشن کي بيڪار رکڻ لاءِ. يا اهي هن پاسو کي مڪمل طور تي نظر انداز ڪن ٿا.

جيتوڻيڪ AWS جاري ڪيو سرور کان سواءِ SQL ڊيٽابيس سرور بيس اوروراجڏهن ته، SQL ڊيٽابيس هن ايپليڪيشن لاءِ مثالي نه آهن، ڇاڪاڻ ته اهي ٽرانزيڪشن کي انجام ڏيڻ لاءِ ڪنيڪشن تي ڀاڙين ٿا، جيڪي جلدي AWS Lambda تي ڳري ٽرئفڪ سان هڪ رڪاوٽ بڻجي سگهن ٿيون. ها، ڊولپرز مسلسل بهتر ڪري رهيا آهن بي سرور ارورا، ۽ توهان کي ان سان تجربو ڪرڻ گهرجي، پر اڄ NoSQL حل وانگر DynamoDB. بهرحال، ان ۾ ڪو شڪ ناهي ته اها صورتحال تمام جلد تبديل ٿي ويندي.

ٽول ڪٽ پڻ تمام گهڻيون پابنديون لاڳو ڪري ٿو، خاص طور تي مقامي جاچ جي ميدان ۾. جيتوڻيڪ اهڙا حل آهن جهڙوڪ Docker-Lambda، DynamoDB Local ۽ LocalStack، انهن کي سخت محنت ۽ ترتيب جي وڏي مقدار جي ضرورت آهي. بهرحال، اهي سڀئي منصوبا فعال طور تي ترقي يافته آهن، تنهنڪري اهو صرف وقت جو معاملو آهي ان کان اڳ جو ٽول ڪٽ اسان جي گهربل سطح تي پهچي.

ترقي جي چڪر تي بي سرور ٽيڪنالاجيز جو اثر

ڇاڪاڻ ته توهان جو انفراسٽرڪچر صرف هڪ ترتيب آهي، توهان اسڪرپٽ استعمال ڪندي ڪوڊ وضاحت ۽ ترتيب ڏئي سگهو ٿا، جهڙوڪ شيل اسڪرپٽ. يا توهان استعمال ڪري سگهو ٿا ترتيب ڏيڻ جي طور تي-ڪوڊ ڪلاس حل جهڙوڪ AWS Cloud Formation. جيتوڻيڪ هي خدمت سڀني علائقن لاءِ ترتيب فراهم نه ڪندي آهي، اها توهان کي اجازت ڏئي ٿي ته مخصوص وسيلن کي استعمال ڪرڻ لاءِ Lambda افعال جي طور تي. اهو آهي، جتي CloudFormation توهان کي ناڪام ٿئي ٿي، توهان لکي سگهو ٿا پنهنجو وسيلو (Lambda فنڪشن) جيڪو هن خال کي بند ڪري ڇڏيندو. انهي طريقي سان توهان ڪجھ به ڪري سگهو ٿا، جيتوڻيڪ توهان جي AWS ماحول کان ٻاهر انحصار کي ترتيب ڏيو.

ڇاڪاڻ ته اهو سڀ ڪجهه صرف ترتيب آهي، توهان مخصوص ماحول، علائقن ۽ استعمال ڪندڙن لاءِ پنهنجي ڊيپلائيمينٽ اسڪرپٽ کي ترتيب ڏئي سگهو ٿا، خاص طور تي جيڪڏهن توهان استعمال ڪري رهيا آهيو انفراسٽرڪچر-جي-ڪوڊ حل جهڙوڪ CloudFormation. مثال طور، توهان ذخيرو ۾ هر شاخ لاءِ انفراسٽرڪچر جي هڪ ڪاپي ترتيب ڏئي سگهو ٿا ته جيئن توهان ترقي جي دوران انهن کي مڪمل طور تي اڪيلائي ۾ جانچي سگهو. اهو ڊولپرز جي راءِ کي تيزيءَ سان تيز ڪري ٿو جڏهن اهي سمجهڻ چاهين ٿا ته ڇا انهن جو ڪوڊ زنده ماحول ۾ مناسب ڪم ڪري ٿو. مينيجرز کي گھڻن ماحوليات کي ترتيب ڏيڻ جي قيمت جي باري ۾ پريشان ٿيڻ جي ضرورت ناهي، ڇاڪاڻ ته اهي صرف حقيقي استعمال لاء ادا ڪندا آهن.

DevOps کي گهٽ پريشانيون آهن ڇو ته انهن کي صرف پڪ ڪرڻ جي ضرورت آهي ته ڊولپرز وٽ صحيح ترتيب ڏنل آهي. توھان کي ھاڻي ضرورت نه آھي منظم ڪرڻ جي مثالن، بيلنسرز، يا سيڪيورٽي گروپ. تنهن ڪري، اصطلاح NoOps تيزيء سان استعمال ڪيو ويو آهي، جيتوڻيڪ اهو اڃا تائين ضروري آهي ته بنيادي جوڙجڪ کي ترتيب ڏيڻ جي قابل ٿي، خاص طور تي جڏهن اهو اچي ٿو IAM ترتيب ۽ بادل وسيلن جي اصلاح.

هتي تمام طاقتور مانيٽرنگ ۽ ويزولائيزيشن جا اوزار آهن جهڙوڪ ايپساگون، ٿنڊرا، ڊيش برڊ ۽ IOPipe. اهي توهان کي توهان جي بي سرور ايپليڪيشنن جي موجوده حالت جي نگراني ڪرڻ جي اجازت ڏين ٿا، لاگنگ ۽ ٽريڪنگ مهيا ڪن ٿا، ڪارڪردگي جي ماپ ۽ فن تعمير جي رڪاوٽ کي پڪڙڻ، قيمت جو تجزيو ۽ اڳڪٿي ڪرڻ، ۽ وڌيڪ. اهي نه رڳو DevOps انجنيئرن، ڊولپرز ۽ آرڪيٽيڪٽس کي ايپليڪيشن جي ڪارڪردگي جو هڪ جامع نظارو ڏين ٿا، پر مينيجرز کي پڻ اجازت ڏين ٿا ته اهي حقيقي وقت ۾ صورتحال جي نگراني ڪن، في سيڪنڊ وسيلن جي قيمتن ۽ قيمت جي اڳڪٿي سان. اهو هڪ منظم زيربنا سان هن کي منظم ڪرڻ تمام گهڻو ڏکيو آهي.

بغير سرور جي ايپليڪيشنن کي ڊزائين ڪرڻ تمام آسان آهي ڇو ته توهان کي ويب سرورز کي ترتيب ڏيڻ، ورچوئل مشينن يا ڪنٽينرز، پيچ سرورز، آپريٽنگ سسٽم، انٽرنيٽ گيٽ ويز وغيره کي ترتيب ڏيڻ جي ضرورت ناهي. انهن سڀني ذميوارين کي ختم ڪندي، هڪ سرور لیس فن تعمير بنيادي تي ڌيان ڏئي سگهي ٿو - حل. ڪاروبار ۽ ڪسٽمر جي ضرورتن.

جڏهن ته ٽول ڪٽ بهتر ٿي سگهي ٿو (اهو هر روز بهتر ٿئي ٿو)، ڊولپرز ڪاروباري منطق کي لاڳو ڪرڻ تي ڌيان ڏئي سگهن ٿا ۽ ايپليڪيشن جي پيچيدگي کي مختلف خدمتن ۾ آرڪيٽيڪچر جي اندر ورهائڻ تي. سرور کان سواءِ ايپليڪيشن مئنيجمينٽ ايونٽ تي ٻڌل آهي ۽ ڪلائوڊ فراهم ڪندڙ (مثال طور SQS، S3 واقعن يا DynamoDB اسٽريمز) طرفان خلاصو آهي. تنهن ڪري، ڊولپرز کي صرف ڪجهه واقعن جو جواب ڏيڻ لاءِ ڪاروباري منطق لکڻ جي ضرورت آهي، ۽ انهي بابت پريشان ٿيڻ جي ضرورت ناهي ته ڊيٽابيس ۽ پيغام جي قطار کي ڪيئن لاڳو ڪجي، يا مخصوص هارڊويئر اسٽوريج ۾ ڊيٽا سان بهتر ڪم کي ڪيئن منظم ڪجي.

ڪوڊ هلائي سگھجي ٿو ۽ مقامي طور تي ڊيبگ ڪيو وڃي، جيئن ڪنهن به ترقياتي عمل سان. يونٽ جي جاچ ساڳي رهي. ڪسٽم اسٽيڪ ترتيب سان مڪمل ايپليڪيشن انفراسٽرڪچر کي ترتيب ڏيڻ جي صلاحيت ڊولپرز کي جلدي اهم موٽ حاصل ڪرڻ جي اجازت ڏئي ٿي بغير جانچ جي قيمت يا قيمتي منظم ماحول تي اثر جي باري ۾ سوچڻ جي.

بغير سرور ايپليڪيشنن جي تعمير لاء اوزار ۽ ٽيڪنالاجي

بي سرور ايپليڪيشنون ٺاهڻ جو ڪو خاص طريقو ناهي. انهي سان گڏ هن ڪم لاء خدمتن جو هڪ سيٽ. AWS اڄ طاقتور سرور بيس حلن جي وچ ۾ اڳواڻ آهي، پر پڻ ڏسو Google Cloud, وقت и باهه. جيڪڏهن توهان AWS استعمال ڪري رهيا آهيو، ايپليڪيشنون گڏ ڪرڻ لاء تجويز ڪيل طريقو آهي بي سرور ايپليڪيشن ماڊل (SAM)، خاص طور تي جڏهن استعمال ڪندي C#، ڇاڪاڻ ته بصري اسٽوڊيو ۾ وڏو اوزار آهي. SAM CLI سڀ ڪجھ ڪري سگھي ٿو جيڪو Visual Studio ڪري سگھي ٿو، تنھنڪري توھان ڪجھ به نه وڃائيندؤ جيڪڏھن توھان ٻئي IDE يا ٽيڪسٽ ايڊيٽر ڏانھن وڃو. يقينا، SAM ٻين ٻولين سان گڏ ڪم ڪري ٿو.

جيڪڏهن توهان ٻين ٻولين ۾ لکي رهيا آهيو، سرور لیس فريم ورڪ هڪ بهترين اوپن سورس ٽول آهي جيڪو توهان کي اجازت ڏئي ٿو ڪنهن به شيءِ کي تمام طاقتور YAML ڪنفيگريشن فائلن سان ترتيب ڏيڻ جي. سرور لیس فريم ورڪ پڻ مختلف ڪلائوڊ سروسز کي سپورٽ ڪري ٿو، تنهنڪري اسان ان کي انهن لاءِ سفارش ڪريون ٿا جيڪي ملٽي ڪلائوڊ حل ڳولي رهيا آهن. اهو هڪ وڏو ڪميونٽي آهي جنهن کي ڪنهن به ضرورت لاء پلگ ان جو هڪ گروپ ٺاهيو آهي.

مقامي جاچ لاءِ، اوپن سورس جا اوزار Docker-Lambda، Serverless Local، DynamoDB Local، ۽ LocalStack چڱيءَ طرح موزون آهن. بي سرور ٽيڪنالاجيون اڃا تائين ترقي جي شروعاتي مرحلن ۾ آهن، جيئن انهن لاءِ اوزار آهن، تنهن ڪري جڏهن پيچيده ٽيسٽ منظرنامي لاءِ ترتيب ڏيڻ، توهان کي محنت ڪرڻي پوندي. جڏهن ته، صرف هڪ ماحول ۾ اسٽيڪ کي ترتيب ڏيڻ ۽ جانچ ڪرڻ ناقابل يقين حد تائين سستو آهي. ۽ توهان کي ڪلائوڊ ماحول جي صحيح مقامي ڪاپي ٺاهڻ جي ضرورت ناهي.

AWS Lambda Layers استعمال ڪريو مقرر ٿيل پيڪيجز جي سائيز کي گهٽائڻ ۽ ڊائون لوڊ کي تيز ڪرڻ لاءِ.

مخصوص ڪمن لاءِ صحيح پروگرامنگ ٻوليون استعمال ڪريو. مختلف ٻولين جا پنهنجا پنهنجا فائدا ۽ نقصان آهن. اتي ڪيترائي معيار آھن، پر JavaScript، Python، ۽ C# (.NET Core 2.1+) AWS Lambda ڪارڪردگي جي لحاظ کان اڳواڻ آھن. AWS Lambda تازو متعارف ڪرايو Runtime API، جيڪو توهان کي توهان جي گهربل ٻولي ۽ رن ٽائم ماحول جي وضاحت ڪرڻ جي اجازت ڏئي ٿو، تنهنڪري تجربو ڪريو.

ترتيب ڏيڻ لاءِ پيڪيج جا سائز ننڍا رکو. اهي ننڍا آهن، اهي تيزيء سان لوڊ ڪن ٿا. وڏيون لائبريريون استعمال ڪرڻ کان پاسو ڪريو، خاص طور تي جيڪڏھن توھان انھن مان ڪجھ خاصيتون استعمال ڪريو. جيڪڏھن توھان جاوا اسڪرپٽ ۾ پروگرام ڪري رھيا آھيو، ھڪڙي تعمير وارو اوزار استعمال ڪريو جيئن توھان جي تعمير کي بهتر ڪرڻ لاءِ Webpack ۽ صرف اھو شامل ڪريو جيڪو توھان کي واقعي جي ضرورت آھي. .NET ڪور 3.0 ۾ QuickJit ۽ Tiered Compilation آھي جيڪو ڪارڪردگي کي بھتر ڪري ٿو ۽ ٿڌي شروعات تي گھڻو مدد ڪري ٿو.

واقعن تي بي سرور افعال جو انحصار ان کي پهريان کان ڪاروباري منطق کي همٿائڻ ڏکيو بڻائي سگھي ٿو. انهي سلسلي ۾، پيغام جون قطارون ۽ رياستي مشينون ناقابل اعتماد حد تائين ڪارائتو ٿي سگهن ٿيون. Lambda فنڪشن هڪ ٻئي کي ڪال ڪري سگهن ٿا، پر اهو صرف ان صورت ۾ ڪريو جڏهن توهان جواب جي اميد نه رکو ("فائر ۽ وساريو") - توهان نٿا چاهيو ته توهان ڪنهن ٻئي فنڪشن جي مڪمل ٿيڻ جي انتظار ۾ بل حاصل ڪرڻ نٿا چاهيو. پيغام جون قطارون ڪاروباري منطق جي حصن کي الڳ ڪرڻ، ايپليڪيشن جي رڪاوٽ کي منظم ڪرڻ، ۽ ٽرانزيڪشن جي پروسيسنگ (FIFO قطار استعمال ڪندي) لاء ڪارائتو آهن. AWS Lambda افعال کي SQS قطارن کي اسٽيڪ پيغام جي قطار طور مقرر ڪري سگھجي ٿو جيڪي بعد ۾ تجزيي لاءِ ناڪام پيغامن جي ٽريڪ رکو. AWS Step Functions (State machines) پيچيده عملن کي منظم ڪرڻ لاءِ تمام ڪارآمد آهن جن کي زنجير جي ڪمن جي ضرورت هوندي آهي. هڪ Lambda فنڪشن جي بدران هڪ ٻئي فنڪشن کي سڏڻ، اسٽيپ افعال رياستي منتقلي کي همٿ ڪري سگهن ٿا، افعال جي وچ ۾ ڊيٽا کي منتقل ڪري، ۽ افعال جي عالمي حالت کي منظم ڪري سگھن ٿا. هي توهان کي ٻيهر ڪوشش ڪرڻ جي شرطن جي وضاحت ڪرڻ جي اجازت ڏئي ٿو، يا ڇا ڪجي جڏهن ڪا خاص غلطي ٿئي ٿي - ڪجهه حالتن ۾ هڪ تمام طاقتور اوزار.

ٿڪل

تازن سالن ۾، بي سرور ٽيڪنالاجيون ترقي ڪري رهيون آهن بي مثال رفتار سان. هن پيراڊائم شفٽ سان لاڳاپيل ڪجهه غلط فهميون آهن. بنيادي ڍانچي ۽ اسڪيلنگ جي انتظام کي ختم ڪرڻ سان، سرور بيس حل اهم فائدا پيش ڪن ٿا، آسان ترقي ۽ DevOps عملن کان وٺي آپريشنل خرچن ۾ وڏي گهٽتائي تائين.
جڏهن ته سرور بي ترتيب انداز ان جي خرابين کان سواءِ نه آهي، اتي مضبوط ڊيزائن جا نمونا آهن جيڪي استعمال ڪري سگھجن ٿيون مضبوط بي سرور ايپليڪيشنون ٺاهڻ يا سرور بيس عناصر کي موجوده فن تعمير ۾ ضم ڪرڻ لاءِ.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو