Альтернативи Backstage

Backstage не є ідеальним вибором для кожної компанії, і не кожна інженерна організація потребує Backstage. Це може здатися дивним, особливо для компанії, яка розробляє на основі Backstage, але це правда. Хоча Backstage є потужним інструментом для вирішення проблем досвіду розробників на великих масштабах, він не завжди підходить для кожної організації, принаймні не одразу, а в деяких випадках і зовсім.

Чи ви стартап, який намагається знайти відповідність продукту і ринку, чи команда з простим і сучасним технічним стеком, бувають моменти, коли Backstage здається більше, ніж вам потрібно. Тут ми розглянемо три сценарії, коли Backstage може не бути найкращим вибором і що можна розглянути як альтернативу.

1. Ви занадто малі, щоб потребувати IDP

Backstage — і Внутрішні розробницькі портали (IDP) загалом — особливо корисні, коли команди стають достатньо великими, щоб комунікація та координація почали давати збої. Для малих команд ці проблеми ще не існують.

Ефект числа Данбара

Робін Данбар теоретизував, що люди можуть підтримувати стабільні стосунки лише з близько 150 людьми — тому й виникло Число Данбара. У робочому контексті менші команди (особливо до 50 осіб) зазвичай працюють з високим рівнем довіри, спільного знання та неформальної відповідальності. Кожен знає кожного, кожен знає, хто чим володіє, документація живе в головах людей, а пошук сервісів не є проблемою.

Переломні точки росту

Однак, коли розмір команди переходить критичні пороги, ці динаміки починають змінюватися:

• При ~50 інженерах: Поширення сервісів стає складним для управління. Неформальні системи власності починають ламатися, а племінні знання стають вузьким місцем для нових співробітників. З'являється більше команд, а їхні робочі процеси і фокус стають більш спеціалізованими.
• При ~100 інженерах: Процес введення в курс справи нових співробітників значно сповільнюється, оскільки новачки більше не можуть покладатися на органічний обмін знаннями. Інструменти та мікросервіси поширюються, що ускладнює видимість власності та здоров’я сервісів.
• Понад 150 інженерів: Сервіси важко знаходити, власність непрозора, а комунікаційні збої починаються без належного інструменту. Стандартизація та можливість пошуку стають пріоритетом.

Альтернативи Backstage для малих команд

Для менших команд вам не потрібен нічого складного для управління документацією та пошуком сервісів. Інструменти, як-от GitHub Wiki або файли README.md у ваших репозиторіях, відмінно підходять для відстеження процесів і деталей сервісів. Якщо вам потрібно трохи більше структури, проста Google Таблиця або Airtable можуть служити легким каталогом сервісів, де можна відслідковувати імена сервісів, власників і ключові деталі. Ці низькозатратні рішення чудово вписуються в існуючі робочі процеси і цілком достатні, поки ваша команда не виросте і все не стане трохи складніше.

Для команд, що не досягли цих порогів, інвестиції в IDP можуть здатися надмірними. Але коли ви наближаєтесь до цих критичних точок, потреба в такій платформі, як Backstage, стає очевидною.

2. Ви надаєте перевагу зручності замість налаштування

Однією з найбільших переваг Backstage є його розширюваність.
Це рішення розроблено для адаптації до унікальних потреб інженерних команд, але ця гнучкість має свою ціну: воно вимагає початкових інвестицій та постійного обслуговування.

Коли зручність має пріоритет

Якщо ви надаєте перевагу легкості використання та простоті над можливістю розширення, Backstage може здатися занадто складним. Вам може підійти готове рішення, яке:

• Є "під ключ" і готове до роботи з мінімальним налаштуванням.
• Не потребує значної кастомізації для задоволення ваших потреб.
• Пропонує технічну підтримку як частину пакету.

В обмін на це, такі готові рішення зазвичай прив'язують вас до попередньо визначеного, закритого роадмапу власницького рішення, але це може не бути проблемою, якщо вашою головною метою є зручність.

Простішу альтернативи Backstage

Якщо зручність та простота є вашим пріоритетом, є альтернативи Backstage, такі як Port або Cortex, які пропонують зручність "з коробки" і часто потребують меншого зусилля для впровадження. Однак це має деякі значні недоліки:

• Обмеження закритого коду: Ви прив’язані до роадмапу постачальника і маєте обмежену можливість розширювати платформу.
• Знижена адаптованість: Ці інструменти можуть не еволюціонувати разом з унікальними потребами вашої команди, коли ви будете рости.

Питання, яке варто поставити собі: чи потрібен вам інструмент, достатньо гнучкий, щоб розвиватися разом з вами, чи ви задоволені інструментом, який працює зараз, навіть якщо він менш адаптивний і розширюваний у довгостроковій перспективі?

3. Ваш технічний стек недостатньо складний для потреби в Backstage

Backstage відмінно працює в середовищах з розгалуженими технічними стеками, численними інструментами та складними конвеєрами. Якщо ваш стек сучасний, об'єднаний і відносно простий, ви ще не відчуваєте ті проблеми, для вирішення яких розроблений Backstage.

Чистий лист vs. Спагеті-код

• Чисті, сучасні стеки: Якщо ваш стек побудований на Kubernetes з одним CI/CD конвеєром і мінімумом мікросервісів, ви, можливо, не відчуєте потреби в функціях каталогу сервісів чи технічної документації Backstage.
• Без застарілих систем: Backstage сяє в середовищах із багаторічним технічним боргом — спагеті-кодом, недокументованими сервісами та розірваними інструментами. Якщо ваш стек новий і чистий, таких проблем може не бути.

Альтернативи Backstage для простих стеків

Backstage розроблений для масштабування. Якщо ви не стикаєтеся з швидким ростом чи проблемами зі складністю застарілих систем, простіші інструменти, як GitHub Wiki/Confluence для документації та внутрішній wiki або Google Таблиця для вашого каталогу сервісів можуть бути достатніми для вас. Проте варто подумати про майбутнє:

• Коли ваша команда зростатиме, навіть чистий стек може стати складним для управління.
• Ранні користувачі IDP часто уникають болю від масштабування, який виникає на пізніших етапах.

Backstage може не бути необхідним сьогодні, але коли ваша команда та стек еволюціонують, ви, можливо, знову звернетеся до його переваг.

Коли Backstage підходить для вас?

Рішення щодо впровадження Backstage залежить від розміру вашої команди, пріоритетів та технічного стеку. Для малих команд із простими потребами або для організацій, що цінують зручність більше за налаштування, Backstage може здатися надмірним. Але коли ви ростете — перетинаючи критичні пороги в 50, 100 чи 150 інженерів — або стикаєтесь із проблемами розповсюдження сервісів, племінними знаннями та складністю застарілих систем, внутрішній розробницький портал, як-от Backstage, може стати трансформаційним.

Якщо ви сумніваєтесь, чи підходить Backstage для вашої команди, ми будемо раді допомогти вам.

Перекладено з: Backstage Alternatives