В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их вместе, получить ту же систему, но на новой архитектуре.
Такого никогда не бывает в жизни.
Жизнь вносит множество сложностей в эту идеальную картину.
Какие конкретно трудности могут увеличить бюджет перехода на микросервисы в два-три раза? Я опишу факторы, которые задерживают процесс перехода на микросервисы и делают его намного дороже, чем предполагалось изначально.
Вы получите контрольный список для оценки этих факторов и сможете более реалистично рассчитать свой переходный бюджет.
Я говорил на эту тему на АрхДэйс 2020 .Перейдите по ссылке, чтобы просмотреть слайды и видео.
(будет опубликовано в ближайшее время) речи https://blog.byndyu.ru/2020/12/archdays-2020.html .
№1 Изменение подхода к работе с мастер-данными
Монолит обычно имеет одну или две большие базы данных, содержащие разные основные данные.Сам монолит содержит код, который управляет этими основными данными.
Например, если «зеленая» часть базы данных — это адресная книга, то «зеленый» монолитный код управляет адресами.
Оказывается, в базе монолита много мастер-данных, а в коде монолита много мастер-систем:
В микросервисах управление основными данными происходит иначе: баз данных много, основные данные нельзя смешивать между микросервисами, а управлять основными данными может только один микросервис.
Например, у «зеленого» микросервиса теперь есть своя база данных с адресами и только он может вносить изменения в эти основные данные.
Другие микросервисы могут читать данные с адресами, но только через «зеленый» микросервис:
В оценку перехода необходимо включить четкое различие между основными данными и основными системами микросервисов.
Такого рода работа занимает довольно много времени, которое тратится на следующее:
- анализ монолитной схемы данных,
- анализ потоков обработки данных,
- анализ использования данных сторонними системами,
- бизнес-цели компании по работе с данными,
- «нарезка» данных в новые базы данных,
- миграция данных в новые микросервисные базы данных,
- миграционное тестирование.
В статье описаны четыре основные стратегии работы с мастер-данными.Как и остальные 9 факторов, обработка мастер-данных должна быть оценена и учтена в бюджете перехода на микросервисы еще до начала перехода.Управление основными данными в микросервисной архитектуре .
№2 Невозможность повторного использования исходного кода монолита
При беглом рассмотрении кода монолита может показаться, что код аккуратно разделен на бизнес-контекст и это не нарушается принцип единоличной ответственности .Если это так, то можно взять монолитный код, распределить этот код по микросервисам, соединить микросервисы между собой и получить ту же систему, но на микросервисной архитектуре.
Практика показывает, что границы ответственности каким-то образом раздвигаются внутри монолита.
Из-за этого невозможно использовать «копипаст» из монолита для заполнения микросервиса кодом.
Весь код и тесты придется писать с нуля, чтобы правильно разделить обязанности между микросервисами.
Если произойдет чудо и код монолита окажется написанным идеально (чего никогда не бывает), то этот код все равно придется дополнять и переписывать под требования микросервисной архитектуры и изменения в инфраструктуре (см.
пункт 4).
Не обманывайтесь оптимизмом владельца продукта и разработчиков монолита.
Вкладывайте столько времени своих разработчиков и тестировщиков, как если бы вы писали систему с нуля, а не просто перемещали готовый код из одного места в другое.
Кроме того, перед началом работы желательно договориться с командой, написавшей монолит, чтобы они выделили время для ваших вопросов по коду.
№3 Редизайн системы
Разработчики так или иначе перепишут код монолита, но нам нужен кто-то, кто правильно разделит монолит на микросервисы исходя из бизнес-требований.При проектировании микросервисной архитектуры необходимо учитывать текущее состояние бизнеса и будущие цели.
Вам придется повторно проанализировать потребности вашего бизнеса, чтобы сделать правильный разрез:
Запланируйте время, чтобы ИТ-архитектор, бизнес-аналитики и заинтересованные стороны могли проанализировать бизнес-требования.
Кроме того, запланируйте время на проектирование API будущей системы.
#4 Создание нового подхода к управлению инфраструктурой
Микросервисы предъявляют новые требования к инфраструктуре.Невозможно взять инфраструктуру монолита и развернуть на ней микросервисы.
Нужно учитывать множество особенностей и использовать специальные инструменты, чтобы не оказаться в ситуации, когда вместо монолита вы создали микросервисный монолит :
Что следует учитывать при оценке:
- Создание инфраструктуры управления API: анализ вызовов, система прав, публикация API и т.д. Для примера рекомендую посмотреть функционал Апигей .
- Переход DevOps-инженеров на работу только в концепции IaC и контейнеризация.
- Реализуйте полное ведение журнала и мониторинг микросервисной архитектуры.
#5 Измерение и проверка SLA каждого микросервиса
Обычно соглашения об уровне обслуживания для вызовов функций не измеряются в рамках монолита.Мало кто отслеживает скорость ответа метода в коде или скорость хранения.
При разделении монолита на микросервисы метод, который ранее вызывался из кода, становится вызовом API. Мы должны гарантировать другим микросервисам определенное соглашение об уровне обслуживания, чтобы весь проект работал предсказуемо.
Для любителей СРЕ Поясню, что здесь правильнее было бы использовать термин SLO, потому что SLA = SLO + санкции за нарушение договоренностей.Другими словами, ранее неявные соглашения об уровне обслуживания становятся явными и требуют доработки:
Работа по определению SLA каждого микросервиса, описанию SLA, тестированию и постоянному мониторингу стоит денег, сама по себе она не произойдет. Это достаточно сложный процесс и его необходимо включить в бюджет.
№6. Микросервисы добавят на несколько порядков больше точек отказа.
Наряду со значительным увеличением количества сервисов по сравнению с монолитом вы получаете увеличение точек интеграции, усложнение процесса CI/CD и распределения мастер-данных, что существенно усложнит всю инфраструктуру.
Шанс получить проблему на производстве будет очень высок, если вы не будете целенаправленно вкладывать средства в отказоустойчивость на всех уровнях: проектировании архитектуры, разработке и тестировании.
Для создания стабильных систем, способных противостоять потрясениям внешней среды, заложите в бюджет следующее:
- Нагрузочное и стресс-тестирование, а в идеале — приложения Хаос-инжиниринг .
- Применение шаблонов проектирования, таких как Автоматический выключатель И Толерантный читатель .
- Настройка инфраструктуры: обнаружение сервисов, проверка работоспособности,.
#7 Реорганизация команды
Когда монолит распадется на множество мелких независимых микросистем, возникнет вопрос: как теперь людям организоваться вокруг этого «роя»?Общее решение звучит так: для каждого микросервиса создайте кросс-функциональные команды (команды сборки и запуска).
Но есть нюансы.
Прежде чем приступить к работе, обсудите и выберите, какая организационная структура подойдет под ваши задачи и ваш бизнес.
Обратите внимание на следующее:
- Выберите подход к распределению обязанностей команды по микросервисам.
Например, возьмем вот этот Сервис на команду .
- Попробуйте InnerSource, чтобы избавить ваши команды микросервисов от входящих запросов.
InnerSource и микросервисы хорошо работают вместе.
.
- Выберите стратегию работы с исходным кодом: монореп, репозиторий продуктов, репозиторий микросервисов.
Если вы решили сделать что-то кроме монорепа, то сразу подумайте, как вы будете распространять общий код микросервисов и как будете управлять общими пакетами.
Если вы выберете монореп, постарайтесь найти инструменты разработки и развертывания, поддерживающие этот подход.
Поэтому обязательно учтите эти процессы в своем плане миграции микросервисов.
Замечание о постепенном переходе
Крупные системы, на которых зарабатывает бизнес, обычно не сразу переходят на новую версию.
Типичный график постепенной замены монолита микросервисами выглядит так:
Самое главное в схеме то, что системы долго живут вместе.
Даже функционал, который уже реализован в микросервисах, не отключается сразу в монолите.
Это важно для следующих трех факторов.
#8 Обратная совместимость с монолитом
Бизнес захочет снизить свои риски и не отключать монолит сразу, а постепенно переходить на микросервисы.Функциональность, реализованная в микросервисах, будет работать параллельно с той же функциональностью в монолите.
Поэтому вам придется реализовать обратную совместимость микросервисов с монолитом.
Это первая часть работы, которую необходимо включить в смету.
Вторая часть работы связана с тем, что монолит не всегда готов принимать потоки данных в удобных для микросервисов протоколах и форматах.
Например, монолит работает с SOAP, а вы реализуете все в protobuf, или монолит знает WCF, а вы пишете на .
NET Core, где WCF реализован частично.
Поэтому часто необходимо дорабатывать функции в монолите, чтобы микросервисы могли отправлять в него данные.
Чтобы эти задачи выполнялись, нужно заранее договориться с командой монолита, с каким приоритетом и по какому процессу они будут принимать задачи от команды микросервисов.
В вашей оценке нужно учитывать доработки микросервисов и монолита для создания обратной совместимости, а также совместное тестирование.
#9 Интеграция и обучение служб поддержки
Если система критически важна для бизнеса, то у нее уже есть процесс технической поддержки.Вам потребуется интегрироваться со службой техподдержки и выстроить процесс техподдержки для двух систем одновременно.
Это обычные шаги при замене старой системы на новую.
Но вот что происходит неожиданно, так это то, что раньше техподдержка иногда залезала в правила базы данных или файлов или «проталкивала» что-то вручную через процесс.
И теперь база данных не одна, их много и они разные.
Файлы находятся где-то в облаке, а информация летит по очередям.
Поэтому вам необходимо учитывать в своей оценке обучение инженеров технической поддержки работе в микросервисной архитектуре.
№ 10. Догоняющий поток функций от бизнеса
Пока новая система постепенно вытесняет старую, бизнес не стоит на месте.Вы не сможете приостановить появление новых функций.
Например, если ЦБ решит изменить правила игры и эти правила затрагивают бизнес, то необходимо будет взять на себя задачу по изменению правил и реализовать ее как в монолите, так и в микросервисах.
Чтобы догоняющий поток функций вашего бизнеса не стал для вас неожиданностью, вам необходимо:
- Заранее согласуйте с командой, разрабатывающей монолит, правила сотрудничества.
- Согласуйте с бизнесом процесс внедрения новых функций в течение срока службы обеих систем.
При оценке перехода на микросервисы учитывайте координацию команд новой и старой систем для работы над новыми функциями и работу по поддержанию обратной совместимости с изменениями монолита и микросервисов.
Контрольный список
По опыту могу сказать, что эти десять пунктов могут занять больше времени и денег, чем само написание системы с использованием микросервисов.Прежде чем приступить к работе по разбиению монолита на микросервисы, рекомендую пройтись по чек-листу, чтобы ничего не упустить:
- Основные данные
- Написание кода по-новому
- Редизайн ИТ-продукта
- Создание новой инфраструктуры
- Измерение и проверка SLA
- Вклад в отказоустойчивость на всех уровнях
- Реорганизация команды
- Работа по обратной совместимости
- Интеграция службы поддержки
- Догоняющий поток функций
После всего описанного выше у вас может возникнуть вопрос, зачем вообще переходить на микросервисы, если это так долго и дорого? Ответ на этот вопрос содержится, например, в мое выступление на AgileDays 2017 и в описании на микросервисы.io
.Чтобы принять обоснованное решение о переходе, а не просто следовать прихоти, желательно оценить плюсы и минусы для вашей конкретной ситуации.
Ссылки на дайвинг:
- Смерть микросервисного безумия в 2018 году Дэйв Керр
- Скрытые издержки микросервисов , Уэйн Гейлс, Майк Хостетлер
- Компромиссы микросервисов Мартин Фаулер
- Шаблон: микросервисная архитектура Крис Ричардсон
- Скрытые издержки микросервисов , Джастин Лейтгеб
- Проблемы и преимущества микросервисного архитектурного стиля Часть 1 + Часть 2 Андре Фаша
