باز کردن بسته مدیریت ای‌پی‌آی (Unbundling API Management)
«باز کردن بسته» اصطلاحی است که طی چند سال گذشته در صنعت مدیریت API بسیار رایج شده است. اما واقعاً باز کردن بسته چیست؟ چه بسته‌هایی در حال باز شدن هستند؟ این موضوع اصلاً از کجا آغاز شد؟
در ادامه به باز کردن بسته در مدیریت API می‌پردازیم. ابتدا بررسی می‌کنیم چه عواملی به ایجاد پلتفرم‌های جامع مدیریت API منجر شد و سپس تحلیل می‌کنیم که آیا و چه زمانی سازمان‌ها باید بسته‌ها را باز کنند یا از ابزارهای متناسب با نیاز برای مدیریت API استفاده کنند.
مدیریت API و پارادایم مونو‌لیتی
برای درک اینکه باز کردن بسته دقیقاً چیست، باید ابتدا درباره مدیریت API صحبت کنیم. مدیریت API اصطلاحی جامع برای سرویس‌ها و سیستم‌هایی است که به مدیریت چرخه عمر و نگهداری یک محصول API کمک می‌کنند. این فرآیند معمولاً از مراحل اولیه آغاز شده و تا زمان توقف یا تبدیل آن API به محصولی جدید ادامه می‌یابد.
در حالی که این سرویس‌ها بسیار مفید هستند، در طول زمان به مسئله‌ای پیچیده تبدیل شدند. برای ارائه‌دهندگان، خیلی زود مشخص شد که مدیریت API در صورت اجرای صحیح، می‌تواند منبع سودآوری چشمگیری باشد. همان‌طور که فروشگاه‌های بزرگ با ترکیب بخش‌های مختلف به موفقیت رسیدند، ارائه‌دهندگان مدیریت API نیز با ترکیب ابزارهای گوناگون در یک سرویس واحد، به موفقیتی مشابه دست یافتند. برای توسعه‌دهندگان API نیز این ایده جذاب بود؛ چرا زمان صرف بررسی رقبا و ابزارهای مختلف کنند وقتی می‌توانستند فقط یک اشتراک را خریداری کنند؟
این نقطه آغاز پیدایش بسته‌های مدیریت API بود. ارائه‌دهندگان مدیریت API از این رویکرد سود زیادی به دست آوردند و توسعه‌دهندگان API نیز از یک راهکار ساده برای رسیدن به قابلیت‌های پایه بهره‌مند شدند.
مجموعه‌ای از مسائل
با این حال این رویکرد بدون مشکل نبود. ارائه‌دهندگان مدیریت API الزاماً انگیزه‌ای برای ایجاد بهترین نسخه از هر قابلیت نداشتند. این موضوع به‌مرور باعث ایستایی ابزارها از نگاه برخی توسعه‌دهندگان شد. از طرف دیگر، استفاده از راهکارهای بسته، هرچند ساده، اما توسعه‌دهندگان را به قراردادهای چندساله یا فرآیندهای پیچیده یکپارچه‌سازی مقید می‌کرد.
این بدین معنی نیست که بسته‌ها کاملاً بد بودند؛ صرفاً آن بهشتِ بی‌نقصی نبودند که وعده‌اش داده شده بود. این بسته‌ها یا راهکاری «به اندازه کافی خوب» برای نیازهای معمول ارائه می‌کردند یا توسعه‌دهندگان را به ابزاری قفل‌شده و ناکارآمد محدود می‌ساختند.
در بسیاری از موارد، مزیت‌های ادعاشده این پلتفرم‌های یکپارچه در عمل توسط ماهیت مونو‌لیتی آن‌ها خنثی می‌شد. طراحی ابزارهای چندمنظوره منجر به کاهش بهینه‌سازی برای کاربردهای خاص می‌شد و این موضوع هزینه را افزایش می‌داد. درحالی‌که توسعه‌دهندگان انتظار داشتند استفاده از یک ابزار جامع زمان و هزینه را کاهش دهد، نیاز به ابزارهای سفارشی، هزینه بیشتری ایجاد می‌کرد.
باز کردن بسته API چیست؟
باز کردن بسته در واقع جایگزینی برای این رویکرد است. به‌جای وابستگی به یک پلتفرم جامع مدیریت API، باز کردن بسته یعنی استفاده از بهترین ابزارهای هر حوزه به صورت انتخابی و جداگانه. این رویکرد آزادی عمل، کنترل هزینه و بهره‌وری بالاتری فراهم می‌کند.
کین لین، مروج API، اشاره می‌کند که باز کردن بسته بیشتر نتیجه واکنش بازاریابی است تا خواسته ذاتی مصرف‌کنندگان:
«من به‌عنوان مصرف‌کننده، روزم را با فکر کردن به اینکه چه چیزهایی را می‌خواهم باز کنم شروع نمی‌کنم. من تنها چیزهایی را که نیاز دارم تهیه می‌کنم… نمی‌خواهم همه منابع مورد نیازم برای پلتفرم API را از یک ارائه‌دهنده بگیرم، همان‌طور که نمی‌خواهم همه منابع لازم برای وب و موبایل را از یک ارائه‌دهنده دریافت کنم.»
اریک واید نیز این دیدگاه را تأیید کرده و می‌گوید بسته‌ها هرچند انتخاب را ساده‌تر می‌کنند، اما اغلب محدودکننده هستند، به‌ویژه زمانی که راهکارهای قدیمی و غیرقابل اتصال مورد استفاده قرار می‌گیرند:
«برای اینکه ارائه‌دهندگان API بیشترین بهره را ببرند، نباید خودمان را در گوشه‌ای گیر بیندازیم. نکته: همیشه در POCها چند ابزار مختلف را تست کنید تا ببینید واقعاً چقدر باز هستند.»
چه زمانی مدیریت کامل چرخه عمر API منطقی است؟
این بدین معنی نیست که راهکارهای بسته هیچ‌وقت مناسب نیستند. برخی شرایط وجود دارند که پلتفرم‌های جامع بهترین گزینه‌اند.
برای برخی APIها نسخه ۱ همان نسخه نهایی است. در چنین مواردی استفاده از ابزاری که «به اندازه کافی خوب» است، منطقی به نظر می‌رسد. این موضوع به‌ویژه درباره APIهای کوچک با نیازهای متعدد صدق می‌کند.
در برخی موارد محدودیت منابع باعث می‌شود استفاده از بسته، مناسب‌ترین راهکار باشد. تیم‌های کوچک که با APIهای پیچیده کار می‌کنند ممکن است وقت کافی برای بررسی ابزارهای تخصصی نداشته باشند. هرچند این رویکرد در آینده ممکن است مشکل‌ساز شود، اما گاهی سرمایه لازم برای انتخاب ابزارهای بهتر در دسترس نیست.
چه زمانی باز کردن بسته منطقی است؟
با این وجود، باز کردن بسته در اکثر سناریوها انتخابی برتر است. به‌ویژه برای APIهایی که به یک ابزار خاص نیاز دارند. بسیاری از تیم‌ها واقعاً نیازی به کل قابلیت‌های یک پلتفرم ندارند. انتخاب ابزار جداگانه برای حل یک مشکل، بهترین و به‌صرفه‌ترین مسیر است.
کریستین پُستا این موضوع را «پرهیز از ایجاد یک سیلوی جدید» می‌نامد. یک پلتفرم جامع توسعه‌دهنده را به یک استک واحد مقید می‌کند و او مجبور می‌شود در محدودیت‌های آن استک کار کند نه بر اساس نیاز واقعی کسب‌وکار.
همچنین APIهای دارای الزامات صنعتی خاص اغلب نمی‌توانند از پلتفرم‌های یکپارچه استفاده کنند. اگر تنها ۵۰٪ یک پلتفرم قابل استفاده است، منطقی است که فقط همان ابزارهای مورد نیاز را انتخاب کنید.
استارتاپ‌ها اغلب راحت‌تر می‌توانند به سمت ابزارهای جداگانه بروند، اما سازمان‌های بزرگ به دلیل فرآیندها و ساختارهای پیچیده، ممکن است به‌سختی از پلتفرم‌های بسته فاصله بگیرند.
آیا موضوع همه یا هیچ است؟
خبر خوب این است که انتخاب بین دو گزینه کاملاً مطلق نیست. بسیاری از ارائه‌دهندگان پلتفرم متوجه این روند شده‌اند و امکان خرید تدریجی و ماژولار را فراهم کرده‌اند.
کُنگ این موضوع را «اصل خرید تدریجی» می‌نامد:
«اصل خرید تدریجی کُنگ به سازمان‌ها امکان می‌دهد با آنچه نیاز دارند شروع کنند و سپس ابزارهای خود را به‌تدریج گسترش دهند… هدف ارائه مجموعه‌ای از قابلیت‌های بهترین در نوع خود است که نیازهای مختلف چرخه عمر API را پوشش می‌دهند.»
راهکارهایی مانند Gravitee نیز امکان اتصال APIها را بدون توجه به پلتفرم و معماری فراهم کرده‌اند و محدودیت‌های پلتفرم‌های مونو‌لیتی را کاهش داده‌اند.
نتیجه‌گیری
باز کردن بسته فقط یک روند زودگذر نیست؛ بلکه بازنگری اساسی در نحوه استفاده بهتر از منابع در اقتصاد API است. هرچند پلتفرم‌های جامع مزایای زیادی دارند، بسیاری از سازمان‌ها متوجه شده‌اند که محدودیت‌ها و قفل‌شدگی ناشی از این پلتفرم‌ها می‌تواند آسیب‌زننده باشد. حرکت به سمت ابزارهای تخصصی و بهترین در نوع خود، گام بعدی نوآوری در بازار API است و آزادی و چابکی بیشتری ارائه می‌دهد.
