بي سرور سرور جي جسماني غير موجودگي بابت ناهي. هي هڪ ڪنٽينر قاتل يا گذرڻ وارو رجحان ناهي. هي ڪلائوڊ ۾ سسٽم ٺاهڻ جو هڪ نئون طريقو آهي. اڄ جي آرٽيڪل ۾ اسان سرور لیس ايپليڪيشنن جي فن تعمير تي رابطو ڪنداسين، اچو ته ڏسو ته سرور لیس سروس فراهم ڪندڙ ۽ اوپن سورس پروجيڪٽ ڪهڙو ڪردار ادا ڪن ٿا. آخرڪار، اچو ته سرور بيس استعمال ڪرڻ جي مسئلن بابت ڳالهايو.
مان هڪ ايپليڪيشن جو سرور حصو لکڻ چاهيان ٿو (يا آن لائن اسٽور پڻ). اهو ٿي سگهي ٿو هڪ چيٽ، هڪ مواد پبلشنگ سروس، يا لوڊ بيلنس. ڪنهن به صورت ۾، اتي تمام گهڻو سر درد هوندو: توهان کي انفراسٽرڪچر تيار ڪرڻو پوندو، ايپليڪيشن جي انحصار کي طئي ڪرڻو پوندو، ۽ ميزبان آپريٽنگ سسٽم بابت سوچڻو پوندو. ان کان پوء توهان کي ننڍن حصن کي تازه ڪاري ڪرڻ جي ضرورت پوندي جيڪا باقي مونولٿ جي آپريشن کي متاثر نه ڪن. چ ،و ، اچو ته نه وساريون لوڊ هيٺ اسڪيلنگ بابت.
ڇا جيڪڏهن اسان عارضي ڪنٽينرز وٺون ٿا، جنهن ۾ گهربل انحصار اڳ ۾ ئي نصب ٿيل آهن، ۽ ڪنٽينر پاڻ کي هڪ ٻئي کان ۽ ميزبان OS کان الڳ ٿيل آهن؟ اسان monolith کي microservices ۾ ورهائينداسين، جن مان هر هڪ کي اپڊيٽ ڪري سگهجي ٿو ۽ ٻين کان آزاديءَ سان ماپ ڪري سگهجي ٿو. ڪوڊ کي اهڙي ڪنٽينر ۾ رکڻ سان، مان ان کي ڪنهن به انفراسٽرڪچر تي هلائي سگهان ٿو. اڳ ۾ ئي بهتر.
ڇا جيڪڏهن توهان ڪنٽينرز کي ترتيب ڏيڻ نٿا چاهيو؟ مان ايپليڪيشن کي اسڪيل ڪرڻ بابت سوچڻ نٿو چاهيان. مان بيڪار هلندڙ ڪنٽينرز لاءِ ادا ڪرڻ نٿو چاهيان جڏهن خدمت تي لوڊ گهٽ ۾ گهٽ آهي. مان ڪوڊ لکڻ چاهيان ٿو. ڪاروباري منطق تي ڌيان ڏيو ۽ روشني جي رفتار تي مارڪيٽ ۾ مصنوعات آڻيو.
اهڙن خيالن مون کي بي سرور ڪمپيوٽنگ ڏانهن وٺي ويو. هن معاملي ۾ Serverless جو مطلب آهي سرور جي جسماني غير موجودگي نه، پر انفراسٽرڪچر مينيجمينٽ سر درد جي غير موجودگي.
خيال اهو آهي ته ايپليڪيشن منطق کي آزاد ڪمن ۾ ورهايو ويو آهي. انهن وٽ هڪ واقعي جي جوڙجڪ آهي. هر فنڪشن هڪ "microtask" انجام ڏئي ٿو. ڊولپر کان جيڪو گھربل آھي اھو آھي افعال کي لوڊ ڪرڻ لاءِ ڪنسول ۾ مهيا ڪيل بادل فراهم ڪندڙ ۽ انھن کي ايونٽ ذريعن سان لاڳاپو. ڪوڊ پاڻمرادو تيار ڪيل ڪنٽينر ۾ مطالبو تي عمل ڪيو ويندو، ۽ مان صرف عمل جي وقت لاءِ ادا ڪندس.
اچو ته ڏسو ته ايپليڪيشن ڊولپمينٽ جو عمل هاڻي ڪيئن نظر ايندو.
ڊولپر جي پاسي کان
ان کان اڳ اسان هڪ آن لائن اسٽور لاءِ ايپليڪيشن بابت ڳالهائڻ شروع ڪيو. روايتي انداز ۾، سسٽم جو بنيادي منطق هڪ monolithic ايپليڪيشن ذريعي ڪيو ويندو آهي. ۽ ايپليڪيشن سان سرور مسلسل هلندو رهي ٿو، جيتوڻيڪ ڪو به لوڊ نه آهي.
بغير سرور ڏانهن منتقل ڪرڻ لاء، اسان ايپليڪيشن کي ٽوڙيو microtasks ۾. اسان انهن مان هر هڪ لاء اسان جي پنهنجي فنڪشن لکندا آهيون. فنڪشن هڪ ٻئي کان آزاد آهن ۽ رياستي معلومات کي ذخيرو نٿا ڪن (بي رياست). اهي شايد مختلف ٻولين ۾ لکيا وڃن. جيڪڏهن انهن مان هڪ "گر"، سڄي ايپليڪيشن بند نه ٿيندي. ايپليڪيشن آرڪيٽيڪچر هن طرح نظر ايندو:
سرور بيس ۾ ڪمن ۾ تقسيم مائڪرو سروسز سان ڪم ڪرڻ جي برابر آهي. پر هڪ microservice ڪيترن ئي ڪمن کي انجام ڏئي سگهي ٿو، ۽ هڪ فنڪشن مثالي طور هڪ انجام ڏيڻ گهرجي. اچو ته تصور ڪريون ته ڪم آهي انگ اکر گڏ ڪرڻ ۽ انهن کي صارف جي درخواست تي ظاهر ڪرڻ. مائڪرو سروس جي طريقي ۾، هڪ ڪم هڪ خدمت ذريعي ڪيو ويندو آهي ٻن داخلا پوائنٽن سان: لکڻ ۽ پڙهڻ. سرور بي ترتيب ڪمپيوٽنگ ۾، اهي ٻه مختلف ڪم هوندا جيڪي هڪ ٻئي سان لاڳاپيل نه هوندا. ڊولپر ڪمپيوٽنگ وسيلن کي بچائيندو آهي، مثال طور، انگ اکر اپڊيٽ ڪيا ويندا آهن انهن جي ڀيٽ ۾ اهي ڊائون لوڊ ڪيا ويا آهن.
بي سرور ڪمن کي لازمي طور تي مختصر مدت ۾ عمل ڪيو وڃي (ٽائم آئوٽ)، جيڪو خدمت فراهم ڪندڙ طرفان طئي ڪيو ويندو آهي. مثال طور، AWS لاءِ ٽائيم آئوٽ 15 منٽ آهي. هن جو مطلب اهو آهي ته ضرورتن کي پورو ڪرڻ لاءِ ڊگھي زندگي جا افعال تبديل ڪرڻا پوندا - اهو ئي آهي جيڪو سرور بيس کي اڄ جي ٻين مشهور ٽيڪنالاجيز کان ڌار ڪري ٿو (ڪنٽينر ۽ پليٽ فارم هڪ خدمت).
اسان هر فنڪشن لاء هڪ واقعو تفويض ڪندا آهيون. ھڪڙو واقعو ھڪڙي عمل لاء ھڪڙو محرڪ آھي:
واقعي
اهو عمل جيڪو فعل انجام ڏئي ٿو
هڪ پراڊڪٽ تصوير اپلوڊ ڪئي وئي آهي مخزن تي.
تصوير کي دٻايو ۽ ڊاريڪٽري تي اپلوڊ ڪريو
جسماني اسٽور ايڊريس ڊيٽابيس ۾ اپڊيٽ ڪيو ويو آهي
نقشن ۾ نئون جڳھ لوڊ ڪريو
ڪسٽمر سامان لاء ادا ڪري ٿو
ادائگي جي پروسيسنگ شروع ڪريو
واقعا ٿي سگھن ٿيون HTTP درخواستون، اسٽريمنگ ڊيٽا، پيغام جون قطارون، وغيره. واقعي جا ذريعا ڊيٽا جون تبديليون يا واقعا آهن. ان کان علاوه، افعال کي ٽائمر ذريعي شروع ڪري سگھجي ٿو.
فن تعمير کي ڪم ڪيو ويو، ۽ ايپليڪيشن تقريبا سرور بنجي وئي. اڳتي هلي اسان خدمت فراهم ڪندڙ ڏانهن وڃو.
فراهم ڪندڙ جي پاسي کان
عام طور تي، سرور بيس ڪمپيوٽنگ پيش ڪئي وئي آهي ڪلائوڊ سروس فراهم ڪندڙن طرفان. انهن کي مختلف طور سڏيو ويندو آهي: Azure افعال، AWS Lambda، Google Cloud Functions، IBM Cloud Functions.
اسان مهيا ڪندڙ جي ڪنسول يا ذاتي اڪائونٽ ذريعي خدمت استعمال ڪنداسين. فنڪشنل ڪوڊ ھيٺ ڏنل طريقن مان ھڪڙي ۾ ڊائون لوڊ ڪري سگھجي ٿو:
- ويب ڪنسول ذريعي بلٽ ان ايڊيٽرن ۾ ڪوڊ لکو،
- ڪوڊ سان آرڪائيو ڊائون لوڊ ڪريو،
- عوامي يا پرائيويٽ git repositories سان ڪم ڪريو.
هتي اسان انهن واقعن کي ترتيب ڏيو جيڪي فنڪشن کي سڏين ٿا. واقعن جا سيٽ مختلف مهيا ڪندڙن لاءِ مختلف ٿي سگھن ٿا.
مهيا ڪندڙ ان جي بنيادي ڍانچي تي هڪ خدمت (FaaS) سسٽم جي طور تي فنڪشن کي ٺاهيو ۽ خودڪار ڪيو:
- فنڪشن ڪوڊ فراهم ڪندڙ پاسي تي اسٽوريج ۾ ختم ٿئي ٿو.
- جڏهن هڪ واقعو ٿئي ٿو، ڪنٽينر تيار ٿيل ماحول سان خودڪار طور تي سرور تي ترتيب ڏنل آهن. هر فنڪشن جو مثال پنهنجو الڳ الڳ ڪنٽينر آهي.
- اسٽوريج مان، فنڪشن کي ڪنٽينر ڏانهن موڪليو ويو آهي، حساب ڪيو ويو آهي، ۽ نتيجو واپس ڪري ٿو.
- متوازي واقعن جو تعداد وڌي رهيو آهي - ڪنٽينرز جو تعداد وڌي رهيو آهي. سسٽم خودڪار طريقي سان ماپ ڪري ٿو. جيڪڏهن صارف فنڪشن تائين رسائي نٿا ڪن، اهو غير فعال ٿي ويندو.
- مهيا ڪندڙ ڪنٽينر لاءِ بيڪار وقت مقرر ڪري ٿو - جيڪڏهن هن وقت دوران ڪم ڪنٽينر ۾ ظاهر نه ٿين ته اهو تباهه ٿي ويندو.
هن طريقي سان اسان کي دٻي مان Serverless حاصل. اسان خدمت لاءِ ادا ڪنداسين ادا-جي-توهان-گو ماڊل استعمال ڪندي ۽ صرف انهن ڪمن لاءِ جيڪي استعمال ڪيا ويا آهن، ۽ صرف ان وقت لاءِ جڏهن اهي استعمال ڪيا ويا هئا.
ڊولپرز کي سروس ۾ متعارف ڪرائڻ لاءِ، مهيا ڪندڙ 12 مھينن تائين مفت ٽيسٽنگ پيش ڪن ٿا، پر ڪل حسابي وقت، هر مهيني درخواستن جو تعداد، فنڊ يا بجلي جي استعمال کي محدود ڪريو.
مهيا ڪندڙ سان ڪم ڪرڻ جو بنيادي فائدو بنيادي ڍانچي جي باري ۾ پريشان نه ڪرڻ جي صلاحيت آهي (سرور، مجازي مشينون، ڪنٽينرز). ان جي حصي لاء، فراهم ڪندڙ لاڳو ڪري سگهي ٿو FaaS ٻنهي کي پنهنجي ترقي ۽ اوپن سورس اوزار استعمال ڪندي. اچو ته انهن بابت وڌيڪ ڳالهايون.
کليل ذريعو پاسي کان
اوپن سورس ڪميونٽي فعال طور تي ڪم ڪري رهي آهي بي سرور اوزار تي گذريل ڪجهه سالن کان. سڀ کان وڏو مارڪيٽ پليئر پڻ مدد ڪن ٿا سرور بيس پليٽ فارمن جي ترقي ۾:
- گوگل ڊولپرز کي ان جو اوپن سورس ٽول پيش ڪري ٿو - . IBM، RedHat، Pivotal ۽ SAP ان جي ترقي ۾ حصو ورتو؛
- IBM بي سرور پليٽ فارم تي ڪم ڪيو ، جيڪو پوءِ اپاچي فائونڊيشن جو هڪ منصوبو بڻجي ويو؛
- Microsoft جي جزوي طور پليٽ فارم ڪوڊ کوليو .
بغير سرور فريم ورڪ جي هدايت ۾ ترقي پڻ جاري آهي. и اڳ ۾ تيار ڪيل ڪبرنيٽس ڪلستر جي اندر تعینات، ڪبرنيٽس ۽ ڊاڪر سوارم ٻنهي سان ڪم ڪري ٿو. فريم ورڪ هڪ قسم جي ڪنٽرولر طور ڪم ڪري ٿو - درخواست تي، اهو ڪلستر جي اندر رن ٽائم ماحول تيار ڪري ٿو، پوء اتي هڪ فنڪشن شروع ڪري ٿو.
فريم ورڪ توهان جي ضرورتن مطابق اوزار کي ترتيب ڏيڻ لاءِ ڪمرو ڇڏي ٿو. تنهن ڪري، Kubeless ۾، هڪ ڊولپر ترتيب ڏئي سگهي ٿو فنڪشن جي عمل جي وقت ختم ٿيڻ (ڊفالٽ قيمت 180 سيڪنڊ آهي). فيشن، سرد شروعات جي مسئلي کي حل ڪرڻ جي ڪوشش ۾، ڪجهه ڪنٽينرز کي هر وقت هلائڻ جي صلاح ڏني وئي آهي (جيتوڻيڪ هن ۾ وسيلن جي گھٽتائي جي قيمت شامل آهي). ۽ OpenFaaS هر ذائقي ۽ رنگ لاءِ ٽرگرز جو هڪ سيٽ پيش ڪري ٿو: HTTP، Kafka، Redis، MQTT، Cron، AWS SQS، NATs ۽ ٻيا.
شروع ڪرڻ لاء هدايتون فريم ورڪ جي سرڪاري دستاويزن ۾ ملي سگھن ٿيون. انهن سان گڏ ڪم ڪرڻ جي ضرورت آهي ٿورڙي وڌيڪ صلاحيتن جي ڀيٽ ۾ جڏهن هڪ فراهم ڪندڙ سان ڪم ڪري رهيو آهي - اهو گهٽ ۾ گهٽ آهي CLI ذريعي ڪبرنيٽس ڪلستر شروع ڪرڻ جي صلاحيت. وڌ ۾ وڌ، ٻيا اوپن سورس ٽولز شامل ڪريو (مثال طور، ڪافڪا قطار مئنيجر).
ان کان سواءِ اسان ڪيئن ڪم ڪريون سرور لیس سان - هڪ مهيا ڪندڙ جي ذريعي يا اوپن سورس استعمال ڪندي، اسان کي سرور لیس طريقي جا ڪيترائي فائدا ۽ نقصان ملندا.
فائدن ۽ نقصان جي نقطي نظر کان
سرور بيس هڪ ڪنٽينر انفراسٽرڪچر جي خيالن کي ترقي ڪري ٿو ۽ هڪ مائڪرو سروس جي طريقي سان، جنهن ۾ ٽيمون هڪ پليٽ فارم سان ڳنڍڻ کان سواء هڪ گهڻ لساني موڊ ۾ ڪم ڪري سگهن ٿيون. سسٽم ٺاهڻ آسان آهي ۽ غلطيون درست ڪرڻ آسان آهن. Microservice architecture توهان کي اجازت ڏئي ٿو ته سسٽم ۾ نئين ڪارڪردگي شامل ڪرڻ جي ڀيٽ ۾ تمام تيزيءَ سان هڪ واحد ايپليڪيشن جي صورت ۾.
سرور بي ترتيب ترقي جي وقت کي اڃا به وڌيڪ گھٽائي ٿو، ڊولپر کي صرف ايپليڪيشن جي ڪاروباري منطق ۽ ڪوڊنگ تي ڌيان ڏيڻ جي اجازت ڏئي ٿي. نتيجي طور، ترقي لاء مارڪيٽ جو وقت گھٽجي ويو آهي.
بونس جي طور تي، اسان لوڊ لاء خودڪار اسڪيلنگ حاصل ڪندا آهيون، ۽ اسان صرف استعمال ڪيل وسيلن لاءِ ادا ڪندا آهيون ۽ صرف ان وقت جڏهن اهي استعمال ڪيا ويندا آهن.
ڪنهن به ٽيڪنالاجي وانگر، سرور بيس نقصانات آهي.
مثال طور، اهڙي خرابي ٿي سگهي ٿي سرد شروع ٿيڻ جو وقت (اوسط طور تي 1 سيڪنڊن تائين ٻولين لاءِ جيئن ته JavaScript, Python, Go, Java, Ruby).
هڪ پاسي، حقيقت ۾، سرد شروع ٿيڻ جو وقت ڪيترن ئي متغيرن تي منحصر آهي: ٻولي جنهن ۾ فنڪشن لکيو ويو آهي، لائبريرين جو تعداد، ڪوڊ جي مقدار، اضافي وسيلن سان رابطي (ساڳي ڊيٽابيس يا تصديق ڪندڙ سرور). جيئن ته ڊولپر انهن متغيرن کي سنڀاليندو آهي، هو شروعاتي وقت کي گهٽائي سگهي ٿو. پر ٻئي طرف، ڊولپر ڪنٽينر جي شروعاتي وقت کي ڪنٽرول نٿو ڪري سگهي - اهو سڀ ڪجهه فراهم ڪندڙ تي منحصر آهي.
ٿڌي شروعات هڪ گرم شروعات ۾ تبديل ٿي سگهي ٿي جڏهن ڪو فنڪشن اڳئين واقعي پاران شروع ڪيل ڪنٽينر کي ٻيهر استعمال ڪري ٿو. اها صورتحال ٽن صورتن ۾ پيدا ٿيندي:
- جيڪڏهن گراهڪ اڪثر ڪري خدمت استعمال ڪن ٿا ۽ فنڪشن ڏانهن ڪالن جو تعداد وڌي ٿو؛
- جيڪڏهن مهيا ڪندڙ، پليٽ فارم يا فريم ورڪ توهان کي اجازت ڏئي ٿو ته ڪجهه ڪنٽينرز کي هر وقت هلائڻ؛
- جيڪڏهن ڊولپر هڪ ٽائمر تي ڪم ڪندو آهي (هر 3 منٽن کي چئو).
ڪيترن ئي ايپليڪيشنن لاء، ٿڌي شروعات ڪو مسئلو ناهي. هتي توهان کي خدمت جي قسم ۽ ڪمن تي تعمير ڪرڻ جي ضرورت آهي. هڪ سيڪنڊ جي شروعاتي دير هميشه ڪاروباري ايپليڪيشن لاءِ نازڪ ناهي، پر اهو طبي خدمتن لاءِ نازڪ بڻجي سگهي ٿو. انهي صورت ۾، سرور کان سواء طريقو شايد وڌيڪ مناسب نه هوندو.
سرور بيس جو ايندڙ نقصان هڪ فنڪشن جي مختصر زندگي آهي (ٽائم آئوٽ جنهن دوران فنڪشن تي عمل ٿيڻ گهرجي).
پر، جيڪڏھن توھان کي ڪم ڪرڻو آھي ڊگھي ڪمن سان، توھان ھائبرڊ آرڪيٽيڪچر استعمال ڪري سگھو ٿا - Serverless کي ٻي ٽيڪنالاجي سان گڏ ڪريو.
نه سڀئي سسٽم ڪم ڪرڻ جي قابل هوندا سرور بيس اسڪيم استعمال ڪندي.
ڪجھ ايپليڪيشنون اڃا تائين ڊيٽا کي ذخيرو ڪنديون ۽ عمل دوران رياست. ڪي اڏاوتون اڪيلائي ۾ رهنديون ۽ ڪي خاصيتون ڊگھيون رهنديون. بهرحال (جهڙوڪ ڪلائوڊ ٽيڪنالاجيز ۽ پوءِ ڪنٽينرز)، سرور بيس هڪ ٽيڪنالاجي آهي جيڪو هڪ عظيم مستقبل سان آهي.
هن رڳ ۾، آئون آسانيء سان سرور جي بغير استعمال ڪرڻ جي مسئلي ڏانهن منتقل ڪرڻ چاهيندس.
اپليڪيشن جي پاسي کان
2018 لاء، سرور جي استعمال جو سيڪڙو . انهن ڪمپنين ۾ جيڪي اڳ ۾ ئي ٽيڪنالاجي کي لاڳو ڪري چڪا آهن انهن جي خدمتن ۾ اهڙيون مارڪيٽ جايون جهڙوڪ Twitter، PayPal، Netflix، T-Mobile، Coca-Cola. ساڳئي وقت، توهان کي سمجهڻ جي ضرورت آهي ته سرور بيس هڪ علاج نه آهي، پر مسئلن جي هڪ خاص حد کي حل ڪرڻ لاء هڪ اوزار آهي:
- وسيلن جي گھٽتائي کي گھٽايو. خدمتن لاءِ هڪ ورچوئل مشين کي مسلسل رکڻ جي ڪا ضرورت ناهي جنهن ۾ ڪجهه ڪالون آهن.
- پرواز تي ڊيٽا کي پروسيس ڪريو. تصويرن کي دٻايو، پس منظر ڪٽيو، وڊيو انڪوڊنگ تبديل ڪريو، IoT سينسر سان ڪم ڪريو، رياضياتي عمل ڪريو.
- "گلو" ٻين خدمتن کي گڏ ڪريو. اندروني پروگرامن سان گڏ Git مخزن، جيرا ۽ ڪئلينڊر سان سليڪ ۾ چيٽ بوٽ.
- لوڊ توازن ڪريو. اچو ته هتي هڪ ويجهي نظر وٺو.
اچو ته چوندا آهن ته هڪ خدمت آهي جيڪا 50 ماڻهن کي راغب ڪري ٿي. ان جي هيٺان ڪمزور هارڊويئر سان گڏ هڪ مجازي مشين آهي. وقت بوقت، خدمت تي لوڊ خاص طور تي وڌي ٿو. پوء ڪمزور هارڊويئر منهن نه ٿا ڪري سگهو.
توهان سسٽم ۾ بيلنس شامل ڪري سگهو ٿا جيڪو لوڊ ورهائيندو، چئو، ٽن ورچوئل مشينن ۾. هن مرحلي تي، اسان صحيح طور تي لوڊ جي اڳڪٿي نٿا ڪري سگهون، تنهنڪري اسان وسيلن جي هڪ خاص مقدار کي "رزرو ۾" هلائيندا آهيون. ۽ اسان دير جي وقت لاء وڌيڪ ادا ڪندا آهيون.
اهڙي صورتحال ۾، اسان هڪ هائبرڊ طريقي سان سسٽم کي بهتر ڪري سگهون ٿا: اسان هڪ ورچوئل مشين کي لوڊ بيلنس جي پويان ڇڏي ڏيون ٿا ۽ ڪمن سان گڏ سرور لیس انڊ پوائنٽ ڏانهن لنڪ رکون ٿا. جيڪڏهن لوڊ حد کان وڌي وڃي ٿي، بيلنس شروع ڪري ٿو فنڪشن جا مثال جيڪي درخواست جي پروسيسنگ جو حصو وٺن ٿا.
اهڙيء طرح، سرور بيس استعمال ڪري سگهجي ٿو جتي اهو ضروري آهي ته وڏي تعداد ۾ درخواستن کي پروسيس ڪرڻ لاء تمام گهڻو نه، پر شدت سان. انهي حالت ۾، 15 منٽن لاء ڪيترن ئي ڪمن کي هلائڻ هڪ مجازي مشين يا سرور کي هر وقت برقرار رکڻ کان وڌيڪ فائدي وارو آهي.
سرور بيس ڪمپيوٽنگ جي سڀني فائدن سان، عمل ڪرڻ کان پهريان، توهان کي پهريان ايپليڪيشن منطق جو جائزو وٺڻ گهرجي ۽ سمجهڻ گهرجي ته سرور بيس ڪنهن خاص صورت ۾ ڪهڙا مسئلا حل ڪري سگهن ٿا.
بي سرور ۽ سليڪٽيل
Selectel تي اسان اڳ ۾ ئي آهيون اسان جي ڪنٽرول پينل ذريعي. ھاڻي اسان پنھنجي FaaS پليٽ فارم ٺاھي رھيا آھيون. اسان چاهيون ٿا ته ڊولپرز هڪ آسان، لچڪدار انٽرفيس ذريعي بي سرور استعمال ڪندي پنهنجا مسئلا حل ڪرڻ جي قابل ٿي وڃن.
جيڪڏهن توهان وٽ خيال آهي ته مثالي FaaS پليٽ فارم ڇا هجڻ گهرجي ۽ توهان پنهنجي منصوبن ۾ بي سرور ڪيئن استعمال ڪرڻ چاهيو ٿا، انهن کي تبصرن ۾ حصيداري ڪريو. پليٽ فارم کي ترقي ڪرڻ وقت اسان توهان جي خواهش کي حساب ۾ آڻينداسين.
مضمون ۾ استعمال ٿيل مواد:
جو ذريعو: www.habr.com