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

بگذارید یک مثال از دنیای واقعی بزنم؛ در شرکتی که من در آن کار میکنم، هر کدام از سرویس‌ها API‌هایشان را در قالب ابزاری به نام swagger منتشر میکنند. Swagger ابزاریست که تحت وب بالا می‌آید و schemaی API‌ها را نشان میدهد و به شما این اجازه را میدهد که از همان جا آن‌ها را فراخوانی کنید. با گذر زمان، تعداد میکروسرویس‌ها در سازمان ما بیشتر شد و به تبع از آن تعداد پنل‌های Swagger برای هر کدام از این اپلیکیشن‌ها هم بیشتر شد و شما می‌بایست که آدرس Swagger همه این سرویس‌ها را حفظ میبودی یا از توسعه دهندگان آن میپرسیدی و مشکل اصلی زمانی بود که تو حتی نمیدانستی که توسعه دهنده‌ی سرویس مد نظر تو چه کسی یا چه تیمی‌ست.

همانطور که در این مثال مشاهده میشود، حلقه‌ی مفقوده در این داستان، عدم وجود بستر مناسب برای انتقال دانش بین تیم‌هاست.

بنابراین چه اتفاقی افتاد؟ یکی از برنامه نویسان خلاق در سازمان اقدام کرد به تولید یک پنل ساده‌ی htmlی که در آن آدرس Swagger همه سرویس‌ها وجود داشت.

اجازه بدهید یک نیازمندی دیگر را مطرح کنم، فرض کنید که یکی از سرویس‌هایتان دچار اشکال شده است، میدانید که این سرویس با چند سرویس دیگر در ارتباط است و نیاز دارید که ببینید این سرویس‌ها که توسط دیگر تیم‌ها توسعه داده‌ میشوند به تازگی دچار تغییری شده است یا خیر. یا تصور کنید که دوست دارید که داکیومنت‌های مربوط به سرویس خودتان یا دیگر سرویس‌ها را در یک جا به طور مجتمع ببینید.

همه این ها باعث میشود که در طول روز مجبور باشید در هزاران پنل لاگین کنید و هزاران اطلاعات مختلف را برای پیشبرد یک مسئله از ابزار‌های مختلف جمع‌آوری کنید. ضمنا همه این ها به شرطی هست که شما دسترسی لازم برای این موضوع را هم داشته باشید.

فرض کنید که یک پنلی وجود داشت که همه این اطلاعات را در خود جا داده بود. زندگی چه قدر ساده‌تر میشد؟ بک‌استیج دقیقا برای همین موضوع به وجود آمده است.

بک استیج چیست؟

و اما بک‌استیج چیست؟ دقیقا بک استیج یک سلوشن برای مسئله‌ی ذکر شده‌ی بالاست. توسعه دهندگان اسپاتیفای هم مثل ما دچار مشکلات بالا بودند و به واسطه‌ی همین، نیازمند این موضوع بودند که به اصطلاح خودشان یک developer portal داشته باشند که بتواند به تسریع و تسهیل انتقال دانش کمک بکند. به همین علت Backstage را توسعه دادند و وقتی که دیدند از نظر تکنولوژی همچین چیز عجیب غریبی هم نیست، اما بسیار گره گشاست تصمیم گرفتند آن را اوپن سورس کنند و یک باری را از روی دوش برنامه نویسان دیگر شرکت‌ها نیز بردارند.

بنابراین بک استیج یک ابزار مبتنی بر خوداظهاری است، (یعنی خود توسعه دهندگان کمک میکنند که این ابزار غنی از اطلاعات شود) که کمی هم اتومیشن به خرج داده است.

اگر بخواهم دقیق‌تر بگویم شما در بک استیج با کمک یک فایل yaml سرویس خود را تعریف میکنید، ای پی آی ها آن را نیز مشخص میکنید، لینک‌های مرتبط با سرویس خود را به اشتراک میگذارید، دیپندنسی‌های سرویست را مشخص میکنید (و هزاران کار دیگر از این دست) و بک استیج مسئولیت نمایش، دسته‌بندی، به روز‌رسانی داده‌های تغییر کرده و… را به عهده میگیرد.

در تصویر زیر نمونه‌ای از لیست سرویس‌ها در بک‌استیج را مشاهده میکنید:

برای هر کدام از سرویس‌ها میتوان اطلاعاتی نظیر وابستگی‌ها به سایر سرویس‌ها، لیست لینک‌ها مهم داکیومنت‌ها و مرج‌ریکوئست‌ها، زبان برنامه نویسی و هر آن چه بخواهیم را نمایش بدهیم
در تصویر زیر نمونه‌ی اطلاعات یک سرویس را به حداقلی‌ترین شکل ممکن(!) میبینید

یکی از اصلی‌ترین ویژگی‌های بک‌استیج این است که شما میتوانید پلاگین‌های متنوعی را روی آن نصب کنید و اطلاعات مربوط به هر کدام از سرویس‌ها را در بک‌استیج غنی‌تر کنیم. به عنوان مثال تصویر زیر نمونه‌ای از پلاگین گیت‌لب است که اطلاعات مربوط به یکی از سرویس‌ها را نمایش میدهد

و اما اگر بخواهم آخر صحبت‌هام رو به اول صحبت‌هام وصل کنم، اگر یادتون بیاد در مورد اشتراک گذاری api ها در قالب swagger صحبت کرده بودم، در backstage برای هر سرویس میتوانید api تعریف کنید، تصویر زیر نمونه‌ای از api تعریف شده در یکی از سرویس‌هاست.

جمع‌بندی

به طور کلی اگر در سازمانتون همه چیز مرتب است و دارید با خوشحالی زندگی میکنید اما وجود تب‌های متعدد در مرورگرتان، آتنتیکیشن‌های فراوان هر روزه و چیزهایی از این قبیل توسعه دهندگانتان را آزار میدهد؛ یا اگر انتقال اطلاعات بین توسعه‌دهندگان سخت شده است و دنبال ابزاری هستید که همه چیز را در یک پنل مشترک، مستند کنید، backstage میتواند به کمک شما بیاید.