Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

бюджет.

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

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

Рис. 52. Метафора стабильности систем

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

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

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

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

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

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

Рис. 53. Распределение людей по микросервисам

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

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

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

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

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

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

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

Рис. 54. График перехода от старой системы к новой

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

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

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

Рис. 55. Сохранение обратной совместимости

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

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

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

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

Рис. 56. Интеграция служб поддержки для работы с микросервисами

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

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

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

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

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

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

Рис. 57. Двойная работа во время существования обеих систем

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

Чек-лист

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

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

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

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

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

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

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

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

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

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

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

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

Глава 4. Где и как применять low-code платформы

Зачем нужны low-code платформы и каковы границы их применимости

Разговоры о программировании без программистов идут постоянно. За последние 15 лет моей работы в IT идёт уже вторая волна