Привіт, Хабре! Представляю вашій увазі авторський переклад статті .
У часи коли світ IT поступово переходить на мікросервіси та інструменти на кшталт Kubernetes, дедалі помітнішою стає лише одна проблема. Ця проблема - версій мікросервісів Все ж таки IT співтовариство вважає, що сьогоднішня ситуація значно краща, ніж попереднього покоління технологій. Проте управління версіями мікросервісів дуже складна проблема. Одним із доказів цьому можуть бути статті на кшталт .
Якщо ви читаючи цей текст, поки не розумієте проблему, дозвольте мені пояснити. Припустимо, що ваш продукт складається з 10 мікросервісів. Тепер припустимо, що для кожного з цих мікросервісів виходить одна нова версія. Тільки одна версія - сподіваюся, ми всі можемо погодитися, що це дуже тривіальний і незначний факт. Тепер проте поглянемо ще раз на наш продукт. З однією лише новою версією кожного компонента у нас тепер з'явилося 1^1 або 2 пермутацій того, як можна скласти наш продукт.
Якщо ще залишилося нерозуміння, дозвольте мені розкласти математику. Отже, маємо 10 мікросервісів, кожен отримує одне оновлення. Тобто, ми отримуємо дві можливі версії на кожен мікросервіс (або стару, або нову). Тепер, для кожного компонента продукту ми можемо використовувати будь-яку з цих двох версій. Математично, це те саме як би у нас було двійкове число з 2 знаків. Наприклад, скажімо, що 10 — це нова версія, а 1 — стара версія — тоді одна можлива пермутація може бути позначена як 0 — де 1001000000й та 1й компоненти оновлені, а решта ні. З математики ми знаємо, що двійкове число із 4 знаків може мати 10^2 або 10 значень. Тобто ми підтвердили масштаби числа, з якою має справу.
Продовжимо міркування далі — а що станеться, якщо ми матимемо 100 мікросервісів і кожен 10 можливих версій? Уся ситуація стає дуже неприємною — тепер у нас 10^100 пермутацій — а це величезна кількість. Тим не менш, я волію позначити цю ситуацію саме так, тому що тепер ми не ховаємося за словами на кшталт «kubernetes», а зустрічаємо проблему як вона є.
Чому мене так захоплює ця проблема? Почасти тому, що працюючи раніше у світі NLP та AI ми багато обговорювали проблему комбінаторного вибуху десь 5-6 років тому. Тільки замість версій ми мали окремі слова, а замість продуктів ми мали пропозиції та параграфи. І хоча проблеми NLP та AI залишаються великою мірою так і невирішеними, треба визнати, що за останні кілька років було зроблено суттєвий прогрес. (На мій погляд, прогрес міг би бути бобільшим, якби люди в галузі трохи менше уваги приділяли машинному навчанню і трохи більше іншим технікам — але це вже офф-топік).
Повернуся до світу DevOps та мікросервісів. Перед нами стоїть величезна проблема, що маскується як слон у Кунсткамері – адже що я часто чую – «просто візьми kubernetes та helm, і все буде добре!» Але ні, все не буде добре, якщо все залишити як є. Більше того, аналітичне вирішення цієї проблеми не є прийнятним через складність. Як і в NLP, нам слід спочатку підійти до цієї проблеми шляхом звуження області пошуку - у цьому випадку за рахунок виключення застарілих пермутацій.
Одна з речей, яка може допомогти — я писав минулого року . Також важливо відзначити, що добре опрацьований процес CI/CD дуже допомагає у скороченні варіацій. Однак, сьогоднішній стан справ з CI/CD недостатньо добре для вирішення проблеми пермутацій без додаткового інструментарію обліку та відстеження компонентів.
Що нам потрібно – це система експериментів на стадії інтеграції, де ми могли б визначити фактор ризику по кожному компоненту, а також мати автоматизований процес оновлення різних компонентів та тестування без втручання оператора – щоб бачити, що працює, а що ні.
Така система експериментів могла б виглядати так:
- Девелопери пишуть тести (це критичний етап – тому що інакше у нас немає критерію оцінки – це як розмітка даних у машинному навчанні).
- Кожен компонент (проект) отримує свою власну CI систему - цей процес на сьогоднішній день добре опрацьований, і питання створення CI системи для одиничного компонента багато в чому вирішено
- «Розумна система інтеграції» збирає результати різних CI систем та збирає проекти-компоненти у фінальний продукт, запускає тестування та нарешті обчислює найбільш короткий шлях до отримання потрібної функціональності продукту виходячи з існуючих компонентів та факторів ризику. Якщо оновлення неможливо, ця система повідомляє розробників про наявні компоненти і на якому з них відбувається помилка. Ще раз повторю, що система тестів тут має критичну важливість — оскільки система інтеграції використовує тести як критерій оцінки.
- CD система, яка потім отримує дані з «Розумної системи інтеграції» та здійснює безпосередньо оновлення. Ця стадія закінчує цикл.
Підсумовуючи, для мене одна з найбільших проблем зараз — відсутність такої «Розумної системи інтеграції», яка б пов'язувала різні компоненти в продукт і таким чином дозволяла відслідковувати, яким чином продукт загалом складений. Мені будуть цікаві думки спільноти із цього приводу (спойлер — я зараз працюю над проектом , яка може стати такою розумною системою інтеграції).
Одна остання річ, яку я хочу згадати, — для мене моноліт не є прийнятним для будь-якого проекту хоч би середнього розміру. Для мене викликають великий скептицизм спроби прискорити час реалізації та якість розробки за рахунок повернення до моноліту. По-перше, моноліт має схожу проблему управління компонентами — серед різних бібліотек, з яких він складається, проте все це не так помітно і проявляється насамперед у часі, який витрачають розробники. Наслідком проблеми моноліту є фактична неможливість вносити зміни до коду — і вкрай повільна швидкість розробки.
Мікросервіси покращують ситуацію, проте згодом мікросервісна архітектура стикається з проблемою комбінаторного вибуху на стадії інтеграції. Так, загалом ми пересунули ту саму проблему — зі стадії розробки на стадію інтеграції. Однак, на мій погляд, підхід мікросервісів все ж таки призводить до кращих результатів, і команди досягають результатів швидше (ймовірно, в основному через зменшення розмірів одиниці розробки — або розмір партії). Однак, перехід від моноліту до мікросервісів поки не дав достатнього покращення процесу — комбінаторний вибух версій мікросервісів — це величезна проблема, і ми маємо великий потенціал покращення ситуації в міру її вирішення.
Джерело: habr.com