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

Несколько слов о планируемом вебинаре. Сидат Варасингх на 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/

Дополнение: запись вебинара

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

    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

  2. Максим! Смотрю запись одноимённого вебинара. Судя по показанный там диаграмме проникновения InfoQ микросервисы уже перешли в 4ю стадию к ретроградам. Значит ли это, что этот подход устаревает? Есть ли альтернативные подходы к проектированию ИТ архитектуры?

    1. Не то, чтоб устаревает. Скорее меняется, распадается на разные другие подходы. Термин стал настолько распространенным и не всегда корректно используемым, что многие предпочитают другие слова. Кто-то говорит о cloud-native приложениях, кто-то о stateless компонентах и т.д.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *