Декомпозиция системы на микросервисы

Несколько слов о планируемом вебинаре. Сидат Варасингх на DZone предложил различать три стратегии замены монолита микросервисами. Первая стратегия: скуп(ложка такая, специальная) для мороженого. По мере необходимости мы осторожно выскребаем фрагменты функционала из унаследованного приложения и реализуем их посредством микросервисов. Вторая стратегия: продолжительное сосуществование legacy, реализованного в виде монолита или набора сервисов, с новым функционалом, выполненным в виде микросервисов. Она называется – стратегия лего. И третья: стратегия взрыва, которая заключается в написании нового приложения сразу в микросервисной архитектуре. Третий вариант не согласуется с принципом Monolith First, но об этом чуть позже.

Проблема, на мой взгляд, состоит в том, что мы не можем выбирать какой стратегии нам следовать. Если идея сделать что-нибудь хорошее посредством микросервисов уже продана организации, то и стратегия уже выбрана. Например, если тот или иной комитет утвердил лозунг: «Новую систему X (платформу, продукт – не важно) мы делаем в микросервисной архитектуре», то ссылаться на принцип Monolith First уже поздно. В лучшем случае вам найдут заметку Стефана Тилкова Don’t start with a monolith … when your goal is a microservices architecture а в реалистичном — вашему проекту нового руководителя. Точно так же если под идею попробовать микросервисы не выделены бюджеты и люди, но зато дано обещание ничего не cломать, то речь будет идти о стратегии мороженого. Правда рано или поздно у вас обязательно спросят: а когда же наш монолит закончится? А вот стратегия номер два выглядит более-менее реалистично, но авторы эссе и колонок уделяют ей наименьшее внимание. Одним словом, нет какого-то одного правильного пути в микросервисы. Каждая ситуация заслуживает своего отдельного рассмотрения.

Следующий момент. Вместе с популярным названием и стратегией, обычно, проданы уже и цели, ну или, как минимум, ожидания. В общем ответ на вопрос «Зачем?» либо уже озвучен, либо подразумевается. Некоторые варианты таких ответов приведены в девяти характеристиках микросервисов или статье Микросервисные компромисы того же Фаулера.  Про компромиссы чуть позже, сначала про ожидания. Говоря словами классика: каждая несчастливая организация, в данный момент времени, осознает свое несчастье по-своему. Кого-то не первый год беспокоит time-to-market. Другие застряли в устаревших решениях и болезненно чувствую свое технологическое отставание. Третьи устали от релизов core-систем, когда 1-2 раза в квартал айтишники, измотанные овертаймами накануне релиза, судорожно стараются починить то, что рассыпалось в результате установки этого самого релиза. Соответственно, обещали вылечить именно то, что больше всего болит. И если не выполняется основное обещание, то разглагольствования о других полезных свойствах микросервисной архитектуры выглядят не особо уместными: ну и что, что у нас старый фунционал рассыпается, зато новый автоматически масштабируется – лишняя фраза. В общем, ожидаемые полезности микросервисов следует, как минимум, расставить в порядке приоритетов. Например, безболезненное развитие функционала core-систем между большими релизами за счет добавления его в виде новых микросервисов – это раз, задействование новых технологий – это два, а time-to-market – это приоритет номер восемь.

И последнее на сегодня, про компромиссы. Когда некто продвигал в организации микросервисы, то наверняка его спрашивали о затратах. И ответ его звучал так: нужно будет развернуть новую инфраструктуру с решениями CNCF, что потребует привлечение 3-5 экспертов, проектирование должно стать более тщательным, разработчикам придется чуть-чуть подучиться… Это неправильный ответ. Вернее, правильный, но не полный. Главный вопрос при внедрении cloud-native или микросервисов, да чего угодно: на какие жертвы организация готова пойти. Вы, вообще, готовы расстаться с ACID в пользу eventual consistency, хотя бы в чём-то? Маркетинг и CХ в вашей компании понимает что такое Task-based UI и без сожалений расстанется с CRUD? Как долго ваши клиенты будут ждать актуализации данных или как быстро начнут осаждать вопросами операторов контакт-центра? В общем, компромиссы они не в перераспределении бюджета между проектами или ФОТа внутри ИТ. Они в изменении бизнес-операций, размывании ответственности, переучивании клиентов и привлечении других партнеров.

Хотите подробностей? Регистрируйтесь на бесплатный вебинар на сайте IT Expert:  https://www.itexpert.ru/rus/webinars/MSA-WEB/ Задавайте вопросы на странице мероприятия в Facebook: https://www.facebook.com/events/921580398233599/

3 ответ. на "Декомпозиция системы на микросервисы"

    1. Как и стратегия №1, разве нет? Я бы разделил задачи замены функционала и замены взаимодействий. При трансформации корпоративного ландшафта можно(и нужно) работать с взаимодействиями(или интеграциями). При переписывании монолитного приложения их, к сожалению, не видно.

      Спасибо за комментарий! Я его учту в вебинаре

  1. Да. Разница между №1 и №2 в том, насколько можно менять монолит. Если монолит поддается изменениям, то №1, а если нет — №2 и паттерн «затмение». Согласен, что надо явно отделять замену функционала и замену взаимодействия. Можно еще добавить замену топологии, т.е. экстернализацию. Вот более современная версия паттерна — слайды 45-50 https://www.slideshare.net/samarin/minicourse-at-vfu-architecting-modern-digital-systems-4 и глава 5 из https://improving-bpm-systems.blogspot.com/2019/03/better-architecting-with-solution.html

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s