Микросервизи: какво е това, защо е необходимо и кога трябва да ги внедряваме

Темата за микросервисната архитектура отдавна ми беше на сърце, но винаги ме спираха две неща — колкото по-дълбоко се задълбочавах в темата, толкова повече ми се струваше, че това, което знам, е очевидно, а онова, което не знам, все още трябва да бъде изучавано. От друга страна, смятам, че вече има какво да обсъдим и на широка аудитория. Така че алтернативните мнения са добре дошли.

Законът на Конвей и връзката между бизнеса, организацията и информационната система

Още веднъж ще си позволя да цитирам:

«Всяка организация, която проектира някаква система (в широк смисъл), ще получи дизайн, чиято структура копира структурата на екипите в тази организация»
— Мелвин Конвей, 1967

На мое мнение, този закон по-скоро се отнася до целесъобразността на организацията на бизнеса, отколкото директно към информационната система. Ще обясня с пример. Да предположим, че имаме достатъчно стабилна бизнес възможност с такъв дълъг жизнен цикъл, че би имало смисъл да организираме предприемачество (не е печатна грешка, но много ми харесва този термин, който приютих). Естествено, че осигуряващата система на този бизнес ще бъде организационно и процесно съобразена с него.

Бизнес-ориентираност на информационните системи

Ще дам пример. Да предположим наличието на бизнес възможност за организиране на бизнес за продажба на пица. В версия V1 (да я наречем предиинформационна) компанията представляваше пицария, каса, служба за доставка. Тази версия беше дълговечна в условия на ниска изменчивост на заобикалящия свят. След това дойде версия 2 — по-развита и в състояние да използва информационната система в основата на бизнеса с монолитна архитектура. И тук, на мое мнение, възниква просто ужасна несправедливост спрямо монолитите — съществува възприятието, че монолитната архитектура не съответства на домейн модела на бизнеса. Да бъде така, системата нямаше да може изобщо да работи - в противоречие с абсолютно същия закон на Конвей и здравия разум. Не, монолитната архитектура напълно съответства на бизнес модела в този етап от развитието на бизнеса — имам предвид етапа, когато системата вече е създадена и внедрена в експлоатация. Напълно впечатляващ факт е, че независимо от архитектурния подход, както версия 3 с услуга-ориентирана архитектура, така и микросервисната архитектура версия N ще работят еднакво добре. Какво е подводният камък?

Всичко тече, всичко се променя или микросервизите са средство за борба със сложността?

Преди да продължим, нека разгледаме някои заблуждения относно микросервисната архитектура.

Поддръжниците на микросервисния подход често казват, че разделянето на монолита на микросервизи опростява разработката чрез намаляване на кодовата база на отделните услуги. На моето мнение, това твърдение е напълно абсурдно. Наистина ли е сложно очевидното взаимодействие в рамките на монолита и хомогенния код? Ако беше така, всички проекти щеше да се изграждат първоначално като микросервизи, докато практиката показва, че миграцията от монолит към микросервизи е много по-разпространена. Сложността не изчезва, тя просто се прехвърля от отделните модули в интерфейсите (независимо дали става дума за данни, RPC, API или други протоколи) и оркестриращите системи. И това е сложно!

Предимството на използването на хетерогенен стек също е съмнително. Няма да споря, че това е възможно, но в реалността е рядкост (за напред да кажа — това е допустимо, но по-скоро като последствие, отколкото предимство).

Животният цикъл на продукта и животният цикъл на услугата

Погледнете отново диаграмата по-горе. Не случайно отбелязах намаляващия живот на отделната версия на бизнеса — в съвременни условия именно ускореното преминаване на бизнеса между версиите е определящо за успеха му. Успехът на продукта се определя от скоростта на проверка на бизнес хипотезите в него. И тук, на моето мнение, е закопано ключовото предимство на микросервисната архитектура. Но нека продължим по ред.

Нека преминем към следващото ниво на еволюцията на информационните системи — към архитектура, ориентирана към услуги (SOA). И така, в определен момент ние отделихме в нашия продукт дълготрайни услуги — дълготрайни в смисъл, че при преминаването между версиите на продукта има шансове жизненият цикъл на услугата да бъде по-дълъг от жизнения цикъл на всяка следваща версия на продукта. Беше логично да не ги променяме изобщо — за нас важно е именно бързината на прехода към следващата версия. Но за съжаление, ние сме принудени постоянно да внасяме промени в услугите — и тук всичко е допустимо, включително практиките на DevOps, контейнеризация и всичко останало, което ни хрумне. Но това все още не са микросервизи!

Микросервизите като средство за справяне със сложността… управление на конфигурацията

И тук можем най-накрая да преминем към определящата роля на микросервизите — това е подход, който опростява управлението на конфигурацията на продукта. По-точно казано, функцията на всеки микросервис описва именно бизнес-функцията в продукта според домейн модела — а това вече са неща, които съществуват не в краткоживееща версия, а в дълготрайна бизнес-възможност. И преминаването към следващата версия на продукта става буквално незабелязано — вие променяте/добавяте един микросервис, а възможно е и просто схемата на тяхното взаимодействие и внезапно се оказвате вече в бъдещето, оставяйки зад борда плачещи конкуренти, които все още скачат между версиите на своите монолити. Сега си представете, че имате достатъчно голям обем микросервизи с предварително определени интерфейси и бизнес-възможности. И вие идвате и строите структурата на вашия продукт от готови микросервизи — просто рисувайки диаграма например. Поздравления — имате платформа — и сега можете да си изградите бизнес. Мечти, мечти.

Изводи

• Архитектурата на системата трябва да се определя от жизнения цикъл на влезлите в нея компоненти. Ако компонентът съществува в рамките на версия на продукта — няма смисъл да увеличаваме сложността на системата, прилагаща микросервисен подход.
• Микросервисната архитектура трябва да се основава на домейн модела — по простата причина, че бизнес-възможността е най-дълготрайната област
• Практиките за доставка (DevOps практики) и оркестрация имат изключително важно значение за микросервизната архитектура, тъй като увеличаването на скоростта за промяна на компонентите поставя по-високи изисквания към бързината и качеството на доставката.

Източник: habr.com