Скрытые расходы при переходе на микросервисы

В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?

Я опишу факторы, которые затягивают процесс перехода на микросервисы и делают его сильно дороже, чем ожидалось вначале. Вы получите чеклист для оценки этих факторов и будете более реалистично считать бюджет перехода.

С этой темой я выступал на ArchDays 2020. По ссылке вы найдете слайды и видео (скоро будет опубликовано) выступления https://blog.byndyu.ru/2020/12/archdays-2020.html.

№1 Изменение подхода к работе с мастер-данными

У монолита обычно есть одна или две большие базы данных, содержащие в себе разношерстные мастер-данные. В самом монолите написан код, который управляет этими мастер-данными. Например, если «зеленая» часть базы данных — это адресный справочник, то «зеленый» код монолита управляет адресами. Получается в базе данных монолита множество мастер-данных, а в коде монолита много мастер-систем:

26cd22a854a616fab5886dfc7ddf84c9

В микросервисах управление мастер-данным происходит иначе: баз данных много, перемешивать мастер-данные между микросервисами нельзя, а управлять мастер-данными может только один микросервис. Например, «зеленый» микросервис теперь получил свою базу данных с адресами и только он может вносить изменения в эти мастер-данные. Другие микросервисы могут читать данные с адресами, но только через «зеленый» микросервис:

3674b966d361c9d685a92006708c32e6

Четкое разграничение мастер-данных и мастер-систем по микросервисам нужно закладывать в оценку перехода. Занимает такая работа довольно много времени, которое уходит на следующее:

  1. анализ схемы данных монолита,

  2. анализ потоков обработки данных,

  3. анализ использования данных сторонними системами,

  4. бизнес-цели компании по работе с данными,

  5. «нарезка» данных по новым базам,

  6. миграция данных в новые базы микросервисов,

  7. тестирование миграции.

Четыре основные стратегии работы с мастер-данными описаны в статье Управления мастер-данными в микросервисной архитектуре.

Как и остальные 9 факторов, переработку мастер-данных нужно оценивать и учитывать в бюджете перехода на микросервисы еще до старта перехода.

№2 Невозможность переиспользования исходного кода монолита

При беглом изучении кода монолита может показаться, что код аккуратно разделен по бизнес-контекстам и в нем не нарушается принцип единственности ответственности. Если это так, значит можно взять код монолита, распределить этот код по микросервисам, соединить микросервисы между собой и получится та же система, но на микросервисной архитектуре.

f0af42d06b9ef8f1eb29f67e91e28e08

Практика показывает, что границы ответственности так или иначе растекаются внутри монолита. Из-за этого не получается использовать «копипаст» из монолита для заполнения микросервиса кодом. Весь код и тесты придется написать с нуля для правильного разделения ответственностей по микросервисам.

4b696e36b29634e9510cfde5bd7b4aa1

Если случилось чудо и код монолита окажется идеально написан (чего никогда не происходит), то всё равно этот код придется дописывать и переписывать под требования микросервисной архитектуры и под изменения в инфраструктуре (см. п.4).

Не поддавайтесь на оптимизм владельца продукта и разработчиков монолита. Закладывайте столько времени своих разработчиков и тестировщиков, как если бы вы писали систему с нуля, а не просто переносили готовый код из одного места в другое. Кроме этого, до начала работ желательно договориться с командой, писавшей монолит, чтобы они выделили время на ваши вопросы по коду.

№3 Проектирование системы заново

Разработчики так или иначе перепишут код монолита, но нужен кто-то, кто правильно разделит монолит на микросервисы, исходя из бизнес-требований. При проектировании микросервисной архитектуры нужно учесть текущее состояние бизнеса и будущие цели. Вам придется заново сделать анализ потребностей бизнеса для правильной «нарезки»:

6403b5470b601bb8c8b6ca8c45282585

Запланируйте время IT-архитектора, бизнес-аналитиков и стейкхолдеров на анализ бизнес-требований. Кроме этого, запланируйте время на проектирование API будущей системы.

№4 Создание нового подхода к управлению инфраструктурой

Микросервисы предъявляют новые требования к инфраструктуре. Не получится взять инфраструктуру монолита и на ней развернуть микросервисы. Нужно учесть множество особенностей и применить специальные инструменты, чтобы не попасть в ситуацию, когда вместо монолита вы создали микросервисный монолит:

4f6f81d5582ce52ba7a86975318ad911

Что нужно учесть в оценке:

  1. Создание инфраструктуры для управления API: анализ вызовов, система прав, публикация API и т.д. Для примера рекомендую посмотреть функциональность Apigee.

  2. Переход DevOps-инженеров на работу только в концепции IaC и контейнеризацию.

  3. Реализовать тотальное логирование и мониторинг микросервисной архитектуры.

№5 Измерение и проверка SLA каждого микросервиса

Обычно внутри монолита не замеряются SLA вызова функций. Мало кто отслеживает скорость ответа метода в коде или скорость работы хранимки. При разделении монолита на микросервисы, метод, который раньше вызывался из кода, становится вызовом API. Приходится гарантировать другим микросервисам конкретный SLA, чтобы вся конструкция работала предсказуемо.

Для любителей SRE уточню, что здесь было бы правильнее использовать термин SLO, потому что SLA = SLO + санкции за нарушение договоренностей.

Другими словами, ранее неявный SLA становятся явными и требует проработки:

b6ae8ef41cb709e2692fa543b89d497f

Работа по определению SLA каждого микросервиса, описанию SLA, тестированию и постоянному мониторингу стоит денег, она не случится сама собой. Это довольно сложный процесс и его надо закладывать в бюджет.

№6 Микросервисы добавят на порядок больше точек отказа

Вместе со значительным увеличением числа сервисов по сравнению с монолитом, вы получаете рост точек интеграции, усложнение процесса CI/CD и распределение мастер-данных, что значительно усложнит всю инфраструктуру. Шанс получить проблему на проде будет очень высоким, если целенаправлено не вкладываться в fault tolerance на всех уровнях: проектирование архитектуры, разработка и тестирование.

64470bcbdbc8e5470f2d2c34cf06fd42

Чтобы создавать стабильные системы, выдерживающие «толчки» внешней среды, заложите в бюджет перехода на микросервисы следующее:

  1. Нагрузочное и стресс-тестирование, и, в идеале, применение chaos engineering.

  2. Применение шаблонов проектирования, таких как Circuit Breaker и Tolerant Reader.

  3. Настройка инфраструктуры: service discovery, health-check,…

№7 Реорганизация команд

Когда монолит распадется на много маленьких независимых микро-систем, то встанет вопрос, как теперь организоваться людей вокруг этого «роя»?

74c5ceb3be1e4f1a158cdbb86e56c6b4

Общее решение звучит так: создавайте кросс-функциональные команды (build-and-run team) под каждый микросервис. Но есть нюансы. До старта работ обсудите и выберете какая оргструктура подойдет под ваши задачи и ваш бизнес. Обратите внимание на следующее:

  1. Выберите подход к распределению ответственности команд между микросервисами. Например, возьмите вот такой Service per team.

  2. Примерьте на себя InnerSource, чтобы разгрузить команды микросервисов от входящих запросов. InnerSource и микросервисы хорошо работаю вместе.

  3. Выберите стратегию работы с исходным кодом: монорепа, репозиторий под продукт, репозиторий под микросервис. Если вы решите делать не монорепу, то сразу подумайте, как вы будете выносить общий код микросервисов и как будете управлять общими пакетами. Если вы выберите монорепу, то попробуйте найти инструменты для разработки и деплоя, которые смогут поддерживать этот подход.

Реорганизация команд не произойдет сама собой, она стоит денег и времени. Поэтому не забудь учесть эти процессы в вашем плане перехода на микросервисы.

Ремарка о постепенности перехода

Большие системы, на которых бизнес зарабатывает деньги, обычно не переключается одномоментно на новую версию. Типовой график постепенной замены монолита на микросервисы выглядит так:

97fd6745d89000abb8c31a4659149fb8

Самое важно на схеме то, что системы долгое время живут вместе. Даже функциональность, которая уже реализована на микросервисах, не сразу отключается в монолите. Это важно для следующих трех факторов.

№8 Обратная совместимость с монолитом

Бизнесу захочется снизить свои риски и не выключать монолит сразу, а переходить на микросервисы постепенно. Функциональность, реализованная в микросервисах, будет работать параллельно с той же функциональностью в монолите. Поэтому вам придется реализовывать обратную совместимость микросервисов с монолитом. Это первая часть работы, которую нужно закладывать в оценку.

d005f716d92caa338f78352ce3dfee39

Вторая часть работы связана с тем, что монолит не всегда готов принимать потоки данных в протоколах и форматах удобных для микросервисов. Например, монолит работает с SOAP, а вы всё реализовываете на protobuf, или монолит знает WCF, а вы пишите на .NET Core, где WCF реализован частично. Поэтому часто приходится доделывать функции в монолите, чтобы микросервисы могли отсылать в него данные. Чтобы эти задачи были сделаны, нужно заранее договориться с командой монолита с каким приоритетом и по какому процессу они будут принимать задачи от команды микросервисов.

В оценке вам нужно учесть доработки в микросервисах и в монолите для создания обратной совместимости, а также совместное тестирование.

№9 Интеграция и обучение служб поддержки

Если система критична для бизнеса, значит у нее уже есть процесс техподдержки. Вам нужно будет интегрироваться со службой техподдержки и выстроить процесс техподдержки двух систем одновременно.

5b71c11f0a611e8440b6a9a9d9c0acfc

Это обычные действия при замене старой системы на новую. Но что бывает неожиданно, так это то, что раньше техподдержка иногда залезала в базу данных или правила файлик или «пропихивала» что-то вручную по процессу. А теперь база данных не одна, их много и они разные. Файлики где-то в облаке, а информация летает через очереди. Поэтому вам нужно заложить в оценку обучение инженеров техподдержки работе в микросервисной архитектуре.

№10 Догоняющий поток фич от бизнеса

Пока новая система постепенно заменяет старую, бизнес не стоит на месте. Не получится поставить на паузу поток новых фич. Например, если Центральный Банк решит поменять правила игры и эти правила затрагивают бизнес, то придется взять в работу задачу от бизнеса на изменение правил и реализовать ее как в монолите, так и в микросервисах.

Чтобы догоняющий поток фич от бизнеса не стал для вас сюрпризом, нужно:

  1. Заранее договориться с командой, разрабатывающей монолит о правилах совместной работы.

  2. Договориться с бизнесом о процессе внесения новых фич в период жизни обеих систем.

992094b9347221cacad9068307eead54

В оценке перехода на микросервисы учитывайте координацию команд новой и старой систем по работе над новыми фичами и работы по сохранению обратной совместимости при изменениях в монолите и микросервисах.

Чеклист

По опыту скажу, что эти десять пунктов могут отнять больше времени и денег, чем само написание системы на микросервисах. Перед стартом работы над дроблением монолита на микросервисы рекомендую пройтись по чеклисту, чтобы ничего не упустить:

  1. Мастер-данные

  2. Написание кода по-новому

  3. Проектирование IT-продукта заново

  4. Создание новой инфраструктуры

  5. Измерение и проверка SLA

  6. Вклад в fault tolerance на всех уровнях

  7. Реорганизация команд

  8. Работы по обратной совместимости

  9. Интеграция служб поддержки

  10. Догоняющий поток фич

Если в плане перехода вы учли все пункты, то скорее всего довольно точно попадете в оценку.

После всего описанного выше вы могли задуматься, зачем вообще переходить на микросервисы, если это так долго и дорого? Ответ на этот вопрос есть, например, в моем выступлении на AgileDays 2017 и в описании на microservices.io. Чтобы принять взвешенное решение о переходе, а не просто пойти за модой, желательно оценить плюсы и минусы для вашей конкретной ситуации.

Ссылки для погружения:

  1. The Death of Microservice Madness in 2018, Dave Kerr

  2. The hidden costs of microservices, Wayne Geils, Mike Hostetler

  3. Microservice Trade-Offs, Martin Fowler

  4. Pattern: Microservice Architecture, Chris Richardson

  5. The Hidden Costs of Microservices, Justin Leitgeb

  6. Challenges and benefits of the microservice architectural style Part 1 + Part 2, André Fachat

© Habrahabr.ru