سرورلس یا سرور سنتی؟ مقایسه Workload، TCO و SLO

Serverless می‌تواند در چند ثانیه هزاران اجرا بسازد و همان لحظه پایگاه داده شما را از پا درآورد. Auto-scaling فقط وقتی مزیت است که Concurrency، Connection، Quota و Backpressure کل زنجیره طراحی شده باشند. از طرف دیگر، یک VPS همیشه «گرم و قابل‌پیش‌بینی» نیست؛ Noisy neighbor، Saturation، Patch، Deploy و Failure domain می‌توانند SLO را بشکنند. پس «سرورلس یا هاست سنتی؟» با یک فهرست مزایا و معایب جواب داده نمی‌شود.

انتخاب قابل‌دفاع از Workload شروع می‌شود: درخواست هم‌زمان است یا Event غیرهم‌زمان؟ میانگین و Peak چند است؟ Duration، State، Connection، Latency و RPO/RTO چیست؟ سپس Service boundary، Quota، TCO، مسئولیت امنیت و عملیات، امکان استفاده قانونی/قراردادی برای ایران و مسیر Exit را مقایسه می‌کنیم.

اول واژه‌ها را درست کنیم؛ «سنتی» یک مدل واحد نیست

Serverless به معنی نبود سرور یا نبود Operations نیست؛ Server provisioning و بخشی از Platform operations از دید تیم پنهان می‌شود. همچنین FaaS تمام Serverless نیست: Container، Database، Queue و Workflow مدیریت‌شده می‌توانند بخشی از معماری Serverless باشند.

برای مقایسه عمومی Shared، Managed، VPS، Cloud و Dedicated بر پایه Workload و SLO، راهنمای انتخاب هاست Pillar اصلی است. این مقاله روی Placement میان Server-based و Serverless تمرکز دارد.

Shared responsibility؛ Serverless هرگز NoOps نیست

در Serverless، Provider سخت‌افزار، Host OS و بخشی از Runtime/Scaling را اداره می‌کند. تیم شما همچنان مالک رفتار برنامه، Dependency، IAM، Secret، Config، داده، Retention، Cost، Observability، Resilience و Incident است.

«Provider Backup دارد» به معنی Restore قابل‌اثبات برای Application نیست. «Managed» نیز Scope استاندارد جهانی ندارد؛ RACI را از Contract و آزمون واقعی استخراج کنید.

Workload Contract؛ ورودی واقعی تصمیم

اسم پروژه—فروشگاه، API، چت‌بات یا MVP—مدل Hosting را تعیین نمی‌کند. این جدول را برای هر Component پر کنید:

Concurrency را از بازدید ماهانه حدس نزنید

Concurrency تقریبی = Request rate × Average duration

این فرمول فقط نقطه شروع است؛ Burst، P95/P99 Duration، Retry و Batch را جدا مدل کنید. تابعی با ۱۰۰ درخواست در ثانیه و زمان ۲ ثانیه، حدود ۲۰۰ اجرای هم‌زمان می‌خواهد؛ اگر Database فقط ۵۰ Connection تحمل کند، Scale تابع مسئله را بدتر می‌کند.

Serverless در عمل از چند سرویس ساخته می‌شود

یک «Function» به‌تنهایی Website نیست. معماری معمول می‌تواند CDN/Object storage برای Frontend، API gateway، Function/Container، Queue، Database، Cache، Secret manager، Identity، Log/Trace و CI/CD داشته باشد. هر سرویس Cost، Quota، Failure mode و Lock-in جدا دارد.

Serverless Applications Lens در AWS Well-Architected نیز Reliability را حاصل Foundation، Monitoring، Change management و Failure management می‌داند؛ Auto-scaling جای طراحی Reliability را نمی‌گیرد.

Auto-scaling نامحدود یا آنی نیست

Providerها Account/Region quota، Scaling rate، Max instance، Concurrency، Payload، Timeout و API limit دارند. Serviceهای پایین‌دست نیز ظرفیت مستقل دارند. مستند Concurrency در AWS Lambda Scaling را تا سقف Account/Region و تنظیمات Function توضیح می‌دهد؛ صفحه Quotaهای Lambda نیز نشان می‌دهد Limit سرویس‌های دیگر می‌تواند زنجیره را محدود کند.

Cloud Run نیز براساس CPU/Concurrency Scale می‌کند و امکان Min/Max instance دارد. مستند رسمی Autoscaling در Cloud Run توصیه می‌کند Max instance برای محافظت از Backendها تنظیم شود.

Load test باید End-to-end باشد؛ تولید هزار Function بدون Database، NAT، Queue و Vendor واقعی نتیجه معماری را نشان نمی‌دهد.

Cold start را اندازه بگیرید، نه اینکه عدد جهانی بدهید

Cold start به Runtime، Package/Image، Initialization، Region، Network/VPC، Secret/Config، Language و Platform بستگی دارد. عدد «چند صد میلی‌ثانیه» برای همه Workloadها معتبر نیست. این Metricها را جدا ثبت کنید:

• Warm و Cold latency در p50/p95/p99؛
• Init duration و سهم Dependency/Network؛
• نرخ Cold invocation در Traffic واقعی؛
• اثر Deploy یا Scale burst؛
• Latency از ISPهای هدف ایران؛
• Cost و Utilization گزینه Min instance/Provisioned capacity.

Min instance یا Provisioned concurrency می‌تواند Tail latency را کم کند اما هزینه Idle و Complexity را برمی‌گرداند. Cron برای Keep-warm تضمین ظرفیت یا SLO نیست. اگر User-facing request حساس است، Warm strategy را در TCO و Failure test بیاورید.

Timeout و Runtime limit بین Provider و Plan فرق دارد

قاعده عمومی «Function حداکثر ۱۵ دقیقه» منقضی و Provider-specific است. جدول جاری Scale/Hosting در Azure Functions نشان می‌دهد Timeout به Plan و نوع Trigger وابسته است و حتی HTTP مسیر جدا دارد. همیشه مستند همان Service، Region و Plan را در تاریخ تصمیم Snapshot کنید.

کار طولانی را لزوماً با افزایش Timeout حل نکنید. Async job، Queue، Durable workflow، Batch یا Serverless container ممکن است Failure recovery و Progress بهتری بدهد.

Pay-per-use به معنی «فقط هزینه تابع» نیست

صورتحساب Serverless ممکن است این ردیف‌ها را داشته باشد:

• Request/Event و CPU/Memory/Duration؛
• Min instance یا Provisioned capacity؛
• API gateway، Load balancer و CDN؛
• Database، Cache، Queue، Workflow و Object storage؛
• Log، Metric، Trace، Retention و Query؛
• Data transfer، Egress، NAT و VPC connector؛
• Build، Artifact/Container registry و Secret/KMS؛
• Backup/Restore، Support plan و Incident؛
• مهندسی، IaC، Security review و Migration/Exit.

صفحه رسمی قیمت Cloud Run نمونه خوبی است: CPU/Memory، Billing mode، Request، Min instance، Region و Data transfer بر Cost اثر دارند. تعرفه را در تاریخ تصمیم از منبع رسمی بگیرید؛ Free tier یا قیمت تبلیغاتی Business case پایدار نیست.

فرمول مقایسه هم‌سطح

Serverless TCO =
Requests + Compute duration + Warm/idle
+ Gateway/DB/Queue/Storage/Network/Telemetry
+ Engineering/Ops/Security/Support/Risk/Exit

Server-based TCO =
Allocated capacity + License/Network/Storage/LB
+ Provisioning/Scaling/Patch/Backup/Observability
+ Engineering/Ops/Security/Support/Risk/Exit

سه سناریوی کم/محتمل/زیاد بسازید: RPS، Duration، Memory، Concurrency، Log volume، Egress، نرخ ارز و Incident. سپس Cost per successful request/job/business outcome را مقایسه کنید، نه فقط هزینه ماهانه Compute.

برای Quote normalization، FX، Egress، SLA و Exit به راهنمای TCO دامنه و هاست مراجعه کنید.

Stateless compute؛ State حذف نمی‌شود، جابه‌جا می‌شود

Function/Container instance ممکن است Reuse شود اما Local memory/filesystem را منبع قطعی State ندانید. Session، File، Lock، Workflow و Transaction به Database، Object storage، Cache یا State machine منتقل می‌شوند؛ این انتقال Latency، Cost و Consistency دارد.

Event delivery، Retry و Idempotency

بسیاری از Event sourceها Semantics حداقل یک‌بار دارند؛ Duplicate ممکن است حتی بدون خطای آشکار رخ دهد. Best practices رسمی AWS Lambda برای Event source mapping، Idempotent بودن Function را توصیه می‌کند.

• Idempotency key با Scope، Payload hash، نتیجه و TTL؛
• Unique constraint یا Inbox برای جلوگیری از اثر تکراری؛
• Retry فقط برای خطای موقت با Backoff/Jitter و سقف؛
• DLQ/Failure destination و Owner برای Poison event؛
• Partial batch response تا یک رکورد کل Batch را تکرار نکند؛
• Ordering فقط وقتی Contract سرویس آن را تضمین می‌کند؛
• Schema version و سازگاری Producer/Consumer؛
• Reconciliation برای پرداخت، ایمیل، موجودی و عملیات خارجی.

تابع Retryشده نباید دو بار مبلغ کم، دو پیامک ارسال یا دو سفارش بسازد. الگوی Idempotency، Timeout و Webhook در راهنمای طراحی API قابل‌اعتماد عمیق‌تر آمده است.

Reliability؛ Failure domain و Recovery را ببینید

Managed service می‌تواند Multi-AZ داخلی داشته باشد، اما Architecture شما ممکن است Single region، Secret واحد، Queue اشتباه یا Database بدون Recovery باشد. SLO را برای Journey کامل بنویسید، نه Availability جداگانه هر سرویس.

Backup خدمت مدیریت‌شده را با Restore drill خودتان تأیید کنید؛ راهنمای بازیابی فاجعه، RPO/RTO و Runbook این لایه را پوشش می‌دهد.

Observability در معماری توزیع‌شده

Logهای جداگانه Function بدون Correlation، Timeline رخداد را نشان نمی‌دهند. Minimum telemetry:

• Correlation/Trace ID از Edge تا Queue/DB؛
• Request/Event count، Error، Duration و Throttle؛
• Cold/init duration، concurrency و instance count؛
• Queue depth/age، Retry و DLQ؛
• Downstream latency/error و Connection saturation؛
• Deploy/Config/Schema version؛
• Cost by Function/Feature/Tenant/Outcome؛
• Structured log با Redaction و Retention؛
• Synthetic probe از شبکه‌های هدف ایران.

Cardinality و Retention می‌توانند Cost Telemetry را منفجر کنند. Sampling باید Debug و Security را کور نکند. طراحی Metric/Log/Trace/SLO در مقاله Observability سایت و Outside-in checks در مانیتورینگ Uptime تکمیل شده‌اند.

امنیت؛ Attack surface عوض می‌شود، حذف نمی‌شود

Patch Host به Provider منتقل می‌شود، اما Misconfiguration، IAM گسترده، Event injection، Secret leakage، Dependency آسیب‌پذیر، SSRF، Log حاوی داده حساس، Supply chain و Abuse هزینه همچنان با شماست. پروژه OWASP Serverless Top ۱۰ تفاوت Attack vectorها را مرور می‌کند؛ آن را با Threat model جاری و OWASP Web/API تکمیل کنید.

• Role کم‌اختیار برای هر Function/Service؛
• AuthN/AuthZ در Gateway و Domain، نه اعتماد به Trigger؛
• Validation برای HTTP و Event payload؛
• Secret manager و Rotation؛ نه Secret در Env dump/Log؛
• Dependency pinning، SBOM، scan و Runtime EOL plan؛
• Network egress policy و محافظت Metadata endpoint؛
• Rate limit، Budget cap و Abuse detection؛
• Encryption/Key policy، Audit log و Incident runbook؛
• Isolation داده Tenant و تست مجوز Object/Property.

برای BOLA/BOPLA، OAuth/JWT، SSRF، Webhook و Incident، راهنمای امنیت API را به Release gate اضافه کنید.

توسعه، تست و Deploy

Local emulator همه رفتار Production—Quota، IAM، Retry، Cold start و Managed dependency—را بازسازی نمی‌کند. پشته تست باید شامل Unit، Contract، Integration در Cloud، Failure injection، Load/soak، Security و Canary باشد.

• IaC برای Function، IAM، Queue، Alarm، Secret و Policy؛
• Environment مجزا با Account/Project boundary مناسب؛
• Artifact immutable و Version/Alias؛
• Backward-compatible Event/DB migration؛
• Canary/weighted traffic و Rollback کد/Config؛
• Replay داده Sanitized و Shadow event در Pilot؛
• Limit test نزدیک Quota اما با محافظت Production؛
• Runbook برای Throttle، backlog، bad deploy و cost spike.

Vendor lock-in؛ کد تنها بخش مهاجرت نیست

Function handler شاید قابل‌انتقال باشد، اما Event format، IAM، API gateway، Database semantics، Queue، Workflow، Observability و IaC معمولاً Coupling اصلی‌اند. Abstraction کامل نیز هزینه و قابلیت Native را کم می‌کند.

Exit plan باید RTO، Data export، DNS/Traffic switch، Dual-run cost و Trigger خروج داشته باشد. «استاندارد باز استفاده می‌کنیم» بدون Drill، شاهد Portability نیست.

آیا WordPress را Serverless کنیم؟

WordPress برای PHP، Database و عملیات فایل/Upload/Plugin/Update طراحی شده است. Requirements رسمی WordPress در Snapshot جاری PHP ۸.۳+، MariaDB ۱۰.۱۱+ یا MySQL ۸.۰+ و HTTPS را توصیه می‌کند. Full dynamic WordPress روی FaaS معمولاً به Database خارجی، Object storage برای Media، Strategy فایل/Plugin، Cache، Cron، Email، Session/Admin و Compatibility نیاز دارد.

گزینه‌ها:

برای بیشتر سایت‌های WordPress، «استفاده هدفمند از Serverless در حاشیه» ارزش سریع‌تری از بازطراحی کل Runtime دارد. CDN برای مخاطب و Origin ایرانی را در راهنمای انتخاب و راه‌اندازی CDN ارزیابی کنید.

ماتریس انتخاب بر پایه Workload

راهنمای تصمیم رسمی AWS Fargate یا Lambda نیز Duration/Event-driven fit، Control، Scaling و Pricing را در انتخاب Compute وارد می‌کند. همان منطق را Vendor-neutral و با داده خودتان اجرا کنید.

Serverless برای ایران؛ Eligibility قبل از Benchmark

• شرایط Provider: کشور، Account، Billing، Export/Service terms و Support را از منبع رسمی بررسی کنید؛ دورزدن محدودیت، معماری تداوم کسب‌وکار نیست؛
• پرداخت و FX: نرخ ارز، Tax/fee، سقف پرداخت و Cost spike را سناریویی کنید؛
• Region/Network: Latency و Availability را از ISP، شهر و دستگاه هدف Probe کنید؛ نزدیک‌ترین Region روی نقشه الزاماً بهترین Route نیست؛
• Dependency ایران: درگاه، SMS، نقشه و سرویس داخلی Timeout/Rate limit متفاوت دارند؛
• Data location: طبقه داده، مسیر، Backup و Requirement قراردادی/حقوقی را بررسی کنید؛
• Vendor داخلی: نام Serverless کافی نیست؛ Runtime، Timeout، Concurrency، Scale rate، Region، SLA، Log، IAM، Pricing و Exit را با PoC راستی‌آزمایی کنید؛
• Fallback: Queue، Static degrade، Provider دوم یا مسیر Manual بر اساس Criticality؛
• Support: زمان پاسخ Incident، Escalation و امکان دسترسی تیم در بحران.

Scorecard انتخاب

Knockout پیش از امتیاز: Service غیرمجاز/غیرقابل‌پرداخت، نبود Region/Data control لازم، Runtime/Timeout ناسازگار، Quota غیرقابل‌افزایش، نبود Recovery یا Cost worst-case فراتر از سقف.

Pilot و مهاجرت بدون Rewrite بزرگ

1. Inventory Component، Event، State، Dependency و SLO؛
2. یک Capability محدود مانند Image resize، Webhook یا Job انتخاب کنید؛
3. Workload/Cost/Responsibility contract و Baseline موجود بسازید؛
4. IaC، Idempotency، Timeout/Retry/DLQ، Telemetry و Budget alert را قبل از Traffic آماده کنید؛
5. Replay و Shadow با داده Sanitized؛
6. Load/soak/burst/quota/downstream/failure/cold test؛
7. Canary یا Dual-run با Reconciliation؛
8. SLO، TCO، MTTR، Developer effort و Exit را مقایسه؛
9. Scale، Iterate یا Stop و Runbook را ثبت کنید.

Kill criteria نمونه

• P99 Latency یا Error budget خارج Threshold؛
• Throttle/Queue age/DB connection غیرقابل‌کنترل؛
• Duplicate effect یا Reconciliation gap؛
• Cost per successful outcome بالاتر از Baseline؛
• Telemetry/Debug ناکافی و MTTR بدتر؛
• Eligibility، Billing یا Support غیرقابل اتکا؛
• Recovery/Export/rollback Drill شکست بخورد.

برنامه ۹۰روزه تصمیم و Pilot

چک‌لیست Serverless یا Server-based

• Component، Trigger، Sync/Async و Outcome دقیق است؛
• RPS/Peak/Burst/Duration/Concurrency و Resource اندازه‌گیری شده‌اند؛
• State، Connection، File، Transaction و Ordering Contract دارند؛
• SLO، Error budget، RPO و RTO روشن‌اند؛
• Quota/Scale rate/Timeout/Payload/Runtime از Docs جاری Snapshot شده‌اند؛
• Max concurrency از Database و Dependency محافظت می‌کند؛
• Retry budget، Idempotency، DLQ و Reconciliation تست شده‌اند؛
• Cold/warm p50/p95/p99 و Min/provisioned option مقایسه شده‌اند؛
• Cost شامل Gateway/DB/Queue/Log/Egress/NAT/Warm/Ops/Exit است؛
• Free tier از Business case پایه حذف شده است؛
• IAM، Secret، Event validation، dependency و abuse control آماده‌اند؛
• Metric/Log/Trace/Correlation/Cost attribution و Alert عملیاتی‌اند؛
• IaC، Environment، Canary و rollback وجود دارند؛
• Backup/Restore و Region/service failure بر اساس RPO/RTO آزموده شده‌اند؛
• Eligibility/Billing/FX/Region/ISP/Dependency ایران تأیید شده‌اند؛
• Provider limit و Support با PoC، نه بروشور، سنجیده شده‌اند؛
• Exit شامل Event/Data/IAM/Telemetry است، نه فقط Source code؛
• Hybrid placement برای هر Workload جدا تصمیم گرفته شده است؛
• Pilot معیار Scale/Iterate/Stop دارد؛
• Owner عملیات و Incident پس از تحویل معلوم است.

جمع‌بندی؛ برچسب نه، Workload و Evidence

Serverless یک مدل عملیاتی ارزشمند است: Provisioning و بخشی از Scaling/Runtime را به Provider می‌سپارد و برای Event، Burst و Capability مستقل می‌تواند Time-to-value خوبی بسازد. در عوض، State، Event semantics، Quota، Cost پراکنده، Observability و Coupling سرویس‌های مدیریت‌شده را باید عمداً طراحی کنید.

Server-based نیز مترادف دستی، کند یا ناامن نیست؛ Managed hosting، PaaS و Container autoscaling گزینه‌های میانی‌اند. پاسخ درست ممکن است WordPress مدیریت‌شده با CDN و چند Function جانبی، API روی Serverless container، یا Core پایدار روی VM و Jobهای Event-driven باشد. Workload contract، SLO، TCO، Load/failure test و Exit drill باید تصمیم را بسازند—به‌خصوص وقتی Eligibility، FX و مسیر شبکه ایران وارد معادله می‌شود.

سؤالات متداول Serverless و هاست سنتی

آیا Serverless واقعاً بدون سرور و بدون عملیات است؟

خیر. Serverها و عملیات Platform وجود دارند و Provider آن‌ها را مدیریت می‌کند. تیم شما همچنان مالک کد، Dependency، IAM، Secret، Config، داده، Event/Retry، Quota، Cost، Observability، Recovery و Incident است. نام دقیق‌تر «کاهش مدیریت مستقیم سرور» است، نه NoOps.

آیا Serverless همیشه ارزان‌تر است؟

خیر. Traffic shape، Duration، Memory/CPU، Concurrency، Warm capacity، Gateway، Database، Queue، Log/Trace، Egress/NAT، Support و کار مهندسی Cost را می‌سازند. سه سناریوی Workload را با TCO کامل و Cost per successful outcome با VM/PaaS مقایسه کنید.

Cold start چقدر است و چگونه رفع می‌شود؟

عدد جهانی ندارد و به Platform، Runtime، Package، Init، Network و Region بستگی دارد. Warm/cold p95/p99 را روی مسیر واقعی اندازه بگیرید؛ Package/Init را کم، Connection را مدیریت و در صورت نیاز Min instance یا Provisioned capacity را با هزینه‌اش مقایسه کنید. Keep-warm تضمین SLO نیست.

آیا WordPress را روی Serverless اجرا کنیم؟

ممکن است، اما Full WordPress به PHP، Database، Media/files، Plugin/update، Cron و Admin state نیاز دارد و Adaptation می‌تواند TCO را بالا ببرد. برای بیشتر سایت‌ها Managed WordPress + CDN و Functionهای جانبی برای Webhook/Image/Job ساده‌تر است. Headless/static نیز Forms، Search، Preview و Invalidation را باید حل کند.

برای پروژه ایرانی Serverless بهتر است یا VPS؟

بدون Workload و Provider evidence پاسخ عمومی ندارد. Eligibility/Terms، Billing/FX، Region و Latency چند ISP، Data location، درگاه/SMS، Quota، Support و Exit را Knockout کنید؛ سپس یک Capability محدود را با Replay، Load/failure test و Canary در برابر VPS/Managed baseline بسنجید.