موقعیتیابی
دژ را میشکند تا دژ بسازد.
چهار دلیل که چرا یک سازمان ایرانی باید کنترلپلن زیرساختش را خودش داشته باشد — و چرا دزکوب برای همین ساخته شد.
چرا اسمش دزکوب است؟
دژکوب، ابزار شکستن دیوارِ دژ بود. سنگین، ساده، و بیرحم نسبت به هر دیواری که سرِ راهش بود.
ما نام را از همانجا وام گرفتیم — و معنایش را وارونه کردیم.
دیواری که امروز مقابل سازمانهای ایرانی ایستاده، دیوارِ وابستگی است: لایسنسی که تمدید نمیشود، ابری که دسترسی را قطع میکند، کنترلپلنی که تصمیمهایش را جایی بیرون از کشور میگیرد. دزکوب برای شکستنِ همان دیوار ساخته شد.
و آنچه پشتِ دیوارِ شکسته میسازد، خودش یک دژ است: زیرساختی که کلیدش دست شماست، هر تصمیمش قابل ردیابی است، و هیچ بخشی از آن به بیرون تلفن نمیزند.
دژ را میشکند تا دژ بسازد.
Dezkube — از دژکوب و Kubernetes.
«خودمیزبان» یک کلمه نیست. یک طیف است.
تقریباً هر پلتفرمی امروز ادعا میکند self-hosted است. ولی «خودمیزبان» میتواند پنج چیز کاملاً متفاوت باشد. این طیف را رسم کردیم چون در جلسههای فنی، همین یک تصویر بیشترین کار را میکند.
| سطح | چه کسی اینجاست | چه چیزی دست شما نیست |
|---|---|---|
| ۱ — SaaS کامل | پلتفرمهای ابری مدیریتشده | همهچیز. زیرساخت، داده، کنترلپلن، کلید |
| ۲ — SaaS با میزبانی منطقهای | ارائهدهندههای منطقهمحور | زیرساخت و کنترلپلن. فقط جغرافیای داده تضمین میشود |
| ۳ — BYOC (ابر خودتان) | پلتفرمهایی که روی حسابِ ابری شما اجرا میکنند | مغزِ تصمیمگیر. بارِ کاری پیش شماست، ولی کنترلپلن جای دیگری است و به آن گزارش میدهد |
| ۴ — خودمیزبان اما ابر-محور | ابزارهایی که فقط روی ابرهای بزرگ کار میکنند | استقلال از ارائهدهندهٔ ابر. روی سختافزار خودتان اجرا نمیشوند |
| ۵ — خودمیزبانِ کامل | دزکوب | هیچ. کنترلپلن، داده، کلید و زیرساخت، هر چهار تا |
اگر فردا اینترنتِ این سازمان قطع شود، چه چیزی از کار میافتد؟
برای سطح ۱ تا ۴، جوابْ «همهچیز» یا «بخشهای مهمی» است. برای دزکوب، جواب «هیچچیز» است — چون هیچ مسیر اجباریای به بیرون وجود ندارد.
چرا نام رقیبی در این جدول نیست
عمداً. نامها در /compare هستند، جایی که جایشان است و میشود دوطرفه دربارهٔ آنها حرف زد. اینجا نامْ این صفحه را به جدلِ برند تبدیل میکند.
چهار تصمیمی که همهچیز از آنها آمد
اینها انتخابهای فنیاند، نه شعار. هر کدام یک کلاسِ کاملِ مشکل را از بین میبرند.
تصمیم ۱ — منبع حقیقت، Kubernetes است؛ نه دیتابیس ما
هر نوشتنی به Kubernetes میرود و دیتابیس ما فقط یک projection است که با watch از خود کلاستر بازسازی میشود. گزینهٔ رد شده: «دیتابیس حقیقت است و کلاستر را همگام نگه میداریم» — همان مدلی که در نهایت به واگرایی میرسد. چه چیزی را حل کرد: کلاسِ کاملِ باگ «واگرایی»؛ اگر کسی مستقیم در کلاستر تغییری بدهد، اختلاف دیده و یا اصلاح یا گزارش میشود.
تصمیم ۲ — الگوریتم را قرض بگیر، مدل را خودت مالک باش
موتورهای اثباتشده را بهعنوان کتابخانه داخل خودمان میآوریم ولی مدلِ داده و تجربهٔ کاربری را خودمان میسازیم. گزینهٔ رد شده: وابسته شدن به یک سرویسِ بیرونیِ سنگین برای هر قابلیت — هر کدام یک وابستگی عملیاتی، یک سطح حملهٔ جدید، و یک مسیرِ ارتقای مستقل. چه چیزی را حل کرد: انعطاف در مدل دسترسی بهازای هر پروژه و هر مستأجر، بدون نوشتن موتور مجوزدهی از صفر.
تصمیم ۳ — فونداسیون قبل از موات
GPU، هوش مصنوعی، مارکتپلیس و عاملیت بعد از محکم شدن امنیت، مدل دسترسی، منبعِ حقیقت و پوشش تست ساخته شدند. گزینهٔ رد شده: ساختنِ زودهنگامِ قابلیتِ چشمگیر برای نمایش، روی پایهای که هنوز سفت نشده. چه چیزی را حل کرد: لایهٔ هوش مصنوعی از روزِ اول، مدلِ سهمیه، ممیزی، ایزولهسازی و رمزنگاریِ همان پلتفرم را به ارث برد — نه یک نسخهٔ موازیِ نصفه.
تصمیم ۴ — تست از روز اول، زنجیرهٔ تأمین بهعنوان پیشفرض.
هیچ تغییری بدون تست مرج نمیشود، کفِ پوشش قفل است، و هر ایمیجی که پلتفرم میسازد SBOM و امضا دارد. گزینهٔ رد شده: «امنیت زنجیرهٔ تأمین را بعداً اضافه میکنیم.» وقتی موقعیت شما حاکمیتی است، «از کجا معلوم این ایمیج همانی است که ساختید؟» اولین سؤال هر ممیز است — و جوابش باید در محصول باشد، نه در یک اسلاید.
تقریباً هیچکس این دو را با هم ندارد
در تحلیل ۱۴ پلتفرم به یک الگوی روشن رسیدیم: پلتفرمهای PaaS ماشین مجازیِ واقعی ندارند، و پلتفرمهای مجازیسازی، تجربهٔ استقرار اپلیکیشن ندارند. سازمانها مجبورند هر دو را بخرند و بعد خودشان به هم بچسبانند — با دو مدل هویت، دو مدل سهمیه، و دو گزارش هزینه که هرگز با هم جور درنمیآیند.
| دسته | نمونه | PaaS | ماشین مجازی واقعی | یک مدل هویت مشترک |
|---|---|---|---|---|
| PaaS خودمیزبان | Coolify، Dokploy، Kubero | ● | ○ | — |
| جایگزینهای VMware | OpenShift، Platform9، Harvester | ◐ | ● | ◐ |
| دزکوب | — | ● | ● | ● |
زیرنویس ◐
جایگزینهای VMware: بخشی از آنها لایهٔ اپلیکیشن دارند، ولی بهعنوان محصولِ ثانویه و معمولاً با مدل حاکمیتیِ جدا.
نکتهٔ فنیای که این را ممکن کرد: ماشین مجازی در دزکوب یک شیء کاملاً جدا نیست. همان مدلِ پروژه، محیط، سهمیه، دسترسی و ممیزی که برای اپلیکیشنها هست، برای ماشینهای مجازی هم هست. یک نفر که از پروژه حذف میشود، همزمان دسترسیاش به اپلیکیشنها و ماشینهای مجازی آن پروژه قطع میشود — نه در دو سیستم جدا، بهصورت دستی.
دزکوب برای شما مناسب نیست اگر…
این سکشن را عمداً گذاشتهایم. هر محصولی که ادعا کند برای همه خوب است، برای هیچکس دقیق نیست.
| اگر… | چرا مناسب نیست | چه چیزی بهتر است |
|---|---|---|
| کمتر از پنج سرور دارید و یک تیم دو نفره | دزکوب برای مقیاس و تفکیکِ چند تیمی طراحی شده. برای یک تیم کوچک، پیچیدگیاش سود نمیدهد. | یک PaaS سبکِ تکسروری |
| میخواهید همین امروز و بدون هیچ تیم زیرساختی راه بیفتد | این محصول روی سختافزار شما نصب میشود. حداقل یک نفر باید مالکِ زیرساخت باشد. | ابر عمومی، تا وقتی مقیاس و الزام حاکمیتی نداشته باشید |
| زیرساختتان کاملاً روی یک ابر عمومی است و قصد خروج ندارید | ارزش اصلی ما استقلال از ارائهدهنده است. اگر آن استقلال را نمیخواهید، بخش بزرگی از ارزش را نمیگیرید. | سرویسهای بومیِ همان ابر |
| دنبال یک ابزار تکمنظورهاید | دزکوب یک کنترلپلنِ یکپارچه است. اگر فقط مانیتورینگ یا فقط CI میخواهید، ما بیشازحد هستیم. | ابزار تخصصیِ همان حوزه |
اگر هیچکدام از این چهار مورد شما نیستید، احتمالاً دقیقاً همان کسی هستید که دزکوب برایش ساخته شد.
اینها را هم ببینید
استدلال را خواندید. حالا محصول را ببینید.
۴۵ دقیقه، روی محصول واقعی، با سؤالهای سختِ خودتان.