Мікросервіси допоможуть вам масштабуватись
Мікросервісні архітектури допомагають масштабувати в багатьох вимірах:
- Трафік і клієнти. Мікропослуги дозволяють обслуговувати більше клієнтів з більшим трафіком та більшою кількістю даних.
- Кількість розробників та команд розробників. За допомогою мікросервісів ви можете додати більше команд розробників, а отже, і більше розробників до вашої програми. Розробники більш продуктивні, оскільки не наступають на ноги так сильно, як у процесі монолітного розвитку.
- Складність і навички. Команди мають менше «поверхні» додатків для роздумів, щоб вони могли працювати над складнішими проблемами у своїй області. З більшою кількістю команд, які працюють над більшою кількістю проблемних областей, можливі більш складні проекти.
Індивідуальна командно-орієнтована сервісна архітектура
Недостатньо просто перенести програму на архітектуру на основі мікросервісів. Архітектура на основі мікросервісів все ще можлива, але ваші команди розробників працюють над проектами, які включають служби та створюють складні взаємодії між вашими командами. Підсумок: ви все ще можете опинитися в бруді розробки, навіть якщо ви перейдете на архітектуру на основі мікросервісів.
Щоб уникнути цих проблем, вам потрібно мати чітку модель власності та відповідальності за послуги. Кожна окрема послуга вимагає єдиного, чіткого, чітко визначеного власника, який несе повну відповідальність за послугу, і робота повинна керуватися та делегуватися на рівні обслуговування. Я пропоную таку модель, як Архітектура обслуговування, орієнтована на єдину команду (STOSA). Ця модель, про яку я розповідаю у своїй книзі Архітектура для масштабу, забезпечує чіткість, яка дозволяє вашому додатку — і вашим командам розробників — адаптуватися до потреб вашого бізнесу.
Вартість мікропослуг
Мікросервісні архітектури мають свою ціну. Хоча окремі сервіси легше розуміти та керувати ними, програма мікросервісів у цілому має значно більше рухомих частин і сама стає складнішим звіром. Це може створити складність програми та проблеми, які створює складність інших аспектів вашої програми. Не варто ігнорувати ці проблеми.
Крім того, багато компаній, що застрягли в бруді (як показано на малюнку 2), починають проект переходу на архітектуру мікросервісів (як показано на малюнку 3). Однак перехід часто буде для них складнішим і дорожчим, ніж очікувалося чи очікувалося. І тому вони відмовляються від зусиль під час міграції. Вони частково мігрували і часто перебувають у гіршому стані, ніж були на початку.
Перш ніж переходити на архітектуру мікросервісів, ви повинні зрозуміти витрати, переваги та проблеми, які попереду. Вам потрібно мати належні очікування, щоб перехід – і ваше майбутнє застосування – досягли успіху.
Значення мікросервісів
Кожна служба є незалежною та ізольованою від будь-якої іншої служби. Кожне міністерство менше, але їх більше. Кожен має чітко визначений інтерфейс між ними, і кожен представляє частину чітко визначеної бізнес-логіки.
Що ще важливіше, кожна служба має одного власника. Команда розробників відповідає за всі аспекти кожної окремої служби.
Додаток є чистішим, а власність та відповідальність чіткішими.
Коротше кажучи, ваша програма масштабована. Не масштабується з точки зору кількості клієнтів, яку він може підтримувати, а скоріше масштабується з точки зору кількості незалежних розробників, проектів та ініціатив, які він має для підтримки вашого бізнесу, що розвивається.
Ваші команди розробників не наступатимуть на ноги і будуть більш продуктивними, тому що в них менше безладу. Вони щасливіші і, швидше за все, довше залишаться в компанії.
Крім того, ви можете збільшити кількість команд розробників, а отже, і кількість розробників, просто перебалансувавши відповідальність власників. Більше розробників стає продуктивнішим, і ви можете досягти кращого прогресу у важливих бізнес-проектах, які мають вирішальне значення для вашого бізнесу, що розвивається.
А коли виникає проблема, аналіз взаємодії між службами значно полегшує визначення, де проблема і яка команда має її усунути. Крім того, кожна команда має набагато менший набір обов’язків, а отже, і більше знань про те, як працюють служби, за які вони відповідають, тому вони зможуть вирішувати проблеми набагато швидше та ефективніше. І оскільки вони краще розуміють сфери, за які вони відповідають, вони рідше вносять помилки в систему.
Зростаюче застосування
Ви добре розпочали з простого додатка, який написаний і підтримується однією особою або невеликою командою розробників. Ваша програма виглядає як на малюнку 1, красиво і просто.
Але час йде, додаток росте. Ваша заявка успішна, і трафік різко збільшується. Вони додають нові функції та можливості та наймають більше розробників для роботи над програмою.
Тепер у вас проблеми. Ніхто не знає, якими частинами програми він володіє. Команда 1 вносить зміни, і це впливає на команду 3. Напруга висока, а продуктивність низька. У програму проникають помилки, і ваш сайт починає давати збої, здавалося б, випадково. І коли щось йде не так, ваші команди намагаються зрозуміти, що не так, тому що жодна людина не може зрозуміти все, що відбувається в програмі. Це яскравий приклад бруду.
Ваші незалежні команди розробників насправді не є незалежними, оскільки зміни, які вносить одна команда, мають величезний вплив на те, над чим працюють інші команди. Не можна працювати над незалежними проектами, тому що всі проекти переплітаються. Інновації пригнічуються, і ваш бізнес теж.