Распиливаем монолит на микросервисы: наш опыт для американской аналитической компании

Привет! На связи Александр Долгов, CEO в Innovedge Soft. Мы занимаемся разработкой сайтов, мобильных приложений и интеграционных сервисов любой сложности. На днях коллега по цеху затронул интересную и непростую тему “Монолит vs микросервисы”, которая неожиданно (учитывая нетехническую направленность ресурса) нашла отклик у сообщества.

“Тем лучше!” - подумали мы, ведь у нас как раз готовилось описание кейса по распиливанию на микросервисы интересного и сложного проекта для одной аналитической компании из США. Итак, готовьте ножовки. Будем пилить!

История классическая. Наш клиент - эксперт в своем деле (аналитика и маркетинг), имеющий пул своих клиентов от текущего работодателя, в один прекрасный момент подумала “why not” и начала делать бизнес. У него, конечно, был друг разработчик в доле, который кодил первую версию системы. Он, естественно, обещал себе, что с первым профитом введет регламенты разработки, code style и прочее, но время шло, проект, катясь по релизной дорожке, рос как снежный ком, впитывая в себя все новую и новую функциональность.

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

С точки зрения кода это было одно большое решение ASP.NET MVC с общим бэкендом и фронтендом, использующее общую довольно распухшую базу данных MS SQL Server.

Главные боли клиента на тот момент:

• Поддержка и расширение функциональности. Из-за плохо продуманной архитектуры и тесной связанности компонентов, правки багов и внедрение новых фич приводили к непредсказуемым результатам. Работая, к примеру, над бэкендом блока для контракторов, часто что-то ломалось у менеджеров, и наоборот.
• Стабильность. Наличие общего бэкенда у двух по сути разных порталов означало, что если что-то пошло не так при релизе менеджерского портала, работа встанет у всех контракторов, и наоборот.
  
• Связанность бэкенда и фронтенда. Из-за особенности инструментов, использованных при разработке системы, в большинстве случаев, изменение функциональности фронтенда вело к ре-деплою системы целиком.
  
• Безопасность. Клиент пришел к нам после предварительно проведенного аудита безопасности с твердым намерением развернуть у себя свой отдельный сервер авторизации.
  
• Безопасность. Клиент пришел к нам после предварительно проведенного аудита безопасности с твердым намерением развернуть у себя свой отдельный сервер авторизации.
  

Решение для нас было очевидным:

Не менее очевидным для нас были и сервисы, на которые монолит должен был быть распилен:

• Авторизационный сервис
• Сервис для контракторов
  
• Сервис для менеджеров
  

Тут следует уточнить, что каждый микросервис это по сути API для соответствующего портала. Фронтенд часть для каждого сервиса также реализуется в виде отдельного проекта/приложения. Просто формально фронт не относится к микросервисам, поэтому в нашем перечислении не указан.

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

Такой масштабный проект - это еще и отличный шанс обновить фреймворки и инструменты, которые использовались для оригинальной системы. Бэкенд-сервисы решено было делать с использованием последней на тот момент версии .NET. Фронт на Angular. Помимо этого, для сервиса авторизации был использован Identity Server, но это запрос клиента, против которого мы возражать не стали.

Ну и куда без новых фич. Раз уж рядом с монолитом растут с нуля новые порталы, то не добавить в них накопленные за последнее время хотелки - преступление.

В нашем случае план был следующий:

1. Реализация авторизационного сервиса. Пользователь, прошедший авторизацию должен иметь доступ как к старому порталу, так и к соответствующему новому порталу.
2. Реализация промежуточной логики с отдельным служебным порталом, через который администраторы могли настраивать какие модули порталов должны открываться в старом портале, а какие уже в соответствующих новых порталах.
   
3. Реализация сервиса для контракторов и фронтенд для портала, который его использует.
   
4. Реализация сервиса для менеджеров и фронтенд для портала, который его использует.
   

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

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

Сам по себе процесс разработки ничем не отличался от привычного, за исключением ряда нюансов:

• Неровная конфигурация команды. У клиента была небольшая инхаус команда, которая была дополнена нашим разработчиком и нашим же тимлидом. В команде клиента были как сильные разработчики с американского рынка, так и пара откровенно слабых ребят из Пакистана.
• Довольно много функционала брали из внешних библиотек (календари, PDF viewrer’ы и т.д.). То есть максимально экономили на разработке того, что могли заместить готовой библиотекой. Отсюда кропотливый выбор подходящих библиотек. Вообще, это отдельная тема для статьи, которую мы уже готовим.
  
• Рваный темп. Пока мы орудуем ножовкой, бизнес как работал так и работает. А это значит, что если в действующем портале возникали баги (или нужна была критически важная фича), мы должны были править код соответствующим образом, и зачастую не только для действующего портала, но и для уже реализованного функционала новых порталов.
  

В результате за 9 месяцев работы команды разработки из 3-5 человек (на разных этапах размер команды менялся), новые порталы были запущены. Помимо более чистой архитектуры, клиент получил обновленный современный фронтенд и с десяток крупных фич, накопившихся в бэклоге.

Если подвести некий итог, то, приступая к такому рода проекту нужно иметь в виду следующее:

• Будет много плохого кода. Неочевидных решений. Запрятанной бизнес-логики. Это нужно учитывать при обсуждении схемы работы. Фикс-прайс тут выглядит тупиковым подходом как для заказчика, так и для подрядчика.
• Перед распиливанием монолита очень важно досконально знать реализованную бизнес-логику - это поможет спланировать в какой последовательности и по какому принципу система будет делиться на микросервисы.
  
• Ну и самое главное: у всех сторон должно быть понимание для чего все это делается. “Микросервисы” - звучит модно и молодёжно. Но нужны они не всем и не всегда.