Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Переходимо з моноліту на мікросервіси ефективно: власний досвід і план дій

Вітаю! Мене звати Дмитро Соляніченко, я Technical Project Manager у сервісній компанії Glorium Technologies. Оскільки ми працюємо зі стартапами на різних етапах — від валідації ідеї і розробки MVP до запуску на ринок готового продукту, — наше робоче середовище є досить динамічним.

Нещодавно ми з командою закінчили розділяти великий моноліт на мікросервіси. Знаю, що це дуже поширена задача, з якою стикаються багато команд. Тож хочу поділитися практичними висновками, і таким чином «підстелити соломку» тим колегам, хто тільки планує поділ моноліту на мікросервіси.

Першочергове завдання для команди

Німецька real-estate компанія звернулася до нас із запитом перевести їхній десктопний застосунок, розроблений 20 років тому, у веб. Історія типова: часу обмаль, оскільки потрібно було встигнути розробити MVP до важливої виставки. Відповідно, ми з нуля створили моноліт з базовими функціями за шаблоном десктоп-версії. В процесі ми частково використовували бібліотеки клієнта, де зберігалася частина бізнес-логіки. Проте суттєву складову усієї бізнес-логіки застосунку мали надавати ми з нашого боку.

Виставка пройшла успішно, тому нам, знову ж таки, дуже швидко, потрібно було з MVP зробити готовий до запуску продукт, який клієнт почне монетизувати. Після цього ми продовжували працювати над усім новим функціоналом і фічами продукту.

Власне, наш проєкт складався з двох монолітів (API) — основного і субпроєкта. Для вирішення завдання ми обрали стек .NET + Azure DevOps. Однією з початкових технічних вимог клієнта до проєкту була можливість перевикористання коду (щось на зразок конструктора) та гнучкість у сетапі.

Оскільки ми орієнтувалися на підхід data-driven decision, за яким рішення приймаються на основі аналізу масиву інформації, безліч компонентів мали налаштовуватися через базу даних.

Коли почали з’являтися архітектурні проблеми, нарощувати фічі ставало все складніше. Проєкт розрісся, перформанс був далеко не завжди найкращий.

З огляду на всі ці фактори, ми прийшли до рішення — розділити проєкт на мікросервіси. Серед наших цілей було:

  • отримати можливість скейлити критичні компоненти (було практично досягнуто максимум можливостей в Azure DevOps з погляду інфраструктури);
  • поліпшити швидкодію і спростити підтримку;
  • за кожним мікросервісом закріпити окремого Principal Engineer, що відповідатиме за свій репозиторій та контролюватиме стабільність роботи застосунку.

Міграція. З якими проблемами ми стикнулися і як їх вирішували

Зважаючи на початкову складність проєкту, ми з командою і не очікували, що переходити на мікросервісну архітектуру буде просто. Почасти ми були готові до ускладнень й технологічних головоломок. Отже, розкажу про основні виклики, з якими ми зіткнулися в організації міграції, адже це досить типові проблеми для таких випадків.

1. Кросзалежності між елементами архітектури, які складно розділити

Кожен мікросервіс під собою намагався викликати інший мікросервіс, ми не могли розділити, що за чим використовується. Нам довелося провести рефакторинг величезної кількості коду. І головною метою був саме поділ, а спрощення та покращення — завданням другорядним. На це пішла велика кількість зусиль, оскільки через загальний підхід із перевикористанням взаємозв’язки були абсолютно скрізь.

Ми почали розносити всю логіку по NuGet-пакетах. У процесі цього виявилося, що деякі з них попадають у циклічні залежності, і тому проєкт не може піднятися. При цьому відстежити ланцюжки викликів було дуже складно — вони тяглися через 5-7 пакетів або більше, що ускладнило і без того непросте завдання. До того ж у нас використовується не зовсім стандартний підхід щодо версійності пакетів на різних середовищах, що ще більше доливало олії до вогню міграції.

Вирішити цю ситуацію нам вдалося за допомогою написання generic-клієнта — так ми хоч трохи уніфікувати виклики.

2. Кілька ендпоінтів і логіка — поза мікросервісами

Деякі частини неможливо було віднести до жодного з мікросервісів. Такі endpoints ми вирішили виділити в окрему структуру. Ми об’єднали їх у не надто навантаженому мікросервісі і зробили його умовно макросервісом. Надалі ми відділили невелику частину від загального проєкту, створивши окремий мікросервіс.

Чому взагалі так сталося? У проєкті було понад пів мільйона рядків коду. З точки зору техзавдання архітектури все виглядало логічно. Але коли ми почали розбиратися з тим, що на своїй ділянці зробив кожний з команди у 20+ девелоперів, то виявили величезну кількість кросзалежностей.

Однією з причин стало також те, що вони активно використовували наші базові принципи проєкту: що більше елементів, які можуть повторно чи інакше використовуватися, то краще.

3. Семантичні проблеми при тестуванні

Для підвищення якості коду та спрощення перевірок, у тому числі на когнітивну складність, ми застосовуємо автоматичний тул SonarQube. При поділі на мікросервіси нам довелося залазити у старі модулі, які писалися за принципом швидкої видачі у продакшен, і реалізовували складну бізнес-логіку. Очевидно, що при винесенні коду нам довелося зачепити ці модулі й умовно «влити» по-новому.

Згідно з вимогами цього інструменту ми мали переписати код і покращити його краще, що відтягувало термін реалізації десь на пів року чи навіть рік. Вольовим рішенням, ми відключили SonarQube на час рознесення по мікросервісах.

4. Merge-конфлікти

Поділом на мікросервіси ми займалися паралельно з основною розробкою. Та згодом стало зрозуміло, що завершити перехід на мікросервіси швидко, як ми планували, не вийде, і врешті ми виконуватимемо подвійну роботу. Через конфлікти злиття розробку, яка велася паралельно з розділенням на мікросервіси, треба було б переробляти знову.

Щоб не програти самим собі, ми вирішили «вливати» зміни з основного проєкту один раз на два тижні. Це дозволило нам значно заощадити час наприкінці всієї операції при розгортанні.

Lessons learned

З огляду на отриманий досвід, хочу підсумувати, які уроки засвоїла всяк команда під час роботи на цьому проєкті в процесі реалізації міграції. А також наголошу на тому, що, на мою думку, варто було зробити, перш ніж розпочинати перехід:

  • виявити очікування клієнта від поділу на мікросервіси — зрозуміти, що це справді потрібно робити на цьому конкретному проєкті;
  • провести детальне попереднє дослідження ланцюгових залежностей — займе багато часу архітектора, але дуже спростить майбутню роботу всій команді;
  • оцінити, який функціонал і яким чином повинен опрацьовуватись, тобто створити карту переходу;
  • зрозуміти, як такий підхід полегшить підтримку проєкту в майбутньому (аби зусилля не виявилися взагалі марними);
  • залучити всю команду до поділу і тимчасово зупинити нову розробку;
  • помножити естімейти вдвічі, а краще втричі.

Попри допущені помилки і перешкоди, маємо і позитивний досвід. Наприклад, покращився перформанс між сервісами, стало легше керувати певними репозиторіями. Також ми досягли більш гнучкого масштабування інфраструктури (скейлебіліті) і, відповідно, потенційно знизили кост за інфраструктуру для клієнта.

Якщо було корисно, залишайте коментарі та діліться власним досвідом розв’язання різних задач і проблем, що виникають при зміні архітектури.

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Стаття нагадує більше історію провалу ніж успішного переходу. Самі написали моноліт, а потім затратно розпиляли...
Є книги, є купа статей про то які підводні камені і як з ними боротись. Враження що архітект вирішив сам прокласти цей шлях, ніж використати доведено робочі практики при розпиленні.

Стаття нагадує більше історію провалу ніж успішного переходу. Самі написали моноліт, а потім затратно розпиляли...

В чому провал? В отриманні бабла за написання моноліту і за розпил на мікросервіси?
Зараз візьмуть статтю, яку кинув Sergey Lysak і ще зароблять на збиранні в моноліт :)

Оскільки ми орієнтувалися на підхід data-driven decision, за яким рішення приймаються на основі аналізу масиву інформації, безліч компонентів мали налаштовуватися через базу даних.

Коли почали з’являтися архітектурні проблеми, нарощувати фічі ставало все складніше. Проєкт розрісся, перформанс був далеко не завжди найкращий.

Так может добавить дата поинтов? Какие проблемы с перформансом? перформансом чего? Какой объем данных? Сколько юзеров? Сколкьо из этих юзеров активных в день/час/минуту? Какой был баттл нек у вас в старой архитектуре и как новая помогал его решить?

Only 1% Need Microservices
$2b annual revenue.

That’s the scale at which companies studied had good reasons for Microservices architecture.

And before that?
...
The goal is not about technology — it’s about the minimal alignment that will support the business to adapt and grow fast.

There may be less fancy buzzwords in the day-to-day jobs, but much more efficiency and delivery of software that will make the difference.

So make the right choice for your business first, in the meanwhile “Modular monolith” and “Minimal architecture” are becoming mainstream again.

Only 1% Need Microservices

Власне класичні гойдалки від одного екстремума до іншого:
Всі побігли робити мікросервіси, тепер мейнстрім — хейтити мікросервіси (а справжні бунтарі будуть просувати мікросервіси). Рівно така сама історія була з СОА.

So make the right choice for your business first, in the meanwhile «Modular monolith» and «Minimal architecture» are becoming mainstream again.

Тут захована пастка: побудувати Modular monolith буде чи не складніше ніж мікросервіси, основна перевага яких саме у створенні фізичних бар’єрів між компонентами системи, що позитивно впливає на зв’язність, але все ж не гарантує низьку зв’язність.

Всі побігли робити мікросервіси

The Death of Microservice Madness in 2018
dwmkerr.com/...​oservice-madness-in-2018

основна перевага яких саме у створенні фізичних бар’єрів між компонентами системи

Так, цей аргумент роками наводиться.

І як на мене його зміст:
Ви не можете співпрацювати, командно розробляти ПЗ, не можете в архитектуру, тому треба вас розсадити по різних серверах.
Але і кодити ви не можете — то нате вам Go. (Пайк так і тролив публічно)

Або якщо спростити :
Раз так і не навчились користуватись виделкою — то тоді краще взагалі її забрати. І ложкою не можете? Ну тоді руками.

не гарантує низьку зв’язність.

На цю тему стільки напрацьовано для класичних підходів, що взагалі мало зрозуміло, що в цьому складного. З інженерної сторони.

А от складнощі з менеджментом, так. І «створення фізичних бар’єрів» це вихід для — безпорадніх менеджерів.

І як на мене його зміст:
Ви не можете співпрацювати, командно розробляти ПЗ, не можете в архитектуру, тому треба вас розсадити по різних серверах.

А це не на вас, це так і є. Зібрати і втримати вмотивовано професійну команду складно і дорого, цей підхід погано масштабується.
Мікросервіси (з сучасним харнесом як то куб) __часто__ адресують надійність, масштабованість, модифікованість значно краще ніж моноліт. (Тут ключове слово — «часто», а не завжди чи гарантовано)

Або якщо спростити :
Раз так і не навчились користуватись виделкою — то тоді краще взагалі її забрати. І ложкою не можете? Ну тоді руками.

Аналогія — ознака відсутності розуміння (це не наїзд, а правило, яким сам користуюсь для пошуку моментів де треба покращити розуміння).

Ваш приклад підміняє процес створення, процесом поглинання, тому він є маніпулятивним. Інша аналогія (можливо теж проблемна) протирічить вашій тезі:
«Раз так і не навчились готувати каву на еспресо машині — то тоді краще взагалі її забрати. І гейзером не можете? Ну тоді от вам розчинна кава»

Власне я п’ю розчинну, бо вона не гірша за практично всі кав’ярні в окрузі. Лише нещодавно знайшов одну де круто готують, але це 20-25 хв пішки від дому.

Мікросервіси (з сучасним харнесом як то куб) __часто__ адресують надійність, масштабованість, модифікованість значно краще ніж моноліт.

Що неможливо довести :) навіть якщо отому _часто_ дати якісь відсоток, за методом — «зі стелі».

Проекти що крутяться в клаудах — частенько нічим принципово від монолітів не відрізняються.
Принаймі мені такі зустрічаються частіше, ніж справді зроблені по новітньому. (в мене навіть свій жарт є на цю типову ситуацію:
замінили шаред хостінг на клауд, щоб розгорнути там черговий вордпресс.
)
Але у презентаціях та самовихваленнях ми почуємо що це мікросервісні проекти :) І вони автоматично записуються в «мікросервісні».

Я просто вказую — що адепти говорять про технічно-інженерні переваги, причому у більшості кейсів ми бачимо вирішення якихось проблем розробки як процессу співпраці людей.

Зібрати і втримати вмотивовано професійну команду складно і дорого, цей підхід погано масштабується.

Так.
І от чудо, виходить мікросервісні системи створювати простіше?

А от я згоден з:
What’s the problem with microservices?
Increased complexity for developers

Things can get a lot harder for developers. In the case where a developer wants to work on a journey, or feature which might span many services, that developer has to run them all on their machine, or connect to them. This is often more complex than simply running a single program.

Причому саме останній тиждень пишу штуку, яка буде являти собою декілька лямбд та примітивний visor для інженкції у деякий тип інстансів системи. Ніяк не рокет сайенс, але точно знаю — для більшості програмістів реалізувати аналог семафора у такий системі буде набагато важче аніж у моноліті :)

Іншими словами — якщо складність розробки моноліта лежить у площині менеджементу, то складність розробки мікросервісних систем — у питаннях девопса. А програмісти які вміють в девопс — ще рідші аніж фулстеки.
Коли ж ми маємо окремий департмент девопсів як людей (а не практик) — то проблеми менеджменту стають ще гострішими, бо девопси і програмісти розмовляють взагалі на різних мовах.

Тобто
Вмотивована професійна команда — треба і для мікросервісів.
Простота окремого мікросервіса — то як проста ліби яка сортує стрінги.
Ні перший, ні друге — саме по собі бізнесу не потрібно.
А треба купа мікросервісів/ліб — які будуть працювати як єдина «інформаційна система».

І ми все одно повернемось до — менеджменту розбробки. до узгодження роботи окремих команд, і т.д.

Аналогія — ознака відсутності розуміння

Аналогія — це іллюстрація, спрощений, схематичний, гіпертрофіовано узагальнений, стислий опис чогось великого, та складного.

це не наїзд

ваше тлумачення терміна «аналогія» — свідчить про відсутність розуміння цього терміна :)

Інша аналогія (можливо теж проблемна) протирічить вашій тезі:

Ніяка аналогія тому — не може нічому протиричіть. Друга, третя аналогія і т.д. — просто будуть вказувати на щось інше у складній темі.
І типова демагогія — використовувати аналогію як аргумент.

І гейзером не можете? Ну тоді от вам розчинна кава.
Власне я п’ю розчинну, бо вона не гірша за практично всі кав’ярні в окрузі.

Тоді не було б сенса існуівання в кав’ярнях :) Вони б зникли — бо витрати часу і грошей більші, ніж залити окропом розчинну каву.
Звісно, питання відкрите — а чи в смаку кави різниця.
Але то вже особиста справа — в мне навіть шлунок негативно реагує на розчинну каву, тому вдома кава-машина. А комусь так — немає різниці навіть на смак :)

основна перевага яких саме у створенні фізичних бар’єрів між компонентами системи
І як на мене його зміст:
Ви не можете співпрацювати, командно розробляти ПЗ, не можете в архитектуру, тому треба вас розсадити по різних серверах.

Это не так, и это очень валидный аргумент в целом. Другое дело что как минимум половина, а то и больше проектов — (еще) не достигли сложности и объемов, когда это преимущество становится реально значимым
Типа небольшого Интернет-магазина который решил поиграть в Амазон ) - тут явно проблем с микросервисами будет на порядок больше чем с old good приложением

(еще) не достигли сложности и объемов, когда это преимущество становится реально значимым, Типа небольшого...

Ну да ж,

Only 1% Need Microservices

:)

и это очень валидный аргумент в целом

такие «ещё» и «другое дело» делают его валидность уровня:
Лучше быть богатым и здоровым, чем бедным и больным.

Я ж об этом, о стилистике апологетики, а не о достоинствах и недостатках :)

Only 1% Need Microservices

Ну, 1% — это преуменьшение, я бы сказал процентов 20 :)

Можливо з точки зору сервісного бізнесу перехід із занедбаного моноліту до мікросервісів «з наскоку» — це й гарна ідея, а от з технічної виглядає дивно. Якщо була проблема в перфомансі, багато роботи з БД, важкість розділення через заплутані, в тому числі, циклічні, залежності, то можливо проблема була не в самому підході через моноліт, а в дизайні компонентів і, скоріш за все, неефективне використання можливостей БД. Мікросервіси жодну з цих проблем не вирішують, а лише створюють нові. Згадок про високонавантаженість, необхідність в розподіленості та асинхронності я не помітив. Тож, на мою думку (яка може бути невірною, адже я не маю повної картини) було б логічніше добре пройтись по дизайну компонентів, покрити тестами, відрефакторити, потюнити запити в базу (особливо якщо використовується ORM), подивитись індекси та структуру таблиць, довести то все до нормального вигляду, а вже потім думати про мікросервіси. Може й моноліт би заграв новими фарбами :)

Взагалі з власного досвіду бачив, що коли немає чіткого розуміння, навіщо потрібні мікросервіси, та як їх правильно робити, то проект може перетворитися на набір монолітів з макаронними арі колами між ними, без використання мікросервісних патернів і вкрай низькою швидкістю розробки, підтримки та поганим перфомансом. Те ж саме з використанням популярних технологій там де їм не місце, наприклад «а давайте заюзаємо dynamo db, це буде вау» а насправді можна було б обійтись трьома джойнами та одним індексом.

Мені хотілося б бачити більше цифр.
Оскільки у вас уже був працюючий прототип який приносить кеш то перехід на мікросервіси може виглядати логічним. Хоча знову ж таки, не зрозуміло яке завдання вирішує ваш проетк і скільки у вас активних юзерів і які узагалі перспективи.
Хочу нагадати мікросервіс-ентузіастам , Фаулер у свому блогу наголошує що більшість стартапів не потребують мікросервісів(оскільки мікросервіси зжерають велику часту фінансів). Усі найкрутіші проекти які ми знаємо починалися як моноліти. Ніщо не заважає перейти від моноліту у сервіси в потрібний час якщо ідея працює.Той самий Bolt чи то Убер, якщо не помиляюся так і розвивалися. Для проектів у яких на папері мільйони щасливих юзерів, а в реалі жодного — це марнотрацтво. Хоча якщо ціль «потрусити» трохи клієнта то мікросервіси це cool.

Якщо було корисно, залишайте коментарі та діліться власним досвідом розв’язання різних задач і проблем, що виникають при зміні архітектури.

Я колись також писав про схожу проблему: що робити з легасі?
Старый ящик — новый ящик, белый ящик — черный ящик. Теорвер или эзотерика?
dou.ua/forums/topic/15512
Читаючи про такі історії розпилу старого моноліту на мікросервіси — різного ступеня успіху, я розумію що це взагалі типовий анти-патерн: реанімація мертвого коня.
Чи можна узяти старий, бувалий запор і зробити з нього конфетку. Звичайно — якщо клієнт бажає, то можна. Це буде десь так: вид запора залишиться тільки «оболонка»:
www.youtube.com/watch?v=NelzxWHmRCg
Коштувати це буде дорожче, ніж нове авто, комфорт водіння і керованість будуть гірші, ніж на новому авто.
Але, на жаль,клієнти цього ніколи не розуміють. Вони хочуть аби ви просто недорого «відремонтували» старе авто — бо колись воно її цілком задовільняло! Але це неможливо — як повернути молодість. Бо і світ вже змінився, і юзери вже інші, і об’єми даних у рази більші і старі бібліотеки вже не підтримуються.
Тому кожна така спроба, навіть якшо вважається успішною, обходиться дорожче і виходить гірше, ніж нова версія «з нуля».
Доречи, деякі бізнесмени підсвідомо це розуміють — тому ніколи не дадуть добро навіть на великий рефакторинг, не кажучи вже про розділення на мікросервіси. Вони просто будуть підпирати стару клячу доки на неї ще є якийсь попит. А ринок вирішить питання дуже просто: хтось молодий та рішучий зробить свого «убивцю Фейсбука, Скайпа, Гугла» і поступово юзери перейдуть до нього, а стару систему просто викинуть, або її придбають володарі нової системи аби пересадити юзерів собі і потім закриють.
Отже єдиний розумний підхід — це «нова версія». Маючи успішну робочу систему треба через кілька років частину грошей направляти у розробку нової версії. Це дозволить не кваплячись проаналізувати що у системі подобається юзерам, що не користується попитом, а що юзери хотіли б побачити чи що є у конкурентів, чи на що може бути попит через кілька років. За перший рік можна тільки зробити ТЗ — а на наступний починати розробку. Навіть 5 років в ІТ — великий час, за який міняються підходи, фреймвоки, технології, архітектура. Якщо перша система була монолітом з єдиною базою, а нову проєктувати «з нуля» без згадок про легасі — то вона буде мати сучасну мікросервісну архітектуру з прицілом на хмари.
Справа у тому, що девелопити сучасну архітектуру набагато легше і швидше. Бо сучасні бібліотеки та фреймвоки вже пристосовані під неї! Є усілякі гайди, приклади, є бутстрапи, є готові прототипи — і навіть можна отримати консультації від розробників.
Узяти якусь стару фічу — і зробити її з нуля у новому проекті вийде швидше, ніж «випилювати» її з монолита намагаючись якось зберегти сумісність. Так за рік можна зробити нову версію у якій буде хай 30% старої функціональності (+ пара нових фіч, які юзери давно хотіли) — але це дозволить пересадити на нову версію, скажімо 50% користувачів (яким цього функціоналу достатньо). Отже ми зменшуємо навантаження на стару систему і одночасно випробовуємо нову.
Далі замість ремонтувати стару систему — ми поступово переносимо потрібні фічі (у виправленому вигляді) у нову систему. З часом юзери будуть переходити.
Саме так MS робить з Windows. Хтось ще сидить на улюбленій Windows XP, але вона вже не буде підтримувати нові ігри — доведеться поступово переходити.
Секрет цього підходу — треба думати і вкладатися у нову версію ще до того, як стара почне валитися. Це ж не нове авто, яке можна швидко придбати коли старе відмовилося їздити. Якщо упустити момент — то виявиться що стара система вже «не тягне», грошей аби усе швидко переписати — нема, чекати поки перепишуть — то втратити юзерів. Доводиться кидати гроші на підтримку і якусь «косметичну» модернізацію старого — остаточно ставлячі хрест на майбутньому.

Узяти якусь стару фічу — і зробити її з нуля у новому проекті вийде швидше, ніж «випилювати» її з монолита намагаючись якось зберегти сумісність. Так за рік можна зробити нову версію у якій буде хай 30% старої функціональності (+ пара нових фіч, які юзери давно хотіли) — але це дозволить пересадити на нову версію, скажімо 50% користувачів (яким цього функціоналу достатньо).

зараз саме проходжу виглядає на диво кумедно особливо з урахуванням сусіднього відділу по офісу який продовжує пиляти старе (з фічами) та ще й взявся «дозапилювати» рівно те саме «на нові платформі технології» я так і не зміг знайти сили сказати «як можна було взагалі здогадатися фактично емулювати г. мамонта модерновою мовою» та «програміст на фортран може писати будь якою мовою як на фортран»

хтось молодий та рішучий зробить свого «убивцю Фейсбука, Скайпа, Гугла» і поступово юзери перейдуть до нього, а стару систему просто викинуть, або її придбають володарі нової системи аби пересадити юзерів собі і потім закриють.

Нерелевантно для 80+% процентов случаев. Большинство подобных проектов связано не с убийством Фейсбуков, а с гораздо более банальными вещами, типа замены старых внутрикорпоративных систем, которые трудно масштабировать \ поддерживать etc.

Узяти якусь стару фічу — і зробити її з нуля у новому проекті вийде швидше, ніж «випилювати» її з монолита намагаючись якось зберегти сумісність

См. выше. Обычно большие фичи в корпоративных системах включают в себя 100500 интеграций с third-party и другими системами. И ты не можешь просто так встать, гордо сказать что-то типа «file-based integration — это старый дерьмовый подход, у нас будут только
events!», и уйти в закат. Потому что у тебя есть еще ERP, CRM и т.п., которые используют и будут использовать «старый» механизм. (ну или +150% к бюджету для доработок других систем)

Я стільки чув цих аргументів на захист старого: і «юзери звикли», і інтеграція з іншими системами, і вже є купа даних у старому форматі і усе, що завгодно.
А потім приходить новий бос і каже: я придумав як зекономити купу грошей: ми купимо готовий CRM і я знаю команду індусів що нам його недорого кастомізірує кувалдою та напилком.
І усе — стара система разом із усіма милицями, інтеграціями і звиклими юзерами іде лісом. Бос сказав — впроваджуємо нову! Ісі в шоці, пів — року бардака та міграцій, юзери страждають, але через пів-року усі звикають і виявляється що так теж можна працювати не гірше. А усі ті заморочки, що стільки років робили — без них теж можна жити. І є з чим інтегруватися замість старого third-party.
А головне — іде лісом галера, і її роздута команда, яка роками смоктала чималі гроші за підтримку «мертвого коня».

Ты скорее всего просто не сталкивался — повторюсь, есть много сфер деятельности, где такой чрезмерно резкий

новий бос

вылетит с работы не через

пів — року бардака

а через неделю, а то и меньше, если такое случится.

Healthcare, финансы, и т.п.

Потому что между бардаком вида «клиент не получил e-mail со скидкой в 10% на день рождения» и «пациенту с аллергией выписали рецепт на неправильное лекарство» разница достаточно большая

ми купимо готовий CRM і

Ты хоть приблизительно представляешь объем работ и стоимость внедрения нового CRM в большой компании?

залучити всю команду до поділу і тимчасово зупинити нову розробку;

А що обов’язково було весь моноліт відразу ділити. По частинах ніяк?

Так можно продать больше тушек/жопочасов.

Читаючи Lessons Learned є відчуття, що на мікросервіси ви так і не перейшли (і скоріш за все не перейдете).

Це той самий випадок, коли все більш-менш працювало на «старому» моноліті і приносило профіт бізнесу. А потім комусь приходить ідея — а давайте зробимо мікросервіси! Це стильно, модно, маладьожно!

Ітог — просрані тисячі євро замовника (якому ви скоріш за все не повідомили про співвідношення ризиків до бенефітів), вповільнена розробка фіч існуючого продукту на моноліті, зниження мотивації команди.
Можна лише уявити психологічний стан розробників, які роблять цю міграцію, а світла у кінці тунеля не видно. Хоча стійте — видно! А, ні, це зустрічний поїзд.

Може вони просто хотіли «потрусити» клієна і підсадити його на голку, а ви тут пишете про модно/стильно. В такому випадку «мікросервіси» це ідеальна архітектура.
Якщо без сарказму, автор привів дуже мало цифр щоб сказати було воно дійсно потрібно чи ні.

ну написав що вперлись в можливості ажуру масштабувати моноліт

в цих випадках сенс є, якщо це допомогло і вирішило конкретні проблеми.

Хм, така цікава тема, такий лонгрід, але жодної діаграми, жодного числа, майже окрім 20 років. Як так?

залучити всю команду до поділу і тимчасово зупинити нову розробку;

Оце не спрацює, не лише тому що клієнт вас пошле нах з ймовірністю 99.999%, а ще й тому, що буде бардак, оскільки під таку задачу треба не всі ті ж ролі в тих же об’ємах, як і під розробку фіч чи багофікс.

помножити естімейти вдвічі, а краще втричі.

А чому не 10? Чому не спрацює PERT?

Сама головна проблема з цими поділами, що, як правило, не хватає коштів та ресурсів на це. На запитання, що отримаємо нового від керівництва? Складно відповісти в його цінностях. А це час та гроші. Хоч всі розуміють, що треба щось міняти з монолітним продуктом 10,20+ років. Але, ну не цього року, може завтра, після завтра ну ітд

Сама головна проблема з цими поділами, що, як правило, не хватає коштів та ресурсів на це. На запитання, що отримаємо нового від керівництва? Складно відповісти в його цінностях. А це час та гроші

З позиції стратег-не-тактик тут все просто:
Визначаємо ключові якісні атрибути, пріоритизуємо їх з бізнес стейкхолдерами, показуємо ризики по кожному з них в термінах страти часу та грошей.
На практиці все буде звісно складніше ніж 1 речення :)

Хоч всі розуміють, що треба щось міняти з монолітним продуктом 10,20+ років.

Не кожен моноліт треба пиляти на мікросервіси.
Якщо реально є необхідність, то вона зазвичай легко переводиться в час та гроші. Напрклад: ми втратили клієнта, бо додавання фічі в репортинг зайняло 2Х часу порівняно з тим, що треба було клієнту, а от з окремим сервісом зайняло б 0.9Х.
Якщо таких сценаріїв складно набрати, то можливо і не варто розбивати на мікросервіси (з ними теж буде купа проблем, просто інших порівняно з монолітом)

На запитання, що отримаємо нового від керівництва? Складно відповісти в його цінностях

Если действительно сложно ответить, то это классическое «решение в поисках проблемы»

Але, ну не цього року, може завтра, після завтра ну ітд

Значит действительно не критично — и скорее всего не стоит чинить то, что не поломано

это классическое «решение в поисках проблемы»

оце мені прям сподобалось;
Дякую!

залучити всю команду до поділу і тимчасово зупинити нову розробку;

На цьому можна розходитись :-)

Чому ж? Це вигідно і для старої команди. Такий підхід має назву: «Resume-Driven Development», і буде з успіхом використовуватись старою командою при пошуку нової роботи одразу чи трохи згодом після розпилу моноліта і репортінга про «вдалу» міграцію. Бо саппортити нового монстра буде той ще квест :)

Підписатись на коментарі