Serverless کیا ہے؟ Serverless Computing آسان الفاظ میں

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

AI کے ساتھ بناتے وقت serverless کیوں اہم ہے

جب آپ AI سے ایپ بناتے ہیں اور ہوسٹنگ کے اختیارات یا کوڈ دیکھتے ہیں تو آپ کو "serverless functions"، "edge functions" یا "cloud functions" نظر آئیں گے۔ بہت سے ہوسٹنگ پلیٹ فارمز یہ پیش کرتے ہیں، اور کچھ AI بلڈرز بیک اینڈ اس طرح تعینات کرتے ہیں۔ اس ماڈل کو سمجھنا تین عملی سوالات میں مدد دیتا ہے:

• لاگت۔ کیا آپ کی ایپ کے استعمال نہ ہونے پر بھی پیسے لگیں گے؟
• رفتار۔ پرسکون وقت کے بعد پہلی درخواست کیوں سست ہے؟
• حدیں۔ کوئی طویل کام، جیسے بڑی رپورٹ بنانا یا ویڈیو پروسیس کرنا، وقت ختم ہو کر کیوں ناکام ہوا؟

یہ جاننا بھی مددگار ہے کہ serverless کیا نہیں ہے: یہ بیک اینڈ کی غیر موجودگی نہیں ہے۔ آپ کے پاس پھر بھی سرور سائیڈ کوڈ ہوتا ہے؛ بس مشینیں کوئی اور چلاتا ہے۔ بنیادی باتوں کے لیے دیکھیں سرور کیا ہے۔

ایک روزمرہ کی مثال

روایتی سرور گاڑی رکھنے جیسا ہے۔ وہ ہمیشہ موجود رہتا ہے، فوراً تیار، مگر آپ اس کے پیسے دیتے ہیں، انشورنس، پارکنگ اور دیکھ بھال، چاہے آپ اسے چلائیں یا نہ چلائیں۔

Serverless ٹیکسی بلانے جیسا ہے۔ آپ صرف اپنے سفر کی ادائیگی کرتے ہیں، اور اگر سو لوگوں کو ایک ساتھ سواری چاہیے تو سو ٹیکسیاں آ جاتی ہیں۔ لیکن گاڑی آنے میں تھوڑا انتظار ہو سکتا ہے (cold start)، ہر سفر کی زیادہ سے زیادہ لمبائی ہوتی ہے، اور ڈرائیور آپ کو پچھلی سواری سے یاد نہیں رکھتا (فنکشنز stateless ہوتے ہیں)۔

serverless فنکشنز کیسے کام کرتے ہیں

سب سے عام شکل میں، جسے functions as a service کہا جاتا ہے:

1. آپ ایک فنکشن لکھتے ہیں، یعنی کوڈ کا ایک چھوٹا ٹکڑا جو ایک طرح کا واقعہ سنبھالتا ہے، جیسے "/api/bookings پر POST کو سنبھالو"۔
2. آپ اسے تعینات کرتے ہیں۔ فراہم کنندہ اسے محفوظ کرتا ہے اور ایک محرک سے جوڑ دیتا ہے: ایک URL، ایک شیڈول، اسٹوریج میں ایک نئی فائل، یا قطار میں ایک پیغام۔
3. ایک واقعہ آتا ہے۔ فراہم کنندہ آپ کے فنکشن کی ایک کاپی شروع کرتا ہے (یا کسی گرم کاپی کو دوبارہ استعمال کرتا ہے)، اسے چلاتا ہے اور نتیجہ لوٹاتا ہے۔
4. یہ خود بخود پیمانہ بدلتا ہے۔ اگر ایک ساتھ ایک ہزار درخواستیں آئیں تو فراہم کنندہ بہت سی کاپیاں متوازی طور پر چلاتا ہے، آپ کے اکاؤنٹ کی حدوں تک۔
5. یہ بیکار ہو جاتا ہے۔ جب ٹریفک رکتا ہے تو کاپیاں بند ہو جاتی ہیں۔ کچھ نہ چلنے پر کمپیوٹ کے لیے آپ کچھ ادا نہیں کرتے۔

جاوا اسکرپٹ میں ایک چھوٹا serverless فنکشن کچھ یوں لگ سکتا ہے:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

یہاں سرور شروع کرنے، پورٹ کھولنے، یا کوئی پروسیس چالو رکھنے کا کوئی کوڈ نہیں ہے۔ یہ سب پلیٹ فارم سنبھالتا ہے۔

"Serverless" کو عام طور پر دوسری منیجڈ سروسز کے لیے بھی ڈھیلے انداز میں استعمال کیا جاتا ہے جو خودکار طور پر پیمانہ بدلتی ہیں اور استعمال کے حساب سے بل کرتی ہیں، مثلاً serverless ڈیٹا بیسز، جو بیکار ہونے پر رک جاتے ہیں۔

اہم اصطلاحات

ایک عملی مثال: ایک چھوٹی بکنگ سائٹ

ایک یوگا اسٹوڈیو کی بکنگ سائٹ ہر اتوار شام نئے شیڈول کے اعلان کے وقت بھاری وزٹس دیکھتی ہے، اور باقی ہفتے بہت کم۔

• ہمیشہ چالو سرور پر، اسٹوڈیو 24/7 ایک مشین کی ادائیگی کرتا ہے، جو اتوار شام کی چوٹی کے لیے موزوں ہو، اور باقی وقت زیادہ تر بیکار رہتی ہے۔
• serverless فنکشنز کے ساتھ، GET /api/classes اور POST /api/bookings فنکشنز ہیں۔ اتوار کا رش خود بخود بہت سی کاپیاں شروع کرتا ہے؛ منگل کی خاموش صبح تقریباً کچھ نہیں چلتا اور بل تقریباً صفر ہوتا ہے۔

تجارتی سمجھوتے بھی نظر آتے ہیں۔ منگل کی صبح سائٹ کھولنے والے پہلے شخص کو cold start کی وجہ سے ایک اضافی لمحہ انتظار کرنا پڑ سکتا ہے۔ ڈیٹا بیس کو بہت سی فنکشن کاپیوں سے آنے والے مختصر عمر کے بہت سے کنکشنز سنبھالنے ہوں گے، جن کے لیے connection pooler کی ضرورت ہو سکتی ہے۔ اور اگر اسٹوڈیو بعد میں "سب کی سالانہ حاضری کی PDF بنائیں" جیسا کام چاہے تو وہ فنکشن کی وقت کی حد سے تجاوز کر سکتا ہے اور کہیں اور چلانا پڑ سکتا ہے۔

serverless کب موزوں ہے، اور کب نہیں

عام غلط فہمیاں

• "Serverless کا مطلب ہے کوئی بیک اینڈ نہیں۔" اس کا مطلب ہے سنبھالنے کے لیے کوئی سرور نہیں۔ آپ پھر بھی بیک اینڈ کوڈ لکھتے اور محفوظ کرتے ہیں۔
• "Serverless ہمیشہ سستا ہوتا ہے۔" کم حجم پر سستا، لیکن ہر درخواست کی قیمت بہت زیادہ اور مسلسل حجم پر جمع ہو کر مہنگا پڑ سکتا ہے۔
• "Serverless لامحدود پیمانہ بدلتا ہے۔" پلیٹ فارمز کی concurrency کی حدیں ہوتی ہیں، اور آپ کا ڈیٹا بیس فنکشنز سے بہت پہلے رکاوٹ بن سکتا ہے۔
• "فنکشن میں محفوظ فائلیں اگلی بار بھی موجود ہوں گی۔" لوکل اسٹوریج عارضی ہوتا ہے۔ ڈیٹا بیس یا فائل اسٹوریج استعمال کریں۔
• "Scale-to-zero، serverless کے برابر ہے۔" متعلقہ ہے، مگر ایک جیسا نہیں۔ کچھ پلیٹ فارمز آپ کی ایپ کو ایک عام سرور کی طرح چلاتے ہیں جو بیکار ہونے پر سو جاتا ہے اور اگلی درخواست پر جاگ جاتا ہے۔ بچت اور پہلی درخواست کی تاخیر تقریباً ایک جیسی ہوتی ہے، مگر ہر درخواست پر فنکشن جیسی فی درخواست وقت کی حدیں نہیں ہوتیں۔

اپنے AI بلڈر سے کیا پوچھیں

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

Mythex ایپس کیسے ہوسٹ کرتا ہے

Mythex اپنی ہوسٹنگ کو serverless functions کے طور پر بیان نہیں کرتا۔ شائع کرنے پر آپ کی ایپ ایک عام ویب ایپ یا کنٹینر کے طور پر چلتی ہے جسے Mythex آپ کے لیے سنبھالتا ہے؛ ہوسٹنگ سیٹ اپ کرنے کی ضرورت نہیں۔ یہ scale-to-zero ہے: شائع شدہ ایپس اور ان کے ڈیٹا بیسز بیکار ہونے پر سو جاتے ہیں اور اگلی وزٹ پر جاگ جاتے ہیں، سوئی ہوئی ایپ کمپیوٹ پر کچھ خرچ نہیں کرتی، اور اضافی مشینیں صرف بھاری ٹریفک کے وقت شروع ہوتی ہیں (Pro پر فی سروس 3 تک)۔ منسلک Postgres ڈیٹا بیس بھی 5 منٹ بیکار رہنے پر سو جاتا ہے اور جتنی دیر جاگا رہے اس کا بل ہوتا ہے۔ یوں آپ کو "جتنا استعمال کریں اتنا ادا کریں" کا بہت سا فائدہ ملتا ہے، اور پرسکون وقت کے بعد پہلی درخواست پر اسی طرح کی تاخیر کے ساتھ۔ دستاویزات میں ہوسٹنگ کی حدیں دیکھیں، اور ہمارے گائیڈز ویب ہوسٹنگ کیا ہے اور ہوسٹنگ کی لاگت کم کیسے کریں پڑھیں۔

سوالات