[Микросервисы] Переход на микросервисную архитектуру

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
19-Сен-2020 02:31

Цитировать

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

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

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

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

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

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

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

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

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

Первые две проблемы удалось решить довольно просто – написанием отдельных клиентов для возможности интеграции монолита и микросервиса и корректировкой функционала монолита соответственно. А вот третья проблема до конца не решена и по настоящее время.
Проблему с несогласованностью по ресурсам удалось частично решить за счет совместного планирования ресурсов. Казалось, что команда учла все свои ошибки, появилось понимание того, что и как нужно делать правильно, и к началу 2020 года было написано порядка десятка микросервисов (некоторые получились совсем не микро), ждущих интеграции и выпуска в продуктив.. Они охватывали своим функционалом большую часть критичных для бизнеса процессов, таких как расчет стоимости и сроков доставки, вывод новых регионов и офисов на продающем сайте, поиск и подбор товаров и т.д.
Мы уверенно двигались вперед, имея уже солидный опыт и набив немало шишек. Казалось, что мы столкнулись со всеми подводными камнями, и теперь остается только обдуманно, шаг за шагом претворять наш план в жизнь.
Что ж…
Карантин, трудовые подвиги и наконец успех
Начало года внесло существенные коррективы в наши планы, и виной тому последствия распространившегося в то время нового коронавируса. Очевидно, что объяснять, о чем идет речь, нет необходимости: все знают по этой теме уже очень и очень много.
Начало пандемии и сопутствующего экономического кризиса заставило нашу компанию немного пересмотреть свои приоритеты на развитие. И как следствие, поменялись приоритеты у ИТ – ставились новые задачи, призванные в кратчайшие сроки переделать бизнес-процессы под новые реалии.
Изменения коснулись и планов по микросервисам. Из-за перераспределения ресурсов интеграция микросервисов с монолитами, а следовательно, и релиз самих микросервисов снова откладывались.
Здесь, наконец, нужно более подробно остановиться на том, что происходило в команде и как команда себя чувствовала.

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

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

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

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

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

оригинал

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

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

Теги для поиска: #_mikroservisy (Микросервисы), #_mikroservisnaja_arhitektura (микросервисная архитектура), #_blog_kompanii_vseinstrumenty.ru (
Блог компании ВсеИнструменты.ру
), #_mikroservisy (
Микросервисы
)

Профиль ЛС

Ответить на тему

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

Текущее время: 22-Ноя 18:00
Часовой пояс: UTC + 5