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

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

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

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

„Всяка организация, която проектира някаква система (в широк смисъл), получава дизайн, чиято структура копира структурата на екипите в тази организация“
— Melvyn Conway, 1967

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

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

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

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

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

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

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

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

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

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

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

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

Изводи

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

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