Технічні команди часом сприймають мікросервіси як панацею, не розуміючи справжню ціну запровадження цієї архітектури. Вона потребує чимало ресурсів з погляду інженерії, підтримки, інфраструктури та зусиль команди. Дмитро Кокот, Head of Engineering в Addmile, проєкту EdTech-стартапу Headway, спростовує найпоширеніші міфи про мікросервіси, а також пояснює, як підготуватися до переходу на цей тип архітектури.
AddMile — коучингова платформа для персонального та карʼєрного розвитку. Місія AddMile — зробити коучинг доступним для кожного та змінити його сприйняття як «практики для топменеджерів».
МІФ №1
Перехід на мікросервіси зробить систему швидкою
Коли ми говоримо про швидкість, ми маємо на увазі швидкодію самого сервісу. Проте загальна система може працювати повільніше. Фактично час від ідеї до потрапляння фічі на продакшн збільшується, адже команді треба подбати про чимало архітектурних питань. Зокрема — про витрати на комунікацію між мікросервісами.
У монолітному продукті комунікація між його частинами зазвичай близька до миттєвої, адже вони знаходяться в одному місці. Додавання мікросервісу — це новий рівень складності. Коли він комунікує з основною частиною продукту мережею, це збільшує час очікування, а при складній агрегації запитів, між ними виникає залежність.
Завдання команди — продумати на етапі побудови архітектури, як мінімізувати цю проблему, звернувшись до патернів проєктування мікросервісів. Йдеться про використання асинхронних операцій, CQRS/SAGA та інші механізми оптимізації комунікації між сервісами.
МІФ №2
Варто одразу будувати мікросервісну архітектуру
В певний момент розвитку продукту більшість команд так чи інакше звертаються до мікросервісної архітектури. Тож чому б не побудувати продукт одразу на мікросервісах? Як інженер, я би погодився, адже ця архітектура вважається більш «дорослою» та якісною з погляду інженерних практик. Водночас вона не підходить для більшості проєктів на стадії MVP.
На перших етапах над проєктом працює маленька команда, якій важливо рухатись швидко, а мікросервісна архітектура сповільнює та ускладнює систему, а також потребує додаткового ресурсу, якого зазвичай немає. Наприклад, проєкт AddMile побудований на монолітній архітектурі з деякими виділеними сервісами, але загалом це дуже близько до повноцінного моноліту. Це дає простір для додаткових швидких експериментів, необхідних на цьому етапі.
Розділ моноліта на мікросервіси — логічний крок, коли продукт стає дуже великим, в його системі багато звʼязаного коду, і над ним працює чимало людей. Тоді зазвичай виникають проблеми із тестуванням та деплоєм. Коли ж продукт знаходиться на ранній стадії, у нього немає легасі та архітектурних проблем, адже він сам по собі невеликий. Розділ на менші частини не логічний і не вартує тих зусиль і ресурсів.
Винятком є кейси, коли команда зі старту створює високонавантажену систему. Наприклад, банківська система — ніхто сьогодні у здоровому глузді не буде робити її монолітною, адже зрозуміло, що це буде високонавантажена система з сотнями мільйонів транзакцій. Проте таких проєктів, які зі старту будують щось велике і грандіозне, — дуже мало.
МІФ №3
Мікросервіс — обовʼязковий етап в життєвому циклі продукту
Насправді продукт може залишитися монолітом впродовж всього «життя», якщо з ним працює невелика команда і підтримує його у належному стані. Чим більша команда, тим вища ймовірність появи конфліктних зон відповідальності, коли багато людей працюють з однією частиною моноліту і мерджать конфліктний код в одну гілку.
Монолітна архітектура не обовʼязково передбачає поганий звʼязний код. Він може бути досить якісним і чистим, мати архітектуру, що не сповільнює його і не утворює безліч проблем, про які зазвичай всі говорять.
МІФ №4
Стабільність: якщо ламається один мікросервіс, всі інші працюють
Мікросервісна архітектура може сприяти зниженню даунтаймів, зокрема завдяки ізоляції сервісів та можливості горизонтального масштабування. Збій одного сервісу не обов’язково призведе до падіння всієї системи. Водночас цей тип архітектури створює додаткові виклики в інтерсервісній комунікації та складності системи загалом.
Уявімо: користувач інтернет-магазину хоче здійснити покупку, скориставшись нарахованими бонусами. У монолітній архітектурі цей функціонал реалізовується просто: створюється транзакція, знімаються бонуси, змінюється ціна і статус покупки. Якщо відбувається збій у транзакції, всі частини автоматично повертаються до початкового стану. В мікросервісах це сутності, які живуть окремим життям, проте впливають одна на одну. У разі збою всім їм потрібно повідомити про це. Отже, у ланцюгу викликів має бути передбачений відкат: якщо щось ламається, компенсаційні івенти у зворотному напрямі повернуть систему до початкового стану. Усіма цими складними звʼязками потрібно вміти керувати.
МІФ №5
Будь-який старий моноліт, що погано працює, можна врятувати мікросервісом
Це правда, при умові, що у вас є достатньо ресурсів і мотивації працювати зі старим кодом, який, наприклад, був написаний 10 років тому. Популярний кейс: стара монолітна банківська система, створена на застарілих технологіях, які вже не підтримуються. Щоб розвивати її далі, виділяють частину, що приносить найбільше користі бізнесу, і виносять в мікросервіс. Для цього знаходять канали комунікації моноліта, розривають їх, створюють адаптери між монолітом і новим мікросервісом. Система починає працювати так, ніби нічого не змінилося, але тепер комунікує з мікросервісом, як із зовнішнім ресурсом.
Цей підхід розв'язуває деякі проблеми, проте є непростим в реалізації. Іноді це настільки дорого і складно, що простіше все переписати.
МІФ №6
Мікросервіс під кожну кнопку
Зі зростанням проєкту кількість мікросервісів і складність системи будуть збільшуватися — від цього нікуди не дітися. Наприклад, у системах, на кшталт Netflix, тисяча мікросервісів.
Для керування цим процесом інфраструктурна команда створює стандартизовані інструменти для розробників, які спрощують створення і підтримку мікросервісів. Це включає написання контрактних файлів, визначення ресурсів, рекомендацій як його дублювати та інформації, як цей сервіс має працювати загалом. Також можна обʼєднувати мікросервіси у доменні групи, відповідно до бізнес-логіки. Це зменшує загальну відповідальність і дозволяє збільшувати кількість мікросервісів без значного впливу на всю систему, адже вони стають настільки відокремленими, що виглядають як продукти інших команд або проєктів.
Геометричне зростання мікросервісів може бути проблемою, якщо команді не вистачає ресурсів для управління ними. Якщо немає окремої інфраструктурної команди, то розробники мають витрачати час на створення інфраструктури замість розробки функціонала. Команда DevOps, яка раніше займалася стабільністю моноліта, тепер має створювати нові інструменти, процеси та вирішувати нові завдання, пов'язані з мікросервісною архітектурою. Тому завдання команди — бути готовою до збільшення вартості розробки та дотримуватися балансу у між додаванням нових мікросервісів і їхньою підтримкою.
МІФ №7
Немає часу пояснювати, нумо робити мікросервіс
На початку своєї кар'єри я, як і більшість розробників, сприймав мікросервісну архітектуру, як щось вишукане та інноваційне. Тому хотілося якомога швидше його спробувати навіть попри відсутність досвіду. Класична історія — коли невеликий MVP-проєкт, що має велике навантаження та обмежені ресурси, переходить на мікросервіси. Найбільш поширені помилки команд:
1. Через неправильне проєктування, утворився складніший розподілений моноліт. Нерідко це трапляється через те, що мікросервіс проєктується із залежностями. При використанні мікросервісів важливо розрізняти stateful (зберігають стан) і stateless (не зберігають стан). Якщо stateful-сервіси неправильно розподілені, наприклад, мають власні бази даних, це порушує концепцію мікросервісів.
2. Недооцінили інтерсервісну комунікацію і вплив на швидкодію продукту. Це особливо помітно, коли виникають цикли викликів між різними сервісами — у непідготовленій мікросервісній архітектурі час очікування може сягати 1000 мс, коли у моноліті — 10 мс.
3. Безпека. Коли ми переходимо до мікросервісної архітектури, з'являється комунікація між різними серверами, які можуть бути розташованими у різних дата-центрах. Це може призвести до проблем з безпекою, таких як витоки даних. У моноліті такі проблеми відсутні, оскільки всі операції відбуваються в одній зоні пам'яті. Важливо готуватися до цих викликів.
4. Розширення команди. Не можна просто перейти на мікросервіси та підтримувати їх тією ж командою. Робота з монолітом вимагає сильної команди та інженерної культури, зокрема потрібна інфраструктурна команда, яка відповідатиме за розгортання та моніторинг. Багато компаній не готові вкладати кошти в окремого архітектора, який міг би спрогнозувати потенційні проблеми. У такому разі можна проконсультуватися з кваліфікованим архітектором, який допоможе побудувати процеси. Також можна використовувати ітеративний підхід для поступового розгортання мікросервісів та набуття досвіду. Наприклад, винесення ненавантажених частин продукту в мікросервіси дасть змогу команді попрактикуватися.
Загалом командам варто готуватися заздалегідь, оскільки побудова мікросервісної архітектури — не той випадок, коли можна вчитися в процесі та гуглити проблеми. Це може дорого коштувати бізнесу.