Найти в Дзене

Сложности при переходе на микросервисную архитектуру, и как это связано с циклом жизни продукта

А нужно ли вообще переходить от монолита к микросервисам? Плюсы и минусы монолита и микросервисов. Мы точно знаем, что строим! Или нет? Вопрос монолита и микросервисов остро вставал еще до появления самих определений. Очень здорово, когда есть возможность заранее определить архитектуру проекта, время на разработку и кадры, которые это реализуют. К сожалению, реальность куда жестче и прозаичнее. Бизнесу нужно успеть раньше конкурентов что-то сделать. Но в случае стартапа вообще не приходится говорить об архитектуре — более актуальна тема преодоления «кризиса становления». У монолита и микросервисов есть свои плюсы и минусы. Думаю, в контексте статьи вряд ли нужно разбирать, что это и как именно устроено. Выражу только личное мнение, исходя из опыта, и быстро перейду к сути и видению проблемы. Микросервисы. Им поют оды, о них мечтают. Они масштабируются, их классно использовать при создании продукта или проекта. К примеру, слишком большие и сложные системы, отлично ложатся на микросервис
Оглавление

А нужно ли вообще переходить от монолита к микросервисам? Плюсы и минусы монолита и микросервисов.

Мы точно знаем, что строим! Или нет?

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

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

Микросервисы. Им поют оды, о них мечтают. Они масштабируются, их классно использовать при создании продукта или проекта. К примеру, слишком большие и сложные системы, отлично ложатся на микросервисную архитектуру. Ее бесконечно удобно дорабатывать, и даже в случае отказа некоторых сервисов, это редко приводит к глобальным сбоям, которые как-то сложно сразу «отловить». Если возникла проблема — откатываем сервис до прошлой версии и тестируем на стендах дальше. Для этого требуется опыт работы с системой, обученный персонал и понятные структуры команды/ролей.

Монолит — его же все попирают! «Он не масштабируется!» или «Долой монолит из современного ИТ!» — такие заявления можно услышать от технических специалистов. Менеджеры, полагающиеся на их мнения, подхватывают этот мотив. Однако с высоты опыта скажу, что монолит — это очень классная штука в умелых руках. Когда нужна максимальная производительность, минимальные издержки времени на производство или прототипирование или конечная компактность. Даже с точки зрения дистрибуции монолит будет удобнее, ведь манипуляций для развертывания существенно меньше.

План простой: делаем, и там как-нибудь

Прелесть современного мира в том, что 99% новых проектов в разработке программного обеспечения — коммерческие. А значит, созданные для привлечения дополнительных средств в виде прибыли. На этом этапе будущий проект уже не демонстрирует какие-то «наклонности» в сторону будущего проекта. Задача — запилить наименьшей ценой с наибольшей скоростью. В этом есть некоторая специфика, как именно рождаются проекты и продукты в ИТ. Обычно появляется идея, буквально нарисованная на салфетке, для партнера, который на первых порах занимается постройкой решения в ИТ. Дальше ее быстро реализуют до состояния MVP, тестируют гипотезы и/или ниши, а затем уже в случае успеха можно сказать, что рождается продукт. Данный цикл занимает разное время. Обозначу его как «в среднем около года». И вот на выходе мы имеет нечто, что точно работает, но работает загадочным образом и как-то. Вероятно, построено при помощи аутсорсеров, без должной команды, без подходов к проектированию и документированию. База знаний? Это все позже, сейчас пилим продукт — подобные слова являются лейтмотивом того самого «около года». И результатом становится монолит.

Но нужно же делать бизнес. Коммерция — это про стратегию устойчивого роста, четкие KPI для команды и показатели бизнеса. Менеджмент, в конце концов. Вот тут-то и начинаются добрые побуждения и умные подходы: скрам или эджайл? Может, у нас будет красивее выглядеть prince2? После вспоминают про сам проект: «А вот код, он вообще как?» И только здесь становится понятно бизнесу, что «код просто делали». А ведь нужен подход, те самые микросервисы или монолит... Хорошо, если на данном этапе выясняется, что это просто написано на коленке, человеком, до которого можно как-то достучаться и получить комментарии. Я помню случай, когда искали нового топ-менеджера, специалиста в ИТ, чья главная задача была «разбить монолит» без ущерба для компании и за полиномиальное время. Речь идет о проекте, написанном, к слову, на ассемблере, потому что так появлялась возможность сделать все на этапе становления команды, и тогда это было: а) возможно вообще реализовать продукт, б) быстро, в) дешево. Хотя сегодня эта компания и лидирует на рынке ценных бумаг, она стремительно теряет свои позиции. Чуть подробнее об этом далее.

Чего может стоить «эволюция в микросервисы»?

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

Подробнее на it-world.ru