اصول مهندسی برای ساخت یک راهکار موفق 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 را به‌کار می‌گیرند. هم‌زمان، بخش‌هایی مثل مالی، دولت، و سلامت که انطباق و مقیاس در آن‌ها هم‌گرا می‌شود، پیشتاز جنبش کلاد-پرم هستند. برای مثال، مؤسسات مالی با داده عظیم (حدود ~450 پتابایتِ 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 کند). در نهایت، درباره چگونگی تحویل سریع وصله‌های امنیتی فکر کنید. ممکن است یک مکانیزم وصله خارج از چرخه برای اصلاحات بحرانی لازم داشته باشید که منتظر انتشار نسخه کامل نماند.

خلاصه اینکه اجرای نرم‌افزار «در طبیعتِ» محیط‌های مشتری چالش‌هایی در تنوع اس&a