Здається, пік хайпа мікросервісами залишився позаду. Ми вже не читаємо кілька разів на тиждень посади «Як я переніс свій моноліт на 150 сервісів». Тепер я частіше чую розумні думки: «Я не ненавиджу моноліт, я просто дбаю про ефективність». Ми навіть спостерігали кілька міграцій . При переході від одного великого додатка до кількох служб меншого розміру вам доведеться вирішувати кілька нових проблем. Перерахуємо їх дуже коротко.
Установка: від базової хімії до квантової механіки
Налаштування базової БД та додатки з фоновим процесом було досить чітким процесом. Я публікую readme на Github — і часто через одну годину, максимум, кілька годин, все працює, а я починаю новий проект. Додавання та запуск коду принаймні для початкового середовища робиться в перший же день. Але якщо ми наважилися на мікросервіси, час початкового запуску злітає до неба. Так, зараз у нас є Docker з оркеструванням і кластер машин K8, але для програміста-початківця все це на порядок складніше. Для багатьох джуніорів це тягар, який справді є непотрібною складністю.
Систему непросто зрозуміти
На хвилинку зупинимося на нашому джуніорі. З монолітними додатками у разі помилки її легко було відстежити і відразу перейти до налагодження. Тепер ми маємо службу, яка розмовляє з іншою службою, яка ставить щось у чергу на шині повідомлень, яка обробляє іншу службу — і тут виникає помилка. Ми повинні зібрати докупи всі ці частини, щоб зрештою дізнатися, що служба А працює у версії 11, а служба Е вже чекає на версію 12. Це дуже відрізняється від мого стандартного консолідованого журналу: доводиться використовувати інтерактивний термінал/налагодник, щоб пройти через процес крок за кроком. Налагодження та розуміння по суті стали складнішими.
Якщо не можна налагодити, можливо, ми їх протестуємо
Безперервна інтеграція та безперервна розробка нині стають спільним місцем. Більшість нових програм, які я бачу, з кожним новим релізом автоматично створюють та запускають тести та вимагають, щоб тести проходили та переглядалися перед реєстрацією. Це відмінні процеси, яких не можна відмовлятися, вони стали великим зрушенням для багатьох компаній. Але тепер, щоб дійсно перевірити сервіс, я маю підняти повну робочу версію своєї програми. Пам'ятаєте нового інженера з кластером K8 зі 150 сервісів? Ну, тепер ми навчимо нашу систему CI, як підняти всі ці системи для перевірки, що все дійсно працює. Ймовірно, це занадто багато зусиль, тому ми просто ізольовано протестуємо кожну частину: я впевнений, що наші специфікації є досить хорошими, API чисті, а відмова служби ізольована і не вплине на інших.
Усі компроміси мають вагому причину. Правильно?
Є багато причин переходу на мікросервіси. Я бачив, що це роблять для більшої гнучкості, масштабування команд, продуктивності, щоб забезпечити кращу стійкість роботи. Але насправді ми вклали десятиліття в інструментарій та практики розробки монолітів, які продовжують розвиватися. Я працюю з професіоналами у різних технологіях. Зазвичай, ми говоримо про масштабування, тому що вони стикаються з лімітами одного вузла бази даних Postgres. Більшість розмов присвячена .
Але мені завжди цікаво дізнатися про їхню архітектуру. На якому етапі переходу до мікросервісів вони перебувають. Цікаво спостерігати, як все більше інженерів кажуть, що вони задоволені своїм монолітним додатком. Багатьом мікросервіси принесуть користь, а вигоди переважать вибоїни на шляху міграції. Але особисто мені дайте, будь ласка, мою монолітну програму, місце на пляжі — і я зовсім щасливий.
Джерело: habr.com