Serverless Architecture
- ●Serverless মানে server নেই তা নয় — মানে server-এর ব্যবস্থাপনা cloud provider সামলায়, তুমি শুধু কোড লেখো।
- ●FaaS (যেমন AWS Lambda)-এ ছোট function event-এর জবাবে চলে, request অনুযায়ী auto-scale করে।
- ●তুমি শুধু আসল ব্যবহারের জন্য পয়সা দাও, কিন্তু cold start আর vendor lock-in মনে রাখতে হবে।
সমস্যাটা কী?
ধরো তুমি একটা ছোট ফিচার বানাতে চাও — কেউ ছবি আপলোড করলে সেটার একটা thumbnail বানানো হবে। এটুকুর জন্য তোমাকে একটা পুরো server ভাড়া নিতে হবে, OS আপডেট রাখতে হবে, security patch দিতে হবে, আর ২৪ ঘণ্টা চালু রাখতে হবে — যদিও হয়তো দিনে মাত্র ১০ বার ছবি আপলোড হয়।
মানে: বেশিরভাগ সময় server বসে বসে বিদ্যুৎ আর টাকা খাচ্ছে, কিন্তু কাজ করছে খুব কম। আবার হঠাৎ ১০ হাজার ছবি এলে সেই একটা server চাপে পড়ে যাবে। এই "সবসময় চালু রাখা" আর "নিজে scale সামলানো"-র ঝামেলা থেকে বাঁচতেই Serverless।
মূল ধারণা
Serverless architecture এমন একটা মডেল যেখানে তুমি server-এর provisioning, scaling বা maintenance নিয়ে ভাবো না — cloud provider সব সামলায়। তুমি শুধু ছোট ছোট function লেখো যা event-এর জবাবে চলে। এই function-চালিত মডেলকে বলে FaaS (Function as a Service)।
নামটা একটু বিভ্রান্তিকর — server থাকেই, কিন্তু সেটা তোমার মাথাব্যথা নয়। তুমি শুধু business logic-এ মন দাও।
মূল বৈশিষ্ট্য: function তখনই চলে যখন কোনো ঘটনা ঘটে — তাই একে Event Trigger বলে। কেউ ছবি আপলোড করল, কেউ API call করল, কিংবা ঘড়িতে নির্দিষ্ট সময় হলো — এসবই trigger।
কীভাবে কাজ করে
Event থেকে execution
- একটা event ঘটে — যেমন S3-তে একটা ফাইল আপলোড হলো।
- Provider function চালু করে — দরকার মতো একটা environment তৈরি করে।
- Function চলে — thumbnail বানায়।
- Function শেষ হলে environment বন্ধ হতে পারে — কোনো কাজ না থাকলে কিছু চলে না।
এই auto-scaling স্বয়ংক্রিয়: ১০টা request এলে ১০টা copy, ১০ হাজার এলে হাজার হাজার copy — তোমাকে কিছু করতে হয় না।
Cold start বনাম Warm start
| অবস্থা | মানে | গতি |
|---|---|---|
| Cold start | অনেকক্ষণ পর প্রথম call, নতুন environment তৈরি হয় | ধীর (কয়েকশ ms – কয়েক সেকেন্ড) |
| Warm start | সদ্য চলেছে এমন environment আবার ব্যবহার | দ্রুত |
Cold Start হলো serverless-এর সবচেয়ে আলোচিত সীমাবদ্ধতা — idle function প্রথমবার জাগতে দেরি করে।
Pricing
| মডেল | কখন টাকা কাটে |
|---|---|
| Traditional server | মাসিক ভাড়া, ব্যবহার যাই হোক |
| Serverless (pay-per-use) | শুধু invocation সংখ্যা ও execution সময় অনুযায়ী |
Pay-per-use-এ কেউ ব্যবহার না করলে তুমি প্রায় কিছুই দাও না — এটাই বড় আকর্ষণ।
নিজের গাড়ি কেনা মানে traditional server — কেনার খরচ, পার্কিং, তেল, সার্ভিসিং, সব তোমার; গাড়ি গ্যারেজে বসে থাকলেও খরচ চলে। Serverless হলো Pathao/Uber ডাকার মতো — দরকার হলে ডাকলে, যতটুকু চড়লে ততটুকু ভাড়া, না চড়লে শূন্য। তবে গাড়িটা আসতে একটু সময় লাগে — এটাই cold start। আর তুমি গাড়ির ব্র্যান্ড বা ড্রাইভার বেছে নিতে পারো না, যেমন vendor-এর নিয়ম মানতে হয়।
সুবিধা ও অসুবিধা
সুবিধা:
- কোনো server ব্যবস্থাপনা নেই: patching, scaling, OS — সব provider-এর দায়িত্ব।
- স্বয়ংক্রিয় scaling: শূন্য থেকে হাজার পর্যন্ত নিজে নিজে।
- খরচ-সাশ্রয়ী: idle হলে প্রায় ০ খরচ; কম-ট্রাফিক বা spiky কাজের জন্য আদর্শ।
- দ্রুত development: infrastructure ভুলে শুধু কোডে মন দেওয়া যায়।
অসুবিধা:
- Cold start latency: দেরি-সংবেদনশীল কাজে সমস্যা।
- Vendor lock-in: AWS Lambda-র কোড সহজে অন্য cloud-এ নেওয়া যায় না।
- সীমাবদ্ধতা: execution time (যেমন AWS-এ ১৫ মিনিট), memory ইত্যাদির সীমা আছে।
- Debugging কঠিন: distributed, ক্ষণস্থায়ী environment-এ সমস্যা খোঁজা কঠিন।
- খরচ অপ্রত্যাশিত হতে পারে: খুব উচ্চ, ধারাবাহিক ট্রাফিকে এটা traditional server-এর চেয়ে দামি হয়ে যেতে পারে।
কখন ব্যবহার করবে / করবে না
ব্যবহার করবে যখন: কাজটা event-চালিত (ফাইল প্রসেসিং, scheduled job, webhook), ট্রাফিক অনিয়মিত বা spiky, কিংবা দ্রুত একটা প্রোটোটাইপ বানাতে চাও কম খরচে।
এড়িয়ে যাবে যখন: কাজটা সবসময় চলমান ও দীর্ঘ (যেমন WebSocket দিয়ে real-time game), latency খুব গুরুত্বপূর্ণ, কিংবা ট্রাফিক বিশাল ও ধারাবাহিক (তখন dedicated server সস্তা)।
সবচেয়ে কমন ফাঁদ: serverless-কে "সবকিছুর সমাধান" ভাবা। যদি তোমার function অনেক বেশি বার, অবিরাম চলে, তাহলে pay-per-use হিসাব উল্টে যায় — মাসে dedicated server-এর চেয়ে অনেক বেশি বিল আসতে পারে। সবসময় তোমার আসল traffic pattern অনুযায়ী খরচ হিসাব করে নাও, ধরে নিও না serverless মানেই সস্তা।
বাস্তব উদাহরণ
Coca-Cola তাদের ভেন্ডিং মেশিনের সিস্টেম serverless-এ নিয়ে গেছে। আগে যখনই কেউ মেশিন থেকে drink কিনত, একটা সবসময়-চালু server সেই লেনদেন সামলাত — যার বেশিরভাগ সময় কোনো কাজ থাকত না। AWS Lambda-তে গিয়ে তারা প্রতিটি কেনাকে একটা event বানাল — শুধু যখন কেউ কেনে তখনই function চলে। ফলে তাদের খরচ নাটকীয়ভাবে কমে — শোনা যায় বছরে হাজার হাজার ডলার সাশ্রয়, কারণ idle সময়ে আর কোনো বিল নেই।
আরেকটা ক্লাসিক উদাহরণ: ছবি/ভিডিও প্রসেসিং — যেমন Netflix-এর মিডিয়া এনকোডিং পাইপলাইনের কিছু অংশ event-চালিত serverless function দিয়ে চলে।
ইন্টারভিউতে cold start নিয়ে জিজ্ঞেস করলে শুধু সমস্যাটা বলো না, সমাধানও বলো: "provisioned concurrency" দিয়ে function গরম রাখা, lightweight runtime (যেমন Go) বেছে নেওয়া, কিংবা warm-up ping পাঠানো। সমস্যা ও তার প্রশমন — দুটোই বলতে পারলে তুমি ব্যবহারিক জ্ঞান দেখাও।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Serverless বলতে আসলে কী বোঝায়?
2. Cold start কী?
3. Serverless-এর pricing মডেল সাধারণত কেমন?