Сложности при переходе на микросервисную архитектуру, и как это связано с циклом жизни продукта
Изображение: alphaspirit.it/Shutterstock.com
Мы точно знаем, что строим! Или нет?
Вопрос монолита и микросервисов остро вставал еще до появления самих определений. Очень здорово, когда есть возможность заранее определить архитектуру проекта, время на разработку и кадры, которые это реализуют. К сожалению, реальность куда жестче и прозаичнее. Бизнесу нужно успеть раньше конкурентов что-то сделать. Но в случае стартапа вообще не приходится говорить об архитектуре — более актуальна тема преодоления «кризиса становления».
У монолита и микросервисов есть свои плюсы и минусы. Думаю, в контексте статьи вряд ли нужно разбирать, что это и как именно устроено. Выражу только личное мнение, исходя из опыта, и быстро перейду к сути и видению проблемы.
Микросервисы. Им поют оды, о них мечтают. Они масштабируются, их классно использовать при создании продукта или проекта. К примеру, слишком большие и сложные системы, отлично ложатся на микросервисную архитектуру. Ее бесконечно удобно дорабатывать, и даже в случае отказа некоторых сервисов, это редко приводит к глобальным сбоям, которые как-то сложно сразу «отловить». Если возникла проблема — откатываем сервис до прошлой версии и тестируем на стендах дальше. Для этого требуется опыт работы с системой, обученный персонал и понятные структуры команды/ролей.
Монолит — его же все попирают! «Он не масштабируется!» или «Долой монолит из современного ИТ!» — такие заявления можно услышать от технических специалистов. Менеджеры, полагающиеся на их мнения, подхватывают этот мотив. Однако с высоты опыта скажу, что монолит — это очень классная штука в умелых руках. Когда нужна максимальная производительность, минимальные издержки времени на производство или прототипирование или конечная компактность. Даже с точки зрения дистрибуции монолит будет удобнее, ведь манипуляций для развертывания существенно меньше.
План простой: делаем, и там как-нибудь
Прелесть современного мира в том, что 99% новых проектов в разработке программного обеспечения — коммерческие. А значит, созданные для привлечения дополнительных средств в виде прибыли. На этом этапе будущий проект уже не демонстрирует какие-то «наклонности» в сторону будущего проекта. Задача — запилить наименьшей ценой с наибольшей скоростью. В этом есть некоторая специфика, как именно рождаются проекты и продукты в ИТ. Обычно появляется идея, буквально нарисованная на салфетке, для партнера, который на первых порах занимается постройкой решения в ИТ. Дальше ее быстро реализуют до состояния MVP, тестируют гипотезы и/или ниши, а затем уже в случае успеха можно сказать, что рождается продукт. Данный цикл занимает разное время. Обозначу его как «в среднем около года». И вот на выходе мы имеет нечто, что точно работает, но работает загадочным образом и как-то. Вероятно, построено при помощи аутсорсеров, без должной команды, без подходов к проектированию и документированию. База знаний? Это все позже, сейчас пилим продукт — подобные слова являются лейтмотивом того самого «около года». И результатом становится монолит.
Но нужно же делать бизнес. Коммерция — это про стратегию устойчивого роста, четкие KPI для команды и показатели бизнеса. Менеджмент, в конце концов. Вот тут-то и начинаются добрые побуждения и умные подходы: скрам или эджайл? Может, у нас будет красивее выглядеть prince2? После вспоминают про сам проект: «А вот код, он вообще как?» И только здесь становится понятно бизнесу, что «код просто делали». А ведь нужен подход, те самые микросервисы или монолит... Хорошо, если на данном этапе выясняется, что это просто написано на коленке, человеком, до которого можно как-то достучаться и получить комментарии. Я помню случай, когда искали нового топ-менеджера, специалиста в ИТ, чья главная задача была «разбить монолит» без ущерба для компании и за полиномиальное время. Речь идет о проекте, написанном, к слову, на ассемблере, потому что так появлялась возможность сделать все на этапе становления команды, и тогда это было: а) возможно вообще реализовать продукт, б) быстро, в) дешево. Хотя сегодня эта компания и лидирует на рынке ценных бумаг, она стремительно теряет свои позиции. Чуть подробнее об этом далее.
Чего может стоить «эволюция в микросервисы»?
Иногда монолит — это осознанный выбор и подход. И в некоторых случаях идеальное решение. На практике же скорее исключение, и на определенном этапе становится очевидным, что переход от монолита к микросервисам необходим и неизбежен, он является ступенью эволюции бизнеса. Хочу отметить, что переход действительно часто нужен и приносит свои плоды. Например, в более низких «костах» изменений продукта или в более предсказуемой интеграции изменений. И даже в возможности внедрения стратегии по управлению изменениями продукта и подобных важных вещей. Без этого трудно представить средний, а тем более крупный бизнес.
Иными словами, очень часто по наличию первого или второго можно говорить о зрелости самого продукта и цикле жизни бизнеса. Еще чаще монолит — это некоторое «легаси», а микросервисы — то, во что переписывают продукт с нуля внутри компании. Бывают случаи, что продукт зависает на полпути, и начинаются самые большие чудеса для компании и ИТ-отдела. Тогда в процессе переписывания на микросервисы внезапно, как снег в декабре, оказывается, что большая часть ресурсов не может быть занята, ведь есть еще и основной бизнес и его планы. Или по срокам затянули, даже несмотря на гибкие методологии, а нужно двигаться дальше. И случается страшное. Две версии одного продукта начинают жить одновременно и вместе. Такой «Франкенштейн», где часть все еще работает на монолите, а часть — уже на микросервисах.
Вопрос на миллионы: делаем или думаем?
Важный вопрос: а нужно ли вообще переходить от монолита к микросервисам? Все помним хорошее правило: работает — не лезь! Ведь переход от монолита к микросервисам дается больно, не всем и не всегда до конца. Часто компании зависают в процессе, не рассчитав трудозатраты и время, необходимое для перехода.
Упомянутый выше случай стоит отдельного внимания в качестве примера того, как компания выросла из «монолита» и стала заложником «быстрого старта». Искали нового топ-менеджера, имеющего способности в ИТ и чья главная задача «разбить монолит», полностью написанный в XXI веке на ассемблере. Это не был сознательный или продиктованный необходимостью выбор. Попросту был специалист, который в моменте «сумел задачу». И вот они сделали. Пока бизнес рос из стартапа, было все прекрасно. Спустя же время осознали, что никто не может его поддерживать или развивать. Для целей компании подойдет и даже показан, стек проще и гораздо современнее, особенно в плане кадров — например, тот же nodeJs выглядел бы вполне органично. Сегодня их бизнес стагнирует. Но вот можно ли сказать, что они совершили ошибку или это был просчет и так нельзя было делать? Это компания, все еще лидер рынка в СНГ, занимающаяся торговлей ценных бумаг. Благодаря такому подходу они захватили большую долю рынка, а потом столкнулись с тем, что не могут вносить изменения, необходимые их клиентам. Для чего им, очевидно, нужно срочно меняться. В данном случае — переписать весь проект с нуля. К сожалению, за несколько лет они так и не сумели это реализовать, а потому существенно теряют в новых клиентах, которым невозможно предоставить полный объем современного сервиса. Даже старые лояльные к ним клиенты уже уходят на более удобные площадки. Однако на протяжении всего времени компания еще жива, и у нее есть шанс довести необходимое до конца.
Еще один пример перехода от «монолита» к «микросервисам», запомнившийся своей курьезностью. Этот анекдотичный случай как раз показателен тем, что в такого рода монолите все работало отлично и в целом свою функцию выполняло от рождения до самого заката бизнеса. В одном из небольших и специализированных некогда существовавших банков — на тот момент (буквально лет 10 назад) весь процессинг фукционировал... на макросах в специально разработанной таблице Excel! И когда я обратил внимание на этот факт, старший сотрудник, занимавшийся вопросами делопроизводства, горестно заметил, что денег на закупку серверов и организацию процессинга согласно требованиям просто-напросто не выделяется. Со временем банк «не прошел санацию». И я абсолютно уверен, что если бы не обстоятельства, Excel-табличка так и работала бы до сегодняшнего дня. И видимо, хорошо, что после моего замечания никто не бросился ничего пилить...
Отдельно внимания нужно удостоить уже упомянутых «Франкенштейнов»: когда проект зависает между двумя состояниями в попытке уйти от плохого старого к светлому хорошему. Уж сколько я подобного навидался — трудно и сосчитать. Бывает, проект начинает жить каким-то третьим образом, когда есть и старый код, и новый. Но окончательно измениться нет уже никакой возможности и сил. При этом весь топ-менеджмент буквально трясет при фразе «закончить переход»...
Думаете, случай ужасный и с вами такого не случится? О чем говорить, если подобный «легаси» есть у таких гигантов, как «Фейсбук»*, «ПайПал» или «Ибей». Зайдя на некоторые страницы этих ресурсов, можно с легкостью увидеть самое очевидное даже для далеких от ИТ пользователей — разметку с приветами из нулевых годов...
И это не связано с плохим менеджментом или недальновидностью собственников, скорее с особенностью менеджмента в ИТ и некоторой спецификой запуска ИТ-продуктов. Ведь никому не нужен отлично спроектированный, с отличным стеком, но неработающий продукт, как и нельзя позволить себе инвестировать сразу много денег в просто «протестировать мысль».
* Facebook признана экстремистской и запрещена на территории РФ.
Как построить систему информационной безопасности, чтобы она обеспечивала защиту на уровне, превосходящем тех, кто наименее подготовлен к угрозам.
Опубликовано 26.04.2024
