سرور لیس فنکشنز
فنکشن بھیجیں۔ سرور کی فکر چھوڑیں۔
ایک repository جوڑیں اور ہر push ایک نیا Node.js یا Python version بناتا ہے۔ ہر فعال invocation اپنی Firecracker microVM حد کے اندر چلتا ہے، snapshot پر مبنی اسٹارٹ کے ساتھ اور بغیر کسی مشترکہ application container کے۔
- push سے لائیو تک تقریباً 25 سیکنڈ
- ناکامی پر پچھلا version لائیو رہتا ہے
- Push موصول ہوا 0.3s
- Node.js dependencies کا build
- v42 فعال ہوا 24.8s
- POST /hello 200 · 23ms
یہ کیسے کام کرتا ہے
تین مراحل، پھر ہر push لائیو۔
Functions باقی Sarpius کی طرح git-پہلے طریقے پر چلتے ہیں، لیکن مختصر مدت کے کاموں کے لیے بنے الگ تھلگ microVMs میں deploy ہوتے ہیں۔
اپنی repository جوڑیں
GitHub، GitLab، Gitea، Bitbucket یا کوئی بھی معیاری git remote چنیں۔ فنکشن آپ کے موجودہ Project کا حصہ بن جاتا ہے۔
function.json شامل کریں
Node.js یا Python، entry فائل، memory tier اور timeout طے کریں۔ runtime کا معاہدہ اسی code کے ساتھ رہتا ہے جس کی وہ وضاحت کرتا ہے۔
Push کریں اور route کریں
ہر push ایک نیا ناقابل تبدیل version بناتا ہے۔ تیار ہونے پر Sarpius بغیر downtime کے traffic بدل دیتا ہے، اور build ناکام ہو تو پچھلا version وہیں رہتا ہے۔
- GitHub
- GitLab
- Gitea
- Bitbucket
- + عمومی remote
اسے چلتے دیکھیں
ایک handler، ایک چھوٹا manifest، ایک لائیو URL۔
request آبجیکٹ میں HTTP method، path، query، headers اور body ہوتے ہیں۔ ایک status، متنی headers اور ایک body لوٹائیں۔
export async function handler(request) {
const input = request.body
? JSON.parse(request.body)
: {};
return {
status: 200,
headers: {
"content-type": "application/json"
},
body: JSON.stringify({
message: `Hello, ${input.name ?? "world"}`,
method: request.method,
path: request.path
})
};
}{
"lang": "node",
"tier": 128,
"entry": "index.mjs",
"timeout_s": 10
}$ curl -X POST \
-H "content-type: application/json" \
-d '{"name":"Ada"}' \
https://hello-function.sarpius.app/hello
{"message":"Hello, Ada","method":"POST","path":"/hello"}خصوصیات
آپ کے Project کا ایک مکمل حصہ۔
Functions آپ کے components، databases اور buckets کے ساتھ رہتے ہیں۔ console deploy، traffic اور لاگت کو ایک ہی جگہ رکھتا ہے۔
git سے لائیو تک
طے شدہ branch پر ہر push ایک build شروع کرتا ہے۔ production میں ناپے گئے اعداد کے مطابق کامیاب version تقریباً 25 سیکنڈ میں لائیو ہو جاتا ہے۔
ایٹمی version سوئچ
فعال version تب ہی بدلتا ہے جب نیا build کامیاب ہو جائے۔ موجودہ traffic فعال ہونے تک پچھلے version تک پہنچتا رہتا ہے۔
Project کے ساتھ مربوط
Functions کو Project سائیڈبار میں اپنا الگ سیکشن ملتا ہے اور وہ routing اور members ایپ کے باقی حصوں کے ساتھ بانٹتے ہیں۔
ایک سادہ request آبجیکٹ
ہر invocation کو method، route کیا ہوا path، خام query، چھنے ہوئے headers اور UTF-8 body ملتی ہے، اور وہ ایک status، متنی headers اور ایک body لوٹاتا ہے۔
Logs اور latency
build logs، حالیہ invocations اور فی گھنٹہ request اور error کی تعداد پڑھیں۔ console invocation کی p50 اور p95 latency پر نظر رکھتا ہے۔
Wallet اور سخت حدیں
استعمال اسی wallet سے کٹتا ہے جس سے باقی Sarpius۔ ایک فنکشن یا پورے Project کے لیے ماہانہ EUR حد مقرر کریں۔
Triggers
request کا جواب دیں یا شیڈول پر چلیں۔
دونوں trigger اقسام ایک ہی فعال version، budget جانچ، usage meter اور microVM isolation استعمال کرتی ہیں۔
آپ کے Project کی اپنی URL
مفت *.sarpius.app subdomain استعمال کریں یا فنکشن کو /api/hello جیسے Project route پر لگائیں۔ method، path، query، headers اور body handler تک پہنچتے ہیں۔
بغیر worker کے شیڈول شدہ کام
پانچ فیلڈ والا معیاری cron expression اور ایک IANA timezone استعمال کریں۔ رپورٹس، صفائی اور بار بار چلنے والے integrations کے لیے ایک فنکشن میں 10 تک schedules شامل کریں۔
claim کیا گیا slot crash کے بعد کبھی دوبارہ نہیں چلایا جاتا۔ چھوٹے ہوئے slots بعد میں پورے نہیں کیے جاتے، اس لیے scheduler کی بحالی کی وجہ سے side effects دو بار نہیں چل سکتے۔
قیمتیں
صرف چلنے والے کام کی ادائیگی کریں۔
compute کو GiB-سیکنڈ میں ناپا جاتا ہے، پھر invocations کی تعداد جوڑی جاتی ہے۔ ماہانہ مفت حد پہلے لگائی جاتی ہے، wallet سے ادا ہونے والے بل پر۔
ہر مہینے، ادائیگی والے استعمال سے پہلے
100,000 GiB-سیکنڈ اور 1,000,000 invocations مفت ہیں۔ بلنگ پورے cent میں ہوتی ہے، نیچے کی طرف گول کر کے، اور بچا ہوا حصہ اس وقت تک آپ کے استعمال میں رہتا ہے جب تک وہ مل کر ایک cent نہ بن جائے۔ کوئی کم از کم چارج نہیں ہے۔
چھوٹی API
128 MiB، اوسطاً 200 ms، 1,000,000 invocations
128/1024 × 0.2 × 1,000,000 = 25,000 GiB-s
25,000 مفت 100,000 سے کم ہے؛ 1,000,000 calls مفت ہیں → €0.00
پچاس لاکھ calls
128 MiB، اوسطاً 500 ms، 5,000,000 invocations
128/1024 × 0.5 × 5,000,000 = 312,500 GiB-s
(312,500 - 100,000) × €0.000016 = €3.40 compute
(5,000,000 - 1,000,000) / 1,000,000 × €0.20 = €0.80 calls → €4.20
بیس لاکھ calls
256 MiB، اوسطاً 1 سیکنڈ، 2,000,000 invocations
256/1024 × 1 × 2,000,000 = 500,000 GiB-s
(500,000 - 100,000) × €0.000016 = €6.40 compute
(2,000,000 - 1,000,000) / 1,000,000 × €0.20 = €0.20 calls → €6.60
چارجز آپ کے موجودہ Sarpius wallet سے کٹتے ہیں۔ بلنگ پہلے ماہانہ مفت حد لگاتی ہے۔ فی فنکشن اور فی Project ماہانہ حد مقرر کی جا سکتی ہے، اور اس کی حفاظتی جانچ مفت کریڈٹ سے پہلے کا مجموعی استعمال گنتی ہے، اس لیے وہ حتمی انوائس سے پہلے رک سکتی ہے۔ جب حد پوری ہو جائے، یا wallet خالی ہونے کی وجہ سے بلنگ فنکشن کو روک دے، تو نئی HTTP requests کو 402 Payment Required ملتا ہے اور کوئی microVM شروع نہیں کی جاتی۔
حفاظتی حدیں
کام کی بات یہ ہے کہ runtime کیا انکار کرتا ہے۔
یہ حدیں سروس کی طرف سے نافذ کی جاتی ہیں۔ یہ کسی dashboard میں لکھی ہلکی نصیحت نہیں ہیں۔
ایک microVM حد
ہر فعال invocation کو مشترکہ application container کی جگہ ایک Firecracker microVM حد ملتی ہے۔ گرم VMs کو ایک ہی فنکشن version کے لیے ترتیب سے دوبارہ استعمال کیا جا سکتا ہے، صارفین کے درمیان کبھی ایک ساتھ نہیں۔
مقررہ memory tiers
function.json میں 128، 256 یا 512 MiB چنیں۔ tier microVM پر نافذ ہوتا ہے اور GiB-سیکنڈ میٹرنگ کی بنیاد بھی ہے۔
زیادہ سے زیادہ 60 سیکنڈ
manifest 1 سے 60 سیکنڈ تک کا timeout طے کر سکتا ہے۔ timeout پر 504 لوٹتا ہے اور VM تباہ کر دی جاتی ہے، کسی غیر یقینی instance کو گرم pool میں واپس نہیں رکھا جاتا۔
Infrastructure بند ہو کر ناکام ہوتا ہے
اگر platform database، usage writer یا host egress guard ثابت نہ کر سکے کہ وہ تیار ہے، تو سروس 503 لوٹاتی ہے اور صارف کا code مفت میں یا پالیسی سے باہر نہیں چلاتی۔
Budget ایک سخت اسٹاپ ہے
فنکشن حد، Project حد یا بلنگ روک پوری ہونے پر VM ملنے سے پہلے HTTP 402 لوٹتا ہے۔ request آگے نہیں بڑھتی اور اضافی خرچ نہیں بناتی۔
Cron زیادہ سے زیادہ ایک بار چلتا ہے
scheduler بھیجنے سے پہلے ایک slot درج کرتا ہے۔ crash سے ایک run چھوٹ سکتا ہے، لیکن جب side effects ہو چکے ہوں تو وہ slot کبھی دوبارہ نہیں چلایا جاتا۔
FAQ
پہلے push سے پہلے کے سوالات۔
نیا version کتنی جلدی لائیو ہوتا ہے؟
production میں ناپے گئے اعداد کے مطابق push سے فعال version تک تقریباً 25 سیکنڈ لگتے ہیں۔ build کا وقت اب بھی repository اور dependencies پر منحصر ہے۔ نیا version فعال ہونے تک پچھلا version جواب دیتا رہتا ہے۔
build ناکام ہو تو کیا ہوتا ہے؟
activation صرف کامیاب build کے بعد ہوتی ہے۔ ناکام build Project میں اپنے log کے ساتھ دکھایا جاتا ہے، جبکہ آخری فعال version لائیو رہتا ہے۔
کیا دو صارفین کبھی ایک function container بانٹتے ہیں؟
صارفین کے فنکشنز کوئی مشترکہ application container نہیں چلاتا۔ ہر فعال invocation کو ایک Firecracker microVM حد ملتی ہے۔ ایک گرم VM کو روک کر بعد میں اسی فنکشن version کے لیے دوبارہ استعمال کیا جا سکتا ہے، اگلی call سے پہلے اس کی گھڑی تازہ کر دی جاتی ہے۔
کون سے runtimes دستیاب ہیں؟
کلوزڈ بیٹا میں Node.js اور Python دستیاب ہیں۔ manifest میں lang: "node" یا lang: "python" لکھا جاتا ہے، اور export کیا ہوا یا متعین handler(request) ہوتا ہے۔
HTTP trigger سے فنکشن کو کیا ملتا ہے؟
handler کو method، route کیا ہوا path، خام query، چھنے ہوئے headers اور UTF-8 body ملتی ہے۔ وہ HTTP status، متنی header قدریں اور response body لوٹاتا ہے۔
خرچ کی حد پر کیا ہوتا ہے؟
سروس microVM لینے سے پہلے HTTP 402 لوٹاتی ہے۔ یہی جواب تب بھی آتا ہے جب wallet مزید استعمال نہ اٹھا سکے اور بلنگ نے فنکشن کو روک دیا ہو۔
فنکشن push کریں۔ Project اپنے پاس رکھیں۔
سرور لیس کام کو اس code، data، routes اور لوگوں کے ساتھ deploy کریں جن سے وہ جڑا ہے۔ اصل execution کی ادائیگی کریں، اور اپنی مقرر کردہ حد پر خود بخود رک جائیں۔