معماری Serverless: چه زمانی نباید از آن در پروژههای سازمانی استفاده کنیم؟
تصور کنید صاحب یک رستوران هستید. در مدل سنتی، شما مجبورید یک آشپزخانه کامل بخرید، اجارهبهای ماهانه پرداخت کنید، یخچالها را سرویس کنید و حتی وقتی مشتریی ندارید، باید هزینه برق و گاز را بدهید. اما حالا تصور کنید سرویسی وجود داشته باشد که در آن شما فقط وقتی سفارش غذا میرسد، یک آشپز حرفهای برای چند دقیقه ظاهر میشود، غذا را میپزد و بلافاصله میرود؛ و شما فقط هزینه همان چند دقیقه کار آشپز و مواد اولیه غذا را میپردازید. هیچ دغدغهای بابت تعمیر یخچال یا پرداخت اجاره فضای خالی ندارید.
این دقیقاً همان ایدهی معماری بدون سرور یا Serverless است. اما آیا واقعاً همه رستورانها (یا همان پروژههای سازمانی) با این مدل راحت میکنند؟ پاسخ کوتاه این است: خیر. هرچند غولهایی مثل AWS، گوگل و مایروسافت سعی میکنند Serverless را به عنوان "آیندهی مطلق" معرفی کنند، اما در دنیای واقعی، استفاده از آن در هر پروژهای میتواند تبدیل به یک کابوس مالی و فنی شود.
«بزرگترین اشتباه در دنیای نرمافزار، استفاده از ابزاری است که "مد" شده است، بدون اینکه نیازهای واقعی کسبوکار و محدودیتهای زیرساختی در نظر گرفته شود.»
بیایید روراست باشیم؛ وقتی صحبت از پروژههای سازمانی (Enterprise) میشود، ما با متغیرهای پیچیدهای مثل امنیت سختگیرانه، بودجههای سالانه پیشبینی شده و سیستمهای قدیمی (Legacy) سر و کار داریم. در این محیطها، Serverless همیشه یک "راه نجات" نیست و گاهی اوقات تبدیل به یک "تله" میشود. در این مقاله قرار است با نگاهی نقادانه بررسی کنیم که کجاست که باید ترمز بکشیم و از این فناوری دوری کنیم.
سرورلس واقعاً به چه معناست؟ (فراتر از نام گمراهکننده)
اولین چیزی که باید روشن کنیم این است که در معماری Serverless، سرور وجود دارد. بله، شاید عجیب باشد، اما نام Serverless یک شوخی تکنولوژیک است. در واقع، سرورها هنوز آنجا هستند، اما مدیریت آنها از دوش شما برداشته شده و به گردن ارائهدهنده سرویس (مثل AWS Lambda یا Google Cloud Functions) افتاده است.
در مدلهای سنتی (حتی در Virtual Machines)، شما باید نگران موارد زیر باشید:
- آپدیت کردن سیستمعامل (Patching)
- مانیتورینگ میزان مصرف CPU و RAM
- تنظیمات Load Balancer برای توزیع ترافیک
- مدیریت فضای دیسک و بکآپها
در Serverless، شما فقط کد خود را مینویسید (یک تابع یا Function) و آن را آپلود میکنید. سرویسدهنده تصمیم میگیرد کد شما کجا اجرا شود، چگونه مقیاس پذیر شود و چه زمانی خاموش شود. این یعنی شما از Infrastructure as a Service (IaaS) به سمت Function as a Service (FaaS) حرکت کردهاید.
اما نکته اینجاست: این راحتی، بهایی دارد. شما کنترل خود را بر روی محیط اجرا از دست میدهید. اگر بخواهید یک تنظیم خاص روی هستهی سیستمعامل تغییر دهید یا یک کتابخانه خاص را در سطح لینوکس نصب کنید، احتمالاً با دیوار بزرگی مواجه میشوید. برای یک استارتاپ کوچک که میخواهد سریع محصولش را عرضه کند، این یک مزیت است؛ اما برای یک سازمان مالی یا دولتی که استانداردهای سختگیرانهای برای کنترل زیرساخت دارد، این یک نقطه ضعف بزرگ است.
پدیده Cold Start یا «خواب زمستانی» توابع
آیا تا به حال پیش آمده که یک وبسایت را باز کنید و اولین بار لود شدن آن چند ثانیه طول بکشد، اما دفعات بعدی با سرعت برق بزند؟ در دنیای Serverless، پدیدهای وجود دارد به نام Cold Start (استارت سرد).
وقتی تابعی در Serverless تعریف میشود، ارائهدهنده برای صرفهجویی در منابع، آن را در حالت آمادهبهکار نگه نمیدارد. وقتی درخواستی میرسد، سیستم باید ابتدا یک کانتینر کوچک ایجاد کند، محیط اجرای زبان برنامه نویسی (مثلاً Node.js یا Python) را بالا بیاورد و سپس کد شما را اجرا کند. این فرآیند ممکن است از چند میلیثانیه تا چندین ثانیه طول بکشد.
چرا این موضوع در پروژههای سازمانی خطرناک است؟
تصور کنید یک اپلیکیشن بانکی دارید که کاربرانی با توقعات بسیار بالا دارد. اگر کاربر روی دکمه "پرداخت" کلیک کند و به دلیل Cold Start، سیستم ۳ ثانیه مکث کند، کاربر تصور میکند برنامه هنگ کرده یا تراکنش ناموفق بوده است. در سیستمهای با ترافیک بالا و Constant Load (بار ثابت)، سرورهای سنتی یا کانتینرهای همیشه فعال (مثل Kubernetes) بسیار بهینهتر هستند چون هیچوقت "نمیخوابند".
البته برخی شرکتها برای حل این مشکل، از قابلیت "Warm-up" استفاده میکنند یا هزینهی بیشتری میپردازند تا توابع همیشه گرم بمانند. اما در این لحظه، شما عملاً دارید دوباره به همان مدل "پرداخت برای منابع رزرو شده" برمیگردید و مزیت اصلی Serverless (یعنی پرداخت فقط به اندازه مصرف) را از دست میدهید.
تلهی هزینهها: وقتی Serverless ارزان نیست
یکی از بزرگترین افسانههای دنیای فناوری این است که "سرورلس همیشه ارزانتر است". بیایید این باور را با واقعیتهای عددی بررسی کنیم. Serverless برای ترافیکهای متغیر، غیرقابل پیشبینی یا کمترافیک، فوقالعاده بهصرفه است. اما وقتی حجم درخواستها به مقیاسهای سازمانی (مثلاً میلیونها درخواست در ساعت) میرسد، معادله تغییر میکند.
در مدل سرور سنتی یا VPS، شما یک مبلغ ثابت ماهانه میپردازید. فرقی نمیکند ۱۰۰ نفر بیایند یا ۱۰۰,۰۰۰ نفر (تا زمانی که منابع سرور اجازه دهد). اما در Serverless، هر درخواست یک هزینه دارد. اگر شما یک پردازش سنگین داشته باشید که هر بار اجرا شود ۵ ثانیه زمان ببرد و میلیونها بار در روز فراخوانی شود، صورتحساب پایان ماه شما میتواند شوکهکننده باشد.
| ویژگی | سرور سنتی / VM | معماری Serverless |
|---|---|---|
| مدل هزینه | ثابت (ماهانه/سالانه) | متغیر (به ازای هر درخواست/زمان اجرا) |
| ترافیک کم/متغیر | هزینه اضافی (اتلاف منابع) | بسیار ارزان (پرداخت به اندازه مصرف) |
| ترافیک بسیار بالا و ثابت | بسیار به صرفه | پتانسیل هزینه بسیار بالا (Exponential) |
| پیشبینی بودجه | آسان و دقیق | دشوار و متغیر |
برای مدیران مالی در سازمانهای بزرگ، predictability (پیشبینیپذیری) بودجه از هر چیزی مهمتر است. اینکه در پایان ماه متوجه شوند ترافیک غیرمنتظرهای باعث شده بودجه IT سالانه در یک ماه تمام شود، یک کابوس مدیریتی است. در چنین شرایطی، استفاده از استراتژیهای ترکیبی یا بازگشت به مدلهای Reserved Instance منطقیتر است. اگر در حال حاضر در حال برنامهریزی برای زیرساخت خود هستید و تردید دارید، شاید مشورت با متخصصان در بخش ارتباطات زایروکس بتواند به شما در انتخاب مدل هزینه مناسب کمک کند.
وابستگی شدید به یک ارائهدهنده (Vendor Lock-in)
این یکی از ترسناکترین جنبههای Serverless است. وقتی شما کدهای خود را بر اساس AWS Lambda مینویسید، شما فقط یک تابع نمینویسید؛ شما در واقع دارید از اکوسیستم AWS استفاده میکنید. کد شما احتمالاً با S3 برای ذخیرهسازی، با DynamoDB برای دیتابیس و با EventBridge برای مدیریت رویدادها گره خورده است.
حالا تصور کنید بعد از دو سال، مدیریت سازمان تصمیم بگیرد به دلیل مسائل سیاسی، تحریمها یا تغییر قیمتها، تمام زیرساخت را به Azure یا Google Cloud منتقل کند. آیا میتوانید کدها را کپی-پیست کنید؟ خیر. شما باید تقریباً تمام لایهی ارتباطی (Glue Code) پروژه را بازنویسی کنید.
در مقابل، اگر از Docker و Kubernetes استفاده کرده باشید، کانتینرهای شما مستقل هستند. شما میتوانید آنها را از هر کلاودی به کلاود دیگر یا حتی به سرورهای داخلی سازمان (On-premise) منتقل کنید بدون اینکه منطق برنامه تغییر کند. در دنیای سازمانهای بزرگ، "استقلال زیرساختی" یک ضرورت است، نه یک انتخاب.
بیایید با یک مثال واقعی پیش برویم. شرکتی را تصور کنید که برای پردازش فاکتورها از توابع Serverless یک شرکت خاص استفاده میکند. ناگهان آن شرکت شرایط خدمات خود را تغییر میدهد یا قیمتها را ۳ برابر میکند. این شرکت حالا در موقعیتی است که یا باید ضرر مالی را بپذیرد یا ماهها وقت صرف مهاجرت به یک پلتفرم دیگر کند. این یعنی قدرت چانهزنی سازمان در برابر تامینکننده به صفر رسیده است.
پیچیدگی در عیبیابی و مانیتورینگ (The Debugging Nightmare)
در یک برنامه سنتی (Monolithic)، شما یک Log File دارید. اگر خطایی رخ دهد، به دنبال Stack Trace میگردید و میبینید مشکل از کجا شروع شده و به کجا رسیده است. اما در معماری Serverless، شما با صدها یا هزاران تابع کوچک طرف هستید که هر کدام در محیطی ایزوله اجرا میشوند.
وقتی یک درخواست کاربر از تابع A به تابع B میرود، سپس یک پیام در Queue میاندازد و تابع C آن را پردازش میکند، پیدا کردن نقطه شکست (Point of Failure) شبیه به پیدا کردن یک سوزن در انبار کاه است. شما دیگر یک سرور ندارید که بتوانید SSH بزنید و وضعیت RAM را چک کنید یا فایلهای Log را زنده (Real-time) ببینید.
شما مجبورید به ابزارهای مانیتورینگ توزیعشده (Distributed Tracing) متکی شوید که خودشان پیچیدگی و هزینه اضافه میکنند. برای تیمهای عملیاتی (Ops) که به ابزارهای کلاسیک عادت کردهاند، این تغییر پارادایم میتواند باعث افزایش زمان Downtime شود، چون تشخیص اینکه "دقیقاً چه چیزی در کجا خراب شده" در یک محیط توزیعشده، بسیار دشوارتر است.
چالشهای امنیتی: وقتی مرزهای شبکه محو میشوند
در معماریهای سنتی، ما مفهومی به نام «دیواره آتش» یا Firewall داریم. تصور کنید سازمان شما مانند یک قلعه است؛ یک دیوار بلند دور تا دور آن کشیده شده و فقط چند درگاه ورودی کنترل شده وجود دارد. هر کسی که میخواهد وارد شود، باید از نگهبانان (Firewall) عبور کند. اما در Serverless، این قلعه از بین میرود و جای آن را صدها «اتاق کوچک» میگیرد که هر کدام در جای متفاوتی از فضای ابری قرار دارند.
این تغییر ساختار، سطح حمله (Attack Surface) را به شدت افزایش میدهد. حالا شما به جای یک نقطه ورودی، هزاران نقطه ورودی (هر تابع یک Endpoint است) دارید. اگر یکی از این توابع به دلیل اشتباه در کدنویسی یا استفاده از یک کتابخانه قدیمی دچار حفره امنیتی شود، مهاجم میتواند از طریق آن تابع وارد اکوسیستم شما شود.
یک نکته حیاتی در مورد دسترسیها: در پروژههای سازمانی، مدیریت دسترسیها (IAM) بسیار پیچیده است. در مدل Serverless، تمایل برنامهنویسان این است که برای راحتی کار، به توابع دسترسیهای گسترده (Wildcard Permissions) بدهند. مثلاً به جای اینکه تابع فقط اجازه "خواندن" از یک پوشه خاص در دیتابیس را داشته باشد، به آن اجازه "مدیریت کامل" دیتابیس میدهند. این یعنی اگر یک تابع هک شود، کل دیتابیس سازمان در معرض خطر قرار میگیرد.
«امنیت در Serverless دیگر یک لایهی بیرونی نیست، بلکه باید در تار و پود هر تکه کد تنیده شود. شما نمیتوانید به قلعه تکیه کنید، باید هر اتاق را به طور جداگانه قفل کنید.»
همچنین باید به موضوع Data Residency یا «محل استقرار دادهها» اشاره کنیم. بسیاری از سازمانهای دولتی یا مالی طبق قانون مجبورند دادههای کاربران خود را در سرورهای داخل کشور یا در یک دیتاسنتر خاص نگه دارند. در Serverless، شما دقیقاً نمیدانید کد شما در کدام دیتاسنتر فیزیکی در حال اجراست. این عدم قطعیت برای سازمانهایی که با قوانین سختگیرانه Compliance (تطبیقپذیری) سروکار دارند، یک ریسک پذیرفتهناپذیر است.
مدیریت حالت (State Management) و کابوس Stateless بودن
بسیاری از افراد تازهوارد در دنیای Serverless با مفهومی به نام Stateless یا «بدون حالت بودن» مواجه میشوند و در ابتدا آن را یک ویژگی مثبت میبینند، اما در پروژههای پیچیده سازمانی، این موضوع تبدیل به یک چالش جدی میشود. برای اینکه بهتر درک کنید، بیایید یک مثال ساده بزنیم.
تصور کنید با یک کارمند اداره تماس میگیرید. او شما را میشناسد، میداند پرونده شما چیست و دقیقاً میداند در مرحلهی کدام کار هستید. این یک سیستم Statefull (دارای حالت) است. حالا تصور کنید هر بار که تلفن را برمیدارید، یک شخص کاملاً غریبه پشت خط باشد که هیچ اطلاعی از تماسهای قبلی شما ندارد و شما باید هر بار تمام مشخصات و تاریخچه خود را از اول توضیح دهید. این دقیقاً همان اتفاقی است که در Serverless میافتد.
توابع Serverless پس از اجرا، کاملاً نابود میشوند. هیچ متغیری در حافظه (RAM) باقی نمیماند تا در درخواست بعدی استفاده شود. اگر برنامه شما نیاز به ذخیره اطلاعات موقتی داشته باشد (مثل Session کاربر یا سبد خرید)، شما نمیتوانید از متغیرهای محلی استفاده کنید. شما مجبورید هر بار اطلاعات را از یک دیتابیس خارجی یا یک Cache (مثل Redis) بخوانید و دوباره بنویسید.
تاثیر این موضوع بر روی پرفورمنس (Performance)
این جابجایی مداوم دادهها بین تابع و دیتابیس، باعث ایجاد یک فشار مضاعف بر روی شبکه و دیتابیس میشود. در یک اپلیکیشن سازمانی با هزاران تراکنش در ثانیه، این "往返" (رفت و برگشت) دادهها میتواند باعث کندی شدید سیستم شود. در حالی که در یک سرور سنتی، شما میتوانستید اطلاعات مهم را در حافظه سریع (In-memory) نگه دارید و در کسری از میلیثانیه به آنها دسترسی داشته باشید.
برای حل این مشکل، ابزارهایی مثل AWS Step Functions معرفی شدهاند تا جریانهای کاری (Workflows) را مدیریت کنند، اما این کار دوباره پیچیدگی معماری را بالا میبرد. شما حالا باید به جای نوشتن کد ساده، یک «نقشه جریان» طراحی کنید که مشخص کند دادهها چگونه بین توابع جابجا شوند. آیا این واقعاً سادهتر از داشتن یک سرور است؟ احتمالاً خیر.
چه زمانی Serverless یک انتخاب «اشتباه» است؟ (چکلیست نهایی)
تا اینجای بحث، دیدیم که Serverless هرچند جذاب است، اما نقاط تاریکی دارد. اما سوال اصلی این است: دقیقاً در چه شرایطی باید بگوییم «نه» به سرورلس؟ بیایید این موارد را به صورت کاربردی بررسی کنیم.
اول: پردازشهای طولانی مدت (Long-running Tasks)
توابع Serverless برای کارهای سریع طراحی شدهاند. اکثر ارائهدهندگان یک محدودیت زمانی (Timeout) دارند (مثلاً ۱۵ دقیقه). اگر شما سیستمی دارید که باید یک گزارش مالی سنگین را تولید کند یا یک ویدیو با کیفیت 4K را رندر کند و این کار ۲ ساعت زمان میبرد، Serverless اصلاً گزینه شما نیست. کد شما وسط کار قطع میشود و شما هیچ کنترلی روی دلیل قطع شدن ندارید.
دوم: نیاز به Latency بسیار پایین (Ultra-low Latency)
اگر در حال ساخت یک سیستم معاملات الگوریتمی در بورس هستید یا یک سیستم کنترل صنعتی که میلیثانیهها در آن حیاتی هستند، Cold Start و تأخیرهای شبکه در Serverless دشمن شما هستند. در این موارد، شما به سختافزاری نیاز دارید که کاملاً تحت کنترل شما باشد و هیچ لایهی اضافی بین کد و سختافزار وجود نداشته باشد.
سوم: دیتابیسهای قدیمی و سنگین (Legacy Databases)
بسیاری از سازمانها هنوز از دیتابیسهای عظیم Oracle یا SQL Server قدیمی استفاده میکنند. این دیتابیسها برای مدیریت تعداد محدودی اتصال (Connection) طراحی شدهاند. اما Serverless میتواند در یک لحظه ۱۰۰۰ تابع را فعال کند و هر کدام سعی کنند یک اتصال به دیتابیس برقرار کنند. نتیجه؟ دیتابیس شما زیر فشار این تعداد Connection متلاشی میشود. بله، ابزارهایی مثل Connection Pooling وجود دارند، اما پیادهسازی آنها در محیط Serverless بسیار پیچیده و گاهی ناکارآمد است.
چهارم: بودجههای سالانه و صلب (Fixed Budgets)
اگر در سازمانی کار میکنید که بودجه IT را از یک سال پیش تعیین کرده و هرگونه تغییر یا افزایش هزینه نیاز به طی کردن مراحل اداری طولانی دارد، مدل "پرداخت به میزان مصرف" یک ریسک است. یک حمله DDoS ساده یا یک حلقه تکرار (Infinite Loop) اشتباه در کد، میتواند در عرض چند ساعت هزاران دلار هزینه ایجاد کند و شما را در وضعیت بحرانی قرار دهد.
آیا راه میانه وجود دارد؟ (Hybrid Approach)
بیایید صادق باشیم؛ دنیا سیاه و سفید نیست. لازم نیست کل پروژه را یا کاملاً Serverless کنید یا کاملاً سنتی. هوشمندانهترین استراتژی برای سازمانهای بزرگ، مدل ترکیبی (Hybrid) است. یعنی استفاده از هر ابزار در جای درستش.
به عنوان مثال، شما میتوانید هستهی اصلی سیستم (Core Logic) و دیتابیسهای حساس را روی کانتینرهای مدیریت شده (مثل Kubernetes) قرار دهید تا پایداری، امنیت و هزینهی ثابت داشته باشید. اما برای کارهای جانبی و غیرمنتظره، از Serverless استفاده کنید. مثلاً:
- ارسال ایمیل تاییدیه پس از ثبتنام (یک کار سریع و متغیر)
- تغییر سایز تصاویر آپلود شده توسط کاربران (پردازشی که هر از گاهی رخ میدهد)
- اجرای گزارشهای هفتگی در ساعات کمترافیک (Cron Jobs)
با این روش، شما مزایای هر دو دنیا را دارید: پایداری و کنترل در هسته، و سرعت و مقیاسپذیری در حاشیه. این همان جایی است که استراتژی محتوایی و فنی به هم میرسند؛ اینکه بدانیم کجا باید از قدرت ابزار استفاده کنیم و کجا باید جلوی آن بایستیم تا سازمان را به ریسک نیندازیم.
جمعبندی نهایی: فلسفه انتخاب ابزار در مقیاس سازمانی
در نهایت، معماری Serverless یک "جادوی" جدید در دنیای نرمافزار است، اما همانطور که در هر جادوگری، پشت پرده ترفندهایی وجود دارد که باید آنها را شناخت. برای یک توسعهدهنده، نوشتن کد در محیط سرورلس لذتبخش است چون دغدغهی مدیریت سرور را ندارد. اما برای یک مدیر فنی (CTO) یا یک معمار سیستم، لذت کدنویسی باید جای خود را به پایداری (Stability)، امنیت (Security) و بهینگی مالی (Cost Optimization) بدهد.
اشتباه رایج بسیاری از سازمانها این است که Serverless را به عنوان یک راهکار برای "کاهش هزینه" میبینند، در حالی که Serverless در واقع راهکاری برای "افزایش سرعت توسعه" (Time-to-Market) است. اگر اولویت شما کاهش هزینههای زیرساختی در ترافیکهای بالاست، سرورلس احتمالاً بدترین انتخاب شماست. اما اگر میخواهید ایدهی خود را سریعاً تست کنید و بدون درگیر شدن با پیچیدگیهای شبکه، محصول را به دست کاربر برسانید، سرورلس یک قهرمان است.
«بهترین معماری، معماری پیچیدهترین نیست؛ بلکه معماریای است که بیشترین تطابق را با نیازهای کسبوکار و تواناییهای تیم عملیاتی داشته باشد.»
اگر بخواهیم یک فرمول ساده برای تصمیمگیری ارائه دهیم، میتوانیم بگوییم:
(ترافیک غیرقابل پیشبینی + نیاز به سرعت در عرضه + کارهای کوتاه مدت) = Serverless ✅
(ترافیک ثابت و بالا + نیاز به کنترل کامل سختافزار + پردازشهای طولانی + بودجه صلب) = Traditional/Containers ❌
گام بعدی برای سازمان شما چیست؟
انتخاب بین معماریهای مختلف، تصمیمی نیست که یکبار گرفته شود و تمام شود. تکنولوژی هر روز در حال تغییر است و چیزی که امروز برای شما بهینه است، ممکن است سال آینده به یک گلوگاه تبدیل شود. نکته کلیدی این است که هرگز اجازه ندهید «ترندهای تکنولوژیک» مسیر تصمیمگیریهای استراتژیک سازمان شما را منحرف کنند.
بسیاری از سازمانها در مسیر مهاجرت به ابر (Cloud Migration) دچار اشتباهات هزینهای شدیدی میشوند، صرفاً به این دلیل که تفاوت بین سرویسهای مدیریت شده و زیرساختهای سنتی را به درستی تحلیل نکردهاند. اینجاست که داشتن یک مشاور خبره که هم دید فنی داشته باشد و هم دید بیزینسی، تفاوت بین یک پروژه موفق و یک شکست هزینهبر را رقم میزند.
اگر در حال حاضر در مرحله طراحی زیرساخت پروژه خود هستید و نمیدانید کدام مدل (Serverless، Microservices یا Monolithic) برای حجم دیتای شما و بودجهتان مناسبتر است، لازم نیست در تاریکی پیش بروید. تحلیل دقیق نیازها و بررسی نقاط ضعف و قوت هر متد، تنها راه پیشگیری از هزینههای گزاف آینده است. برای اینکه بدانید دقیقاً کدام معماری میتواند بیشترین بازدهی را برای بیزنس شما داشته باشد و چگونه توازن بین هزینه و پرفورمنس را برقرار کنید، پیشنهاد میکنیم با متخصصان ما در بخش ارتباطات زایروکس گفتگو کنید تا با بررسی جزئیات پروژه شما، بهینهترین نقشه راه فنی را طراحی کنیم.
سخن پایانی
به یاد داشته باشید که هیچ ابزاری "بهترین" نیست؛ فقط ابزاری وجود دارد که "مناسبترین" است. Serverless ابزاری قدرتمند است، اما مانند هر ابزار قدرتمندی دیگر، اگر در جای اشتباه به کار رود، میتواند آسیب بزند. هدف ما در دنیای مهندسی نرمافزار، ساخت سیستمی است که شبها به ما اجازه خواب راحت بدهد، نه سیستمی که ما را منتظر یک صورتحساب غیرمنتظره یا یک Cold Start طولانی نگه دارد. هوشمندانه انتخاب کنید، به صورت ترکیبی پیش بروید و همیشه کنترل زنجیره ارزش خود را در دست داشته باشید.