10 причин НЕ використовувати мікросервіси

1159

10 причин НЕ використовувати мікросервіси

Мікросервіси

Мікросервісна архітектура - це модель розробки програмного забезпечення, при якій програма будується з автономних і слабко пов'язаних між собою модулів. На практиці це спрощує створення та управління проєктами, тому такий підхід використовують у своїх продуктах навіть відомі бренди, зокрема PayPal, Netflix та Amazon.

Так, мікросервіси пропонують безліч переваг. Але треба розуміти — це не панацея, і сліпо використовувати їх у кожному проєкті точно не варто. Чому? Команда SpaceLab підготувала одразу 10 відповідей на це питання, тому перейдемо одразу до справи.

Підвищена складність

Використання мікросервісів потребує великої кількості додаткової інфраструктури. Як мінімум, динамічне виявлення служб, балансування навантаження, синхронна або асинхронна взаємодія. В результаті складність розробки та обслуговування ПЗ помітно збільшується, а отже, доведеться розширювати і бюджет проєкту. І тут уже виникає питання — чи готовий замовник збільшувати інвестиції чи краще віддати перевагу монолітному підходу.

2. Складність тестування

При використанні мікросервісів QA-інженерам значно додається роботи. Це пов'язано з тим, що їм потрібно як протестувати окремо кожну службу, так й перевірити коректність її у поєднані із іншими пов'язаними сервісами і системами.

3. Мікросервіси важко налагоджувати

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

4. Низька продуктивність

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

5. Збільшення операційних витрат

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

6. Підвищені витрати на розгортання

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

7. Складність у відстеженні даних

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

8. Для розробки потрібна спеціальна команда

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

9. Безпека продукту

Захист даних у мікросервісній архітектурі - це набагато складніше завдання, порівняно із забезпеченням безпеки монолітної програми. Зрозуміло, розробники можуть використовувати поширені фреймворки та бібліотеки, у тому числі такі, як Spring Security, JWT та OAuth 2.0, але все ж таки вони закривають не всі питання.

10. Мікросервіси потрібні не завжди

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

Висновок

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

Якщо ви хочете отримувати більше цікавої та корисної інформації про IT-ринок, підписуйтесь на наш Telegram-канал!