Как микросервисы помогают бизнесу

Сергей Зинкевич

директор по развитию бизнеса КРОК Облачные сервисы

Когда увеличивается конкуренция, на первый план выходит параметр time-to-market. Под ним имеется в виду скорость выпуска на рынок любых доработок клиентских сервисов и продуктов. Это может быть в том числе «фича», которая ускоряет скорость загрузки контента, повышает юзабилити сайта и приложения, способствует кросс-продажам.

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

Из-за цифровизации и пандемии, которая подтолкнула многие компании к онлайну, time-to-market новой клиентской функциональности стал одной из метрик эффективности бизнеса. Считается, что низкий параметр TTM снижает жизнеспособность продукта на 20% (данные Gartner).

В погоне за скоростью компании начинают пересматривать подходы к построению и развитию ИТ-архитектуры, которая лежит в основе сервисов. Пришло понимание, что классическая инфраструктура (её ещё называют монолитной) плохо справляется с актуальными вызовами. Взамен ей всё чаще обращаются к микросервисам — особому подходу, позволяющему ускорить ИТ-разработку и выход конечных продуктов на рынок.

В активной фазе микросервисы в России стали применять около пяти лет назад, хотя первые упоминания этого подхода в мире датируются началом 2000-х. По мнению аналитиков Allied Market Research, объём рынка микросервисов к 2026 году превысит $8 миллиардов, демонстрируя ежегодный прирост на уровне 18%. Это одна из точек роста глобального ИТ-рынка, включая нашу страну. Из 500 клиентов КРОК Облачные сервисы не менее 65% уже используют у себя микросервисную архитектуру, а примерно 18% планируют «распилить свой монолит» в ближайшие годы.

В чём преимущества микросервисов?

Рассмотрим на примере двух типов архитектур.

Монолитные архитектуры

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

Минусы:

• Сложность внесения изменений. Чтобы поменять что-то, пусть и незначительное, в структуре, например, e-commerce платформы (предположим, код модуля, отвечающий за каталог товаров), надо вручную отследить и скорректировать большое количество других зависимостей. Это не только увеличивает время доработки онлайн-ресурса, но и требует вовлечения большого количества инженеров.
• Трудности масштабирования. В монолитных архитектурах не всегда возможно нарастить вычислительные мощности для какого-то одного из сервисов, например, только лишь основной витрины товаров или модуля, отвечающего за оплату. Можно нарастить потребление ресурсов для всего сайта, а это часто бывает избыточно.
• Риски сбоев. Из-за связности компонентов сбой на уровне ПО одного из сервисов с большой долей вероятности негативно повлияет на всю платформу.
• Сложность внедрения новых технологий. Если платформа была написана, предположим, на Python, перейти на что-то другое фактически нереально. В ИТ-отрасли это ещё зовется legacy — унаследованной инфраструктурой, которая в статичном виде может функционировать годами.
• Большие трудозатраты на поддержку. Когда сервисов становится много, нужен супер-квалифицированный специалист, который сможет видеть верхнеуровневую картину. Скорее всего, найти такого на рынке не получится, либо он будет стоить слишком дорого для компании. Единственный путь — вырастить его изнутри.

Микросервисы

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

Плюсы:

• Простота и скорость развёртывания. Благодаря отсутствию зависимости от других сервисов внести изменения можно гораздо быстрее — недели вместо месяцев в монолитной архитектуре.
• Оптимальность масштабирования. Повышение производительности касается только тех сервисов, которым это действительно необходимо. За счёт этого достигается экономия на инфраструктуре.
• Большой выбор технологического стека. Язык программирования можно менять в зависимости от предпочтений ИТ-разработчика или релевантности для конкретной бизнес-задачи. Это важно, так как позволяет привлечь с рынка специалистов, которые не хотят ограничивать себя той или иной технологией.
• Многократное использование. Однажды написав микросервис, его можно использовать многократно в похожих задачах. Благодаря этому уменьшаются трудозатраты и количество рутинных операций, совершаемых ИТ-специалистом.

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

Кроме того, сам «распил монолита» не кажется такой уж простой задачей. Дополнительный барьер — это всё те же высокие затраты на сопровождение инфраструктуры — бич для российского рынка ближайших лет (уже сейчас дефицит ИТ-специалистов составляет 1 миллион человек в год). Если количество сервисов в инфраструктуре превышает сотню, нужна помощь дополнительных архитекторов и DevOps-специалистов, которые будут разрабатывать API-интерфейсы для согласованности приложений.