سرور لیس سرورز کی جسمانی عدم موجودگی کے بارے میں نہیں ہے۔ یہ کنٹینر قاتل یا گزرنے والا رجحان نہیں ہے۔ یہ کلاؤڈ میں سسٹم بنانے کا ایک نیا طریقہ ہے۔ آج کے مضمون میں ہم سرور لیس ایپلی کیشنز کے فن تعمیر پر بات کریں گے، آئیے دیکھتے ہیں کہ سرور لیس سروس فراہم کرنے والے اور اوپن سورس پروجیکٹس کا کیا کردار ہے۔ آخر میں، آئیے سرور لیس استعمال کرنے کے مسائل کے بارے میں بات کرتے ہیں۔
میں کسی ایپلیکیشن (یا یہاں تک کہ آن لائن اسٹور) کا سرور حصہ لکھنا چاہتا ہوں۔ یہ ایک چیٹ، مواد کی اشاعت کی خدمت، یا لوڈ بیلنسر ہو سکتا ہے۔ کسی بھی صورت میں، بہت زیادہ سر درد ہو گا: آپ کو بنیادی ڈھانچہ تیار کرنا پڑے گا، درخواست کے انحصار کا تعین کرنا پڑے گا، اور میزبان آپریٹنگ سسٹم کے بارے میں سوچنا پڑے گا۔ پھر آپ کو چھوٹے اجزاء کو اپ ڈیٹ کرنے کی ضرورت ہوگی جو باقی مانولتھ کے آپریشن کو متاثر نہیں کرتے ہیں۔ ٹھیک ہے، آئیے بوجھ کے نیچے اسکیلنگ کے بارے میں نہ بھولیں۔
کیا ہوگا اگر ہم عارضی کنٹینرز لیں، جس میں مطلوبہ انحصار پہلے سے نصب ہے، اور کنٹینرز خود ایک دوسرے سے اور میزبان OS سے الگ تھلگ ہیں؟ ہم یک سنگی کو مائیکرو سروسز میں تقسیم کریں گے، جن میں سے ہر ایک کو دوسروں سے آزادانہ طور پر اپ ڈیٹ اور اسکیل کیا جا سکتا ہے۔ کوڈ کو ایسے کنٹینر میں رکھ کر، میں اسے کسی بھی انفراسٹرکچر پر چلا سکتا ہوں۔ پہلے سے بہتر۔
اگر آپ کنٹینرز کو کنفیگر نہیں کرنا چاہتے تو کیا ہوگا؟ میں درخواست کی پیمائش کے بارے میں نہیں سوچنا چاہتا۔ جب سروس پر بوجھ کم سے کم ہو تو میں بیکار چلنے والے کنٹینرز کے لیے ادائیگی نہیں کرنا چاہتا۔ میں کوڈ لکھنا چاہتا ہوں۔ کاروباری منطق پر توجہ مرکوز کریں اور روشنی کی رفتار سے مصنوعات کو مارکیٹ میں لائیں۔
اس طرح کے خیالات مجھے سرور لیس کمپیوٹنگ کی طرف لے گئے۔ اس معاملے میں سرور لیس کا مطلب ہے۔ سرورز کی جسمانی عدم موجودگی نہیں بلکہ انفراسٹرکچر مینجمنٹ کی سر دردی کی عدم موجودگی۔
خیال یہ ہے کہ درخواست کی منطق کو آزاد افعال میں تقسیم کیا گیا ہے۔ ان کا ایک واقعہ ڈھانچہ ہے۔ ہر فنکشن ایک "مائکروٹاسک" انجام دیتا ہے۔ ڈویلپر سے صرف اتنا ضروری ہے کہ کلاؤڈ فراہم کنندہ کے ذریعہ فراہم کردہ کنسول میں فنکشنز لوڈ کریں اور انہیں ایونٹ کے ذرائع سے جوڑیں۔ کوڈ کو خود بخود تیار کردہ کنٹینر میں طلب کرنے پر عمل میں لایا جائے گا، اور میں صرف عملدرآمد کے وقت کی ادائیگی کروں گا۔
آئیے دیکھتے ہیں کہ ایپلیکیشن ڈویلپمنٹ کا عمل اب کیسا ہوگا۔
ڈویلپر کی طرف سے
اس سے پہلے ہم نے آن لائن سٹور کے لیے درخواست کے بارے میں بات کرنا شروع کی تھی۔ روایتی نقطہ نظر میں، نظام کی بنیادی منطق یک سنگی ایپلی کیشن کے ذریعہ انجام دی جاتی ہے۔ اور ایپلی کیشن کے ساتھ سرور مسلسل چل رہا ہے، چاہے کوئی بوجھ نہ ہو۔
سرور لیس پر جانے کے لیے، ہم ایپلیکیشن کو مائیکرو ٹاسک میں توڑ دیتے ہیں۔ ہم ان میں سے ہر ایک کے لیے اپنا فنکشن لکھتے ہیں۔ فنکشنز ایک دوسرے سے آزاد ہیں اور ریاستی معلومات کو محفوظ نہیں کرتے (بے ریاست)۔ وہ مختلف زبانوں میں بھی لکھے جا سکتے ہیں۔ اگر ان میں سے ایک "گر جاتا ہے"، تو پوری درخواست نہیں رکے گی۔ ایپلیکیشن کا فن تعمیر اس طرح نظر آئے گا:
سرور لیس میں افعال میں تقسیم مائیکرو سروسز کے ساتھ کام کرنے کے مترادف ہے۔ لیکن ایک مائیکرو سروس کئی کام انجام دے سکتی ہے، اور ایک فنکشن مثالی طور پر ایک کو انجام دینا چاہیے۔ آئیے تصور کریں کہ کام اعداد و شمار جمع کرنا اور صارف کی درخواست پر ظاہر کرنا ہے۔ مائیکرو سروس اپروچ میں، ایک کام کو ایک سروس کے ذریعے دو انٹری پوائنٹس کے ساتھ انجام دیا جاتا ہے: لکھنا اور پڑھنا۔ سرور لیس کمپیوٹنگ میں، یہ دو مختلف فنکشنز ہوں گے جو ایک دوسرے سے متعلق نہیں ہیں۔ ڈویلپر کمپیوٹنگ کے وسائل کو بچاتا ہے اگر، مثال کے طور پر، اعداد و شمار کو ڈاؤن لوڈ کیے جانے سے زیادہ کثرت سے اپ ڈیٹ کیا جاتا ہے۔
سرور لیس افعال کو مختصر مدت (ٹائم آؤٹ) میں انجام دیا جانا چاہیے، جس کا تعین سروس فراہم کنندہ کرتا ہے۔ مثال کے طور پر، AWS کے لیے ٹائم آؤٹ 15 منٹ ہے۔ اس کا مطلب ہے کہ ضروریات کے مطابق طویل المدتی فنکشنز کو تبدیل کرنا پڑے گا - یہی وہ چیز ہے جو سرور لیس کو آج کی دیگر مشہور ٹیکنالوجیز (کنٹینرز اور پلیٹ فارم بطور سروس) سے ممتاز کرتی ہے۔
ہم ہر فنکشن کو ایک ایونٹ تفویض کرتے ہیں۔ ایک واقعہ ایک عمل کا محرک ہے:
واقعہ
وہ عمل جو فنکشن انجام دیتا ہے۔
ایک پروڈکٹ کی تصویر کو ذخیرہ میں اپ لوڈ کر دیا گیا ہے۔
تصویر کو کمپریس کریں اور ڈائرکٹری میں اپ لوڈ کریں۔
ڈیٹا بیس میں فزیکل اسٹور کا پتہ اپ ڈیٹ کر دیا گیا ہے۔
نقشوں میں ایک نیا مقام لوڈ کریں۔
کلائنٹ سامان کی ادائیگی کرتا ہے۔
ادائیگی کی کارروائی شروع کریں۔
ایونٹس HTTP درخواستیں، سٹریمنگ ڈیٹا، پیغام کی قطاریں، وغیرہ ہو سکتے ہیں۔ ایونٹ کے ذرائع ڈیٹا کی تبدیلیاں یا واقعات ہیں۔ اس کے علاوہ، افعال کو ٹائمر کے ذریعے متحرک کیا جا سکتا ہے۔
فن تعمیر پر کام کیا گیا، اور ایپلیکیشن تقریباً سرور لیس ہو گئی۔ اگلا ہم سروس فراہم کرنے والے کے پاس جاتے ہیں۔
فراہم کنندہ کی طرف سے
عام طور پر، سرور لیس کمپیوٹنگ کلاؤڈ سروس فراہم کرنے والوں کے ذریعہ پیش کی جاتی ہے۔ انہیں مختلف طریقے سے کہا جاتا ہے: Azure Functions، AWS Lambda، Google Cloud Functions، IBM Cloud Functions۔
ہم سروس کو فراہم کنندہ کے کنسول یا ذاتی اکاؤنٹ کے ذریعے استعمال کریں گے۔ فنکشن کوڈ کو درج ذیل طریقوں میں سے کسی ایک طریقے سے ڈاؤن لوڈ کیا جا سکتا ہے۔
- ویب کنسول کے ذریعے بلٹ ان ایڈیٹرز میں کوڈ لکھیں،
- کوڈ کے ساتھ آرکائیو ڈاؤن لوڈ کریں،
- عوامی یا نجی گٹ ذخیروں کے ساتھ کام کریں۔
یہاں ہم ان واقعات کو ترتیب دیتے ہیں جو فنکشن کو کہتے ہیں۔ واقعات کے سیٹ مختلف فراہم کنندگان کے لیے مختلف ہو سکتے ہیں۔
فراہم کنندہ نے اپنے بنیادی ڈھانچے پر فنکشن بطور سروس (FaaS) سسٹم بنایا اور خودکار بنایا:
- فنکشن کوڈ فراہم کنندہ کی طرف اسٹوریج میں ختم ہوتا ہے۔
- جب کوئی واقعہ ہوتا ہے، تیار ماحول والے کنٹینرز سرور پر خود بخود تعینات ہو جاتے ہیں۔ ہر فنکشن مثال کا اپنا الگ تھلگ کنٹینر ہوتا ہے۔
- اسٹوریج سے، فنکشن کو کنٹینر میں بھیجا جاتا ہے، حساب لگایا جاتا ہے، اور نتیجہ واپس آتا ہے۔
- متوازی واقعات کی تعداد بڑھ رہی ہے - کنٹینرز کی تعداد بڑھ رہی ہے۔ نظام خود بخود ترازو کرتا ہے۔ اگر صارفین فنکشن تک رسائی حاصل نہیں کرتے ہیں تو یہ غیر فعال ہو جائے گا۔
- فراہم کنندہ کنٹینرز کے لیے بیکار وقت کا تعین کرتا ہے - اگر اس وقت کے دوران کنٹینر میں افعال ظاہر نہیں ہوتے ہیں، تو یہ تباہ ہو جاتا ہے۔
اس طرح ہم سرور لیس کو باکس سے باہر کر دیتے ہیں۔ ہم پے-ایس-یو-گو ماڈل کا استعمال کرتے ہوئے سروس کے لیے ادائیگی کریں گے اور صرف ان فنکشنز کے لیے جو استعمال کیے گئے ہیں، اور صرف اس وقت کے لیے جب وہ استعمال کیے گئے تھے۔
ڈیولپرز کو سروس میں متعارف کرانے کے لیے، فراہم کنندگان 12 ماہ تک مفت ٹیسٹنگ کی پیشکش کرتے ہیں، لیکن حساب کے کل وقت، ماہانہ درخواستوں کی تعداد، فنڈز یا بجلی کی کھپت کو محدود کرتے ہیں۔
فراہم کنندہ کے ساتھ کام کرنے کا بنیادی فائدہ بنیادی ڈھانچے (سرور، ورچوئل مشینیں، کنٹینرز) کے بارے میں فکر نہ کرنے کی صلاحیت ہے۔ اس کے حصے کے لیے، فراہم کنندہ اپنی پیشرفت اور اوپن سورس ٹولز کا استعمال کرتے ہوئے FaaS کو نافذ کر سکتا ہے۔ آئیے ان کے بارے میں مزید بات کرتے ہیں۔
اوپن سورس کی طرف سے
اوپن سورس کمیونٹی پچھلے کچھ سالوں سے سرور لیس ٹولز پر فعال طور پر کام کر رہی ہے۔ مارکیٹ کے سب سے بڑے کھلاڑی سرور لیس پلیٹ فارمز کی ترقی میں بھی حصہ ڈالتے ہیں:
- گوگل ڈویلپرز کو اس کا اوپن سورس ٹول پیش کرتا ہے - . IBM، RedHat، Pivotal اور SAP نے اس کی ترقی میں حصہ لیا۔
- IBM سرور لیس پلیٹ فارم پر کام کیا۔ جو کہ پھر اپاچی فاؤنڈیشن کا ایک پروجیکٹ بن گیا۔
- مائیکروسافٹ جزوی طور پر پلیٹ فارم کوڈ کھول دیا .
سرور لیس فریم ورک کی سمت میں بھی ترقی جاری ہے۔ и پہلے سے تیار کبرنیٹس کلسٹرز کے اندر تعینات، Kubernetes اور Docker Swarm دونوں کے ساتھ کام کرتا ہے۔ فریم ورک ایک قسم کے کنٹرولر کے طور پر کام کرتا ہے - درخواست پر، یہ کلسٹر کے اندر رن ٹائم ماحول تیار کرتا ہے، پھر وہاں ایک فنکشن شروع کرتا ہے۔
فریم ورک آپ کی ضروریات کے مطابق ٹول کو ترتیب دینے کے لیے جگہ چھوڑ دیتے ہیں۔ لہذا، کوبیلیس میں، ایک ڈویلپر فنکشن کے عمل کے ٹائم آؤٹ کو ترتیب دے سکتا ہے (پہلے سے طے شدہ قدر 180 سیکنڈ ہے)۔ فِشن، کولڈ سٹارٹ کے مسئلے کو حل کرنے کی کوشش میں، کچھ کنٹینرز کو ہر وقت چلانے کا مشورہ دیتا ہے (حالانکہ اس میں وسائل کے بند ہونے کے اخراجات شامل ہیں)۔ اور OpenFaaS ہر ذائقہ اور رنگ کے لیے محرکات کا ایک سیٹ پیش کرتا ہے: HTTP، Kafka، Redis، MQTT، Cron، AWS SQS، NATs اور دیگر۔
شروع کرنے کے لیے ہدایات فریم ورک کے سرکاری دستاویزات میں مل سکتی ہیں۔ ان کے ساتھ کام کرنے کے لیے فراہم کنندہ کے ساتھ کام کرنے کے مقابلے میں تھوڑی زیادہ مہارت کی ضرورت ہوتی ہے - یہ کم از کم CLI کے ذریعے Kubernetes کلسٹر شروع کرنے کی صلاحیت ہے۔ زیادہ سے زیادہ، دیگر اوپن سورس ٹولز (مثال کے طور پر، کافکا قطار مینیجر) شامل کریں۔
اس سے قطع نظر کہ ہم سرور لیس کے ساتھ کیسے کام کرتے ہیں - فراہم کنندہ کے ذریعے یا اوپن سورس کا استعمال کرتے ہوئے، ہمیں سرور لیس اپروچ کے متعدد فوائد اور نقصانات حاصل ہوں گے۔
فوائد اور نقصانات کے نقطہ نظر سے
سرور لیس کنٹینر انفراسٹرکچر اور مائیکرو سروس اپروچ کے آئیڈیاز تیار کرتا ہے، جس میں ٹیمیں ایک پلیٹ فارم سے بندھے بغیر کثیر لسانی موڈ میں کام کر سکتی ہیں۔ سسٹم بنانا آسان ہے اور غلطیوں کو درست کرنا آسان ہے۔ مائیکرو سرویس آرکیٹیکچر آپ کو نظام میں نئی فعالیت کو یک سنگی ایپلی کیشن کے مقابلے میں زیادہ تیزی سے شامل کرنے کی اجازت دیتا ہے۔
سرور لیس ترقی کے وقت کو اور بھی کم کرتا ہے، ڈویلپر کو مکمل طور پر ایپلی کیشن کی کاروباری منطق اور کوڈنگ پر توجہ مرکوز کرنے کی اجازت دیتا ہے۔ نتیجے کے طور پر، ترقی کے لئے مارکیٹ کا وقت کم ہو گیا ہے.
بونس کے طور پر، ہمیں لوڈ کے لیے خودکار پیمانہ ملتا ہے، اور ہم صرف استعمال شدہ وسائل کی ادائیگی کرتے ہیں اور صرف اس وقت جب وہ استعمال ہوتے ہیں۔
کسی بھی ٹیکنالوجی کی طرح، سرور لیس کے بھی نقصانات ہیں۔
مثال کے طور پر، اس طرح کا نقصان کولڈ سٹارٹ ٹائم ہو سکتا ہے (جاوا اسکرپٹ، ازگر، گو، جاوا، روبی جیسی زبانوں کے لیے اوسطاً 1 سیکنڈ تک)۔
ایک طرف، حقیقت میں، کولڈ اسٹارٹ ٹائم بہت سے متغیرات پر منحصر ہوتا ہے: وہ زبان جس میں فنکشن لکھا جاتا ہے، لائبریریوں کی تعداد، کوڈ کی مقدار، اضافی وسائل کے ساتھ مواصلت (وہی ڈیٹا بیس یا تصدیقی سرور)۔ چونکہ ڈویلپر ان متغیرات کو کنٹرول کرتا ہے، اس لیے وہ آغاز کا وقت کم کر سکتا ہے۔ لیکن دوسری طرف، ڈویلپر کنٹینر کے آغاز کے وقت کو کنٹرول نہیں کر سکتا - یہ سب فراہم کنندہ پر منحصر ہے۔
کولڈ سٹارٹ ایک گرم آغاز میں تبدیل ہو سکتا ہے جب کوئی فنکشن پچھلے ایونٹ کے ذریعہ شروع کردہ کنٹینر کو دوبارہ استعمال کرتا ہے۔ یہ صورت حال تین صورتوں میں پیدا ہوگی:
- اگر کلائنٹ کثرت سے سروس استعمال کرتے ہیں اور فنکشن میں کالز کی تعداد بڑھ جاتی ہے۔
- اگر فراہم کنندہ، پلیٹ فارم یا فریم ورک آپ کو کچھ کنٹینرز کو ہر وقت چلانے کی اجازت دیتا ہے۔
- اگر ڈویلپر ٹائمر پر فنکشن چلاتا ہے (ہر 3 منٹ میں کہے)۔
بہت سے ایپلی کیشنز کے لیے، کولڈ اسٹارٹ کوئی مسئلہ نہیں ہے۔ یہاں آپ کو سروس کی قسم اور کاموں کو بنانے کی ضرورت ہے۔ کاروباری درخواست کے لیے ایک سیکنڈ کی شروعات میں تاخیر ہمیشہ اہم نہیں ہوتی، لیکن یہ طبی خدمات کے لیے اہم بن سکتی ہے۔ اس صورت میں، سرور کے بغیر نقطہ نظر شاید اب مناسب نہیں ہو گا.
Serverless کا اگلا نقصان کسی فنکشن کی مختصر زندگی ہے (ٹائم آؤٹ جس کے دوران فنکشن کو انجام دیا جانا چاہیے)۔
لیکن، اگر آپ کو طویل المدت کاموں کے ساتھ کام کرنا ہے، تو آپ ہائبرڈ فن تعمیر کا استعمال کر سکتے ہیں - سرور لیس کو کسی اور ٹیکنالوجی کے ساتھ جوڑیں۔
تمام سسٹمز سرور لیس اسکیم کا استعمال کرتے ہوئے کام کرنے کے قابل نہیں ہوں گے۔
عملدرآمد کے دوران کچھ ایپلیکیشنز اب بھی ڈیٹا اور اسٹیٹ کو اسٹور کریں گی۔ کچھ فن تعمیر یک سنگی رہیں گے اور کچھ خصوصیات طویل عرصے تک رہیں گی۔ تاہم (کلاؤڈ ٹیکنالوجیز اور پھر کنٹینرز کی طرح)، سرور لیس ایک ایسی ٹیکنالوجی ہے جس کا مستقبل بہت اچھا ہے۔
اس سلسلے میں، میں سرور لیس اپروچ کو استعمال کرنے کے مسئلے کی طرف آسانی سے آگے بڑھنا چاہوں گا۔
درخواست کی طرف سے
2018 کے لیے، سرور کے بغیر استعمال کا فیصد . جن کمپنیوں نے اپنی خدمات میں ٹیکنالوجی کو پہلے ہی لاگو کیا ہے ان میں ٹویٹر، پے پال، نیٹ فلکس، ٹی موبائل، کوکا کولا جیسی مارکیٹ کی کمپنیاں شامل ہیں۔ اسی وقت، آپ کو یہ سمجھنے کی ضرورت ہے کہ سرور لیس کوئی علاج نہیں ہے، بلکہ مسائل کی ایک مخصوص حد کو حل کرنے کا ایک ذریعہ ہے:
- وسائل کا وقت کم کریں۔ ایسی خدمات کے لیے ایک ورچوئل مشین کو مسلسل رکھنے کی ضرورت نہیں ہے جن کی کالیں کم ہوں۔
- فلائی پر ڈیٹا پر کارروائی کریں۔ تصویروں کو سکیڑیں، پس منظر کاٹیں، ویڈیو انکوڈنگ کو تبدیل کریں، IoT سینسر کے ساتھ کام کریں، ریاضی کی کارروائیاں کریں۔
- دیگر خدمات کو ایک ساتھ "گلو" کریں۔ اندرونی پروگراموں کے ساتھ گٹ ریپوزٹری، جیرا اور کیلنڈر کے ساتھ سلیک میں چیٹ بوٹ۔
- بوجھ کو متوازن رکھیں۔ آئیے یہاں قریب سے دیکھیں۔
ہم کہتے ہیں کہ ایک ایسی خدمت ہے جو 50 لوگوں کو راغب کرتی ہے۔ اس کے نیچے کمزور ہارڈ ویئر کے ساتھ ایک ورچوئل مشین ہے۔ وقتا فوقتا، سروس پر بوجھ نمایاں طور پر بڑھ جاتا ہے۔ پھر کمزور ہارڈ ویئر کا مقابلہ نہیں کر سکتا۔
آپ سسٹم میں ایک بیلنسر شامل کر سکتے ہیں جو کہ لوڈ کو تین ورچوئل مشینوں میں تقسیم کرے گا۔ اس مرحلے پر، ہم بوجھ کا درست اندازہ نہیں لگا سکتے، اس لیے ہم وسائل کی ایک خاص مقدار کو "ریزرو میں" چلاتے رہتے ہیں۔ اور ہم ڈاؤن ٹائم کے لیے زیادہ ادائیگی کرتے ہیں۔
ایسی صورت حال میں، ہم ہائبرڈ اپروچ کے ذریعے سسٹم کو بہتر بنا سکتے ہیں: ہم ایک ورچوئل مشین کو لوڈ بیلنس کے پیچھے چھوڑ دیتے ہیں اور فنکشنز کے ساتھ سرور لیس اینڈ پوائنٹ کا لنک لگاتے ہیں۔ اگر بوجھ حد سے بڑھ جاتا ہے تو، بیلنسر فنکشن کی مثالیں شروع کرتا ہے جو درخواست کی کارروائی کا حصہ لے لیتا ہے۔
اس طرح، سرور لیس کو استعمال کیا جا سکتا ہے جہاں درخواستوں کی ایک بڑی تعداد کو اکثر نہیں بلکہ پوری شدت سے پروسیس کرنا ضروری ہو۔ اس صورت میں، 15 منٹ تک کئی فنکشن چلانا ایک ورچوئل مشین یا سرور کو ہر وقت برقرار رکھنے سے زیادہ منافع بخش ہے۔
سرور لیس کمپیوٹنگ کے تمام فوائد کے ساتھ، نفاذ سے پہلے، آپ کو پہلے ایپلی کیشن کی منطق کا جائزہ لینا چاہیے اور یہ سمجھنا چاہیے کہ سرور لیس کسی خاص معاملے میں کن مسائل کو حل کر سکتا ہے۔
سرور لیس اور سلیکٹیل
سلیکٹل میں ہم پہلے ہی ہیں۔ ہمارے کنٹرول پینل کے ذریعے۔ اب ہم اپنا FaaS پلیٹ فارم بنا رہے ہیں۔ ہم چاہتے ہیں کہ ڈویلپرز ایک آسان، لچکدار انٹرفیس کے ذریعے سرور لیس کا استعمال کرتے ہوئے اپنے مسائل حل کرنے کے قابل ہوں۔
اگر آپ کے پاس آئیڈیا ہے کہ مثالی FaaS پلیٹ فارم کیا ہونا چاہئے اور آپ اپنے پروجیکٹس میں سرور لیس کو کس طرح استعمال کرنا چاہتے ہیں تو انہیں تبصروں میں شیئر کریں۔ پلیٹ فارم تیار کرتے وقت ہم آپ کی خواہشات کو مدنظر رکھیں گے۔
مضمون میں استعمال ہونے والے مواد:
ماخذ: www.habr.com