Вместо введения

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

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

Основное внимание в статье будет уделено тем глобальным проблемам, с которыми сталкивалась наша команда на протяжении всего проекта.

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

С чего все начиналось

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

После принятия решения о переходе на микросервисную архитектуру было создано отдельное подразделение из опытных и инициативных ребят. Определяющим фактором для рассмотрения кандидатуры для перевода в новый отдел стала высокая экспертность в одной или нескольких существующих информационных системах.



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

В качестве стратегии перехода на микросервисы было выбрано сразу два пути:

1. выносим в микросервисы то, что (как мы думали) вынести проще всего;
2. выносим в микросервисы то, чей перевод на микросервисы решает больше всего проблем как для бизнеса, так и для ИТ.

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

Команда находилась в начале пути. Это было счастливое время: будущее виделось светлым и безоблачным, и нам казалось, что у нас есть план.

Первые трудности

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



Лучше всего архитектуру наших отдельных систем иллюстрирует вот эта картинка, взятая из статьи Стефана Тилкова «Don’t start with a monolith».  Как мы видим, функциональные блоки в монолите крайне сильно связаны друг с другом. Это является серьезным препятствием для процесса выноса отдельного функционала в микросервис. 

Для справки: возраст  наших монолитов – около 13 лет, а размер кодовой базы среднего монолита – примерно 1,2 млн строк.

Другими словами, команда раз за разом сталкивалась со следующими проблемами:

• крайне трудоемкий процесс аналитики существующего функционала;
• часто недостаточное понимание того, что именно мы выносим в микросервис;
• сложности интеграции монолита с новым микросервисом.

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

Тем не менее, спустя несколько месяцев команда стала показывать первые результаты  – первые микросервисы дружелюбно предоставили свои API всем желающим. Команда поверила в свои силы и точно знала, что все делает правильно. Что ж, многое в нашей жизни достаточно иллюзорно.

Первые успехи и новые трудности

Несмотря на первые трудности команда получила и новый опыт, и первые результаты. Но возникли некоторые неучтенные риски, мешающие запуску микросервисов.

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

Первые две проблемы удалось решить довольно просто – написанием отдельных клиентов для возможности интеграции монолита и микросервиса и корректировкой функционала монолита соответственно. А вот третья проблема до конца не решена и по настоящее время.

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

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

Что ж…

Карантин, трудовые подвиги и наконец успех

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

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

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

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



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


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

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

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

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

• частые созвоны по скайпу с актуализацией текущего статуса по работам и оперативное решение возникающих вопросов;
• поддержание позитивного настроя в команде с постоянной проверкой ресурсного состояния каждого.

Как итог

Вместо заключения хотелось бы остановиться на выводах, которые мы для себя сделали…

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

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

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

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