محدودیت‌های هاست اشتراکی و راه‌حل‌های واقعی

خیلی از کسب‌وکارهای کوچک و متوسط روی هاست اشتراکی‌ان. دلیلش هم منطقیه: ارزونه، نگه‌داری نمی‌خواد و برای یه سایت معمولی کاملاً کافیه.

مسئله وقتی پیدا می‌شه که همون کسب‌وکار بخواد یه سیستم مدیریتی جدی روی همون زیرساخت داشته باشه.

محدودیت واقعی چیه

روی یه هاست اشتراکیِ معمولی معمولاً این‌ها رو ندارید:

• دسترسی SSH — یعنی هیچ دستوری روی سرور نمی‌تونید اجرا کنید.
• Composer — یعنی مدیریت وابستگی‌های PHP، که تقریباً همه‌ی فریم‌ورک‌های مدرن بهش وابسته‌ن، در دسترس نیست.
• کنترل روی نسخه‌ی PHP و افزونه‌ها — یا محدوده، یا اصلاً نیست.
• امکان اجرای فرایند پس‌زمینه — صف و کار زمان‌بندی‌شده به شکل متعارف قابل اجرا نیست.

نتیجه‌ی عملی این فهرست یه جمله‌ست: فریم‌ورک‌های متعارف عملاً قابل استفاده نیستن. نه این‌که سخت باشن؛ قابل نصب نیستن.

سه گزینه‌ای که واقعاً وجود داره

وقتی تو پروژه‌ی ERP برند عطر دست‌ساز به این نقطه رسیدیم، سه راه جلومون بود:

۱. مشتری زیرساخت رو عوض کنه. ساده‌ترین راه برای ما. سرور اختصاصی یا VPS بگیره، ما هم با ابزار متعارف بسازیم. هزینه‌اش اما یه‌بار نیست — یه هزینه‌ی جاریِ ماهانه‌ست که تا آخر عمر سیستم ادامه داره، به‌علاوه‌ی نگه‌داری‌ای که کسب‌وکار باید یا خودش انجام بده یا برای انجامش هزینه بده.

۲. یه راه‌حل آماده‌ی میزبانی‌شده. سریع‌ترین راه، ولی همون مسئله‌ی همیشگی رو داره: فرایند کسب‌وکار باید با فرض اون نرم‌افزار جور دربیاد. این‌جا با تولیدی‌ای طرف بودیم که هم‌زمان مواد اولیه، نیمه‌ساخته، چند شعبه و فروشنده‌ی شیفتی داشت. چیزی که با فرض عمومی جور دربیاد پیدا نشد.

۳. ساختن در محدودیت. یعنی پذیرفتن زیرساخت به همون شکلی که هست و ساختن چیزی که روش اجرا بشه.

چیزی که انتخاب کردیم و چرا

گزینه‌ی سوم رو انتخاب کردیم: یه ساختار MVC اختصاصی با PHP خالص، بدون هیچ وابستگی خارجی.

باید صادق باشیم درباره‌ی هزینه‌اش: این تصمیم، ساخت رو سخت‌تر کرد. خیلی از چیزهایی که یه فریم‌ورک آماده می‌ده — مسیریابی، لایه‌ی دسترسی به داده، اعتبارسنجی — باید نوشته می‌شدن. یعنی زمان بیش‌تر.

چیزی که در عوض به دست اومد این بود که هزینه‌ی جاری مشتری ثابت موند. سیستم روی همون هاستی اجرا می‌شه که از قبل داشت و بابتش پول می‌داد.

این تصمیم همیشه درست نیست

مهمه که این رو به یه قاعده‌ی کلی تبدیل نکنیم. «ساختن در محدودیت» وقتی منطقیه که:

• محدودیت پایدار باشه، نه موقت. اگه کسب‌وکار قراره تا شش ماه دیگه رشد کنه و به هر حال زیرساختش عوض بشه، ساختن در محدودیت یعنی دو بار ساختن.
• دامنه‌ی کار مشخص باشه. هرچی سیستم بزرگ‌تر، هزینه‌ی نداشتن ابزار متعارف بیش‌تر.
• هزینه‌ی جاری برای اون کسب‌وکار واقعاً مهم باشه. برای بعضی کسب‌وکارها هزینه‌ی ماهانه‌ی سرور در برابر ارزش سیستم ناچیزه؛ اون‌جا این بحث اصلاً موضوعیت نداره.

اگه هیچ‌کدوم از این سه شرط برقرار نباشه، پیشنهاد درست همون گزینه‌ی اوله — و همون رو می‌گیم.

نکته‌ی عملی برای وقتی که دارید انتخاب می‌کنید

قبل از این‌که کسی بهتون بگه «باید سرور بگیرید» یا «باید فلان نرم‌افزار رو بخرید»، این سؤال رو بپرسید:

اگه این هزینه‌ی ماهانه رو ضرب در سه سال کنم، چقدر می‌شه؟ و اون عدد در برابر چیزی که به دست میارم، منطقیه؟

جواب گاهی «بله»ست. ولی این سؤالیه که باید قبل از تصمیم پرسیده بشه، نه بعدش.