سرور لیس انقلاب کیوں تعطل کا شکار ہے۔

اہم نکات

  • اب کئی سالوں سے ہم سے وعدہ کیا جا رہا ہے کہ سرور لیس کمپیوٹنگ (سرور لیس) ایپلی کیشنز کو چلانے کے لیے مخصوص OS کے بغیر ایک نئے دور کا آغاز کرے گی۔ ہمیں بتایا گیا کہ اس طرح کے ڈھانچے سے اسکیل ایبلٹی کے بہت سے مسائل حل ہوں گے۔ اصل میں، سب کچھ مختلف ہے.
  • اگرچہ بہت سے لوگ سرور لیس ٹیکنالوجی کو ایک نئے آئیڈیا کے طور پر دیکھتے ہیں، لیکن اس کی جڑیں 2006 میں Zimki PaaS اور Google App Engine کے ساتھ تلاش کی جا سکتی ہیں، یہ دونوں ہی بغیر سرور کے فن تعمیر کا استعمال کرتے ہیں۔
  • سرور کے بغیر انقلاب کے رک جانے کی چار وجوہات ہیں، محدود پروگرامنگ لینگویج سپورٹ سے لے کر کارکردگی کے مسائل تک۔
  • سرور لیس کمپیوٹنگ اتنا بیکار نہیں ہے۔ اس سے دور۔ تاہم، انہیں سرورز کے لیے براہ راست متبادل کے طور پر نہیں دیکھا جانا چاہیے۔ کچھ ایپلی کیشنز کے لیے، وہ ایک آسان ٹول ہو سکتے ہیں۔

سرور مر گیا، سرور زندہ باد!

یہ بے سرور انقلاب کے پیروکاروں کی جنگ ہے۔ پچھلے کچھ سالوں میں انڈسٹری پریس پر ایک سرسری نظر یہ نتیجہ اخذ کرنے کے لیے کافی ہے کہ سرور کا روایتی ماڈل ختم ہو چکا ہے اور چند سالوں میں ہم سب بغیر سرور کے فن تعمیرات کا استعمال کریں گے۔

جیسا کہ انڈسٹری میں کوئی بھی جانتا ہے، اور جیسا کہ ہم نے اپنے مضمون میں بھی اشارہ کیا ہے۔ سرور لیس کمپیوٹنگ کی حالت، یہ غلط ہے. میرٹ پر بہت سے مضامین کے باوجود سرور کے بغیر انقلاب، یہ کبھی نہیں ہوا. حقیقت میں، حالیہ مطالعات سے پتہ چلتا ہےکہ شاید یہ انقلاب اپنے انجام کو پہنچ چکا ہو۔

سرور لیس ماڈلز کے کچھ وعدے یقیناً پورے ہوئے ہیں، لیکن سبھی نہیں۔ ہر کوئی نہیں۔

اس مضمون میں میں اس حالت کی وجوہات پر غور کرنا چاہتا ہوں۔ سرور لیس ماڈلز کی لچک کی کمی اب بھی ان کے وسیع تر اختیار کرنے میں رکاوٹ کیوں ہے، حالانکہ وہ مخصوص، اچھی طرح سے متعین حالات میں کارآمد رہتے ہیں۔

سرور لیس کمپیوٹنگ کے ماہروں نے کیا وعدہ کیا ہے۔

سرور لیس کمپیوٹنگ کے مسائل کی طرف جانے سے پہلے، آئیے دیکھتے ہیں کہ انہیں کیا فراہم کرنا تھا۔ بے سرور انقلاب کے وعدے۔ بے شمار اور - بعض اوقات - بہت مہتواکانکشی تھے۔

اصطلاح سے ناواقف افراد کے لیے، یہاں ایک مختصر تعریف ہے۔ سرور لیس کمپیوٹنگ ایک ایسے فن تعمیر کی وضاحت کرتی ہے جس میں ایپلی کیشنز (یا ایپلی کیشنز کے حصے) رن ٹائم ماحول میں ڈیمانڈ پر چلتی ہیں جو عام طور پر دور سے ہوسٹ کی جاتی ہیں۔ اس کے علاوہ، سرور لیس سسٹم کی میزبانی کی جا سکتی ہے۔ مضبوط سرور لیس سسٹمز کی تعمیر پچھلے کچھ سالوں سے سسٹم ایڈمنسٹریٹرز اور SaaS کمپنیوں کی ایک بڑی تشویش رہی ہے، جیسا کہ (یہ دعویٰ کیا جاتا ہے) یہ فن تعمیر "روایتی" کلائنٹ/سرور ماڈل کے مقابلے میں کئی اہم فوائد پیش کرتا ہے:

  1. سرور لیس ماڈلز کے لیے صارفین کو اپنے آپریٹنگ سسٹم کو برقرار رکھنے یا مخصوص آپریٹنگ سسٹم کے ساتھ مطابقت رکھنے والی ایپلیکیشنز بنانے کی ضرورت نہیں ہوتی ہے۔ اس کے بجائے، ڈویلپر مشترکہ کوڈ بناتے ہیں، اسے بغیر سرور پلیٹ فارم پر اپ لوڈ کرتے ہیں، اور اسے چلتا دیکھتے ہیں۔
  2. سرور لیس فریم ورک میں وسائل کا بل عام طور پر منٹ (یا اس سے بھی سیکنڈوں میں) ہوتا ہے۔ اس کا مطلب ہے کہ کلائنٹ صرف اس وقت کے لیے ادائیگی کرتے ہیں جب وہ اصل میں کوڈ پر عمل درآمد کرتے ہیں۔ یہ روایتی کلاؤڈ VM کے ساتھ موافق ہے، جہاں مشین زیادہ تر وقت بیکار رہتی ہے، لیکن آپ کو اس کی قیمت ادا کرنی ہوگی۔
  3. اسکیل ایبلٹی کا مسئلہ بھی حل ہوگیا۔ سرور لیس فریم ورک میں وسائل کو متحرک طور پر تفویض کیا جاتا ہے تاکہ سسٹم آسانی سے مانگ میں اچانک اضافے کا مقابلہ کر سکے۔

مختصراً، سرور لیس ماڈل لچکدار، کم لاگت، توسیع پذیر حل فراہم کرتے ہیں۔ مجھے حیرت ہے کہ ہم نے اس خیال کے بارے میں پہلے نہیں سوچا تھا۔

کیا یہ واقعی کوئی نیا آئیڈیا ہے؟

دراصل خیال نیا نہیں ہے۔ صارفین کو صرف اس وقت کے لیے ادائیگی کرنے کی اجازت دینے کا تصور جب سے کوڈ کے اصل میں چلتا ہے تب سے اسے متعارف کرایا گیا تھا۔ Zimki PaaS 2006 میں، اور اسی وقت، گوگل ایپ انجن نے ایک بہت ہی ملتا جلتا حل پیش کیا۔

درحقیقت، جسے اب ہم "سرور لیس" ماڈل کہتے ہیں، وہ بہت سی ٹیکنالوجیز سے پرانا ہے جنہیں اب "کلاؤڈ مقامی" کہا جاتا ہے جو تقریباً ایک جیسی فراہم کرتی ہیں۔ جیسا کہ نوٹ کیا گیا ہے، سرور لیس ماڈل بنیادی طور پر SaaS بزنس ماڈل کی صرف ایک توسیع ہیں جو کئی دہائیوں سے چلی آرہی ہے۔

یہ بھی تسلیم کرنے کے قابل ہے کہ سرور لیس ماڈل کوئی FaaS فن تعمیر نہیں ہے، حالانکہ دونوں کے درمیان تعلق ہے۔ FaaS بنیادی طور پر سرور لیس فن تعمیر کا کمپیوٹ مرکوز حصہ ہے، لیکن یہ پورے نظام کی نمائندگی نہیں کرتا ہے۔

تو یہ سب ہائپ کیوں؟ ٹھیک ہے، جیسا کہ ترقی پذیر ممالک میں انٹرنیٹ کی رسائی کی شرح آسمان کو چھو رہی ہے، اسی طرح کمپیوٹنگ وسائل کی مانگ بھی بڑھ رہی ہے۔ مثال کے طور پر، تیزی سے بڑھتے ہوئے ای کامرس سیکٹر والے بہت سے ممالک کے پاس ان پلیٹ فارمز پر ایپلی کیشنز کے لیے کمپیوٹنگ کا بنیادی ڈھانچہ نہیں ہے۔ یہ وہ جگہ ہے جہاں ادا شدہ سرور لیس پلیٹ فارم آتے ہیں۔

سرور لیس ماڈلز کے ساتھ مسائل

کیچ یہ ہے کہ سرور لیس ماڈلز میں… مسائل ہیں۔ مجھے غلط مت سمجھو: میں یہ نہیں کہہ رہا ہوں کہ وہ اپنے آپ میں اور ان کے بارے میں برا ہیں یا کچھ حالات میں کچھ کمپنیوں کو اہم قیمت فراہم نہیں کرتے ہیں۔ لیکن "انقلاب" کا بنیادی دعویٰ - کہ سرور لیس فن تعمیر تیزی سے روایتی کی جگہ لے لے گا - کبھی پورا نہیں ہوتا۔

اس لیے.

پروگرامنگ زبانوں کے لیے محدود تعاون

زیادہ تر سرور لیس پلیٹ فارم صرف مخصوص زبانوں میں لکھی گئی ایپلی کیشنز کو چلانے کی اجازت دیتے ہیں۔ یہ ان نظاموں کی لچک اور موافقت کو سختی سے محدود کرتا ہے۔

سرور لیس پلیٹ فارمز کو زیادہ تر بڑی زبانوں کی حمایت کرنے کے لیے سمجھا جاتا ہے۔ AWS Lambda اور Azure Functions غیر تعاون یافتہ زبانوں میں ایپلیکیشنز اور فنکشنز چلانے کے لیے ایک ریپر بھی فراہم کرتے ہیں، حالانکہ یہ اکثر کارکردگی کی قیمت پر آتا ہے۔ لہذا زیادہ تر تنظیموں کے لئے، یہ حد عام طور پر کوئی بڑی بات نہیں ہے۔ لیکن یہاں بات ہے۔ سرور لیس ماڈلز کا ایک فائدہ یہ سمجھا جاتا ہے کہ غیر واضح، کبھی کبھار استعمال ہونے والے پروگرام سستے استعمال کیے جاسکتے ہیں کیونکہ آپ صرف ان کے چلنے کے وقت کی ادائیگی کرتے ہیں۔ اور غیر واضح، شاذ و نادر ہی استعمال ہونے والے پروگرام اکثر... غیر واضح، شاذ و نادر ہی استعمال ہونے والی پروگرامنگ زبانوں میں لکھے جاتے ہیں۔

یہ سرور لیس ماڈل کے اہم فوائد میں سے ایک کو نقصان پہنچاتا ہے۔

کسی فروش کا پابند ہونا

سرور لیس پلیٹ فارمز کے ساتھ دوسرا مسئلہ، یا کم از کم جس طرح سے وہ فی الحال نافذ کیے گئے ہیں، یہ ہے کہ وہ عام طور پر آپریشنل سطح پر ایک جیسے نظر نہیں آتے۔ تحریری افعال، تعیناتی اور انتظام کے لحاظ سے عملی طور پر کوئی معیاری کاری نہیں ہے۔ اس کا مطلب ہے کہ فیچرز کو ایک پلیٹ فارم سے دوسرے پلیٹ فارم پر منتقل کرنا بہت وقت طلب ہے۔

سرور لیس ماڈل میں جانے کا سب سے مشکل حصہ کمپیوٹیشنل فیچرز نہیں ہیں، جو کہ عام طور پر کوڈ کے صرف ٹکڑے ہوتے ہیں، بلکہ ایپلیکیشنز کس طرح منسلک سسٹمز جیسے آبجیکٹ اسٹوریج، شناختی انتظام، اور قطاروں کے ساتھ بات چیت کرتی ہیں۔ افعال کو منتقل کیا جا سکتا ہے، لیکن باقی ایپلی کیشن نہیں کر سکتے ہیں. یہ وعدہ کردہ سستے اور لچکدار پلیٹ فارمز کے بالکل برعکس ہے۔

کچھ لوگوں کا کہنا ہے کہ سرور کے بغیر ماڈلز نئے ہیں اور ان کے کام کرنے کے طریقے کو معیاری بنانے کا وقت نہیں ملا ہے۔ لیکن وہ اتنے نئے نہیں ہیں، جیسا کہ میں نے اوپر لکھا ہے، اور بہت سی دوسری کلاؤڈ ٹیکنالوجیز جیسے کنٹینرز پہلے ہی اچھے معیارات کی ترقی اور وسیع پیمانے پر اپنانے کی وجہ سے بہت زیادہ آسان ہو چکے ہیں۔

کارکردگی

سرور لیس پلیٹ فارمز کی کمپیوٹنگ کارکردگی کی پیمائش کرنا مشکل ہے، جزوی طور پر اس لیے کہ دکاندار معلومات کو خفیہ رکھنے کا رجحان رکھتے ہیں۔ زیادہ تر کا کہنا ہے کہ ریموٹ، سرور لیس پلیٹ فارمز پر خصوصیات اتنی ہی تیزی سے چلتی ہیں جتنی کہ وہ اندرونی سرورز پر چلتی ہیں، کچھ ناگزیر تاخیر کے مسائل کو بچاتے ہیں۔

تاہم، کچھ ثبوت دوسری صورت میں بتاتے ہیں۔ وہ فنکشن جو پہلے کسی خاص پلیٹ فارم پر نہیں چلتے، یا کچھ عرصے سے نہیں چلتے، شروع ہونے میں کچھ وقت لگتے ہیں۔ اس کی وجہ یہ ہے کہ ان کے کوڈ کو آسانی سے دستیاب اسٹوریج میڈیم پر پورٹ کیا گیا ہے، حالانکہ - جیسا کہ بینچ مارکس کے ساتھ ہے - زیادہ تر دکاندار آپ کو ڈیٹا پورٹ کرنے کے بارے میں نہیں بتائیں گے۔

یقینا، اس کے ارد گرد حاصل کرنے کے کئی طریقے ہیں. ایک یہ کہ آپ کا سرور لیس پلیٹ فارم جس بھی کلاؤڈ لینگویج پر چلتا ہے اس کے لیے فیچرز کو بہتر بنانا ہے، لیکن اس سے اس دعوے کو کسی حد تک نقصان پہنچتا ہے کہ یہ پلیٹ فارم "چست" ہیں۔

ایک اور نقطہ نظر یہ یقینی بنانا ہے کہ کارکردگی کے لحاظ سے اہم پروگراموں کو "تازہ" رکھنے کے لیے باقاعدگی سے چلایا جائے۔ یہ دوسرا نقطہ نظر، یقیناً، اس دعوے کا تھوڑا سا مخالف ہے کہ سرور لیس پلیٹ فارم زیادہ لاگت کے حامل ہیں کیونکہ آپ صرف اس وقت کے لیے ادائیگی کرتے ہیں جب آپ کے پروگرام چلتے ہیں۔ کلاؤڈ فراہم کرنے والوں نے کولڈ اسٹارٹ کو کم کرنے کے نئے طریقے متعارف کرائے ہیں، لیکن ان میں سے بہت سے لوگوں کو "اسکیل ٹو ون" (اسکیل ٹو ون) کی ضرورت ہوتی ہے، جس سے FaaS کی اصل قدر کو نقصان پہنچتا ہے۔

کولڈ اسٹارٹ کے مسئلے کو جزوی طور پر اندرون ملک سرور لیس سسٹم چلا کر حل کیا جا سکتا ہے، لیکن یہ اپنی قیمت پر آتا ہے اور اچھی طرح سے وسائل رکھنے والی ٹیموں کے لیے ایک بہترین آپشن رہتا ہے۔

آپ پوری ایپلیکیشنز نہیں چلا سکتے

آخر میں، شاید سب سے اہم وجہ کیوں کہ سرور لیس فن تعمیر روایتی ماڈلز کو جلد ہی کسی بھی وقت تبدیل نہیں کریں گے یہ ہے کہ وہ (عام طور پر) پوری ایپلی کیشنز نہیں چلا سکتے ہیں۔

زیادہ واضح طور پر، یہ لاگت کے نقطہ نظر سے ناقابل عمل ہے۔ آپ کے کامیاب یک سنگی کو شاید چار درجن فنکشنز کے سیٹ میں تبدیل نہیں کیا جانا چاہیے جو آٹھ گیٹ ویز، چالیس قطاروں، اور ایک درجن ڈیٹا بیس مثالوں کے ذریعے ایک ساتھ بندھے ہوئے ہوں۔ اس وجہ سے، سرور لیس نئی پیشرفت کے لیے بہتر موزوں ہے۔ عملی طور پر کوئی موجودہ ایپلیکیشن (فن تعمیر) پورٹ نہیں کی جا سکتی ہے۔ آپ ہجرت کر سکتے ہیں، لیکن آپ کو شروع سے شروع کرنا ہوگا۔

اس کا مطلب یہ ہے کہ زیادہ تر معاملات میں، سرور لیس پلیٹ فارمز کو بیک اینڈ سرورز کی تکمیل کے طور پر کمپیوٹیشنل طور پر گہرا کام انجام دینے کے لیے استعمال کیا جاتا ہے۔ یہ کلاؤڈ کمپیوٹنگ کی دیگر دو شکلوں، کنٹینرز اور ورچوئل مشینوں سے بہت مختلف ہے، جو ریموٹ کمپیوٹنگ کو انجام دینے کا ایک جامع طریقہ پیش کرتی ہیں۔ یہ مائیکرو سروسز سے سرور لیس سسٹمز میں منتقل ہونے کے چیلنجوں میں سے ایک کو واضح کرتا ہے۔

یقینا، یہ ہمیشہ ایک مسئلہ نہیں ہے. آپ کے اپنے ہارڈویئر کو خریدے بغیر وقتاً فوقتاً بھاری کمپیوٹنگ وسائل استعمال کرنے کی صلاحیت بہت سی تنظیموں کو حقیقی اور دیرپا فائدے پہنچا سکتی ہے۔ لیکن اگر کچھ ایپلی کیشنز اندرونی سرورز پر ہیں اور دیگر سرور لیس کلاؤڈ آرکیٹیکچرز پر ہیں، تو مینجمنٹ پیچیدگی کی ایک نئی سطح میں داخل ہوتی ہے۔

انقلاب زندہ باد؟

ان تمام شکایات کے باوجود، میں سرور کے بغیر حل کے خلاف نہیں ہوں۔ ایمانداری سے۔ یہ صرف اتنا ہے کہ ڈویلپرز کو سمجھنے کی ضرورت ہے - خاص طور پر اگر وہ پہلی بار بغیر سرور کے ماڈلز کی تلاش کر رہے ہیں - کہ یہ ٹیکنالوجی سرورز کا براہ راست متبادل نہیں ہے۔ اس کے بجائے، ہماری تجاویز اور وسائل کو چیک کریں۔ بغیر سرور ایپلی کیشنز کی تعمیر اور فیصلہ کریں کہ اس ماڈل کو کس طرح لاگو کرنا ہے۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں