اصول مهندسی برای ساخت یک راهکار موفق Cloud-Prem چیست؟

نکات کلیدی

• Cloud-Prem که شامل Bring Your Own Cloud (BYOC) نیز می‌شود، یک رویکرد معماری است که صفحه کنترل (Control Plane) و صفحه داده (Data Plane) را از هم جدا می‌کند و به مشتریان خدماتی شبیه کلاد ارائه می‌دهد، در حالی که داده‌ها و زیرساخت تحت کنترل خودشان باقی می‌ماند. Cloud-Prem در پاسخ به الزامات حاکمیت داده، انطباق مقرراتی و ملاحظات هزینه در فضای هوش مصنوعی و سازمانی، به‌سرعت در حال محبوب‌شدن است.
• در معماری یک راهکار Cloud-Prem، از ابتدا باید قابلیت جابه‌جایی و تکرارپذیری را در نظر گرفت؛ با بسته‌بندی سرویس در قالب کانتینر، ارکستره‌کردن آن با Kubernetes و ارائه آن از طریق infrastructure-as-code، اپراتورها و پایپ‌لاین‌های GitOps/CI-CD تا هر محیط هدف بتواند به‌صورت خودکار دیپلوی شود.
• چالش‌های عملیاتی ناشی از وجود تعداد زیادی نمونه ایزوله‌شده مشتری را پیش‌بینی کنید؛ با ساخت تله‌متری مبتنی بر رضایت، ارائه ابزارهای تشخیصی اسکریپت‌شده و خودکارسازی ارتقاها، تا بدون دسترسی مستقیم، دیدپذیری و پایداری حفظ شود.
• با ذهنیت zero-trust و دسترسی حداقلی برای وِندور در محیط مشتری کار کنید، همراه با مرزبندی شفاف، و در عین حال امکان دسترسی امن برای پشتیبانی (مثلاً تونل‌های پشتیبانی JIT) را فراهم کنید؛ چون پشتیبانی کاملاً بدون دخالت در عمل غیرواقعی است.
• پشتیبانی از Cloud-Prem به مدل قیمت‌گذاری متفاوتی نیاز دارد (اشتراک فقط برای نرم‌افزار و پرداخت هزینه زیرساخت توسط مشتری) و تمرکز بر موارد استفاده سازمانی با ارزش بالا؛ و هم‌راستاسازی استراتژی محصول، سرمایه‌گذاری مهندسی و رویکرد فروش برای پایداری Cloud-Prem، از طریق سرمایه‌گذاری مجدد در اتوماسیون برای جبران هزینه‌های بالاتر پشتیبانی و حفظ حاشیه سود سالم.

مقدمه و انگیزه

راهکارهای کلاد-پرم، که اغلب «نرم‌افزار به‌عنوان سرویس خصوصی» (SaaS) یا «ابرِ متعلق به خودتان» (BYOC) نامیده می‌شوند، مزیت‌های نرم‌افزار ابری را با کنترل درون‌سازمانی (On-Premises) ترکیب می‌کنند. در مدل کلاد-پرم، سرویسِ یک فروشنده در محیط خودِ مشتری (حساب ابری یا دیتاسنترِ او) مستقر می‌شود اما همچنان توسط فروشنده مدیریت می‌گردد.

هدف این است که استقراری شبیه ابر با امنیت و کنترل درون‌سازمانی ارائه شود. BYOC به‌طور مشخص به استقرار نرم‌افزار در ابرِ خودِ مشتری (مثلاً حساب AWS/Azure او) به‌جای ابرِ فروشنده اشاره دارد و کنترل کامل محل داده را به مشتری می‌دهد. در اصل، کلاد-پرم بین ابر و آن‌پرم پل می‌زند: فروشنده اپلیکیشن را مدیریت می‌کند، اما داده حساس و پردازش داخل زیرساخت مشتری باقی می‌ماند.

این رویکرد با جدا کردن صفحه کنترل سرویس (که توسط فروشنده مدیریت می‌شود) از صفحه داده (که در محیط مشتری اجرا می‌شود) به دست می‌آید. فروشنده از طریق صفحه کنترل، به‌روزرسانی و پایش را ارکستره می‌کند، در حالی که تمام داده‌ها و محاسبات مشتری برای امنیت، محلی باقی می‌مانند.

چندین نیرو در حال ایجاد علاقه به استقرارهای کلاد-پرم هستند، به‌خصوص بین استارتاپ‌های هوش مصنوعی و سازمان‌ها در صنایع قانون‌مند، مانند حاکمیت داده و انطباق، امنیت و اعتماد، هزینه و گرانش داده، و روندهای صنعتی.

در رسیدگی به مسائل حاکمیت داده و انطباق، سازمان‌ها با مقررات سخت‌گیرانه (GDPR، HIPAA، قوانین داده مالی) روبه‌رو هستند که داده باید تحت کنترل خودشان باقی بماند. نگه‌داشتن داده در ابرِ خودشان یا آن‌پرم می‌تواند انطباق را ساده‌تر کند و از انتقال اطلاعات حساس به ابرهای مدیریت‌شده توسط فروشنده جلوگیری کند. SaaS سنتی اغلب در برآورده کردن الزامات سخت‌گیرانه فراتر از استانداردهای عمومی مثل Service Organization Control 2 (SOC 2) ناکام می‌ماند. کلاد-پرم تضمین می‌کند داده هرگز از دامنه مشتری خارج نمی‌شود و الزامات حاکمیت را برآورده می‌سازد.

حاکمیت داده و انطباق مقررات

سازمان‌ها با مقررات سخت‌گیرانه‌ای مانند GDPR، HIPAA و قوانین داده مالی روبه‌رو هستند که الزام می‌کنند داده‌ها تحت کنترل خودشان باقی بماند. نگه‌داشتن داده در کلاد یا آن‌پرمیس خود سازمان می‌تواند انطباق را ساده‌تر کند و از انتقال اطلاعات حساس به کلاد وندور جلوگیری نماید. SaaS سنتی اغلب فراتر از استانداردهای عمومی مانند SOC 2 قادر به پاسخ‌گویی به این الزامات نیست. Cloud-Prem تضمین می‌کند داده هرگز از دامنه مشتری خارج نمی‌شود و الزامات حاکمیتی را برآورده می‌کند.

امنیت و اعتماد

با افزایش رخدادهای امنیتی در کلاد و نگرانی درباره اینکه چه کسی به داده‌های حیاتی دسترسی دارد، شرکت‌ها خواهان نظارت و کنترل بیشتری بر وضعیت امنیتی خود هستند. Cloud-Prem مشکل «جعبه سیاه» SaaS را کاهش می‌دهد، چون مشتری می‌تواند محیط خود را ببیند و کنترل کند. برای مثال، اپلیکیشن‌های هوش مصنوعی اغلب به دسترسی سطح بالا به سیستم‌های داخلی نیاز دارند؛ اجرای آن‌ها در شبکه مشتری، ریسک افشای اعتبارنامه‌ها و خروجی‌های حساس را کاهش می‌دهد. علاوه بر این، اگر وندور دسترسی مستقیم به محیط اجرایی نداشته باشد، ریسک تهدیدات داخلی یا نشت میان مستاجران نیز کمتر می‌شود.

هزینه و گرانش داده

بسیاری از بارهای کاری هوش مصنوعی و داده‌های بزرگ شامل دیتاست‌های عظیمی هستند که جابه‌جایی‌شان گران است و ملاحظات هزینه و گرانش داده را به همراه دارد. در SaaS خالص، مشتریان ممکن است هزینه‌های بالای خروج داده (Egress) و ذخیره‌سازی بپردازند تا دائماً داده را به ابر فروشنده ارسال کنند. کلاد-پرم این مدل را برعکس می‌کند: محاسبه را به جایی می‌برد که داده از قبل آنجا زندگی می‌کند، هزینه‌های انتقال داده را حذف می‌کند و تأخیر را کاهش می‌دهد. این برای صنایع داده‌محور حیاتی است؛ مثلاً یک بانک بزرگ با پتابایت‌ها داده آن‌پرم می‌تواند تحلیل‌ها را محلی اجرا کند و از تکثیر آن به یک ابر خارجی با هزینه زیاد جلوگیری کند. یک مطالعه اشاره کرد که سازمان‌ها با استفاده از یک پلتفرم استریمینگ BYOC (Redpanda) در محیط ذخیره‌سازی خودشان، نسبت به گزینه‌ی میزبانی‌شده توسط فروشنده، تا ده برابر کاهش هزینه دیده‌اند.

صنعت به سمت کنترل بیشتر روی داده و هزینه‌های زیرساخت در حرکت است. استارتاپ‌های هوش مصنوعی برای جذب مشتریان سازمانی که حریم خصوصی و کنترل می‌خواهند، مدل‌های BYOC را به‌کار می‌گیرند. هم‌زمان، بخش‌هایی مثل مالی، دولت، و سلامت که انطباق و مقیاس در آن‌ها هم‌گرا می‌شود، پیشتاز جنبش کلاد-پرم هستند. برای مثال، مؤسسات مالی با داده عظیم (حدود ~۴۵۰ پتابایتِ JP Morgan که بسیار فراتر از مقیاس‌های معمول SaaS است) کلاد-پرم را برای کشف تقلب و تحلیل‌ها پذیرفته‌اند چون نیازهای عملکردی‌شان را بدون قربانی کردن حاکمیت داده برآورده می‌کند. در مجموع، یک شناخت رو‌به‌رشد وجود دارد که یک ابر SaaS «یک‌اندازه-برای-همه» برای هر سناریویی کار نمی‌کند. معماری‌های کلاد-پرم اکنون به‌عنوان یک «حد میانی» ظاهر شده‌اند تا بهترینِ هر دو جهان را بگیرند: سرعت نوآوری ابر با کنترل آن‌پرم.

مقایسه Cloud-Prem، SaaS و Hybrid

برای شفاف‌سازی، مقایسه Cloud-Prem با SaaS سنتی و مدل‌های هیبرید مفید است.

Software as a Service (SaaS)

در مدل SaaS خالص، وندور اپلیکیشن را در کلاد خودش (اغلب چندمستاجری) میزبانی می‌کند و مشتریان از طریق اینترنت به آن دسترسی دارند. داده و زیرساخت کاملاً تحت مالکیت و کنترل وندور است. مشتری کنترل را با راحتی معاوضه می‌کند: وندور نگه‌داری، مقیاس‌دهی و امنیت کل استک را مدیریت می‌کند. این مدل راه‌اندازی سریع و بار IT حداقلی دارد. اما اقامت داده و انطباق مقرراتی به پلتفرم وندور وابسته است. برای سازمان‌های بدون دغدغه مقرراتی، سادگی و مقیاس‌پذیری SaaS جذاب است، اما برای صنایع حساس، کافی نیست.

Cloud-Prem (BYOC / Private SaaS)

در Cloud-Prem، نرم‌افزار به‌صورت تک‌مستاجری در اکانت کلاد یا دیتاسنتر خود مشتری اجرا می‌شود، اما توسط وندور (کامل یا جزئی) مدیریت می‌گردد. این در اصل یک SaaS خصوصی است. مشتری مالک زیرساخت (VPC یا سرورهای آن‌پرمیس) و داده‌هاست و الزامات حاکمیت داده را برآورده می‌کند، در حالی که وندور می‌تواند به‌روزرسانی، مانیتورینگ و پشتیبانی را در چارچوب دسترسی‌های اعطا‌شده انجام دهد. این مدل نسبت به SaaS کنترل و سفارشی‌سازی بیشتری می‌دهد، با پیچیدگی بالاتر در راه‌اندازی.

Hybrid

هیبرید می‌تواند به دو زمینه اشاره کند:

(الف) استقرار هیبرید ابری که در آن بخش‌هایی از راهکار در محیط‌های مختلف اجرا می‌شوند،

(ب) استراتژی ارائه هیبرید که در آن یک فروشنده هم SaaS و هم گزینه‌های آن‌پرم را پشتیبانی می‌کند. از نظر معماری، بسیاری از راهکارهای کلاد-پرم ذاتاً هیبرید هستند (مثلاً صفحه کنترل میزبانی‌شده توسط فروشنده به‌علاوه صفحه داده آن‌پرم یک معماری SaaS هیبرید است). برخی فروشندگان این را جلوتر می‌برند و بعضی سرویس‌ها را چندمستاجری نگه می‌دارند در حالی که فقط مؤلفه‌های مشخصی را در شبکه مشتری مستقر می‌کنند. برای نمونه، فروشنده ممکن است یک کنسول مدیریت مرکزی را در ابر اجرا کند، اما یک ایجنت یا اپلاینس ارائه دهد که در سایت مشتری مستقر است و داده را مدیریت می‌کند (در محصولات تحلیلی و امنیتی رایج است). این رویکرد می‌تواند بدون سربار یک استقرار کامل BYOC، تا حدی مشکل کنترل داده را کم کند. مثال دیگر مدل «private link» اسنوفلیک است: سرویس در ابر اسنوفلیک می‌ماند، اما مشتریان از طریق لینک‌های شبکه خصوصی و امن متصل می‌شوند، انگار داخل شبکه خودشان است. این تاکتیک هیبرید برای کاهش نگرانی‌های حاکمیت داده استفاده می‌شود.

از نگاه مقایسه‌ای، مدل‌ها روی ابعاد کلیدی مثل کنترل داده و حریم خصوصی، مالکیت زیرساخت، مقیاس‌پذیری و به‌روزرسانی‌ها، پشتیبانی و عملیات، و استراتژی سازمانی هیبرید تفاوت دارند.

کنترل داده و حریم خصوصی

SaaS کمترین کنترل مشتری را ارائه می‌دهد (داده در قلمرو فروشنده است)، هیبرید/کلاد-پرم کنترل قوی ارائه می‌دهد (داده در ابر یا آن‌پرم مشتری می‌ماند)، و آن‌پرم سنتیِ کاملاً خودمدیریت بیشترین کنترل را می‌دهد. BYOC و مدل‌های هیبرید برای اعمال اقامت‌داده جذاب‌اند (مثلاً نگه داشتن دیتابیس‌ها در ریجن یا VPC مشتری برای تبعیت از قوانین محلی، در حالی که این ممکن است در SaaS تضمین نشود).

مالکیت زیرساخت

در SaaS، زیرساخت متعلق به فروشنده است و توسط او اداره می‌شود. در کلاد-پرم، زیرساخت متعلق به مشتری است (ابر یا در محل)، اما فروشنده معمولاً برای مدیریت نرم‌افزارش مقداری دسترسی دارد. راهکارهای هیبرید مؤلفه‌ها را بین هر دو رویکرد تقسیم می‌کنند. مالک بودنِ زیرساخت یعنی مشتریان می‌توانند از تعهدات و پیکربندی‌های ابری موجود استفاده کنند، اما همچنین یعنی باید نیازهای منابع نرم‌افزار را در محیط خودشان جا بدهند.

مقیاس‌پذیری و به‌روزرسانی‌ها

سیستم‌های SaaS شفاف مقیاس می‌گیرند؛ فروشنده پشت صحنه ظرفیت اضافه می‌کند و به‌روزرسانی‌ها را پیوسته منتشر می‌کند. استقرارهای BYOC برای مقیاس‌دهی به برنامه‌ریزی بیشتری نیاز دارند (نمونه‌ی هر مشتری باید اندازه‌گذاری و تنظیم شود، اغلب با اسکریپت‌های اتوماسیون یا کوبرنتیز برای کشسانی). به‌روزرسانی‌ها در کلاد-پرم معمولاً با مشتری هماهنگ می‌شوند (یا از طریق یک صفحه کنترل مرکزی در ساعات کم‌ترافیک انجام می‌شوند)، نه انتشار فوری. یک رویکرد هیبریدِ صفحه کنترل می‌تواند اجازه دهد فروشنده به‌روزرسانی‌ها را سریع‌تر از آن‌پرم سنتی به نمونه‌های مشتری برساند، اما نه به روانیِ یک SaaS چندمستاجری واقعی.

پشتیبانی و عملیات

فروشندگان در SaaS دیدپذیری و کنترل کامل دارند و پشتیبانی پیش‌دستانه را ممکن می‌کنند (می‌توانند لاگ‌ها، متریک‌ها و غیره را به راحتی ببینند). در کلاد-پرم، به‌طور پیش‌فرض دید فروشنده محدود است. عیب‌یابی ممکن است نیاز داشته باشد مشتری لاگ‌ها را به اشتراک بگذارد یا اجازه نشست‌های ریموت بدهد مگر اینکه ابزارهای تله‌متری تعبیه شده باشند (بعداً بیشتر درباره این چالش). مدل‌های هیبرید می‌توانند طوری طراحی شوند که داده سلامت را به خانه گزارش کنند (phone-home). در سمت مشتری، SaaS تقریباً هیچ تلاش عملیاتی IT لازم ندارد، در حالی که BYOC یعنی تیم عملیات مشتری هم درگیر است (فراهم‌سازی منابع ابری، اطمینان از اتصال شبکه و غیره) همراه با فروشنده. سفارشی‌سازی هم متفاوت است. SaaS معمولاً یک‌اندازه-برای-همه است (با برخی تنظیمات قابل پیکربندی)، در حالی که یک استقرار BYOC می‌تواند سازگارتر باشد (مثلاً مشتری می‌تواند آن را با سیستم‌های داخلی یکپارچه کند یا پیکربندی امنیتی سفارشی داشته باشد). به همین دلیل سازمان‌های بزرگ اغلب BYOC را ترجیح می‌دهند؛ می‌تواند با محیط و سیاست‌هایشان سازگار شود، در حالی که SaaS محدودیت‌های یکنواخت‌تری تحمیل می‌کند.

استراتژی سازمانی هیبرید

برخی شرکت‌های نرم‌افزاری یک ارائه‌ی هیبرید را اتخاذ می‌کنند و هم خط محصول ابری و هم آن‌پرم را نگه می‌دارند. این می‌تواند بازار بزرگ‌تری را پوشش دهد اما به قیمت پیچیدگی مهندسی و پشتیبانی. مسیر Atlassian نمونه برجسته‌ای است: آن‌ها سال‌ها نسخه‌های سرور (آن‌پرم) و ابری Jira/Confluence را ارائه می‌کردند. اخیراً Atlassian تلاش کرد «cloud-first» شود و آن‌پرم را کنار بگذارد، اما مشتریان سازمانی در برابر مهاجرت کامل به ابر مقاومت کردند. Atlassian مجبور شد بپذیرد که بسیاری از مشتریان بزرگ هیبرید باقی می‌مانند (برای برخی نیازها از نسخه‌های دیتاسنتر آن‌پرم استفاده می‌کنند و به‌تدریج برای بقیه سراغ ابر می‌روند). درس این است که فروشندگان ممکن است لازم باشد در یک گذار طولانی، یا حتی نامحدود، ترکیبی از مدل‌ها را پشتیبانی کنند تا همه بخش‌های مشتری را راضی نگه دارند.

کلاد-پرم/BYOC بین دو سرِ طیف SaaS و آن‌پرم قرار می‌گیرد. یک مصالحه بین کنترل و راحتی ارائه می‌دهد. هر مدل مزیت‌های خودش را دارد. SaaS بیشترین سادگی، مقیاس‌پذیری و بهره‌وری فروشنده را فراهم می‌کند. آن‌پرم بیشترین امنیت و خودمختاری را فراهم می‌کند. کلاد-پرم تلاش می‌کند این دو را با استفاده از فناوری‌های مدرن cloud-native در قلمرو مشتری با هم ازدواج دهد. در ادامه، بررسی می‌کنیم چطور چنین راهکارهای کلاد-پرم را به‌طور مؤثر معماری کنیم.

الگوهای معماری کلیدی برای راهکارهای کلاد-پرم

طراحی یک محصول کلاد-پرم به الگوهای معماری قدرتمندی نیاز دارد که استقرارها را قابل‌حمل، قابل اتکا، و قابل مدیریت در محیط‌های متعدد مشتری کند. اصول کلیدی شامل طراحی میکروسرویسی و ماژولار، استقرارهای بومیِ کوبرنتیز، زیرساخت-به‌صورت-کد (IaC) و اتوماسیون، جداسازی صفحه کنترل/صفحه داده، حفظ ردپای سبک، پیش‌فرض‌های امن، راهبردهای افتِ کنترل‌شده (graceful degradation) و ساده‌سازی بسته‌بندی و تحویل است.

طراحی میکروسرویسی و ماژولار

راهکارهای کلاد-پرم از یک معماری میکروسرویسی سود می‌برند، جایی که اپلیکیشن به سرویس‌های loosely coupled (کم‌وابسته) شکسته می‌شود. این ماژولار بودن، به‌روزرسانی و سفارشی‌سازی را آسان‌تر می‌کند. اجزای منفرد می‌توانند برای هر مشتری ارتقا یا پیکربندی شوند بدون اینکه کل سیستم تحت تأثیر قرار بگیرد. میکروسرویس‌ها همچنین اجازه می‌دهند بخش‌هایی از سیستم مستقل مقیاس بگیرند (مثلاً اگر یک مشتری از ماژول تحلیل زیاد استفاده می‌کند، می‌توانید همان مؤلفه را روی کلاسترش جداگانه مقیاس دهید). علاوه بر این، سرویس‌های کوچک‌تر راحت‌تر کانتینری می‌شوند و در محیط‌های متنوع دوباره مستقر می‌گردند.

یک مونولیت برای موارد ساده می‌تواند کار کند، اما در عمل بیشتر فروشندگان می‌بینند ماژولار کردن سیستم (با قراردادهای API روشن بین سرویس‌ها) انعطاف‌پذیری نصب‌های آن‌پرم را خیلی بهتر می‌کند. سرویس‌های بدون حالت (Stateless) به‌خصوص ارزشمندند. با نگه داشتنِ تا حد ممکنِ وضعیت در ذخیره‌گاه‌های داده بیرونی (یا در دیتابیس مدیریت‌شده‌ی مشتری)، سرویس‌های اپلیکیشن می‌توانند آزادانه ری‌استارت یا مقیاس شوند، که وقتی با منابع آن‌پرم غیرقابل‌اتکا یا ارتقاها سروکار دارید مهم است. اگر مؤلفه‌های حالت‌دار لازم‌اند (مثلاً دیتابیس یا صف پیام)، در نظر بگیرید آن‌ها را پشت یک اینترفیس انتزاع کنید تا وقتی زیرساختِ مشتری فراهم است، از آن استفاده کنند. برای مثال، یک اپ BYOC می‌تواند اجازه دهد به سرویس دیتابیس یا ذخیره‌سازی شیء موجودِ مشتری وصل شود تا از دوباره‌کاری و افزایش ردپای منابع جلوگیری شود.

استقرار بومیِ کوبرنتیز

کوبرنتیز به استاندارد بالفعل برای بسته‌بندی و استقرار نرم‌افزار کلاد-پرم تبدیل شده است. با پذیرفتن مانیفست‌های کوبرنتیز (چارت‌های Helm، اپراتورها و غیره)، فروشندگان می‌توانند یک روش استقرار یکسان در محیط‌های متعدد به دست آورند. کوبرنتیز یک لایه انتزاعی روی تفاوت‌های زیرساختی فراهم می‌کند. فروشندگان اغلب یک Helm chart یا بسته‌ی yaml کوبرنتیز ارسال می‌کنند که همه پادها، سرویس‌ها، ingress و غیره را تعریف می‌کند. این نه تنها نصب را استاندارد می‌کند، بلکه از ویژگی‌های کوبرنتیز مثل زمان‌بندی، خودترمیمی، و سهمیه منابع برای عملیات امن‌ترِ چندمؤلفه‌ای بهره می‌برد. تیم‌های پیشرفته یک Kubernetes Operator می‌سازند، که اساساً یک کنترلر اختصاصی اپلیکیشن است که در کلاستر اجرا می‌شود تا کارهایی مثل بکاپ، مقیاس‌دهی، و ارتقاهای اپ را خودکار کند. اپراتورها دانش عملیاتی را کد می‌کنند و استقرار را برای مشتریان «دست‌کم‌دخالت‌تر» می‌سازند.

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

زیرساخت به‌صورت کد (IaC) و اتوماسیون

هر استقرار مشتری را به‌عنوان زیرساختی تکرارپذیر که در کد تعریف شده است در نظر بگیرید. Terraform، Pulumi، یا Crossplane می‌توانند برای اسکریپت‌کردن فراهم‌سازی منابع ابری (شبکه‌ها، VMها، کلاسترهای کوبرنتیز) که محصول نیاز دارد استفاده شوند. این کار یکنواختی را تضمین می‌کند و اتوماسیون را ممکن می‌سازد. برای مثال، یک فروشنده ممکن است ماژول‌های Terraform ارائه دهد که مشتریان اجرا می‌کنند تا منابع لازم AWS و نقش‌های IAM برای استقرار BYOC را بسازند و خطاهای راه‌اندازی را کاهش دهند. IaC همچنین به انطباق کمک می‌کند. ممیزی و بازبینی یک پیکربندی اعلامی ساده‌تر از راه‌اندازی دستی است.

پذیرفتن GitOps (با ابزارهایی مثل Argo CD یا Flux) الگوی قدرتمند دیگری است. وضعیت مطلوب اپلیکیشن (مانیفست‌های کوبرنتیز، config mapها و غیره) می‌تواند در یک مخزن Git نگه داشته شود که منبع حقیقت است. سپس کلاستر (از طریق Argo/Flux) به‌طور پیوسته تغییرات Git را اعمال می‌کند. این‌گونه، ارتقا یا تغییرات پیکربندی به سادگی کامیت کردن فایل‌های جدید در repo است، و اگر لازم باشد می‌تواند rollback شود. GitOps مدیریت تغییرات قابل ممیزی فراهم می‌کند (یک مزیت بزرگ برای مشتریان سازمانی) و می‌تواند اجازه دهد فروشندگان به‌روزرسانی‌ها را به شکلی کنترل‌شده و برای مشتری قابل‌مشاهده منتشر کنند (مشتری می‌تواند تغییرات را در git log خودش ببیند).

جداسازی صفحه کنترل / صفحه داده:

همان‌طور که قبلاً معرفی شد، مشخصه‌ی کلیدی معماری کلاد-پرم جدا کردن سیستم به یک صفحه کنترلِ مدیریت‌شده توسط فروشنده و یک صفحه داده‌ی مستقر در محیط مشتری است. به‌طور مشخص، این می‌تواند یعنی فروشنده یک سرویس وب مرکزی را (اغلب در ابرِ خود فروشنده) اجرا می‌کند که وظایف چندمستاجری را انجام می‌دهد، مثل کنسول مدیریت، لایسنس‌دهی، هماهنگی به‌روزرسانی‌ها، و پایش جهانی. مؤلفه‌های سنگین پردازش داده (دیتابیس‌ها، موتورهای پردازش و غیره) در محیط مشتری اجرا می‌شوند. صفحه کنترل و صفحه داده به‌صورت امن ارتباط دارند، اغلب با این الگو که صفحه داده اتصال را به سمت بیرون به صفحه کنترل آغاز می‌کند (برای جلوگیری از نیاز به دسترسی ورودی از طریق فایروال‌های مشتری).

این الگو چندین مزیت دارد. فروشنده می‌تواند ناوگانِ استقرارهای مشتری را از صفحه کنترل ارکستره کند (ارسال فرمان ارتقا، جمع‌آوری تله‌متری) در حالی که داده مشتری محلی می‌ماند. مشکلات صفحه داده یک مشتری روی دیگران اثر نمی‌گذارد (به‌خاطر ایزولاسیون قوی)، اما فروشنده همچنان می‌تواند یک تجربه یکپارچه‌ی شبیه SaaS از طریق UI صفحه کنترل ارائه دهد. صفحه کنترل می‌تواند سرویس‌های چندمستاجری را میزبانی کند که داده حساس را دست نمی‌زنند (مثل تجمیع‌کننده متریک یا دیتابیس پیکربندی با فقط متادیتا)، و با این کار از تکرار آن‌ها برای هر مشتری جلوگیری می‌شود.

این جداسازی همچنین با بهترین‌عمل‌های امنیتی هم‌راستاست. حداقل داده ممکن وارد صفحه کنترل می‌شود (ایده‌آل: فقط متریک‌های ناشناس‌سازی‌شده یا کانفیگ‌ها)، و تمام محاسبات و ذخیره‌سازی سنگین در منطقه مشتری انجام می‌شود. بسیاری از محصولات مدرن «SaaS هیبرید» (مثل feature store شرکت Tecton، تحلیل real-time شرکت StarTree و غیره) از این مدل استفاده می‌کنند. صفحه کنترل SaaS راحتی کاربر و مدیریت متمرکز می‌دهد، در حالی که صفحه داده (اغلب نرم‌افزار کانتینری) در حساب ابری مشتری مستقر می‌شود.

ردپای سبک و پیش‌فرض‌های امن

وقتی در محیط مشتری اجرا می‌شوید، نرم‌افزار شما باید از نظر مصرف منابع و عملیات تلاش کند «شهروند خوبی» باشد. یادتان باشد هزینه‌های زیرساخت می‌تواند باد کند و برای مشتری به ROI منفی در راهکار کلاد-پرم منجر شود! برای یک ردپای حداقلی بهینه کنید..

به عبارت دیگر، اجازه دهید با اندازه‌های نمونه کوچک برای توسعه/تست استقرار انجام شود، و مؤلفه‌ها فقط در صورت نیاز مقیاس بگیرند. مصرف منابع در حالت بیکار باید پایین باشد تا مشتری با قبض‌های بزرگ یا نیاز سخت‌افزاری غیرمنتظره برای نصب آزمایشی غافلگیر نشود. این راهبرد شامل ارائه‌ی کلیدها (toggle) برای خاموش کردن ویژگی‌های استفاده‌نشده یا استفاده از معماری ماژولار است تا مؤلفه‌های اختیاری (مثل یک سرویس افزونه) اگر مشتری نیاز ندارد، کاملاً حذف شوند. ایمنی عملیاتی یعنی طراحی برای جداسازی خرابی و رفتار قابل پیش‌بینی. با این ذهنیت، تماس‌های خارجی را rate-limit کنید (تا به یک API داخلی DDoS نکنید)، اگر سرویس شما به endpointهای فراهم‌شده توسط مشتری وابسته است circuit breaker پیاده‌سازی کنید، و برای تاب‌آوری، ترجیحاً retryهای بدون حالت داشته باشید.

افتِ کنترل‌شده (Graceful Degradation)

سیستم باید قطعی‌ها را به‌صورت افتِ کنترل‌شده مدیریت کند. اگر صفحه کنترل فروشنده از کار بیفتد یا ارتباطش را از دست بدهد، صفحه داده مشتری باید در یک حالت تنزل‌یافته اما کارا ادامه دهد (شاید بدون به‌روزرسانی‌های جدید)، نه اینکه کرش کند. ابزارهای لاگ‌گیری و دیباگ باید داخلی باشند (قابل دسترسی برای تیم عملیات مشتری) تا حتی اگر مهندسان فروشنده نتوانند فوراً وارد شوند یا از SSH یا کنترل ریموت دسکتاپ استفاده کنند، مشتری بتواند عیب‌یابی اولیه را خودش انجام دهد. خلاصه: برای خودمختاری طراحی کنید؛ هر نمونه باید پس از استقرار بتواند با حداقل دست‌گرفتن کار کند.

بسته‌بندی و تحویل

تحویل نرم‌افزار کلاد-پرم اغلب یعنی بسته‌بندی آن به‌صورت ایمیج‌های کانتینر و چارت‌های Helm، به‌علاوه اسکریپت‌های کمکی. برای توزیع به‌روزرسانی‌ها از رجیستری‌های استاندارد کانتینر و package managerها استفاده کنید. بسیاری از فروشندگان انتخاب می‌کنند یک رجیستری خصوصی میزبانی کنند یا از سیستمی مثل Replicated استفاده کنند که می‌تواند اپ را برای نصب‌های air-gapped هم بسته‌بندی کند. استفاده از ایمیج‌های کانتینر با همه وابستگی‌های bake شده (و ایمیج‌های پایه‌ی سیستم‌عاملی که امن شده‌اند) نیاز به اینترنت در زمان اجرا برای کشیدن مؤلفه‌ها را حذف می‌کند. وقتی مشتری‌ها در شبکه‌های air-gapped هستند، با ارائه‌ی بسته‌های نصب آفلاین از آن‌ها پشتیبانی کنید، مثل یک آرشیو قابل دانلود شامل همه ایمیج‌ها و چارت‌ها، به‌همراه checksumها.

چارت‌های Helm یک روش رایج برای کپسوله کردن همه پارامترهای قابل پیکربندیِ یک نصب هستند؛ با تنظیم فایل‌های values، استقرار می‌تواند با ترجیحات مختلف مشتری هدف‌گیری شود (تعداد نودها، فعال/غیرفعال کردن برخی ماژول‌ها و غیره). یک رویه‌ی نوظهور دیگر استفاده از Docker یا OCI image bundle برای مجموعه‌های کامل اپلیکیشن است (برخی ابزارها اجازه می‌دهند یک «application image» داشته باشید که مانیفست‌های کوبرنتیز و ایمیج‌ها را با هم شامل می‌شود). فارغ از روش، همه چیز را نسخه‌بندی کنید و تکرارپذیر نگه دارید. همان آرتیفکتی که در CI تست شده باید همان چیزی باشد که به مشتریان تحویل می‌شود.

معماری‌های کلاد-پرم به‌شدت به اصول cloud-native تکیه می‌کنند: کانتینری‌سازی، ارکستراسیون کوبرنتیز، زیرساخت-به‌صورت-کد، و جداسازی صفحه کنترل/صفحه داده. این الگوها تضمین می‌کنند که در حالی که استقرار هر مشتری ایزوله است، همه آن‌ها می‌توانند به‌صورت مقیاس‌پذیر مدیریت شوند.

در ادامه، درباره چالش‌های دنیای واقعی که هنگام پیاده‌سازی و بهره‌برداری از چنین راهکارهایی پیش می‌آید صحبت می‌کنیم.

چالش‌های کلیدی

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

پیچیدگی استقرار و ناهمگنی محیط

هر محیط مشتری یکتا است با ارائه‌دهنده‌های ابری مختلف، ریجن‌ها، تنظیمات شبکه، سیاست‌های امنیتی، نسخه‌های کوبرنتیز و غیره. یک مشتری ممکن است روی AWS با شبکه تخت و دسترسی اینترنت اجرا کند، دیگری روی Azure با قوانین سخت VNet، و دیگری روی یک کلاستر کوبرنتیز آن‌پرم کاملاً air-gapped. بسته به پایگاه مشتری بالقوه، فرآیند استقرار شما باید آن‌قدر تاب‌آور باشد که هر کدام از این تنوع‌ها را پشتیبانی کند. چنین انعطافی به تست گسترده روی چند پلتفرم (حداقل AWS، GCP، Azure، احتمالاً OpenShift، و نسخه‌های vanilla K8s) نیاز دارد تا مطمئن شوید چارت‌های Helm یا اسکریپت‌های شما همه‌جا کار می‌کنند.

حتی پایه‌هایی مثل کلاس‌های ذخیره‌سازی یا تعریف لودبالنسر می‌توانند بین محیط‌ها متفاوت باشند. اتوماسیون می‌تواند کمک کند (مثلاً صفحه کنترل ابر را تشخیص دهد و کانفیگ‌ها را تنظیم کند)، اما احتمالاً به یک نصب‌کننده انعطاف‌پذیر نیاز دارید که قابل سفارشی‌سازی باشد. وجه دیگر، مدیریت وابستگی‌هاست. برخلاف محیط کنترل‌شده SaaS، نصب‌های آن‌پرم ممکن است مجبور شوند با وابستگی‌های مدیریت‌شده توسط مشتری (دیتابیس‌ها، ارائه‌دهنده‌های هویت و غیره) یکپارچه شوند. رسیدگی به سناریوهای یکپارچه‌سازی متعدد پیچیدگی اضافه می‌کند. بسیاری از فروشندگان این مسئله را با ارسالِ تا حد ممکنِ همه چیز داخل استقرار کاهش می‌دهند (مثلاً استفاده از دیتابیس تعبیه‌شده یا بسته‌بندی سرویس‌های لازم)، اما این مصرف منابع را افزایش می‌دهد.

پیدا کردن تعادل درست سخت است. در نهایت، انتظار یک چرخه استقرار طولانی‌تر برای کلاد-پرم را داشته باشید: به جای کلیک کردن روی «deploy» در ابر خودتان، دارید بسته‌ای آماده می‌کنید که دیگران مستقرش کنند، که اغلب رفت‌وبرگشت با تیم عملیات‌شان برای درست انجام شدن را می‌طلبد. سرمایه‌گذاری روی مستندسازی خوب، pre-flight checkها (اسکریپت‌هایی برای اعتبارسنجی اینکه محیط پیش‌نیازها را دارد)، و شاید یک سندباکس «trial run» (مثل نسخه Docker Compose یا minikube) می‌تواند درد را کم کند. ارائه‌های مدیریت‌شده مثل DuploCloud هم می‌تواند تا حدی کمک کند.

نقاط کور دیدپذیری و پایش

در مدل SaaS، تیم DevOps شما دسترسی مستقیم به پایش دارد: لاگ‌ها، متریک‌ها، تریس‌ها، هرچه بخواهید. در کلاد-پرم، به‌طور پیش‌فرض آن دیدپذیری را از دست می‌دهید. اپلیکیشن پشت فایروال شخص دیگری اجرا می‌شود، شاید روی ماشین‌هایی که نمی‌توانید واردشان شوید. این فقدان دسترسی یک چالش بزرگ در پشتیبانی محصول ایجاد می‌کند. چطور می‌فهمید سالم است؟ چطور مشکلات عملکرد یا خطاها را دیباگ می‌کنید؟

برای مقابله با این مسئله، راهکارهای کلاد-پرم اغلب مؤلفه‌های دیدپذیری داخلی دارند که در محیط مشتری کار می‌کنند و سپس بینش‌ها را به‌صورت امن با فروشنده به اشتراک می‌گذارند. برای مثال، ممکن است یک گردآورنده متریک (مثل Prometheus یا Grafana agentها) در هر نصب مستقر کنید که داده عملکرد را جمع می‌کند. این داده می‌تواند برای مشتری قابل نمایش باشد (تا نمونه خودش را پایش کند) و به‌صورت انتخابی با اجازه مشتری به صفحه کنترل فروشنده یا تیم پشتیبانی ارسال شود.

نکته کلیدی این است که هیچ داده حساس ارسال نشود؛ به جای آن روی متادیتا و شاخص‌های سلامت تمرکز کنید. برخی فروشندگان یک داشبورد پایش را به‌عنوان بخشی از محصول ارائه می‌کنند که هم مشتری و هم فروشنده می‌توانند ببینند (مثلاً از طریق یک پورتال وب امن یا با اعطای دسترسی موقت توسط مشتری). در عمل، بسیاری از فروشندگان BYOC یک پایپ‌لاین تله‌متری «phone home» پیاده‌سازی می‌کنند: صفحه داده به‌طور دوره‌ای اطلاعات وضعیت را به صفحه کنترل push می‌کند. این می‌تواند شامل شماره نسخه‌ها، مصرف منابع، heartbeat checkها و غیره باشد. علاوه بر این، وقتی تشخیص عمیق‌تر لازم است، مشتریان ممکن است نیاز داشته باشند bundleهای پشتیبانی تولید کنند: آرشیوهایی از لاگ‌ها و کانفیگ‌ها که می‌توانند به اشتراک بگذارند.

دیدپذیری در BYOC حوزه‌ای در حال تکامل است؛ ابزارهای جدیدی مثل Insightful و DuploCloud در حال ظهور هستند تا بدون نقض حریم خصوصی، دید را برگردانند، با فراهم کردن انطباق SOC2 یا استفاده از سیستم‌های پایش فدره. عاقلانه است که پایش را یک جزء درجه‌یک معماری کنید، نه یک فکرِ بعدی، تا در تولید کور پرواز نکنید. نبودِ بینش می‌تواند به عدم رعایت SLA و مشتریان ناامید منجر شود وقتی مسائل سریع قابل تعیین نیستند.

محیط‌های air-gapped و آفلاین

برخی مشتریان سازمانی (دولت، دفاع، زیرساخت حیاتی) در شبکه‌های air-gapped کار می‌کنند که کاملاً از اینترنت جدا هستند. پشتیبانی از این استقرارها از چند جهت چالش است. اول، تحویل نرم‌افزار باید آفلاین باشد (از طریق USBهای رمزگذاری‌شده یا انتقال فایل از یک پل امن). پایپ‌لاین استقرار شما باید تحویل به‌روزرسانی‌ها را به‌صورت بسته‌های قابل دانلود که همه چیز لازم را دارند پشتیبانی کند (بدون pull از رجیستری‌های عمومی). لایسنس‌ها نمی‌توانند آنلاین تأیید شوند، پس ممکن است فایل‌های لایسنس آفلاین یا دانگل لازم باشد. دوم، پس از استقرار، سیستم نمی‌تواند به صفحه کنترل یا ابر شما برای سرویس‌های مدیریت‌شده دسترسی داشته باشد. هر قابلیتی که معمولاً به فراخوانی API ابری وابسته است باید یک جایگزین آن‌پرم داشته باشد. برای مثال، اگر SaaS شما معمولاً از سرویس ایمیل ابری برای ارسال اعلان‌ها استفاده می‌کند، نسخه آن‌پرم ممکن است نیاز داشته باشد به سرور SMTP مشتری یکپارچه شود.

دیدپذیری در حالت air-gapped هم سخت است: نمی‌توانید خودکار متریک‌ها را بیرون بکشید، پس به مشتری متکی می‌شوید که دوره‌ای لاگ‌ها را صادر کند یا اجازه بازدید حضوری بدهد. طراحی برای air-gap ممکن است شامل اجرای یک سرور به‌روزرسانی محلی یا یک صفحه کنترل محلی در سایت مشتری باشد. برخی شرکت‌ها یک اپلاینس فیزیکی یا یک ایمیج VM از پیش بارگذاری‌شده تحویل می‌دهند که با وابستگی‌های خارجی حداقلی نصب می‌شود. تست مسیر نصب آفلاین ضروری است. هیچ چیز بدتر از نصب‌کننده‌ای نیست که تلاش کند وابستگی‌ها را از اینترنت بگیرد و در یک دیتاسنتر قفل‌شده شکست بخورد.

به‌روزرسانی‌های امنیتی یک نگرانی ویژه‌اند: در محیط ایزوله، نرم‌افزار ممکن است سریع وصله نشود. فروشندگان باید با تیم امنیتی مشتری کار کنند تا بسته‌های وصله‌ی تاییدشده را به‌طور منظم ارائه دهند. استقرارهای air-gapped اغلب چرخه عمر طولانی دارند (چون به‌روزرسانی سخت است)، پس اگر به این فضا می‌فروشید، برنامه‌ریزی کنید نسخه‌های قدیمی‌تر را برای مدت طولانی‌تری پشتیبانی کنید.

مسئولیت مشترک و مدل امنیتی

کلاد-پرم یک مسئولیت امنیتی مشترک پیچیده بین فروشنده و مشتری ایجاد می‌کند. در SaaS، فروشنده همه‌چیز را در ابر خودش امن می‌کند. در آن‌پرم، مشتری همه‌چیز را امن می‌کند. در BYOC، مسئولیت‌ها محو می‌شوند: ابر مشتری جداسازی شبکه و امنیت زیرساخت پایه را فراهم می‌کند، اما اپلیکیشن فروشنده در آن محیط دسترسی سطح بالا دارد. مرزبندی روشن و بهترین‌عمل‌ها حیاتی‌اند. برای مثال، یک راه‌اندازی BYOC معمولی ممکن است از مشتری بخواهد یک VPC یا namespace اختصاصی برای اپ بسازد و به تیم فروشنده یا صفحه کنترل، دسترسی محدود بدهد (اغلب از طریق یک نقش IAM یا VPN به آن محیط).

فروشندگان باید دسترسی حداقلِ لازم را اعمال کنند: فقط کمینه نقش‌های لازم را درخواست کنید (مثلاً توانایی استقرار کانتینرها و خواندن متریک‌های CloudWatch، نه دسترسی کامل به همه منابع ابری). بسیاری از شرکت‌ها دسترسی just-in-time پیاده می‌کنند: فروشنده دسترسی دائمی به محیط زمان‌کار ندارد مگر اینکه مشتری صریحاً یک نشست پشتیبانی باز کند یا صفحه کنترل هنگام انجام یک به‌روزرسانی خودکار، یک credential کوتاه‌مدت تولید کند. این به نگرانی مشتریان کمک می‌کند که عملیات فروشنده هر وقت بخواهد بتواند داده را زیرورو کند. همه دسترسی‌ها باید قابل ممیزی باشند: از ابزارهای ممیزی ابر یا لاگ‌های خودتان برای ثبت اقدام‌های فروشنده استفاده کنید.

جنبه دیگر امنیت داده است. اگر فروشنده هر سطحی از دسترسی به سیستم‌های داخل محیط مشتری دارد، باید در سمت خودتان شیوه‌های امنیتی قوی تضمین کنید (بررسی پیشینه برای مهندسان، آموزش، 2FA روی هر دسترسی ریموت و غیره)، چون یک رخنه در سمت فروشنده می‌تواند بالقوه رخنه در چندین محیط مشتری باشد. برخی سازمان‌ها این را با الزام به پشتیبانی از کلیدهای رمزنگاریِ تأمین‌شده توسط مشتری کاهش می‌دهند، تا حتی اگر فروشنده به دیتابیس دسترسی داشته باشد، داده با کلیدی رمز شده باشد که فقط مشتری می‌داند.

خلاصه: اعتماد کنید ولی راستی‌آزمایی کنید. سیستم را طوری طراحی کنید که مشتری اگر بخواهد بتواند فروشنده را قطع کند و همچنان اجرا کند (شاید در حالت تنزل‌یافته)، و کنترل کامل داده‌اش را داشته باشد (خروجی گرفتن، بکاپ، و حذف به اختیار). ایجاد یک ماتریس مسئولیت مشترک روشن (مشابه مدل‌های ارائه‌دهندگان ابر) یک رویه خوب است. مستندسازی کنید کدام کارهای امنیتی مسئولیت فروشنده است (مثلاً مدیریت آسیب‌پذیری اپ، ایمیج‌های بدون CVE و غیره) و کدام مسئولیت مشتری است (مثلاً امن کردن محیط پیرامونی شبکه، وصله OS اگر VMها توسط مشتری مدیریت می‌شوند). یک مدل امنیتی خوب‌فکرشده و شفافیت، برای جلب اعتماد مشتری خیلی مؤثر است.

موانع دیباگ و پشتیبانی

وقتی در یک استقرار کلاد-پرم مشکلی پیش می‌آید، عیب‌یابی می‌تواند در مقایسه با SaaS دردناک کند باشد. در SaaS، مهندسان شما اغلب سریع می‌توانند مسئله را در staging بازتولید کنند، یا روی همان نمونه مشکل‌دار دیباگ زنده انجام دهند (چون تحت کنترل شماست). در BYOC، ممکن است خودتان را در یک تماس Zoom با ادمین مشتری ببینید که از او می‌خواهید فرمان‌ها را برایتان اجرا کند، اگر بد مدیریت شود.

این چالش یعنی باید برای پشتیبانی‌پذیری برنامه‌ریزی کنید. حالت‌های تشخیصی داخل اپ بسازید (مثلاً یک URL ویژه یا دستور CLI که یک گزارش تشخیصی جمع می‌کند). مشتریان را تشویق کنید طوری مستقر کنند که شما بتوانید به لاگ‌ها دسترسی داشته باشید، مثل ارائه گزینه‌ای برای فوروارد کردن لاگ‌ها به یک سیستم لاگینگِ فروشنده یا دست‌کم به یک باکت S3 که شما بتوانید دسترسی بگیرید. برخی فروشندگان یک «ایجنت پشتیبانی» کوچک ارسال می‌کنند که می‌تواند یک تونل امن باز کند تا فروشنده برای دیباگ اضطراری با یک کلیک از سمت مشتری وارد شود. اگر این کار را می‌کنید، مطمئن شوید واقعاً اختیاری و قابل ممیزی است. مشتریان می‌خواهند بدانند چه زمانی داخل سیستم‌شان هستید.

رویکرد دیگر برای پشتیبانی‌پذیری، نگه داشتن یک محیط مرجع در سمت شماست که هر راه‌اندازی اصلی مشتری را تقلید کند تا بتوانید مستقل بازتولید کنید. اما با توجه به داده و بارهای کاری یکتا، همیشه ممکن نیست. انتظار داشته باشید دیباگ شامل سربار ارتباطی بیشتر باشد. تیم شما رفت‌وبرگشت بیشتری با تیم عملیات مشتری خواهد داشت و مسائل ممکن است زمان بیشتری برای مشخص شدن بگیرند. این پیامد هزینه‌ای هم دارد (نیروی پشتیبانی، زمان).

برای کاهش این مسائل، قبل از انتشارها روی تست و QA قوی سرمایه‌گذاری کنید. گرفتن باگ‌ها در آزمایشگاه خیلی بهتر از تلاش برای درست کردن آن‌ها در یک محیط ریموت مشتری است که دسترسی محدود یا صفر دارید. همچنین یک استراتژی رول‌اوت canary یا فازبندی را در نظر بگیرید. اگر صفحه کنترل دارید، می‌توانید ابتدا به چند مشتری دوست (friendly) به‌روزرسانی بدهید، ببینید چیزی می‌شکند یا نه، بعد به بقیه بروید، به جای اینکه همه را هم‌زمان با یک آپدیت بد بزنید که در ریموت سخت عیب‌یابی می‌شود.

مدیریت ارتقا و پراکندگی نسخه

یکی از سخت‌ترین چالش‌های عملیاتی مدیریت استقرارهای زیاد در نسخه‌های مختلف است. در SaaS خالص، معمولاً یک نسخه (آخرین) را برای همه کاربران اجرا می‌کنید. در کلاد-پرم، برخی مشتریان فوراً ارتقا می‌دهند، برخی نسخه‌ها را رد می‌کنند یا به‌خاطر سیاست‌های داخلی‌شان ماه‌ها ارتقا را عقب می‌اندازند. با گذشت زمان ممکن است مجبور شوید چندین نسخه فعال از نرم‌افزار را در میدان پشتیبانی کنید. تیم‌های مهندسی و پشتیبانی باید سازگاری عقب‌رو (backwards compatibility) و دانش نسخه‌های قدیمی‌تر را حفظ کنند. عاقلانه است یک سیاست سخت‌گیرانه پشتیبانی نسخه پیاده کنید (مثلاً پشتیبانی از N و N-1، نسخه‌های قدیمی‌تر نیازمند قرارداد پشتیبانی تمدیدی ویژه) تا انفجار تعداد نسخه‌های پشتیبانی‌شده رخ ندهد.

خودکارسازی ارتقاها تا حد ممکن هم کلیدی است. اگر صفحه کنترل دارید، می‌تواند هماهنگ کند که ایمیج‌های کانتینر جدید روی کلاسترهای مشتری رول‌اوت شود (شاید در زمان‌بندی‌هایی که مشتری تنظیم می‌کند). با این حال، باید اتوماسیون را با احتیاط متعادل کنید. مشتریان سازمانی اغلب می‌خواهند نسخه‌های جدید را اول در staging اعتبارسنجی کنند قبل از اینکه تولید ارتقا پیدا کند. ارائه گزینه «بدون ارتقا بدون تأیید» مهم است، حتی اگر سیستم شما auto-update دارد، خیلی‌ها آن را خاموش می‌کنند و فرآیند دستی را ترجیح می‌دهند.

تکنیک دیگر برای آن‌پرم، استقرارهای blue-green یا canary است. یک نسخه جدید را کنار نسخه قدیم تحویل دهید و به مشتری اجازه دهید وقتی آماده است سوییچ کند، یا به‌صورت تدریجی داده مهاجرت کند. این برای سرویس‌های بدون حالت آسان‌تر است، اما برای دیتابیس‌ها یا مؤلفه‌های حالت‌دار ممکن است شامل مهاجرت‌های پیچیده داده باشد. تست رویه‌های ارتقا در همه توپولوژی‌های پشتیبانی‌شده ضروری است تا از ارتقاهای شکست‌خورده‌ای جلوگیری شود که مداخله دستی می‌خواهد (سناریوی کابوس اگر یک سیستم آن‌پرم را ساعت ۳ صبح brick کند). در نهایت، درباره چگونگی تحویل سریع وصله‌های امنیتی فکر کنید. ممکن است یک مکانیزم وصله خارج از چرخه برای اصلاحات بحرانی لازم داشته باشید که منتظر انتشار نسخه کامل نماند.

خلاصه اینکه اجرای نرم‌افزار «در طبیعتِ» محیط‌های مشتری چالش‌هایی در تنوع استقرار، پایش، مسئولیت‌های امنیتی، و مدیریت چرخه عمر ایجاد می‌کند. آگاهی از این چالش‌ها قدم اول است. در ادامه درباره مبادله‌ها و انتخاب‌ها در ابزار و استراتژی صحبت می‌کنم که می‌توانند بخشی از این دردها را کاهش دهند.

مبادله‌ها و انتخاب‌ها

وقتی یک ارائه کلاد-پرم را مهندسی می‌کنید، تیم‌ها با انتخاب‌ها و مبادله‌های مهم طراحی روبه‌رو می‌شوند. در ادامه تصمیم‌های کلیدی و اثرشان بر راهکار آمده است.

GitOps در برابر استقرار سنتی

یک تصمیم این است که به‌روزرسانی‌ها و تغییرات پیکربندی چگونه تحویل داده شوند. رویکرد GitOps (با ابزارهایی مثل Argo CD یا Flux) وضعیت مطلوب استقرار را به‌عنوان کد در یک مخزن در نظر می‌گیرد. این رویکرد می‌تواند برای کلاد-پرم قدرتمند باشد. فروشنده می‌تواند مانیفست‌های به‌روزرسانی را از طریق یک شاخه Git عرضه کند و کلاستر مشتری آن‌ها را pull و apply کند. این کار یک ردپای ممیزی روشن می‌دهد و بازگشت به عقب به سادگی revert کردن یک commit است.

مبادله اینجا پیچیدگی است، چون همه مشتری‌ها با راه‌اندازی GitOps برای یک اپلیکیشن شخص ثالث راحت نیستند. برخی ممکن است رویکرد سنتی‌تر را ترجیح دهند (دانلود نصب‌کننده جدید، اجرای آن). GitOps در محیط‌هایی می‌درخشد که مشتریان کنترل و دیدپذیری تغییرات را می‌خواهند (در فین‌تک و دولت رایج). همچنین نوعی مدل «SaaS خود-سرویس» را ممکن می‌کند، که فروشنده نسخه‌های جدید را در یک repo منتشر می‌کند، اما مشتری تصمیم می‌گیرد چه زمانی sync کند. از طرف دیگر، اگر فرآیند داخلی مشتری بسیار دستی است یا دانش GitOps ندارد، اجبار به آن می‌تواند مانع باشد. حد میانی این است که هر دو را ارائه دهید: تحویل پیوسته مبتنی بر GitOps برای کسانی که اتوماسیون می‌خواهند، و مسیر ارتقای دستی قدم‌به‌قدم برای دیگران.

اپراتورهای کوبرنتیز در برابر اسکریپت‌های ساده‌تر

همان‌طور که قبلاً گفته شد، استفاده از Kubernetes Operator می‌تواند بخش بزرگی از چرخه عمر اپلیکیشن را خودکار کند (راه‌اندازی، بازیابی، ارتقاها). نوشتن اپراتور (یا استفاده از فریم‌ورک اپراتور) یک سرمایه‌گذاری است که می‌تواند شبیه ساختن یک محصول کوچک در کنار محصول اصلی باشد. مزیت، مقیاس‌پذیری مدیریت است. با یک اپراتور خوب، یک مهندس می‌تواند ده‌ها استقرار مشتری را نظارت کند چون اپراتور مسائل روتین را خودکار مدیریت می‌کند، مثل ری‌استارت کردن پادها، تغییر اندازه کلاسترها، و بکاپ گرفتن از داده. اپراتورها همچنین می‌توانند با پایپ‌لاین‌های GitOps برای یک راهکار کامل CI/CD در محیط‌های مشتری یکپارچه شوند.

گزینه جایگزین استفاده از Helm chartهای ساده‌تر یا اسکریپت‌ها و تکیه بر رویه‌های دستی یا نیمه‌خودکار برای نگه‌داری است. اوایل عمر محصول، یک اپراتور کامل ممکن است بیش از نیاز باشد، پس برخی استارتاپ‌ها با Helm و مستندات شروع می‌کنند و بعداً با افزایش مشتری‌ها به اپراتور تکامل می‌دهند. مبادله بین اتوماسیون و تلاش انسانی است. اتوماسیون بیشتر (از طریق اپراتورها) کارِ تکراری مداوم را کم می‌کند اما هزینه توسعه و پیچیدگی اولیه بالاتری دارد. اتوماسیون همچنین یک مؤلفه دیگر معرفی می‌کند که می‌تواند باگ داشته باشد. رویکرد عمل‌گرایانه اغلب این است که تا حد ممکن ساده شروع کنید (برای اینکه استقرارهای اولیه کار کند و دانش جمع شود) و سپس دردناک‌ترین کارهای دستی را به‌تدریج با اپراتور یا اسکریپت‌های اضافی خودکار کنید.

تله‌متری امن در برابر حریم خصوصی

برای دیدپذیری و انطباق لایسنس، فروشندگان اغلب تله‌متری از نصب‌های آن‌پرم می‌خواهند. انتخاب‌ها از متریک‌های کاملاً اختیاری و ناشناس تا پایش تهاجمی‌تر گسترده‌اند. یک مبادله روشن وجود دارد. تله‌متری بیشتر می‌تواند پشتیبانی و کشف پیش‌دستانه مشکل را به‌طور چشمگیر بهتر کند (و همچنین مطمئن شود مشتریان شرایط را نقض نمی‌کنند)، اما اگر با دقت مدیریت نشود می‌تواند اعتماد را فرسوده کند. بهترین‌عمل این است که شفاف و امن باشید: دقیقاً مستند کنید چه چیزی ارسال می‌شود، مطمئن شوید در مسیر رمزنگاری شده است، و به مشتری اجازه دهید اگر خواست خاموشش کند. بسیاری از مشتریان سازمانی ترافیک خروجی سیستم را موشکافانه بررسی می‌کنند. یک الگوی طراحی که جواب می‌دهد این است که یک فهرست کوچک و قابل ممیزی از متریک‌ها داشته باشید (مثلاً وضعیت روشن/خاموش سیستم، نسخه، بار CPU، و یک هش از کلید لایسنس).

این متریک‌ها به صفحه کنترل ارسال می‌شوند. همه چیز دیگر (لاگ‌های جزئی و غیره) آن‌پرم می‌ماند مگر اینکه کاربر یک آپلود پشتیبانی را فعال کند. این رویکرد بیشتر تیم‌های امنیتی را راضی می‌کند و هنوز اطلاعات ضروری را به فروشنده می‌دهد. صفحه کنترل فروشنده همچنین باید این تله‌متری را به مشتری برگرداند (یک داشبورد یا صفحه سلامت) تا یک خیابان دوطرفه باشد و «spywareِ phone-home» نباشد. در صنایع قانون‌مند، گاهی هیچ تله‌متری مجاز نیست. در این موارد، فروشنده باید کور عمل کند یا گزارش‌های دستی دوره‌ای بخواهد. این یک مبادله دشوار است: انتخاب بین دید و حریم خصوصی. تعادل درست به میزان تحمل مشتری شما بستگی دارد.

به‌روزرسانی و وصله‌کردن آفلاین

پشتیبانی از محیط‌های کاملاً آفلاین یک نقطه تصمیم است، چون سربار مهندسی و فرآیندی را شدیداً افزایش می‌دهد (همان‌طور که در چالش‌ها گفته شد). اگر بازار هدف شما دفاع، سلامت، یا زیرساخت حیاتی را شامل می‌شود، ممکن است انتخابی نداشته باشید. اما اگر نه، ممکن است تصمیم بگیرید نصب‌های air-gap را به‌طور رسمی پشتیبانی نکنید تا عملیات ساده‌تر شود. برخی شرکت‌ها صراحتاً اتصال اینترنت را به‌عنوان یک پیش‌نیاز برای ارائه آن‌پرم‌شان لیست می‌کنند و مشتریان واقعاً air-gapped را به سمت نسخه‌های قدیمی‌ترِ لایسنس‌محور یا حتی بدون پشتیبانی هدایت می‌کنند.

اگر آفلاین را پشتیبانی می‌کنید، انتخاب مکانیزم به‌روزرسانی حیاتی است. آیا فایل‌های ISO/tarball دوره‌ای می‌دهید که همه چیز را شامل باشد؟ مشتری‌ها چطور اعمالش می‌کنند: با یک ابزار CLI یا با جایگزینی دستی کانتینرها؟ مبادله بین بسامد به‌روزرسانی و اندازه بسته است. به‌روزرسانی‌های کوچک و پرتعداد آنلاین راحت‌اند، اما آفلاین مشتری‌ها معمولاً بسته‌های بزرگ‌تر اما کم‌تعداد را ترجیح می‌دهند (چون هر بار اعمال کردن دردسر دارد). ممکن است در نهایت دو مسیر نگه دارید: یک جریان آپدیت پیوسته برای استقرارهای متصل و یک بسته آفلاین فصلی برای محیط‌های ایزوله. هر مسیر سربار اضافه می‌کند (تست، بسته‌بندی)، پس مطمئن شوید تیم‌تان ظرفیت وعده‌هایی که می‌دهید را دارد.

پشتیبانی چندنسخه‌ای و سازگاری

همان‌طور که گفته شد، برخورد با چندین نسخه فعال سخت است. یک انتخاب استراتژیک این است که آیا همه مشتریان را مجبور می‌کنید هماهنگ (یا در یک بازه زمانی تنگ) به‌روز شوند یا نه. برخی فروشندگان نرم‌افزار آن‌پرم از شروط لایسنس یا قراردادهای پشتیبانی استفاده می‌کنند تا مشتریان را ملزم کنند در یک یا دو نسخه از آخرین نسخه باقی بمانند. اگر اهرم دارید یا به‌روزرسانی‌ها نسبتاً آسان‌اند، این می‌تواند کار کند. بار مهندسی را کم می‌کند (نسخه‌های کمتر برای باگ‌فیکس). اما تحمیل ارتقا بیش از حد می‌تواند مشتریانی را که ثبات را ترجیح می‌دهند ناراحت کند، خصوصاً اگر ارتقاها سابقه خرابکاری داشته باشند.

رویکرد دیگر ارائه نسخه‌های پشتیبانی بلندمدت (LTS) است. یک انتشار در سال را به‌عنوان LTS تعیین کنید که برای مثلاً دو سال فیکس‌های backport شده بگیرد، در حالی که انتشارهای میانی فقط سه تا شش ماه پشتیبانی داشته باشند. این اجازه می‌دهد مشتریان محافظه‌کار روی شاخه پایدار بمانند و مشتریان پیشرو جدیدترین را بگیرند. سپس می‌توانید تلاش‌های پشتیبانی را مطابق آن هدایت کنید. سازگاری هم یک انتخاب است. آیا صفحه کنترل جدید شما همیشه با صفحه‌های داده قدیمی backward-compatible می‌ماند؟ اگر مشتری محیطش را ارتقا ندهد، آیا کنترل SaaS شما هنوز می‌تواند آن را مدیریت کند؟ حفظ backward compatibility در APIها پیچیدگی اضافه می‌کند، اما می‌تواند انعطاف زمان‌بندی ارتقا را هم بیشتر کند. برخی طراحی‌ها ساده می‌گویند نمونه‌های قدیمی را مدیریت نمی‌کنند. UI صفحه کنترل مثلاً ممکن است یک نمونه را اگر خیلی قدیمی است به‌عنوان unsupported علامت بزند و مشتری را مجبور کند برای بازگشت قابلیت کامل ارتقا دهد. زود تصمیم بگیرید چقدر می‌خواهید «سخت‌گیر» باشید و این سیاست را روشن ارتباط دهید.

درجه دخالت عملی فروشنده در پشتیبانی

کلاد-پرم اغلب با پشتیبانی بسیار دست‌به‌کار شروع می‌شود، با مهندسانی که دستی به هر استقرار کمک می‌کنند. در گذر زمان، ایده‌آل این است که به سمت یک مدل خودکارتر و خودسرویس حرکت کند. یک تصمیم استراتژیک این است که در عملیات جاری چقدر روی خدمات (services) در برابر محصول (product) تکیه کنید. در رویکرد بسیار خودکار، مشتری‌ها در سیستم‌ها (صفحه کنترل، ابزارها) سرمایه‌گذاری می‌کنند تا مثلاً یک مهندس ops در سمت فروشنده بتواند پنجاه استقرار مشتری را از طریق داشبوردهای مرکزی مدیریت کند. این در سمت عملیات شبیه SaaS واقعی است، اما نیازمند ساخت ابزارهای داخلی است (مثل کاری که Palantir با Apollo انجام داد). در رویکرد دست‌به‌کار، هر مشتری ممکن است توجه فردی بخواهد و یک تیم «مهندسی قابلیت‌اعتماد مشتری» بسازید که فعالانه هر استقرار را مدیریت و پشتیبانی کند. این رویکرد اگر فقط انتظار چند ده مشتری بزرگ دارید قابل انجام‌تر است (و واقعاً برخی شرکت‌های B2B این‌گونه سودآور کار می‌کنند، عملاً مثل یک ارائه‌دهنده سرویس مدیریت‌شده).

مبادله بین مقیاس‌پذیری و فوریت است. استارتاپ‌های مرحله اولیه ممکن است به‌خاطر منابع محدود توسعه، پشتیبانی دستی را انتخاب کنند و استقرارهای اولیه را مثل پروژه مدیریت کنند. این می‌تواند موفقیت را تضمین کند و بازخورد جمع کند. اما مقیاس نمی‌گیرد. با افزایش مشتری‌ها، این رویکرد مگر اینکه به مدیریت محصولی‌تر pivot کنید، مهندسی را تحت فشار می‌گذارد. اغلب مسیر فازبندی است: دست‌گرفتن زیاد برای N مشتری اول، هم‌زمان با ساخت اتوماسیون، تا برای مشتری N+1 سیستم‌ها آماده باشد و onboarding آسان‌تر شود و غیره. مهم است دانشی را که از هر استقرار دستی به دست می‌آید ثبت کنید و به بهبود محصول یا runbookها برگردانید.

قیمت‌گذاری و سودآوری

کلاد-پرم پیامدهای عمیقی روی مدل کسب‌وکار شما دارد. برخلاف SaaS که فروشنده هزینه‌های زیرساخت ابری را می‌پردازد و آن هزینه‌ها را داخل قیمت اشتراک می‌گذارد، در BYOC مشتری مستقیم قبض‌های ابر را می‌پردازد. از یک طرف، این ساختار فروشنده را از هزینه متغیر آزاد می‌کند: فروشنده هزینه compute/storage مشتری را نمی‌دهد، و مشتری‌ها حتی می‌توانند از تخفیف‌های ابریِ مذاکره‌شده خودشان استفاده کنند. از طرف دیگر، این ساختار نحوه قیمت‌گذاری محصول را عوض می‌کند. معمولاً قیمت‌گذاری BYOC بر اساس اشتراک نرم‌افزار فقط است، نه مصرف زیرساخت. این می‌تواند قیمت روی برچسب را کمتر از SaaS نشان دهد، اما مشتری باید هزینه‌های AWS/Azure خودش را اضافه کند تا هزینه واقعی را حساب کند. فروشندگان باید تفاوت‌های قیمت‌گذاری را روشن توضیح دهند تا مشتری‌ها غافلگیر نشوند که اجرای نسخه BYOC هنوز هزینه‌های ابری قابل‌توجهی روی طرف آن‌ها می‌گذارد.

عامل دیگر این است که در SaaS، فروشندگان از چندمستاجری و صرفه‌های مقیاس بهره می‌برند (تجمیع منابع بین مشتریان). اما در BYOC، هر استقرار تک‌مستاجری است و اغلب برای ایمنی با ظرفیت اضافی اندازه‌گذاری می‌شود. معماری‌های چندمستاجری ذاتاً در مقیاس هزینه‌کارآمدترند، یعنی اگر نرم‌افزار شما می‌توانست به‌صورت یک سرویس بزرگ اجرا شود، احتمالاً منابع کل کمتری نسبت به پنجاه نمونه کوچک جداگانه مصرف می‌کرد. بنابراین، یک فروشنده BYOC اغلب باید حاشیه سود نرم‌افزار بالاتری بگیرد تا کارایی ازدست‌رفته را جبران کند (چون مشتری دارد آن را می‌پردازد).

با این حال، فشار رقابتی ممکن است سقف قیمتی ایجاد کند. قیمت‌گذاری به‌ازای نود یا به‌ازای نمونه در BYOC رایج است (مثلاً شارژ به ازای هر نود کلاستر تحت مدیریت)، اما این می‌تواند مشتری را تشویق کند برای صرفه‌جویی کم‌تخصیص (under-provision) کند و بالقوه عملکرد را خراب کند. برخی مشتری‌ها به‌جای آن قیمت‌گذاری به‌ازای کاربر یا هزینه سالانه ثابت را انتخاب می‌کنند. شما همچنین باید هزینه اضافه پشتیبانی و مهندسیِ نگه‌داشتن استقرارهای آن‌پرم را حساب کنید. قراردادهای پشتیبانی سازمانی یا قیمت‌های لیست بالاتر قاعده‌اند. سودآوری ممکن است به ازای هر مشتری کمتر باشد، خصوصاً در مراحل اولیه که ابزارها کامل توسعه نیافته و پشتیبانی high-touch است. طرف دیگر سکه این است که BYOC اغلب قراردادهای بزرگ‌تری را باز می‌کند (مشتریان سازمانی که SaaS را نمی‌پذیرفتند ممکن است برای یک راهکار BYOC پول بزرگ بدهند). بسیاری از شرکت‌های موفق قراردادهای چند میلیون دلاری برای نرم‌افزار آن‌پرم بسته‌اند، جایی که SaaS فقط می‌توانست اشتراک‌های ماهانه کوچک به دست آورد.

پس، مبادله می‌تواند چرخه‌های فروش کندتر و گران‌تر باشد، اما با ارزش قرارداد سالانه (ACV) بالاتر. مدل‌سازی این جنبه‌های مالی حیاتی است، تا مطمئن شوید قیمت نه فقط ویژگی‌های نرم‌افزار، بلکه سربار عملیاتیِ پشتیبانی در محیط‌های متنوع مشتری را هم پوشش می‌دهد. برخی استارتاپ‌ها با ارائه BYOC خیلی ارزان دچار مشکل شدند و بعد فهمیدند پایدار کردنش سودآور نیست وقتی زمان مهندسی را حساب می‌کنند. به‌طور کلی، BYOC/کلاد-پرم به سمت مدل فروش سازمانی متمایل است (قراردادهای بزرگ‌تر، مدیران حساب، و چرخه فروش طولانی‌تر) در مقایسه با مدل حجمی SaaS. این باید با استراتژی شرکت شما هم‌راستا باشد، که نه فقط یک تصمیم مهندسی، بلکه یک تصمیم کسب‌وکاری است.

برای جمع‌بندی (بدون خلاصه‌سازی محتوا، فقط همان جمله): راهکارهای کلاد-پرم نیازمند پیمایش مبادله‌ها بین اتوماسیون و تلاش دستی، دیدپذیری و حریم خصوصی، سخت‌گیری و انعطاف در به‌روزرسانی‌ها، و چگونگی استخراج ارزش با توجه به ساختار هزینه متفاوت هستند. پاسخ یک‌اندازه-برای-همه وجود ندارد؛ تیم‌های موفق انتخاب‌های آگاهانه‌ای می‌کنند که با نیازهای مشتری و توانمندی‌های شرکت‌شان هم‌راستا باشد. در ادامه، به چند مطالعه موردی نگاه می‌کنیم تا ببینیم این اصول و چالش‌ها در سازمان‌های واقعی چگونه نمود پیدا می‌کنند.

مطالعات موردی

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

Redpanda – موفقیت BYOC در پلتفرم استریمینگ داده

Redpanda Data (یک پلتفرم استریمینگ سازگار با Kafka) از همان ابتدا مدل BYOC را پذیرفت. آن‌ها Redpanda BYOC را ارائه می‌کنند، یک سرویس استریمینگ کاملاً مدیریت‌شده که در حساب ابری خودِ مشتری مستقر می‌شود. این رویکرد به‌شدت با شرکت‌های مالی و تکنولوژی که به استریمینگ داده کم‌تأخیر نیاز دارند بدون اینکه زیرساخت داده‌شان را واگذار کنند، هم‌صدا شد. معماری Redpanda صفحه کنترل و صفحه داده را جدا می‌کرد.

سرویس Redpanda روی object storage در VPC مشتری اجرا می‌شود، در حالی که تیم Redpanda از طریق یک صفحه کنترل آن را مدیریت می‌کند. نتیجه چشمگیر بود، چون مشتریان آن‌ها نسبت به استفاده از Kafka از طریق SaaS، عمدتاً به‌خاطر حذف data egress و بهینه‌سازی مصرف منابع در محیط خودشان، تا ده برابر کاهش هزینه دیدند. موفقیت Redpanda باعث شد بازیگر جاافتاده (Confluent) واکنش نشان دهد. Confluent گزینه BYOC نداشت و دید برخی مشتریان بزرگ Redpanda را ترجیح می‌دهند. این در نهایت به خرید یک استارتاپ به نام Warpstream توسط Confluent ختم شد تا قابلیت‌های BYOC خود را تقویت کند.

درس‌های کلیدی: Redpanda نشان داد که اگر معماری شما واقعاً زیرساخت مشتری را به‌طور کارآمد به‌کار بگیرد (در مورد آن‌ها، استفاده از object storage ابری به‌عنوان log store)، BYOC می‌تواند در عملکرد/هزینه برای بارهای کاری بزرگ از SaaS چندمستاجری بهتر باشد. آن‌ها همچنین اهمیت جداسازی صفحه داده/صفحه کنترل را برای سیستم‌های استریمینگ تأیید کردند. درس دیگر زمان‌بندی بازار است. آن‌ها یک تقاضا (حاکمیت داده در استریمینگ) را هدف گرفتند که رهبر بازار به آن پاسخ نمی‌داد و این به آن‌ها برتری داد.

Couchbase Capella – دیتابیس هیبرید ابری

Couchbase، یک فروشنده دیتابیس NoSQL که از گذشته با نرم‌افزار سازمانی آن‌پرم شناخته می‌شد، Capella را راه‌اندازی کرد، DBaaS کاملاً مدیریت‌شده‌ی خودشان، تا در عصر ابر رقابت کند. Capella کلاسترهای Couchbase را برای مشتریان روی AWS، Azure، و GCP اجرا می‌کند. جالب اینکه Couchbase تشخیص داد بسیاری از مشتریان یکپارچگی با محیط‌های موجودشان را می‌خواهند، پس Capella را با حالت‌های استقرار انعطاف‌پذیر ساخت. برای مثال، Capella از VPC peering و PrivateLink برای اتصال به شبکه ابری مشتری پشتیبانی می‌کند، و Couchbase Autonomous Operator به مشتریان اجازه می‌دهد Couchbase را روی کوبرنتیز در دیتاسنترها یا ابرهای خودشان اجرا کنند.

Capella عملاً یک طیف از سرویس‌ها ارائه می‌دهد: از چندمستاجری (Couchbase-hosted) تا کلاسترهای مدیریت‌شده توسط مشتری با ارکستراسیون ابری Couchbase. نتیجه مثبت بوده است. Couchbase توانست مشتریان قدیمی خود را به ابر بیاورد با ارائه یک حد میانی راحت (می‌توانند داده را تدریجی مهاجرت دهند، و از replication هیبرید بین Capella و کلاسترهای self-hosted استفاده کنند). Capella به‌عنوان یک موفقیت در فعال کردن یک «کلاد-پرم اختیاری» دیده می‌شود. مشتریانی که نیاز دارند می‌توانند دیتابیس را در محیط خودشان اجرا کنند (مثل Red Hat OpenShift با Operator)، در حالی که بقیه می‌توانند اجازه دهند Couchbase آن را میزبانی کند.

درس‌های کلیدی: حتی یک فروشنده سنتاً آن‌پرم می‌تواند اگر آن را هیبرید-دوست بسازد به یک مدل سرویس‌شده‌ی ابری pivot کند. یک نکته کلیدی نیاز به اتوماسیون قوی است (در اینجا Operator) برای مدیریت استقرارها در محیط‌های مختلف. همچنین با پشتیبانی از replication هیبرید بین آن‌پرم و Capella، Couchbase پذیرفت که بسیاری از سازمان‌ها مدت طولانی در حالت هیبرید خواهند ماند و آن را به ویژگی تبدیل کرد نه مشکل.

DeltaStream – SaaS خصوصی از روز اول

DeltaStream یک استارتاپ است که یک پلتفرم پردازش استریم بدون سرور ارائه می‌کند (تحلیل real-time روی داده‌های استریمینگ، با اتکا به Apache Flink). از همان ابتدا، DeltaStream هم سرویس ابری چندمستاجری و هم استقرار SaaS خصوصی (BYOC) را برای ابرهای خودِ مشتری ارائه داد. این قابل توجه است چون بسیاری از استارتاپ‌ها گزینه آن‌پرم را به تعویق می‌اندازند، اما DeltaStream از آن به‌عنوان یک نقطه فروش استفاده کرد تا سازمان‌هایی را هدف بگیرد که از ارسال داده‌های استریمینگ به بیرون از محیط‌شان مردد هستند. مشتریانی که گزینه BYOC را انتخاب می‌کنند می‌توانند موتور پردازش DeltaStream را در VPC خود مستقر کنند و همچنان کاملاً توسط DeltaStream مدیریت شود. این مدل احتمالاً به آن‌ها در صنایعی مثل فین‌تک یا مخابرات کمک کرد که نگرانی محل داده دارند. این شرکت اخیراً یک Series A جذب کرد و به «پذیرش گسترده داده استریمینگ» و نیاز به ابزارهایی که بتوانند امن در هر محیطی اجرا شوند اشاره کرد.

درس‌های کلیدی: رویکرد DeltaStream نشان می‌دهد شروع کردن با ذهنیت BYOC می‌تواند برای شرکت‌های جدید یک تمایز باشد، نه صرفاً یک افزونه. اما این یعنی از همان ابتدا بار مهندسی سنگین‌تر. ساخت یک پلتفرم serverless که بتواند در حساب‌های ابری دلخواه مستقر شود کار ساده‌ای نیست. موفقیت نهایی آن‌ها هنوز کاملاً مشخص نیست چون هنوز در مراحل اولیه‌اند، اما رویکردشان یک روند نوظهور را برجسته می‌کند. استارتاپ‌های جدید پلتفرم داده (به‌خصوص بعد از ۲۰۲۰) اغلب از روز اول برای BYOC طراحی می‌کنند، بازتابِ انتظار بازار برای انعطاف استقرار.

Palantir – تکامل از آن‌پرم به SaaS-هیبرید

Palantir نمونه‌ای شاخص از مدیریت موفق نرم‌افزار آن‌پرم در مقیاس است (هرچند با یک مدل بسیار high-touch). پلتفرم‌های Palantir (Foundry، Gotham) توسط دولت‌ها و سازمان‌های بزرگ استفاده می‌شوند که اغلب به استقرارهای آن‌پرم یا ابر اختصاصی برای امنیت نیاز دارند. در سال‌های اولیه، Palantir به‌طور فعال مهندسان را در محل مشتری می‌فرستاد تا هر نمونه را مستقر و سفارشی کند (مشهور به «مهندسان forward-deployed» به جای فروشنده‌ها). عملیات را خدمات-محور و نه‌چندان مقیاس‌پذیر می‌کرد، اما به آن‌ها اجازه داد نیازهای مشتری را عمیق بفهمند و محصول را پالایش کنند.

با گذشت زمان، Palantir بخش زیادی از فرآیند استقرار را محصولی کرد. آن‌ها یک پلتفرم داخلی به نام Apollo ساختند تا استقرار و به‌روزرسانی نرم‌افزار را در محیط‌های آن‌پرم، ابر، و هیبرید خودکار کند. اتوماسیون استقرارشان اجازه داد ویژگی‌ها و فیکس‌ها را خیلی سریع‌تر از فرآیندهای دستی سنتی به نصب‌های مشتری برسانند. Apollo reportedly می‌تواند نرم‌افزار Palantir را در ده‌ها سایت با حداقل دخالت انسانی به‌روزرسانی کند، فرآیندی که در غیر این صورت بسیار کند می‌بود. سرمایه‌گذاری‌های Palantir جواب داد. آن‌ها توانستند حاشیه سود ناخالص را تا سطوح شبیه SaaS بالا ببرند (حدود هشتاد و یک درصد)، در حالی که آن‌پرم را هم پشتیبانی می‌کردند، با استانداردسازی استقرارها و تمرکز فقط روی قراردادهای بزرگی که تلاش را توجیه می‌کرد. اکنون تبلیغ می‌کنند که Foundry می‌تواند «در ابر، آن‌پرم، یا هیبرید» به‌صورت بی‌وقفه مستقر شود، و مشتریان بزرگی مثل Airbus و Morgan Stanley آن را در حالت‌های مختلف اجرا می‌کنند.

درس‌های کلیدی: Palantir نشان می‌دهد پشتیبانی از آن‌پرم در مقیاس ممکن است، اگر سرمایه‌گذاری مهندسی کافی (اتوماسیون، ابزارسازی) انجام دهید و در انتخاب مشتری گزینشی باشید (آن‌ها دنبال قراردادهای عظیم می‌روند تا اقتصادش جواب دهد). یک درس، اهمیت ساخت یک پلتفرم تحویل داخلی قدرتمند است. محصول Apollo آن‌ها عملاً پیش‌درآمد بسیاری از ابزارهای تجاری امروزی برای مدیریت نرم‌افزار کلاد-پرم است. درس دیگر این است که مدل خدمات می‌تواند به مدل محصول تبدیل شود. اوایل کار، مقدار زیادی کار سفارشی لازم بود، اما Palantir از همان کار برای ساخت یک راهکار تکرارپذیرتر استفاده کرد و به‌تدریج تلاش به ازای هر مشتری را کم کرد. در نهایت، داستان Palantir واقعیت را برجسته می‌کند که سازمان‌ها حاضرند برای نرم‌افزاری که محدودیت‌های استقرارشان را رعایت می‌کند پرمیوم بپردازند. لازم نیست یک مدل SaaS کم‌هزینه را دنبال کنید اگر ارزش شما یک رویکرد high-touch را پشتیبانی می‌کند.

Atlassian – کنار گذاشتن آن‌پرم و واکنش منفی مشتریان

همه موارد موفقیت خالص نیستند. تجربه Atlassian یک داستان عبرت‌آموز درباره اینکه چگونه از هیبرید به ابر گذار می‌کنید. Atlassian مدت‌ها نسخه‌های آن‌پرم ابزارهایش (Jira Server، Confluence Server) را در کنار یک ارائه ابری رو به رشد ارائه می‌کرد. در ۲۰۲۰، Atlassian پایان عمر نسخه‌های سرور را اعلام کرد (با Feb 2024 به‌عنوان پایان پشتیبانی) تا مشتریان را به ابر یا نسخه میانی دیتاسنتر (کلاستر خودمدیریت) سوق دهد.

در حالی که از نظر استراتژیک قابل فهم بود (ابر درآمد تکرارشونده و پشتیبانی آسان‌تر می‌دهد)، بسیاری از مشتریان، به‌خصوص سازمان‌های بزرگ و نهادهای دولتی، ناراضی بودند. یا نمی‌خواستند به دلایل داده به ابر بروند یا دریافتند Atlassian Cloud برای کاربردهای پیچیده آن‌ها به اندازه کافی ویژگی ندارد. Atlassian بعداً موضعش را نرم‌تر کرد و پیام‌رسانی را به «enterprise-first» تغییر داد و پذیرفت بسیاری از مشتریان بزرگ هیبرید باقی می‌مانند (و بنابراین برای مدت طولانی از دیتاسنتر آن‌پرم استفاده خواهند کرد). Atlassian تعهدی برای پشتیبانی از نیازهای آن مشتریان نشان داد و گفت مهاجرت‌های ابری را در بازه کوتاه تحمیل نمی‌کند.

در نهایت، Atlassian محصول سرور را پایان داد، اما هنوز محصول دیتاسنترش را (اساساً یک استقرار نمونه خصوصی) برای کسانی که نیاز دارند ارائه می‌کند. در عمل، آن‌ها یک مدل کلاد-پرم را ارائه می‌دهند که کاملاً توسط مشتری مدیریت می‌شود. رشد ابر Atlassian قوی است، اما مجبور شدند کمک مهاجرت گسترده، تخفیف‌ها، و حتی بازگرداندن برخی قابلیت‌های جدید آن‌پرم را ارائه دهند تا مشتریان مردد را راضی کنند.

درس‌های کلیدی: اگر قصد دارید یک ارائه آن‌پرم را به نفع ابر کنار بگذارید، انتظار مقاومت داشته باشید و برای یک دوره طولانی هیبرید برنامه‌ریزی کنید. مشتریان سرمایه‌گذاری زیادی در سفارشی‌سازی‌های آن‌پرم کرده‌اند و یک‌شبه جابه‌جا نمی‌شوند. ارتباط زودهنگام و مکرر حیاتی است، باید یک دلیل قانع‌کننده بدهید (فراتر از «ما شما را روی ابر می‌خواهیم»)، و مطمئن شوید محصول ابری شما واقعاً همه use caseها را پوشش می‌دهد وگرنه شکاف خواهید داشت. Atlassian یاد گرفت که رویکرد «همه یا هیچ» ریسک از دست دادن بزرگ‌ترین مشتریان را دارد. نکته این است که پشتیبانی از یک مدل کلاد-پرم یا هیبرید ممکن است برای آینده قابل پیش‌بینی برای برخی بخش‌های مشتری ضروری باشد. نمی‌توانید فقط خاموشش کنید بدون اینکه جایگزین قدرتمندی ارائه دهید.

استارتاپ‌های مرحله اولیه – هشدار درباره BYOC زودهنگام

برای شرکت‌های خیلی جوان، پشتیبانی از کلاد-پرم می‌تواند یک بار سنگین باشد. بسیاری از استارتاپ‌های مرحله اولیه در ابتدا روی یک SaaS تک‌مستاجری تمرکز می‌کنند برای سادگی، حتی درخواست‌های آن‌پرم را رد می‌کنند تا منابع کافی داشته باشند. چالش این است: اگر اولین مشتری بالقوه بزرگ شما استقرار آن‌پرم می‌خواهد، آیا توسعه را منحرف می‌کنید تا آن را بسازید یا روی نقشه راه می‌مانید؟ برخی استارتاپ‌ها که دنبال قراردادهای اولیه آن‌پرم رفتند با کار سفارشی و پشتیبانی کند شدند و ممکن است فرصت مقیاس‌دادن محصول اصلی را از دست داده باشند. از طرف دیگر، نادیده گرفتن کامل آن‌پرم می‌تواند شما را از بازارهای پرسود مثل دولت یا مالی تا مدت‌ها بیرون نگه دارد.

یک راهبرد استفاده از پلتفرم‌های شخص ثالث برای بسته‌بندی آن‌پرم است. برای مثال، شرکت‌ها می‌توانند از Replicated، Portainer، یا Glasskube استفاده کنند. این شرکت‌ها فریم‌ورک‌هایی ارائه می‌دهند تا یک اپ SaaS را به یک محصول آن‌پرم آسان‌نصب تبدیل کنند (مدیریت لایسنس، به‌روزرسانی‌ها و غیره). این ابزارها می‌توانند زمان را کم کنند. چندین استارتاپ با تیم کوچک توانسته‌اند از Replicated برای ارائه نسخه آن‌پرم استفاده کنند. مبادله‌ها هزینه است (این پلتفرم‌ها ارزان نیستند) و اینکه هنوز باید استقرارها را تست و پشتیبانی کنید. رویکرد جایگزین این است که آن‌پرم را به‌عنوان یک milestone در نظر بگیرید که بعد از تثبیت محصول ابری تکمیل می‌شود.

شرکت‌های مرحله اولیه باید بازار را دقیق بسنجند. اگر آن‌پرم/BYOC یک تمایز بزرگ برای دامنه شماست (مثلاً ابزارهای توسعه برای سازمان‌ها و پلتفرم‌های داده)، شاید ارزش داشته باشد زود سرمایه‌گذاری کنید. در غیر این صورت، ممکن است عاقلانه‌تر باشد اول به بلوغ محصول با SaaS برسید، بعد گسترش دهید. اگر یک مشتری آن‌پرم اولیه را پذیرفتید، او را شریک طراحیِ مشارکتی کنید و راهکار را برای استفاده مجدد عمومی کنید، نه یک هک سفارشی یک‌باره. قیمت‌گذاری را طوری انجام دهید که تلاش اضافی را توجیه کند (قیمت‌گذاری سازمانی). بسیاری از بنیان‌گذاران با یک لوگوی بزرگ که آن‌پرم می‌خواهد وسوسه شده‌اند، اما بعد فهمیده‌اند قرارداد وقتی زمان مهندسی را حساب می‌کنی سودآور نیست. یک بالانس است و موفقیت اغلب یعنی یا گفتن «هنوز نه» تا زمانی که آماده باشید، یا استفاده از راه‌حل‌های موقت مثل میزبانی مدیریت‌شده در ابر مشتری (در اصل یک BYOC دستی) برای پل زدن.

مطالعه موردی	مدل ارائه	نتیجه / وضعیت	درس‌های کلیدی
Redpanda	پلتفرم استریم BYOC (دیپلوی در کلاد مشتری، مدیریت‌شده توسط وندور)	موفق به جذب گسترده مشتریان سازمانی شد؛ مشتریان تا حدود ۱۰ برابر کاهش هزینه نسبت به Kafka به‌صورت SaaS تجربه کردند. Confluent در واکنش، اقدام به خرید یک شرکت کرد.	BYOC می‌تواند در مقیاس، عملکرد و هزینه بهتری نسبت به SaaS چندمستاجری داشته باشد. جداسازی صفحه کنترل و داده و یکپارچگی با ذخیره‌سازی مشتری، مزایای مهمی در کارایی و حاکمیت داده ایجاد می‌کند.
Couchbase Capella	سرویس NoSQL DBaaS مدیریت‌شده با گزینه‌های هیبرید (سرویس کلاد + Operator مدیریت‌شده توسط مشتری)	مهاجرت مشتریان on-prem به کلاد با موفقیت انجام شد. از کلاد، on-prem و replication هیبرید پشتیبانی می‌کند.	انعطاف‌پذیری در دیپلوی، انتقال را آسان می‌کند. اتوماسیون Kubernetes (Operator) حیاتی است. پشتیبانی هیبرید یک مزیت رقابتی است، نه بار فنی قدیمی.
DeltaStream	پردازش استریم Private SaaS / BYOC (مبتنی بر Flink)	در مراحل اولیه؛ با مدل BYOC-first توانست traction بگیرد. موفق به جذب ۱۵ میلیون دلار سرمایه Series A شد.	BYOC از روز اول برای جذب سازمان‌ها مؤثر است، اما به سرمایه‌گذاری مهندسی زودهنگام نیاز دارد. تمرکز بر امنیت و سادگی برای کاهش اصطکاک در محیط مشتری ضروری است.
Palantir	پلتفرم آنالیتیکس on-prem و هیبرید (سیستم دیپلوی Apollo)	به حاشیه سود حدود ۸۱٪ دست یافت، در حالی که از on-prem، هیبرید و کلاد برای مشتریانی مانند Airbus و Morgan Stanley پشتیبانی می‌کند.	مدل خدماتی اولیه با Apollo به تحویل خودکار تبدیل شد. ابزارسازی داخلی برای مقیاس‌پذیری حیاتی است. تمرکز بر قراردادهای سازمانی بزرگ بازده بالایی دارد.
Atlassian	SaaS و on-prem (Server / Data Center)؛ تلاش برای مهاجرت کامل به کلاد	نسخه Server در سال ۲۰۲۴ متوقف شد؛ به دلیل مقاومت مشتریان، نسخه Data Center برای مشتریان هیبرید حفظ شد.	مهاجرت اجباری به کلاد باعث واکنش منفی شد. پشتیبانی هیبرید همچنان ضروری است. تغییرات باید شفاف و همراه با گزینه‌های بلندمدت باشند.
استارتاپ‌های مراحل اولیه	SaaS-first و سپس on-prem (یا با ابزارهای ثالث مثل Replicated)	بسیاری BYOC را تا Series B یا بعد به تعویق می‌اندازند. برخی با Replicated نسخه on-prem اولیه را با تیم کوچک عرضه می‌کنند.	on-prem در مراحل اولیه پرهزینه است. باید بین حواس‌پرتی مهندسی و درآمد تعادل برقرار شود. قیمت‌گذاری BYOC باید هزینه پشتیبانی را منعکس کند.