Serverless function: কীভাবে কাজ করে ও কখন ব্যবহার করবেন

Serverless মানে server নেই এমন নয়। মানে আপনি সেগুলো সামলান না। কোড আপলোড করেন, provider দরকারে তা চালায়, স্বয়ংক্রিয়ভাবে scale করে এবং আসলে ব্যবহৃত সময় ও resource-এর বিল করে। প্রচলিত রূপ FaaS (functions as a service), যেমন AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers এবং Vercel বা Netlify function।

কীভাবে কাজ করে

১. আপনি ছোট একটি function লেখেন যা event নেয় ও ফল ফেরত দেয়। ২. একটি trigger যুক্ত করেন: HTTP request, ফাইল upload, queue-র বার্তা, database বদল বা schedule। ৩. Trigger চালু হলে provider একটি পরিবেশ শুরু করে, আপনার function চালায় এবং পরবর্তী কলে সেই পরিবেশ পুনর্ব্যবহার করতে পারে। ৪. হাজার event এলে অনেক কপি সমান্তরালে চলে। একটিও না এলে কিছু চলে না, বিলও হয় না (সংশ্লিষ্ট সেবা বাদে)।

export async function handler(event) {
  const name = event.queryStringParameters?.name ?? "world";
  return { statusCode: 200, body: JSON.stringify({ message: "Hello " + name }) };
}

সঠিক signature provider ভেদে আলাদা।

শক্তি

• Server ব্যবস্থাপনা নেই: patch নেই, ক্ষমতা পরিকল্পনা নেই।
• স্বয়ংক্রিয় scaling, শূন্য পর্যন্ত নামা সহ।
• ব্যবহার অনুযায়ী দাম, যা spike-যুক্ত বা কম traffic-এ সস্তা।
• ছোট backend যুক্তি দ্রুত পাঠানো।
• Event-চালিত কাজের জন্য ভালো মানানসই।

সীমা ও লাভ-ক্ষতি

• Cold start: নিষ্ক্রিয়তার পর প্রথম request ধীর হতে পারে যখন নতুন পরিবেশ শুরু হয়। runtime, package-এর আকার ও provider ভেদে আলাদা। Edge runtime সাধারণত অনেক দ্রুত।
• সময় ও memory সীমা: function সাধারণত বড়জোর কয়েক মিনিটে শেষ করতে হয়, memory সীমিত। দীর্ঘ কাজে অন্য টুল লাগে।
• Stateless: প্রতিটি কল আলাদা পরিবেশে চলতে পারে। গুরুত্বপূর্ণ data memory বা স্থানীয় disk-এ রাখবেন না। database, cache বা object storage ব্যবহার করুন।
• Database সংযোগ: অনেক সমান্তরাল function অনেক সংযোগ খুলে সাধারণ database কাবু করে ফেলতে পারে। connection pooler বা serverless-বান্ধব database বা HTTP-ভিত্তিক driver ব্যবহার করুন।
• বড় পরিসরে খরচ: স্থির, ভারী traffic কয়েকটি সবসময়-চালু server-এর চেয়ে বেশি ব্যয়বহুল হতে পারে।
• Debug ও স্থানীয় পরীক্ষা কঠিন, আর অনেক provider-নির্দিষ্ট trigger ব্যবহার করলে vendor lock-in বাড়তে পারে।
• সাধারণ function-এ WebSocket-এর মতো দীর্ঘ সংযোগ অস্বস্তিকর।

ভালো ব্যবহার

• Webhook ও ছোট API।
• Upload-এর পর ছবি resize বা প্রক্রিয়া।
• Schedule করা কাজ (cron-ধাঁচের)।
• Queue-র বার্তা বা stream event প্রক্রিয়া।
• Service-এর মাঝে সংযোগ ও হালকা automation।
• অত্যন্ত পরিবর্তনশীল traffic-এর সাইট।

কখন সাধারণ server বা container ভালো

• স্থির উচ্চ traffic যেখানে সবসময়-চালু instance সস্তা।
• দীর্ঘ কাজ, ভারী state-যুক্ত background worker বা WebSocket।
• অত্যন্ত latency-সংবেদনশীল পথ যেখানে cold start অগ্রহণযোগ্য।
• বিশেষ software বা পরিবেশের সূক্ষ্ম নিয়ন্ত্রণ লাগা অ্যাপ।
• যেসব দল এক provider-এর মডেলে বাঁধা পড়তে চায় না।

শূন্যে নামতে পারা container platform মাঝামাঝি পথ, function-এর চেয়ে বেশি স্বাধীনতা সহ।

ভালো অভ্যাস

• Function ছোট ও কেন্দ্রীভূত রাখুন, এবং cold start কমাতে deployment package ছোট রাখুন।
• Handler idempotent বানান। Event একাধিকবার আসতে পারে, তাই একই event দুবার প্রক্রিয়া নিরাপদ হতে হবে।
• যুক্তিসঙ্গত timeout ও memory এবং নিচের সিস্টেম রক্ষায় concurrency limit দিন।
• প্রতিটি function-এ least-privilege role ব্যবহার করুন।
• Secret রাখুন secrets manager বা platform-এর secret store-এ, কোডে নয়।
• Logging, metrics ও alert যোগ করুন। structured log ও trace ID ব্যবহার করুন।
• Async trigger-এ dead-letter queue দিন, যাতে ব্যর্থ event হারিয়ে না গিয়ে পরীক্ষার জন্য থাকে।
• বিলে নজর রাখুন, কারণ নিজেকে trigger করা bug বা loop দ্রুত খরচ বাড়াতে পারে।

মূল কথা: event-চালিত, spike-যুক্ত ও ছোট কাজে যেখানে server কাজ চান না, সেখানে serverless দারুণ। Cold start, সীমা, stateless এবং database সংযোগের পরিকল্পনা করুন, handler idempotent বানান, আর traffic স্থির ও ভারী হলে সাধারণ server বাছুন।

---

Networking ও Cloud সিরিজ, পর্ব ২ (cloud-এর গোড়া): 5 নম্বর (মোট 5)। আগের লেখা: Object storage (S3)-এর গোড়া: bucket, access ও presigned URL.