کانون توجه در معماری SIG: API Governance 🔦
این پنجمین گفتوگو از مجموعه Spotlight روی معماری SIG است که زیرپروژهها را معرفی میکند. موضوع این قسمت، SIG Architecture: API Governance است و در ادامه گفتوگویی دوستانه و فنی با Jordan Liggitt، سرپرست زیرپروژه مدیریت API، میخوانید. هدف، روشنتر کردن نقش حاکمیت API در اکوسیستم Kubernetes و نحوه تعامل آن با توسعهدهندگان و تیمهاست.
پرسش: کمی درباره خودتان و حضورتان در اکوسیستم Kubernetes بگویید.
JL: من Jordan Liggitt هستم. زندگی شخصیام شامل خانواده و موسیقی است و در زمینه مهندسی نرمافزار در Google کار میکنم. از حدود 2014 روی Kubernetes فعال هستم. کار شروعی من حول احراز هویت و authorization بود؛ تلاش اولم افزودن یک OAuth server به Kubernetes بود که البته همانموقع به صورت کامل ادغام نشد، اما همان مسیر باعث شد در طراحی و توسعه قابلیتهای authz/authn در core API مشارکت کنم. در طول زمان در تعریف APIها و نسخهبندی آنها حضور داشتم — از نسخههای اولیه مثل v1beta3 تا v1 — و از 2016 به عنوان reviewer و از 2017 به عنوان approver در حوزه API فعالتر شدم. امروز روی رهبری زیرپروژههای مدیریت API و سازماندهی کد برای SIG Architecture کار میکنم و در SIG Auth هم نقش فناوری دارم.
پرسش: دقیقاً چه زمانی در پروژه API Governance وارد شدید و حوزه کاری این زیرپروژه چیست؟
JL: API Governance حوزهای گسترده است: تمام سطوحی که سیستم با آنها تعامل دارد را شامل میشود — نه فقط REST API عمومی، بلکه چیزهایی که خیلیها آنها را «API» در نظر نمیگیرند: flags خط فرمان، فایلهای پیکربندی، رفتار باینریها، نحوه ارتباط با کامپوننتهای back-end و هر رابط دیگری. REST بزرگ و واضح است و مخاطب بیشتری دارد، اما این سطوح «داخلی» هم API هستند و باید مدیریت شوند. هدف اصلی ما ایجاد توازنی میان پایداری (stability) و امکان نوآوری است: خیلی ساده، اگر هرگز تغییر نکنیم ثبات آسان است، اما توان تکامل از دست میرود. پس باید اجازه تغییر را بدهیم و در عین حال وعدههای سازگاری را محترم بشماریم.
پرسش: در مورد دروازههای کیفیت در چرخه حیات تغییرات Kubernetes؛ API Governance کِی و چگونه وارد میشود؟
JL: ما دستورالعملها و قراردادهایی داریم — اسناد زنده که با تجربه بهروزرسانی میشوند — هم برای APIها بهطور کلی و هم برای روش تغییر آنها. این اسناد گاهی طولانی و تخصصیاند، به همین دلیل ما علاوه بر متنها، در مراحل طراحی و اجرا مشارکت فعال میکنیم. بعضی تیمها صرفاً بدون گرفتن بازخورد از API Review طراحی را جلو میبرند؛ این بد نیست اما معمولاً وقتی پیادهسازی آغاز شد، بازخوردها عمیقتر میشوند و تغییرات ساختاری موردنیاز نمایان میگردد. بنابراین ما در طراحی یا اجرای هر تغییر API درگیر میشویم تا بازخورد زودهنگام بدهیم و در زمانهای مناسب بررسیهای لازمه انجام شود.
پرسش: نقش KEP در این مسیر چیست؟
JL: KEPها (Kubernetes Enhancement Proposals) بسته به جزئیات متفاوتاند؛ برخی شامل تعریف صریح API هستند و آنوقت میتوان بررسی API را از مرحله طراحی انجام داد. برخی دیگر صرفاً مفهومیاند و جزئیات را به اجرا واگذار میکنند — که اشکالی ندارد، اما یعنی پیادهسازی اکتشافیتر است و بررسی API ممکن است بعد از اجرا تغییرات ساختاری پیشنهاد دهد. همیشه یک تبادل وجود دارد: طراحی دقیق پیشاپیش در برابر کشف تکراری در حین اجرا. ما منعطف هستیم و هم مشارکت زودهنگام را تشویق میکنیم و هم از مشورت در زمان پیادهسازی استقبال میکنیم.
پرداختن به یکپارچگی مفهومی: Kubernetes تقریباً همهجا از APIها استفاده میکند، بنابراین API Governance برای حفظ این یکپارچگی ضروری است. چگونه این یکپارچگی ثبت و تضمین میشود؟
JL: ما در سند قراردادها الگوها و راهحلهایی که در طول زمان یاد گرفتهایم را مطرح میکنیم: در موقعیتهای مشخص چه باید انجام شود. علاوه بر اسناد، ابزارهای خودکار مانند linters، checks و تستهای خودکار داریم که الگوها را تضمین میکنند و خطاها را حتی وقتی انسانها از آنها غافل میشوند، مییابند. هر بار که سناریوی جدیدی ظاهر میشود، بازخوردها را جمع میکنیم، رویکرد مناسب را تعیین میکنیم و آن را در اسناد و ابزارها منعکس میکنیم. گاهی لازم است چند تلاش کنیم تا به رویکردی برسیم که هم مقبول و هم پایدار باشد.
پرسش: نقطه عطف یا چالش قابلتوجهی که تجربهتان نشان میدهد چه بوده است؟
JL: یکی از لحظات مهم ورود CRDها (CustomResourceDefinitions) بود. قبل از CRD، تقریباً تمام APIها توسط تیمهای core ساخته و کاملاً بررسی میشدند؛ ما نوعها و زمینهها را درک و کنترل میکردیم. با CRDها، هر کسی میتوانست هر چیزی را تعریف کند—نسخههای اولیه حتی طرحواره (schema) هم لازم نداشتند—و این آزادی بلافاصله تغییر را تسریع کرد، اما همچنین چالشهای پایداری بزرگی ایجاد کرد. بعد که CRDها به GA رسیدند، schema اجباری شد اما برای سازگاری با نسخههای قبلی escapeهایی وجود داشت. در چند نسخه اخیر، قابلیتهای اعتبارسنجی داخلی برای CRDها (validation) به تدریج به GA رسیدند؛ این دومین نقطه عطف بزرگ بود: بازگرداندن ثبات. حالا با رویکردی مثل validation ratcheting میتوانیم به نویسندگان CRD کمک کنیم قراردادهایی تعریف کنند بدون اینکه اشیاء موجود را بشکنند — یعنی اجازه میدهیم قواعد جدید اضافه شوند اما طوری که سازگاری عقبرو حفظ شود.
سؤال: API Governance چطور با SIG Architecture و API Machinery تعامل میکند؟
JL: SIG Architecture جهت کلی سیستم را تعیین میکند و با API Machinery همکاری میکند تا اطمینان حاصل شود جهت تعیینشده توسط سیستم پشتیبانی میشود. API Governance هم با سایر SIGها تعامل میکند تا قراردادها و الگوها را تعریف کرده و استفاده مداوم از امکاناتی که API Machinery فراهم میکند را تضمین نماید. به عبارت دیگر، Architecture چارچوب و سیاستگذاری را میسازد، API Machinery امکانات فنی را فراهم میکند، و API Governance ایندو را در عمل به هم پیوند میدهد تا تجربهای یکپارچه و قابلاعتماد برای کاربران و اپراتورها ایجاد شود.
پرسش: آیا مراحل انتشار مثل feature freeze یا code freeze حجم کاری شما را تغییر میدهد؟
JL: ما معمولاً در دو زمان اصلی فعالتر میشویم: طراحی و پیادهسازی. مشارکت طراحی قبل از freezeهای پیشرفت افزایش مییابد، و مشارکت پیادهسازی هم قبل از code freeze بالا میرود. اما بسیاری از تلاشها چند نسخه را در بر میگیرند، بنابراین همیشه ترکیبی از طراحی و پیادهسازی در جریان است. یک ضدالگوی شایع این است که تیمها ماهها روی یک ویژگی فکر میکنند و آن را چند هفته قبل از freeze ارائه میدهند و ناگهان از ما میخواهند که همه آن را در مدت کوتاهی مرور کنیم — این کار، کیفیت را سخت میکند. برای تغییرات بزرگ با اثرات API، بهترین زمان درگیری زودهنگام است؛ در بین دورههای شدید ریلیز وقتی مردم پهنای باند دارند، کار بررسی بلندمدت بهتر انجام میشود.
پرسش: چگونه میتوان در مدیریت API مشارکت کرد؟ فعالیت آغازین چه باید باشد؟
JL: بهترین روش این است که از یک تغییر مشخص و کوچک شروع کنید و فرآیند کامل را دنبال کنید: طراحی، پیادهسازی، review. دنبال کردن یک change از ابتدا تا انتها بسیار آموزنده است. مشارکت در جلسات بررسی زنده (ویدیو یا صوتی) معمولاً بازخورد بهتر و سریعتری میدهد؛ اگر تغییری را دنبال میکنید یا دارید توسعه میدهید، از برگزارکننده بپرسید آیا زمانی برای review زنده هست یا خیر و در آن جلسه شرکت کنید. بعد از چند تغییر کوچک میتوانید به تغییرات بزرگتر و نهایتاً APIهای جدید برسید و درک عملی از قراردادها و الگوها شکل میگیرد. بهطور عملی: مستندات قراردادها را بخوانید، KEPها و PRهای مرتبط را دنبال کنید، در بحثهای API Review شرکت کنید و کمکم نقش فعالتری بگیرید.
آخرین نکات و جمعبندی:
JL: دلیل اینکه ما روی سازگاری و ثبات تاکید میکنیم این است که کاربران به این ثبات وابستهاند. برای مشارکتکنندگان طبیعی است که الزامات را بهعنوان مانع ببینند؛ اما سیستمهای ما با محیطهای کاربران یکپارچه شدهاند و ما به آنها قول دادهایم که قراردادها را زیر پا نگذاریم. بنابراین حتی اگر نیاز به کار اضافی، حرکت آهستهتر یا تکرار باشد، ما ترجیح میدهیم ثبات را انتخاب کنیم. سوال محوری که همیشه میپرسیم این است: شما میخواهید کاری را حالا انجام دهید — چگونه میتوانیم طوری طراحی کنیم که بعداً بتوان آن را بدون شکستن سازگاری تکامل داد؟ همچنین فرض میکنیم اشتباه خواهیم کرد؛ پس چطور مکانیزمهایی برای اصلاح و بهبود قرار دهیم در حالی که قولهای سازگاری را نگه داشتهایم؟ این دیدگاه است که همه تصمیمات ما را هدایت میکند 🤝.
ممنون از Jordan برای زمان و توضیحات شفاف — امیدوارم این گفتوگو به تیمها و مهندسان DevOps/SRE کمک کند بهتر درک کنند چرا و چگونه API Governance در Kubernetes اثرگذار است 🛠️.
