Найважливіше, що потрібно пам’ятати з мікросервісами, це те, що вони стосуються не в першу чергу технічних проблем, а організаційних проблем. Отже, коли ми розглядаємо, чи повинна організація використовувати мікросервіси, і як ці сервіси розгортаються, нам потрібно подивитися, чи має організація проблеми, які вирішує стиль мікропослуг.
Тоді відповідь на ваше запитання щодо вашої архітектури залежатиме здебільшого від розміру вашої технологічної команди, організаційної структури, віку вашого продукту, ваших поточних практик розгортання та того, як вони можуть змінитися в середньостроковій перспективі.
Як приклад, якщо ваша організація:
- має менше 25 технічних працівників,
- організовані в 1 або 2 команди,
- кожна з яких працює на будь-якій частині продукту,
- якому менше 12 місяців,
- і розгортається все відразу (наприклад, щодня, щотижня, щомісяця),
- і орг не збирається швидко рости,
то ви майже напевно хочете зараз забути про мікросервіси. У такій ситуації команда все ще нова у вивченні домену, тому, ймовірно, не знає всього, що потрібно, щоб дійсно зрозуміти, що було б чудовим способом розділити систему на розподілену архітектуру. Це означає, що якщо вони розділять їх зараз, вони, ймовірно, захочуть змінити межі пізніше, і це стане дуже дорогим, коли у вас вже є розподілена система, і при цьому в моноліті набагато простіше. Більше того, лише з невеликою командою, яка може працювати над будь-якою частиною системи (і підтримувати її), мало підстав інвестувати в побудову платформи, де окремі команди можуть розгорнути та підтримувати окремі сервіси. Організація на цьому етапі, як правило, набагато більше турбується про те, щоб знайти клієнтів і швидко повторити продукт, можливо, навіть поворотний продукт, на відміну від створення команд автономними та побудови високомасштабної, стійкої архітектури. Монолітна архітектура має сенс у цьому пункті, але адобре розроблений моноліт, з чіткими межами компонентів, що забезпечуються API, та інкапсульований доступ до даних, що дозволяє легко виводити служби в окремі процеси згодом.
Розглянемо трохи далі і розглянемо організацію, яка ...
- понад 50 технічних працівників,
- організовано в 7 команд,
- кожна з яких працює лише на певних ділянках продукту,
- якому 3 роки,
- і має команди, які хочуть розгорнути свою роботу незалежно від того, що роблять інші команди.
Така організація, безумовно, повинна будувати розподілену архітектуру. Якщо вони цього не роблять, а всі ці команди працюють в моноліті, вони зіткнуться з усіма організаційними проблемами, коли команди потребують координації своєї роботи, випуски затягуються, поки одна команда закінчує контроль якості за новою функцією, виправленням використовує великі клопоти для персоналу та клієнтів. Більше того, із зрілим продуктом організація повинна достатньо знати про домен, щоб мати можливість розумно розділити як домен, так і команди (у такому порядку; див. Закон Конвея) на розумні, автономні підрозділи, які можуть досягти прогресу, мінімізуючи координацію.
Здається, ви вже вибрали мікросервіси. Залежно від того, де ви сидите на вагах вище, можливо, ви хочете переглянути це рішення.
Якщо ви хочете продовжувати розвиватися за допомогою мікросервісів, але розгортати їх все в одному контейнері, знайте, що в цьому немає нічого поганогоякщо це відповідає тому, як працює ваша організація в даний момент. Чи це створить проблеми для вашої структури проекту в майбутньому? Ну, якщо ви успішно розвиваєтесь, і ваша організація зростає, мабуть, настане час, коли розгортання одного контейнера вже не найкраще підходить, зокрема, коли команди починають володіти службами і хочуть розгорнути лише їх сервіс, не розгортаючи весь додаток . Але ця самостійність прийде ціною додаткових робіт і складності, і це може не принести вам ніякої користі в цей час. Тільки тому, що це не буде правильним підходом для вашої системи в майбутньому, не означає, що це не правильний підхід на сьогодні. Хитрість полягає в тому, щоб слідкувати за цим і знати, коли робити додаткові інвестиції.