В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?
Я опишу факторы, которые затягивают процесс перехода на микросервисы и делают его сильно дороже, чем ожидалось вначале. Вы получите чеклист для оценки этих факторов и будете более реалистично считать бюджет перехода.
С этой темой я выступал на ArchDays 2020. По ссылке вы найдете слайды и видео (скоро будет опубликовано) выступления https://blog.byndyu.ru/2020/12/archdays-2020.html.
№1 Изменение подхода к работе с мастер-данными
У монолита обычно есть одна или две большие базы данных, содержащие в себе разношерстные мастер-данные. В самом монолите написан код, который управляет этими мастер-данными. Например, если "зеленая" часть базы данных — это адресный справочник, то "зеленый" код монолита управляет адресами. Получается в базе данных монолита множество мастер-данных, а в коде монолита много мастер-систем:
В микросервисах управление мастер-данным происходит иначе: баз данных много, перемешивать мастер-данные между микросервисами нельзя, а управлять мастер-данными может только один микросервис. Например, "зеленый" микросервис теперь получил свою базу данных с адресами и только он может вносить изменения в эти мастер-данные. Другие микросервисы могут читать данные с адресами, но только через "зеленый" микросервис:
Четкое разграничение мастер-данных и мастер-систем по микросервисам нужно закладывать в оценку перехода. Занимает такая работа довольно много времени, которое уходит на следующее:
анализ схемы данных монолита,
анализ потоков обработки данных,
анализ использования данных сторонними системами,
бизнес-цели компании по работе с данными,
"нарезка" данных по новым базам,
миграция данных в новые базы микросервисов,
тестирование миграции.
Четыре основные стратегии работы с мастер-данными описаны в статье Управления мастер-данными в микросервисной архитектуре.
Как и остальные 9 факторов, переработку мастер-данных нужно оценивать и учитывать в бюджете перехода на микросервисы еще до старта перехода.
№2 Невозможность переиспользования исходного кода монолита
При беглом изучении кода монолита может показаться, что код аккуратно разделен по бизнес-контекстам и в нем не нарушается принцип единственности ответственности. Если это так, значит можно взять код монолита, распределить этот код по микросервисам, соединить микросервисы между собой и получится та же система, но на микросервисной архитектуре.
Практика показывает, что границы ответственности так или иначе растекаются внутри монолита. Из-за этого не получается использовать "копипаст" из монолита для заполнения микросервиса кодом. Весь код и тесты придется написать с нуля для правильного разделения ответственностей по микросервисам.
Если случилось чудо и код монолита окажется идеально написан (чего никогда не происходит), то всё равно этот код придется дописывать и переписывать под требования микросервисной архитектуры и под изменения в инфраструктуре (см. п.4).
Не поддавайтесь на оптимизм владельца продукта и разработчиков монолита. Закладывайте столько времени своих разработчиков и тестировщиков, как если бы вы писали систему с нуля, а не просто переносили готовый код из одного места в другое. Кроме этого, до начала работ желательно договориться с командой, писавшей монолит, чтобы они выделили время на ваши вопросы по коду.
№3 Проектирование системы заново
Разработчики так или иначе перепишут код монолита, но нужен кто-то, кто правильно разделит монолит на микросервисы, исходя из бизнес-требований. При проектировании микросервисной архитектуры нужно учесть текущее состояние бизнеса и будущие цели. Вам придется заново сделать анализ потребностей бизнеса для правильной “нарезки”:
Запланируйте время IT-архитектора, бизнес-аналитиков и стейкхолдеров на анализ бизнес-требований. Кроме этого, запланируйте время на проектирование API будущей системы.
№4 Создание нового подхода к управлению инфраструктурой
Микросервисы предъявляют новые требования к инфраструктуре. Не получится взять инфраструктуру монолита и на ней развернуть микросервисы. Нужно учесть множество особенностей и применить специальные инструменты, чтобы не попасть в ситуацию, когда вместо монолита вы создали микросервисный монолит:
Что нужно учесть в оценке:
Создание инфраструктуры для управления API: анализ вызовов, система прав, публикация API и т.д. Для примера рекомендую посмотреть функциональность Apigee.
Переход DevOps-инженеров на работу только в концепции IaC и контейнеризацию.
Реализовать тотальное логирование и мониторинг микросервисной архитектуры.
№5 Измерение и проверка SLA каждого микросервиса
Обычно внутри монолита не замеряются SLA вызова функций. Мало кто отслеживает скорость ответа метода в коде или скорость работы хранимки. При разделении монолита на микросервисы, метод, который раньше вызывался из кода, становится вызовом API. Приходится гарантировать другим микросервисам конкретный SLA, чтобы вся конструкция работала предсказуемо.
Для любителей SRE уточню, что здесь было бы правильнее использовать термин SLO, потому что SLA = SLO + санкции за нарушение договоренностей.
Другими словами, ранее неявный SLA становятся явными и требует проработки:
Работа по определению SLA каждого микросервиса, описанию SLA, тестированию и постоянному мониторингу стоит денег, она не случится сама собой. Это довольно сложный процесс и его надо закладывать в бюджет.
№6 Микросервисы добавят на порядок больше точек отказа
Вместе со значительным увеличением числа сервисов по сравнению с монолитом, вы получаете рост точек интеграции, усложнение процесса CI/CD и распределение мастер-данных, что значительно усложнит всю инфраструктуру. Шанс получить проблему на проде будет очень высоким, если целенаправлено не вкладываться в fault tolerance на всех уровнях: проектирование архитектуры, разработка и тестирование.
Чтобы создавать стабильные системы, выдерживающие "толчки" внешней среды, заложите в бюджет перехода на микросервисы следующее:
Нагрузочное и стресс-тестирование, и, в идеале, применение chaos engineering.
Применение шаблонов проектирования, таких как Circuit Breaker и Tolerant Reader.
Настройка инфраструктуры: service discovery, health-check,...
№7 Реорганизация команд
Когда монолит распадется на много маленьких независимых микро-систем, то встанет вопрос, как теперь организоваться людей вокруг этого "роя"?
Общее решение звучит так: создавайте кросс-функциональные команды (build-and-run team) под каждый микросервис. Но есть нюансы. До старта работ обсудите и выберете какая оргструктура подойдет под ваши задачи и ваш бизнес. Обратите внимание на следующее:
Выберите подход к распределению ответственности команд между микросервисами. Например, возьмите вот такой Service per team.
Примерьте на себя InnerSource, чтобы разгрузить команды микросервисов от входящих запросов. InnerSource и микросервисы хорошо работают вместе.
Выберите стратегию работы с исходным кодом: монорепа, репозиторий под продукт, репозиторий под микросервис. Если вы решите делать не монорепу, то сразу подумайте, как вы будете выносить общий код микросервисов и как будете управлять общими пакетами. Если вы выберите монорепу, то попробуйте найти инструменты для разработки и деплоя, которые смогут поддерживать этот подход.
Реорганизация команд не произойдет сама собой, она стоит денег и времени. Поэтому не забудьте учесть эти процессы в вашем плане перехода на микросервисы.
Ремарка о постепенности перехода
Большие системы, на которых бизнес зарабатывает деньги, обычно не переключается одномоментно на новую версию. Типовой график постепенной замены монолита на микросервисы выглядит так:
Самое важно на схеме то, что системы долгое время живут вместе. Даже функциональность, которая уже реализована на микросервисах, не сразу отключается в монолите. Это важно для следующих трех факторов.
№8 Обратная совместимость с монолитом
Бизнесу захочется снизить свои риски и не выключать монолит сразу, а переходить на микросервисы постепенно. Функциональность, реализованная в микросервисах, будет работать параллельно с той же функциональностью в монолите. Поэтому вам придется реализовывать обратную совместимость микросервисов с монолитом. Это первая часть работы, которую нужно закладывать в оценку.
Вторая часть работы связана с тем, что монолит не всегда готов принимать потоки данных в протоколах и форматах удобных для микросервисов. Например, монолит работает с SOAP, а вы всё реализовываете на protobuf, или монолит знает WCF, а вы пишите на .NET Core, где WCF реализован частично. Поэтому часто приходится доделывать функции в монолите, чтобы микросервисы могли отсылать в него данные. Чтобы эти задачи были сделаны, нужно заранее договориться с командой монолита с каким приоритетом и по какому процессу они будут принимать задачи от команды микросервисов.
В оценке вам нужно учесть доработки в микросервисах и в монолите для создания обратной совместимости, а также совместное тестирование.
№9 Интеграция и обучение служб поддержки
Если система критична для бизнеса, значит у нее уже есть процесс техподдержки. Вам нужно будет интегрироваться со службой техподдержки и выстроить процесс техподдержки двух систем одновременно.
Это обычные действия при замене старой системы на новую. Но что бывает неожиданно, так это то, что раньше техподдержка иногда залезала в базу данных или правила файлик или "пропихивала" что-то вручную по процессу. А теперь база данных не одна, их много и они разные. Файлики где-то в облаке, а информация летает через очереди. Поэтому вам нужно заложить в оценку обучение инженеров техподдержки работе в микросервисной архитектуре.
№10 Догоняющий поток фич от бизнеса
Пока новая система постепенно заменяет старую, бизнес не стоит на месте. Не получится поставить на паузу поток новых фич. Например, если Центральный Банк решит поменять правила игры и эти правила затрагивают бизнес, то придется взять в работу задачу от бизнеса на изменение правил и реализовать ее как в монолите, так и в микросервисах.
Чтобы догоняющий поток фич от бизнеса не стал для вас сюрпризом, нужно:
Заранее договориться с командой, разрабатывающей монолит о правилах совместной работы.
Договориться с бизнесом о процессе внесения новых фич в период жизни обеих систем.
В оценке перехода на микросервисы учитывайте координацию команд новой и старой систем по работе над новыми фичами и работы по сохранению обратной совместимости при изменениях в монолите и микросервисах.
Чеклист
По опыту скажу, что эти десять пунктов могут отнять больше времени и денег, чем само написание системы на микросервисах. Перед стартом работы над дроблением монолита на микросервисы рекомендую пройтись по чеклисту, чтобы ничего не упустить:
Мастер-данные
Написание кода по-новому
Проектирование IT-продукта заново
Создание новой инфраструктуры
Измерение и проверка SLA
Вклад в fault tolerance на всех уровнях
Реорганизация команд
Работы по обратной совместимости
Интеграция служб поддержки
Догоняющий поток фич
Если в плане перехода вы учли все пункты, то скорее всего довольно точно попадете в оценку.
После всего описанного выше вы могли задуматься, зачем вообще переходить на микросервисы, если это так долго и дорого? Ответ на этот вопрос есть, например, в моем выступлении на AgileDays 2017 и в описании на microservices.io. Чтобы принять взвешенное решение о переходе, а не просто пойти за модой, желательно оценить плюсы и минусы для вашей конкретной ситуации.
Ссылки для погружения:
The Death of Microservice Madness in 2018, Dave Kerr
The hidden costs of microservices, Wayne Geils, Mike Hostetler
Microservice Trade-Offs, Martin Fowler
Pattern: Microservice Architecture, Chris Richardson
The Hidden Costs of Microservices, Justin Leitgeb
Challenges and benefits of the microservice architectural style Part 1 + Part 2, André Fachat
