Статтю на тему мікросервісної архітектури я хотів написати давно, проте весь час зупиняли два моменти — чим далі я поринав у тему, тим більше мені здавалося, що те, що я знаю, очевидно, а що не знаю, ще вивчати і вивчати. З іншого боку, вважаю, що вже є про що поміркувати і в широкій аудиторії. Тож альтернативні думки вітаються.
Закон Конвею та зв'язок між бізнесом, організацією та інформаційною системою
Я вкотре дозволю собі процитувати:
«Будь-яка організація, яка проектує якусь систему (у широкому значенні) отримає дизайн, чия структура копіює структуру команд у цій організації»
- Melvyn Conway, 1967
На мій погляд, цей закон швидше співвідноситься до доцільності організації бізнесу, ніж безпосередньо до інформаційної системи. Поясню з прикладу. Припустимо, у нас є досить стабільна бізнес-можливість з життєвим циклом такої тривалості, щоб мало сенс організувати підприємство (це не друкарська помилка, але мені дуже подобається цей термін, який я поцупив) Природно, що система цього бізнесу, що забезпечує, буде організаційно і процесно відповідати цьому бізнесу .
Бізнес-орієнтованість інформаційних систем
Поясню з прикладу. Допустимо наявність бізнес-можливості з організації бізнесу з продажу піци. У V1 версії (назвемо її доінформаційною) компанія являла собою піцерію, касу, службу доставки. Ця версія була довгоживучою в умовах низької мінливості навколишнього світу. Потім на зміну прийшла версія 2 - більш просунута і вміє використовувати інформаційну систему у своїй основі для бізнесу з монолітною архітектурою. І тут, на мій погляд, виникає ось просто жахлива несправедливість по відношенню до монолітів. нібито монолітна архітектура не відповідає доменній моделі бізнесу. Та якби це так, система б не змогла працювати взагалі -у суперечності з тим самим законом Конвею та здоровим глуздом. Ні, монолітна архітектура повністю відповідає бізнес-моделі на даному етапі розвитку бізнесу — я, звичайно, маю на увазі етап, коли система вже створена і введена в експлуатацію. Цілком чудовий факт, що незалежно від архітектурного підходу і сервісно-орієнтована архітектура версії 3 і мікросервісна архітектура версії N працюватиме однаково добре. У чому каверза?
Все тече, все змінюється чи мікросервіси – засіб боротьби зі складністю?
Перш ніж продовжити, розглянемо деякі помилки щодо мікросервісної архітектури.
Прибічники використання мікросервісного підходу часто свідчать, що розбиття моноліту на мікросервіси спрощує підхід до розробки з допомогою зменшення кодової бази окремих сервісів. На мій погляд це твердження є цілковитим маренням. Серйозно, очевидна взаємодія в рамках моноліту та гомогенного коду видається складною? Якби це справді було так, усі проекти б спочатку будувалися як мікросервіси, тоді як практика показує, що міграція з моноліту в мікросервіси є куди більш поширеною. Складність нікуди не зникає, вона просто переходить з окремих модулів в інтерфейси (чи то шини даних, RPC, API та інші протоколи) та оркеструючі системи. І це складно!
Перевага використання гетерогенного стеку також є сумнівною. Я не сперечатимусь, що таке теж можливо, але в реальності рідко зустрічається (Забігаючи вперед — це повинно мати місце бути — але швидше як наслідок, ніж перевага).
Життєвий цикл продукту та життєвий цикл сервісу
Погляньте ще раз на діаграму вище. Я не випадково відзначив життєвий цикл окремої версії бізнесу, що зменшується, — в сучасних умовах саме прискорення переходу бізнесу між версіями є визначальним для його успіху. Успішність продукту визначається швидкістю перевірки бізнес-гіпотез у ньому. І ось тут на мій погляд і закопано ключову перевагу мікросервісної архітектури. Але ходімо по порядку.
Перейдемо на наступний щабель еволюції інформаційних систем - на сервіс-орієнтовану архітектуру SOA. Отже, у певний момент ми виділили у своєму продукті довгоживучі сервіси — довгоживуючі у тому сенсі, що з переході між версіями продукту є шанси, що життєвий цикл сервісу буде довше, ніж життєвий цикл чергової версії продукту. Логічно було б не змінювати їх взагалі – нам важлива саме швидкість переходу до наступної версії. Але, на жаль, ми змушені вносити постійні зміни до сервісів — і тут у нас все годиться, і практики DevOps, і контейнеризація, і таке інше — що спаде на думку. Але це ще не мікросервіси!
Мікросервіси як засіб боротьби зі складністю ... управління конфігурацією
І ось тут ми можемо перейти до визначальної ролі мікросервісів - це підхід, що спрощує управління конфігурацією продукту. Детальніше кажучи, функція кожного мікросервісу описує саме бізнес-функцію всередині продукту згідно з доменною моделлю — а це вже речі, які живуть не в короткоживучій версії, а в довготривалій бізнес-можливості. І перехід до наступної версії продукту відбувається буквально непомітно - ви змінюєте/додаєте один мікросервіс, а можливо і просто схему їх взаємодії і раптово опиняєтеся вже в майбутньому, залишаючи за бортом конкурентів, що плачуть, продовжують стрибати між версіями своїх монолітів. Тепер уявіть собі, що є досить великий обсяг мікросервісів із заздалегідь визначеними інтерфейсами та бізнес-можливостями. І ви приходите і будуєте структуру вашого продукту з готових мікросервісів - просто малюючи діаграму, наприклад. Вітаю – у вас з'явилася платформа – і тепер ви можете собі накликати бізнес. Мрії мрії.
Висновки
- Архітектура системи повинна визначатися життєвим циклом компонентів, що входять до неї. Якщо компонент живе в рамках версії продукту - немає сенсу збільшувати складність системи, застосовуючи мікросервісний підхід.
- Мікросервісна архітектура повинна ґрунтуватися на доменній моделі — тому що бізнес-можливість найбільш довготривала область
- Практики доставки (практики DevOps) та оркестрації мають для мікросервісної архітектури одне з найважливіших значень — тому, що збільшення швидкості зміни компонентів висуває підвищені вимоги до швидкості та якості доставки.
Джерело: habr.com