برای مقایسه سرویس‌دهنده ابری ایرانی با AWS، ابتدا باید سرویس مورد نیاز را مشخص کرد. یک ماشین مجازی، پلتفرم استقرار برنامه و CDN سه کار متفاوت انجام می‌دهند. مقایسه نام شرکت‌ها بدون این تفکیک، معمولاً به فهرستی از ویژگی‌هایی می‌رسد که برای پروژه شما هم‌وزن نیستند. اگر هدف یک فروشگاه فارسی است، محل داده، مسیر پرداخت، پشتیبانی و امکان ادامه کار هنگام اختلال، از تعداد کل محصولات یک شرکت مهم‌تر می‌شوند.
متن قبلی تقسیم قطعی بازار میان چند شرکت و سریع‌تر بودن خدمات داخلی برای تمام کاربران ایرانی را مطرح می‌کرد. چنین ادعاهایی به داده مشخص درباره بازار و مسیر شبکه نیاز دارند. در این راهنما رتبه‌بندی شرکت‌ها یا سرعت بدون اندازه‌گیری وجود ندارد. نمونه‌های رسمی خدمات را می‌خوانیم و یک روش تصمیم‌گیری ارائه می‌کنیم که تیم بتواند با اطلاعات پروژه خودش کامل کند.
لایه خدمت را درست انتخاب کنید
IaaS منابع زیرساختی مانند ماشین مجازی را در اختیار شما می‌گذارد. در این مدل معمولاً مسئولیت سیستم‌عامل مهمان و نرم‌افزار برنامه بر عهده تیم است. PaaS بخشی از مدیریت محیط اجرای برنامه را برمی‌دارد، ولی منطق برنامه و داده همچنان نیاز به نگهداری دارند. CDN نسخه‌هایی از محتوای قابل cache را توزیع می‌کند و جای پایگاه داده یا سرور برنامه را نمی‌گیرد.
برای نمونه، مستندات لیارا محصولات PaaS، VPS، دیتابیس و Object Storage را جدا معرفی می‌کند. در AWS نیز EC2 به منابع محاسباتی و S3 به Object Storage مربوط‌اند. انتخاب مناسب این است که نیازهای مشخص را در لایه هم‌نوع مقایسه کنید؛ نام «ابر» به تنهایی درباره مسئولیت و شکل اجرای برنامه اطلاعات کافی نمی‌دهد.
یک پروژه Laravel، مثلاً به اجرای PHP، پایگاه داده، فایل‌های کاربر و صف کارها نیاز دارد. همه این نیازها را در یک ردیف «هاست» پنهان نکنید. اگر پلتفرم برنامه را مدیریت می‌کند ولی Worker صف را جدا می‌خواهید، آن جزء باید در هزینه و نگهداری لحاظ شود. اگر فایل کاربر در دیسک موقت instance قرار دارد، راه‌اندازی مجدد ممکن است قرارداد ذخیره‌سازی مورد انتظار شما را برآورده نکند.
مسیر کاربر و مسیر داده را جدا بنویسید
نزدیک بودن یک مرکز داده به بخشی از کاربران می‌تواند به مسیر شبکه مربوط باشد، اما نتیجه همه اتصال‌ها یکسان نیست. اپراتور، اتصال داخلی و خارجی، مسیر دسترسی به سرویس جانبی و نوع محتوا اثر دارند. ادعای کلی «داخلی همیشه سریع‌تر است» قرارداد قابل اتکا برای محصول نمی‌سازد. حتی اگر سند صفحه سریع برسد، API بیرونی مورد نیاز آن ممکن است دیر پاسخ دهد.
در فروشگاه، مرور محصول، پرداخت و دریافت فایل سه مسیر متفاوت‌اند. ممکن است تصویرها از CDN بیایند، برنامه در یک مرکز داده اجرا شود و درگاه پرداخت در مسیر دیگری باشد. روی کاغذ این اجزا را بکشید و برای هر ارتباط مالک و راه شکست را مشخص کنید. این کار کمک می‌کند بفهمید تعویض میزبان واقعاً کدام بخش تجربه را تغییر می‌دهد.
دسترسی تیم توسعه هم بخشی از همین مسیر است. نصب وابستگی‌ها، دریافت imageهای container و اجرای build به اتصال‌های خاصی نیاز دارد. پروژه‌ای که سرویس عمومی آن کار می‌کند ولی تیم نمی‌تواند نسخه تازه را منتشر کند، همچنان مشکل عملیاتی دارد. راه دریافت بسته و نگهداری artifact را قبل از انتخاب بنویسید. استفاده از mirror هم باید با کنترل نسخه و منشأ بسته همراه باشد.
پایگاه داده و فایل‌ها را با قرارداد نگهداری ببینید
دیتابیس مدیریت‌شده بخشی از کار عملیات را کم می‌کند، اما schema، queryهای سنگین و مجوزهای برنامه همچنان مسئولیت تیم‌اند. مشخص کنید سرویس چه نسخه‌ای ارائه می‌کند، ارتقا چگونه انجام می‌شود و محدودیت اتصال چیست. رفتار نسخه‌های متفاوت پایگاه داده ممکن است بر برنامه اثر بگذارد. انتخاب بر اساس نام موتور، بدون خواندن تنظیم و قرارداد نسخه، کافی نیست.
برای پشتیبان، عبارت «backup دارد» مبهم است. باید معلوم شود چه چیزی ذخیره می‌شود، چه مدت نگه داشته می‌شود، چه کسی اجازه restore دارد و بازیابی در چه سطحی انجام می‌شود. فایل‌های Object Storage و دیتابیس هم به یک راهبرد هماهنگ نیاز دارند. بازیابی پایگاه داده بدون فایل‌های متناظر ممکن است رکوردهایی بسازد که به فایل موجود اشاره نمی‌کنند.
Object Storage برای نگهداری object است و رفتار آن را نباید فایل سیستم محلی فرض کرد. APIهای شبیه S3 نیز ممکن است همه قابلیت‌های سرویس اصلی را با همان جزئیات پشتیبانی نکنند. عملیات مورد نیاز شما، مانند URL امضاشده، سیاست دسترسی یا نسخه‌بندی باید با مستند همان ارائه‌دهنده تطبیق داده شود. اگر فقط آپلود و دانلود ساده لازم دارید، نیازی نیست قابلیت نامرتبط را معیار اصلی کنید.
امنیت، مسئولیت مشترک دارد
در Shared Responsibility Model در AWS، مسئولیت مشتری با نوع سرویس تغییر می‌کند. همین پرسش را درباره هر ارائه‌دهنده بپرسید: چه کسی سیستم‌عامل را به‌روز می‌کند، دسترسی‌ها را تنظیم می‌کند و به رخداد پاسخ می‌دهد؟ عنوان «مدیریت‌شده» باید به وظیفه مشخص تبدیل شود. نرم‌افزار آسیب‌پذیر برنامه صرفاً به خاطر قرار گرفتن در زیرساخت ابری اصلاح نمی‌شود.
دسترسی تیم را به حساب‌های شخصی قابل مدیریت تفکیک کنید. یک رمز مشترک برای تمام اعضا، خروج فرد از تیم را دشوار می‌کند و پیگیری تغییر را از بین می‌برد. وظیفه انتشار، مشاهده گزارش و مدیریت صورت‌حساب لزوماً به مجوز یکسان نیاز ندارد. هنگام انتخاب پلتفرم، امکان تعریف نقش‌ها و ثبت تغییرات را با نیاز سازمان بسنجید، نه فقط وجود صفحه تنظیمات حساب.
رازهای برنامه باید از مخزن کد و خروجی client جدا باشند. تغییر ارائه‌دهنده زمان مناسبی برای روشن کردن مالک راز و روش چرخش آن است. اگر کلید ذخیره‌سازی در چند پروژه کپی شده، انتقال یک پروژه ممکن است روی دیگری اثر بگذارد. قبل از حذف یا جایگزینی کلید، مصرف‌کنندگان آن را ثبت کنید تا تغییر زیرساخت به قطع ناخواسته قابلیت دیگری منجر نشود.
دسترسی قراردادی و پرداخت را قطعی فرض نکنید
شرایط ایجاد حساب، پرداخت، پشتیبانی و دسترسی خدمات با ارائه‌دهنده و وضعیت مشتری تغییر می‌کند. درباره سرویس خارجی، امکان فنی باز شدن یک صفحه را معادل مجاز بودن استفاده یا تداوم حساب ندانید. شرایط رسمی و پاسخ قابل استناد ارائه‌دهنده باید با وضعیت واقعی مشتری تطبیق داده شود. این مطلب راهی برای دور زدن محدودیت قرارداد یا مقررات ارائه نمی‌کند و درباره مجاز بودن یک حساب مشخص حکم نمی‌دهد.
برای سرویس داخلی هم پرداخت ریالی یا پشتیبانی فارسی به خودی خود تمام ریسک را برطرف نمی‌کند. قرارداد SLA، روش ثبت تیکت، دامنه مسئولیت و مسیر بازیابی را بخوانید. عبارت تبلیغاتی «پایداری بالا» با تعهد قابل استناد یکسان نیست. تیم باید بداند در رخداد مشکل چه اطلاعاتی می‌فرستد، کدام کانال پاسخ‌گوست و چه گزینه‌ای برای ادامه کار دارد.
هزینه کل معماری را محاسبه کنید
ماشین پایه تنها بخشی از هزینه است. ذخیره‌سازی، خروج داده، پشتیبان، IP، دیتابیس، منابع build و نگهداری تیم ممکن است جدا حساب شوند. قیمت‌های جاری را از صفحه رسمی همان طرح بگیرید و تاریخ مقایسه را بنویسید. یک جدول با رقم ثابت و بدون مشخصات مصرف، پس از تغییر قیمت یا الگوی استفاده اعتبار خود را از دست می‌دهد.
برای برآورد، یک سناریوی صریح از مصرف معمول و یک سناریوی رشد تهیه کنید. مشخص کنید کدام فرض اندازه‌گیری شده و کدام فرض طراحی است. مقدارهای فرضی را به‌عنوان نتیجه واقعی معرفی نکنید. اگر محصول فایل حجیم تحویل می‌دهد، هزینه انتقال داده می‌تواند نسبت به یک API کوچک اهمیت متفاوتی داشته باشد. انتخاب را با نوع بار کاری بسنجید.
ترکیب چند ارائه‌دهنده ممکن است برای بخشی از محصول مفید باشد، اما پیچیدگی تازه دارد. ارتباط میان دو شبکه، مدیریت دسترسی و عیب‌یابی بین سرویس‌ها هزینه‌اند. راهبرد چندابری را صرفاً به خاطر متنوع بودن نام‌ها انتخاب نکنید. اگر یک بخش نیاز واقعی به محیط دیگری دارد، مرز آن را روشن و تعداد وابستگی‌های میان دو بخش را محدود کنید.
تصمیم را قابل بازنگری ثبت کنید
یک سند کوتاه بسازید که نیازهای غیرقابل چشم‌پوشی، لایه خدمت، محل داده و مسیر انتشار را ثبت کند. برای هر گزینه، پاسخ‌های مستند و موارد نامشخص را کنار هم بگذارید. نامشخص بودن قابلیت را با نداشتن آن یکی نگیرید؛ پیش از خرید درباره همان سؤال مشخص پاسخ بگیرید. این روش از یک مقایسه کلی «ایرانی یا خارجی» به تصمیمی درباره همان پروژه می‌رسد.
برای آماده‌سازی انتقال، وابستگی‌های محیط را از کد برنامه جدا کنید و روش راه‌اندازی را نگه دارید. مقاله Docker برای توسعه‌دهندگان به ثبت محیط اجرا و CI/CD به انتشار قابل تکرار مربوط است. قدم بعدی، تهیه فهرست اجزای واقعی محصول و سؤال‌های قراردادی هر جزء است؛ انتخاب شرکت پس از روشن شدن این فهرست معنا پیدا می‌کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!