نحوهٔ برخورد سازمان‌ها با دروازه‌ها (gateways) و پلتفرم‌های مدیریت در طول سال‌ها تغییر کرده است و در برخی موارد، حتی بسیار چشمگیر. برای یکپارچه‌سازی سیستم‌ها و چارچوب‌هایی که اغلب در یک سازمان پراکنده و ناهمگون هستند، برخی به مفهومی به نام مدیریت API فدرال‌شده روی آورده‌اند.
آخرین گزارش Postman State of the API نشان داد که یک‌سوم از ناشران API از چندین دروازه استفاده می‌کنند. مدیریت API فدرال‌شده برای یکپارچه‌سازی این دروازه‌ها پدید آمده است تا APIها متمرکزتر، قابل مشاهده‌تر و دارای حاکمیت بیشتر شوند، در حالی که همچنان انعطاف‌پذیری لازم را برای تیم‌های مستقل فراهم می‌کنند.
امروز قصد داریم این رویکرد را بررسی کنیم، همچنین رویکردهای دیگری را که با آن رقابت می‌کنند. خواهیم دید چرا مدیریت API فدرال‌شده جذاب است و چند بهترین روش را ارائه می‌کنیم تا همین امروز بتوانید کار با این رویکرد را آغاز کنید!
مشکل مدیریت پلتفرم API
مشکل مدیریت پلتفرم API این است که یک پلتفرم الزاماً یک موجودیت واحد است که باید برای مجموعهٔ گسترده‌ای از موارد استفاده و استقرارها مناسب باشد. همیشه چالشی دائمی بین پشتیبانی از چرخه‌های توسعه و نیازهای متنوع و در عین حال حفظ میزان مشخصی از کنترل، یک چارچوب باکیفیت و یک مرکز سازمانی برای مدیریت سیستم وجود دارد.
برای حل این مسئله، سازمان‌ها رویکردهای مختلفی اتخاذ کرده‌اند که هرکدام نقاط قوت و ضعف خود را دارند. این رویکردها با تمرکز بر ویژگی‌هایی که نیاز به تقویت دارند توجیه می‌شوند، اما در بسیاری از موارد، تفاوت‌ها منجر به افزایش سردرگمی و پیچیدگی شده‌اند.
مدل متمرکز
در این مدل، پلتفرم به‌صورت متمرکز توسط تیمی کنترل می‌شود که کار اصلی‌اش مدیریت و نگهداری پلتفرم است. اغلب از آن به‌عنوان مدل سازمانی نام برده می‌شود، زیرا مدل سنتی سازمان‌های بزرگ است. یک مخزن کنترل مرکزی به‌صورت یک سرویس مشترک ارائه می‌شود و هر تغییری در این سرویس مشترک باید تأیید و مدیریت شود.
این رویکرد مزایای مهمی دارد اما عمدتاً بر حاکمیت، امنیت و انطباق تمرکز دارد. متمرکز بودن همه‌چیز باعث می‌شود کنترل و اعمال استانداردها بسیار آسان‌تر باشد و کاهش افزونگی‌ها یا عملکردهای جداگانه، این روند را روان‌تر می‌کند.
البته، یک مدل کاملاً متمرکز کنترل را از تیم‌های کوچک‌تر می‌گیرد. وقتی همه‌چیز متمرکز است، استقلال بسیار محدودی وجود دارد، که حتی تصمیمات کوچک API را وارد چرخهٔ طولانی تأیید، بررسی، پیاده‌سازی و ممیزی می‌کند. این سرعت را به‌شدت کاهش می‌دهد و به‌طور طنزآمیز، اغلب منجر به دور زدن کنترل مرکزی برای انجام وظایف ساده می‌شود.
مدل سلف‌سرویس API
مدل سلف‌سرویس حرکتی دور از کنترل متمرکز بر اساس ایدهٔ یک جریان کاربر غیرمتمرکز است. این رویکرد به تیم‌ها یا توسعه‌دهندگان اجازه می‌دهد APIهای خود را با حداقل نظارت از سوی یک نهاد مرکزی مدیریت کنند. با استفاده از قالب‌ها و مستندات، بدنهٔ مرکزی می‌تواند راهنمایی ارائه دهد، اما در نهایت تنها یک راهنماست — نه کنترل‌کننده.
این رویکرد مزایای بزرگی برای تیم‌های کوچک دارد. این روش بسیار سبک است و انجام کار را سریع و مقیاس‌پذیری را آسان می‌کند. اغلب باعث افزایش سرعت و انعطاف‌پذیری بیشتر برای نوآوری و تکرار می‌شود.
اما این فرآیند معایب مهمی دارد. در حالی که موانع مدل متمرکز را حذف می‌کند، در مقیاس، نبود ثبات و حاکمیت را وارد سیستم می‌کند. این مسئله می‌تواند منجر به نقص‌های امنیتی، آسیب‌پذیری‌ها و نبود الگوهای باثبات برای مصرف و توسعهٔ API شود.
از سوی دیگر، تکثیر تلاش‌ها و ابزارها یک مشکل بزرگ است. وقتی سازمان کنترل متمرکز ندارد، ابزارها، منابع، سرورها و کارکنان مضاعف می‌شوند. منابع IT سایه‌وار نتایج رایج این مدل هستند، و استفاده از ابزارهای مختلف برای همان کار نیز بسیار رایج است، به‌ویژه وقتی تیم‌ها یک شاخص را برای اهداف متفاوت دنبال می‌کنند.
پلتفرم به‌عنوان محصول
برای ایجاد یک راه‌حل ترکیبی، مدل پلتفرم به‌عنوان محصول (PaaP) به‌عنوان یک راهکار مکمل توسعه یافته است. این مدل فرآیند مدیریت API را به‌عنوان یک محصول در نظر می‌گیرد، با این هدف که تیم API دستورالعمل‌ها، مستندات و پشتیبانی لازم را برای تیم‌های دیگر ارائه دهد تا از پلتفرم استفاده کنند. این موضوع منجر به دیدگاه‌های تحول‌آفرین دربارهٔ پلتفرم می‌شود، کاربران داخلی را به نوعی مشتری تبدیل می‌کند و اولویت را بر سهولت استفاده می‌گذارد، در حالی که استانداردسازی در حاکمیت و امنیت ادامه می‌یابد.
این مدل مزایای مهمی دارد، مانند اعطای استقلال همراه با میزان مشخصی از کنترل. این رویکرد اجازه می‌دهد سیاست‌های حاکمیتی تعیین شود و در عین حال نوآوری و تکرار روی پلتفرم مرکزی امکان‌پذیر باقی بماند.
اما این رویکرد نیز هزینه‌هایی دارد و این هزینه‌ها قابل توجه‌اند. تبدیل پلتفرم داخلی به یک محصول به معنای سرمایه‌گذاری سنگین، تیم پشتیبانی بزرگ، و ایجاد الزاماتی مانند بازاریابی داخلی و آموزش است چیزهایی که در دیگر مدل‌ها وجود ندارند.
گزینهٔ دیگر: مدیریت API فدرال‌شده
در مواجهه با این انتخاب‌ها، یک پارادایم جدید با عنوان مدیریت API فدرال‌شده پدید آمده است. این رویکرد بهترین ویژگی‌های مدل‌های قبلی را اقتباس می‌کند و سعی دارد به تیم‌ها همان‌جا که هستند پاسخ دهد و ابزارهای لازم برای توسعه و تکرار را فراهم کند.
Salesforce مدیریت API فدرال‌شده را این‌گونه تعریف می‌کند:
«فدراسیون API مجموعه‌ای از اصول طراحی، ابزارها و زیرساخت‌هاست که امکان افشا کردن مجموعه‌ای از سرویس‌ها و جریان‌های رویداد در یک بستر محدود را به‌عنوان یک API واحد و منسجم برای مشتریان خارجی فراهم می‌کند، در حالی که اجازه می‌دهد سرویس‌های مستقل داخل این بستر بدون محدودیت تکاملی تغییر کنند.»
مدیریت API فدرال‌شده یک رویکرد نیمه‌غیرمتمرکز است که در آن APIها توسط تیم‌ها و بخش‌های داخل سازمان مدیریت می‌شوند. این مدیریت شبیه مدل متمرکز است، اما قدرت بین تیم‌هایی تقسیم می‌شود که واقعاً از محصول استفاده می‌کنند. به‌عبارت دیگر، به‌جای متمرکز کردن همهٔ قدرت در یک مرجع واحد، تیم‌ها خودمختار می‌شوند و اختیار مدیریت API خود را دریافت می‌کنند.
در نهایت، این رویکرد تیم‌هایی عمدتاً خودمختار ایجاد می‌کند که همچنان در سطح مرکزی همسو هستند. تیم‌های مختلف مانند توسعه، امنیت یا مانیتورینگ می‌توانند پلتفرم و ابزارهای خود را مدیریت کنند، مشروط به اینکه با یک پارادایم مرکزی هم‌راستا باشند.
مزایای مدیریت API فدرال‌شده
-
خودمختاری غیرمتمرکز: هر تیم می‌تواند API خود را مستقل مدیریت کند و حاکمیتی اعمال کند که متناسب با نیازهای واقعی و محیط کاری آن باشد.
-
حاکمیت جهانی: سیاست‌ها در سطح سازمانی مشخص می‌شوند اما در سطح تیمی اعمال می‌شوند، که تعادل بین استقلال و استانداردسازی ایجاد می‌کند.
-
بسیار مشارکتی: تیم‌ها باید همکاری کنند، بهترین روش‌ها را به اشتراک بگذارند و حاکمیت داده را هماهنگ کنند. انعطاف‌پذیری به‌جای سخت‌گیری در این مدل ذاتی است.
معایب مدیریت API فدرال‌شده
-
پیچیدگی و ناهماهنگی: به‌دلیل توزیع اختیار، احتمال بروز تفاوت‌های زیاد و پیچیدگی بالا وجود دارد.
-
نیاز به هماهنگی زیاد: برای جلوگیری از اصطکاک، نیاز به همکاری سنگین بین تیم‌ها ضروری است.
چگونه مدیریت API فدرال‌شده را پیاده‌سازی کنیم؟
۱. ایجاد دروازهٔ مرکزی
ابتدا باید یک دروازهٔ API مرکزی، سیستم مانیتورینگ، لاگ‌گیری و… ایجاد کنید.
سپس کنترل دسترسی توزیع‌شده تعریف کنید تا هر تیم بتواند بخش مرتبط با خود را مدیریت کند.
۲. تنظیم حاکمیت API
سیاست‌های طراحی، امنیت، نسخه‌بندی، قالب داده، دسترسی و احراز هویت را تنظیم و مستندسازی کنید.
۳. پیاده‌سازی غیرمتمرکزسازی
پورتال‌های توسعه‌دهندهٔ غیرمتمرکز ایجاد کنید تا تیم‌ها بتوانند APIهای خود را منتشر کنند.
سیستم احراز هویت و مجوزگذاری توزیع‌شده ضروری است.
۴. ارائهٔ کنترل‌ها و دیدپذیری
ابزارهای مانیتورینگ مشترک، داشبوردهای مرکزی و تجمیع داده را اضافه کنید.
۵. مستندسازی و اشتراک دانش
برای جلوگیری از سیلو شدن تیم‌ها، باید فرهنگ مستندسازی و اشتراک اطلاعات را تقویت کنید.
نتیجه‌گیری
مدیریت API فدرال‌شده یک رویکرد قدرتمند است که می‌تواند در محیط‌های مختلف کسب‌وکاری کار کند. با برنامه‌ریزی و تفکر آینده‌نگر، این مدل می‌تواند به تیم‌های توانمندتر و حاکمیت مرکزی مؤثرتر در مقیاس منجر شود.
