به گزارش از وبسایت cncf، مسئله اصلی مکان فیزیکی سرور شما نیست؛ بلکه این است که چه نهادی می‌تواند خواستار دسترسی یا تحویل محتوای موجود روی آن شود 🔒.

برای سال‌ها ارائه‌دهندگان ابری، حاکمیت را صرفاً یک مسئله جغرافیایی می‌دیدند: یک region یا country انتخاب کنید و داده‌ها را محلی نگه دارید. اما قوانینی مانند قانون ابر ایالات متحده معادله را تغییر دادند؛ دسترسی به داده‌ها بیشتر تابع کنترل شرکت‌ها است تا محل فیزیکی. حتی یک زیرساخت عملیاتی هایپراسکیلر در فرانکفورت همچنان تحت قوانین شرکت مادر قرار می‌گیرد. انتخاب region یک کنترل جغرافیایی است و حاکمیت یک موضوع قضایی — و این تمایز به طور فزاینده‌ای تصمیمات طراحی زیرساخت را شکل می‌دهد.

پیشنهاد ژوئن 2026 برای CADA چارچوبی چهار لایه برای حاکمیت تدارکات ابری در بخش عمومی معرفی می‌کند. دولت فدرال کانادا نیز فروشندگان ابری را براساس اقامت داده و کنترل قضایی کانادا امتیازبندی می‌کند. بسیاری از کشورها همچنان الزاماتی برای localize کردن داده‌ها، حاکمیت یا اقامت داده‌ها دارند و چارچوب‌های نظارتی اکنون فراتر از اقامت داده به موضوعاتی مثل کنترل عملیاتی، شفافیت زنجیره تأمین، قابلیت حمل و انعطاف‌پذیری می‌پردازند. قوانین دیگری مثل قانون داده اتحادیه اروپا، قانون هوش مصنوعی، NIS2 و DORA نیز بر قابلیت ردیابی، پاسخگویی، وابستگی‌های زنجیره تأمین و ریسک تمرکز تاکید دارند.

در مجموع این روندها نشان می‌دهند که کنترل زیرساخت دیگر صرفاً یک اولویت فنی نیست؛ بلکه به یک انتظار نظارتی تبدیل شده است. این بحث اغلب به عنوان حفظ حریم خصوصی مطرح می‌شود، اما در واقع به اندازه زیادی مربوط به انعطاف‌پذیری است: همان معماری‌هایی که جلو مداخله حقوقی خارجی را می‌گیرند می‌توانند مواجهه با تحریم‌ها، اختلافات تجاری، تعلیق خدمات، تغییرات مجوز یا خروج فروشندگان را نیز کاهش دهند 🛡️.

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

الگوی در حال ظهور در اروپا این است که شرکت‌های تحت نظارت به جای خرید ویژگی حاکمیت از هایپراسکیلرها، پلتفرم‌های مستقل را از مؤلفه‌های open source می‌سازند. الگو کم‌کم آشنا می‌شود: Kubernetes لایه orchestration و policy را فراهم می‌کند، GitOps یکپارچگی عملیاتی در حوزه‌های قضایی مختلف را به همراه دارد و OpenStack زیرساخت پایه را تامین می‌کند. این ترکیب به سازمان‌ها امکان می‌دهد الزامات حاکمیتی را از طریق معماری و نه صرفاً قراردادها اجرا کنند. نمونه‌های واقعی شامل اپراتورهای راه‌آهن ملی، بانک‌های بزرگ و شرکت‌های مخابراتی اروپایی است که از Kubernetes، GitOps و اتوماسیون مبتنی بر سیاست برای اجرای بارهای کاری تنظیم‌شده در محیط‌های مستقل استفاده می‌کنند.

ایجاد زیرساخت مستقل خود چالش‌برانگیز است و نگهداری مستمر آن چالشی دیگر. بسیاری از فرایندهای انطباق هنوز متکی به مستندات، بازبینی‌ها و اقدامات دستی هستند که در مقیاس صدها یا هزاران بار کاری به خوبی جواب نمی‌دهند. Kubernetes این وضعیت را تغییر می‌دهد چون اجازه می‌دهد الزامات حاکمیتی مستقیماً توسط پلتفرم اعمال شوند: admission controllers می‌توانند قبل از برنامه‌ریزی یک Pod قواعد قرار دادن را اعمال کنند، node affinity تضمین می‌کند که بارها فقط روی زیرساخت‌های مجاز در حوزه قضایی صحیح قرار گیرند و namespace isolation مرزهای روشنی بین مستأجرها، محیط‌ها یا مناطق برقرار می‌کند. Policy engines هر درخواست API را در برابر نیازهای sovereignty ارزیابی کرده و منابع ناسازگار را پیش از رسیدن به production رد می‌کنند. رویکرد Policy as code این گفتمان را به عملیات می‌آورد: خط‌مشی‌ها در Git نگه‌داری و از طریق خطوط CI بررسی و در زمان استقرار اجرا می‌شوند. ابزارهایی مانند OPA/Gatekeeper و Kyverno امکان رمزگذاری الزامات حوزه قضایی را مستقیماً در خوشه فراهم می‌کنند. نتیجه، اجرای مستمر به جای تایید دوره‌ای است؛ هر تغییر قابل ردیابی و هر تصمیم استقرار قابل ممیزی می‌شود و در نتیجه حاکمیت تبدیل به یک توانمندی پلتفرمی می‌گردد.

اما Kubernetes همچنان به یک لایه زیرساختی زیر خود وابسته است: compute، networking، storage و identity همه باید از جایی تأمین شوند. اگر آن پایه به پلتفرمی گره خورده باشد که خارج از حوزه قضایی شما اداره می‌شود، حفظ برخی تضمین‌ها دشوارتر می‌شود. اینجا نقش OpenStack روشن می‌شود: OpenStack خدمات زیرساختی‌ای فراهم می‌آورد که Kubernetes روی آن تکیه می‌کند، و در عین حال به سازمان اجازه می‌دهد این خدمات را در محدوده صلاحیت خودش اجرا کند. Ironic امکان provision فلز خالی را می‌دهد بدون نیاز به hypervisor اختصاصی بین بار کاری و سخت‌افزار، Keystone مدیریت هویت را خودمیزبان نگه می‌دارد، Neutron جداسازی شبکه را زیر کنترل اپراتور ارائه می‌دهد و Ceph ذخیره‌سازی توزیع‌شده را روی زیرساختی که مالک و عامل آن هستید فراهم می‌کند. OpenStack می‌تواند کاملاً در یک محیط کنترل‌شده مستقر شود: بدون اجباری برای telemetry خارجی یا وابستگی‌های خارجی برای عملیات روزمره. ترکیب این دو لایه است که معماری مؤثر را می‌سازد؛ Kubernetes لایه policy و enforcement را فراهم می‌کند و OpenStack زیرساخت را.

بخش سخت ماجرا، عملیات آن است. حاکمیت معمولاً به معنی محیط‌های جدا برای هر حوزه قضایی است؛ بنابراین هر ارتقا، چرخش گواهی، تغییر RBAC، وصله امنیتی و برنامه‌ریزی ظرفیت به جای یک خوشه در چندین خوشه انجام می‌شود. GitOps این وضعیت را عملیاتی‌پذیر می‌کند: یک مخزن Git شامل پیکربندی‌های مشترک و overlayهای ویژه حوزه‌های قضایی است؛ controllersهای GitOps داخل هر خوشه به طور مداوم آن حالت مطلوب را آشتی می‌دهند. نیازی به یک کنترل‌پلن مرکزی نیست؛ هر خوشه پیکربندی را محلی می‌کشد و اعمال می‌کند. مزیت انطباق هم روشن است: هر تغییر بازبینی، نسخه‌بندی و قابل ممیزی است؛ وقتی از شما بپرسند در یک کلاستر چه چیزی در یک زمان مشخص اجرا می‌شد، پاسخ در تاریخچه commit موجود است. همین اصل در مورد زنجیره تأمین نرم‌افزار نیز صدق می‌کند؛ SBOMها، image signing و سیاست‌های پذیرش کمک می‌کنند تنها بارهای کاری تاییدشده به production برسند.

برای سازمان‌هایی که دنبال سطوح بالاتری از حاکمیت هستند، دید نمی‌تواند در سطح سیستم‌عامل متوقف بماند: firmware، management controllers و اجزای سخت‌افزاری پایین‌تر از پشته نرم‌افزاری قرار دارند و اغلب دسترسی وسیعی به میزبان دارند. به همین دلیل BOMهای سخت‌افزاری و attestationهای firmware نیز وارد گفتگوهای حاکمیت شده‌اند. ساختن زیرساخت‌ها در حال انجام است و هدف CADA افزایش قابل توجه ظرفیت دیتاسنتر در اروپا است، اما خود سخت‌افزار به تنهایی حاکمیت ایجاد نمی‌کند؛ لایه پلتفرم به همان اندازه اهمیت دارد. هوش مصنوعی این موضوع را برجسته‌تر می‌کند: تنظیم‌کننده‌ها توجه ویژه‌ای به نحوه آموزش، مدیریت و ممیزی مدل‌ها دارند و زیرساخت‌های آموزشی بر همان مبنای حاکمیتی که داده‌ها ارزیابی می‌شوند بررسی می‌شوند. یادگیری فدرال نمونه‌ای از تأثیر معماری است؛ به جای انتقال داده‌ها به نقطه‌ای مرکزی، آموزش در جایی انجام می‌شود که داده‌ها قرار دارند. خوشه‌های مستقل Kubernetes آموزش محلی انجام می‌دهند و تنها به‌روزرسانی‌های مدل بین حوزه‌ها جابجا می‌شود؛ همان سیاست‌ها، مرزهای namespace و کنترل‌های حاکمیتی که برای انطباق استفاده می‌شوند، پایه‌ و اساس سیستم‌های AI توزیع‌شده را شکل می‌دهند.

برای تیم‌های پلتفرم دیگر سؤال این نیست که آیا الزامات حاکمیتی در راه هستند یا نه — آن‌ها هم‌اکنون تصمیمات خرید، طراحی زیرساخت و مدل‌های عملیاتی را تحت تأثیر قرار داده‌اند. خبر خوب این است که بلوک‌های ساختمانی موجودند: Kubernetes برای orchestration و policy، OpenStack برای زیرساخت پایه، و GitOps به همراه policy engines، امنیت زنجیره تأمین نرم‌افزار و image identity همه کنار هم قرار می‌گیرند. در حالی که زیرساخت‌های ابری سال‌ها برای متمرکزسازی بهینه شده بودند، حاکمیت روندی معکوس را می‌طلبد: کنترل منطقه‌ای بیشتر، شفافیت بیشتر و مالکیت عملیاتی قوی‌تر. سوال اصلی این است که آیا حاکمیت صرفاً مستندسازی خواهد شد یا اینکه پلتفرم‌ها قادر خواهند بود آن را به‌طور خودکار اعمال کنند.

بسیاری از فناوری‌هایی که در این مطلب ذکر شدند به‌صورت open source توسعه یافته و استفاده می‌شوند. برای مشاهده کارهای منبع باز و مشارکت‌های VEXXHOST به GitHub مراجعه کنید: https://github.com/vexxhost 🔗