Неудачная попытка перехода с монолита на микросервисную архитектуру и чему я научился

Я не буду включать названия компаний или команд в эту статью по очевидным причинам.

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

Говоря о монолите, этот был ярким примером того, какими плохими могут оказаться монолиты. Он был полон спагетти-кода и имел небольшое покрытие модульными тестами, что делало рефакторинг еще более сложным, чем предполагалось. Кроме того, в этой конкретной организации была команда контроля качества, которая отвечала за обнаружение всех ошибок перед выпуском. Это сделало разработчиков очень ленивыми в их тестировании, поскольку у них была эта «сеть безопасности», созданная этой командой тестировщиков. Вы могли регулярно слышать фразу «QA поймает ошибки, не волнуйтесь». Проблема в том, что иногда они этого не делали, и нам приходилось делать исправления, откаты и ночную поддержку — все самое интересное.

Кроме того, этот огромный проект выходил каждые две недели. Освобождение стало своеобразным ритуалом. Мы все собрались в комнате (20+ человек) и ребята из DevOps нажали большую красную кнопку. Потом мы все смотрели логи и ждали, когда система сломается (так всегда и было). После того, как он сломался, мы должны были принять решение, должны ли мы сделать откат, исправление или вручную исправить что-то в БД? Все это заняло 3–4 часа, и в итоге у нас все еще были проблемы, которые были замечены, и клиенты начали звонить посреди ночи.

Я рассказываю все это, чтобы вы могли понять, как мы отчаянно пытались избавиться от этого монолита и разделить его на более мелкие проекты.

Микросервис

Микросервисы очень просты в выпуске и управлении, они также дают команде свободу работать независимо от других команд и имеют отдельные циклы выпуска. Мы хотели иметь возможность выпускать релизы 2–3 раза в неделю и работать с одной веткой. Что-то, что было невозможно с монолитом. Наша команда была пионером, и все ждали от нас успеха, чтобы они могли использовать нашу работу в качестве PoC перед высшим руководством и могли оправдать усилия, необходимые для перехода от монолита.

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

Компромисс 1

Этот сервис не будет иметь отдельного пользовательского интерфейса и будет частью существующего пользовательского интерфейса монолита. Это сэкономит время, но создаст связь между двумя системами. У нас были довольно сильные ребята из пользовательского интерфейса, и им удалось реализовать модульный пользовательский интерфейс, который легко интегрировался в существующие проекты, предположительно, ему также было легко существовать самостоятельно (что было нашим планом на будущее).

Компромисс 2

У нас был процесс KYC, который требовал интеграции в стороннюю систему. Этот процесс требовал больших усилий, и мы решили передать его на аутсорсинг команде подрядчиков. Это было огромной ошибкой, потому что поток необходим, и без него мы не смогли бы запустить проект. Мы сделали себя зависимыми от внешней команды, которая не слишком заботилась о нашем успехе.

Компромисс 3 (последний гвоздь в крышку гроба)

В монолите был аналогичный поток, который мы могли повторно использовать с небольшими изменениями. Однако для этого наша основная бизнес-логика должна была быть реализована внутри монолита. Это сэкономило нам много времени, но мы ввели неразрывную связь между нашими микросервисами и монолитом. В конце концов, это означало, что мы были привязаны к его циклу выпуска (мерзость, описанная выше) и действительно не могли дать большую ценность, не заливая еще больше кода в легаси, надеясь, что когда-нибудь у нас будет время его извлечь. Этот день так и не наступил.

Судьба наших микросервисов

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

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

Уроки

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

Если бы мы просто использовали монолит как услугу, это сделало бы нас независимыми от него. Мы должны были относиться к этому как к отдельному проекту, который мы не можем трогать, как к чужой сущности, которую мы не контролируем. Это единственный способ гарантировать, что однажды мы перестанем полагаться на него. Да, это усложнило бы нашу первоначальную настройку, но, в конце концов, связь убила весь проект. Компания долгое время не пыталась создать еще один микросервис после нашей неудачи.

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

Избегайте использования компаний-подрядчиков любой ценой. Они очень дорогие, общение очень затруднено, и они отчитываются перед внешними организациями. Кроме того, работа, выполняемая этими сервисными компаниями, часто некачественная, и им нет дела до вас или вашего проекта.

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

Надеюсь, эта короткая история окажется для вас полезной и интересной, и спасибо за прочтение :)