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

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

154
4 минуты

Сергей Зинкевич
Директор по развитию сервисов

Когда увеличивается конкуренция, на первый план выходит параметр 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-интерфейсы для согласованности приложений.

28 марта 2022
Облака как возможность: аналитика КРОК Облачные сервисы
За первые две недели марта 2022 года количество запросов на услуги КРОК Облачные сервисы увеличилось на 960%, по сравнению с тем же периодом прошлого года. Компании на фоне приостановленных поставок ИТ-оборудования ищут доступные инструменты для поддержки бизнес-процессов и модернизации инфраструктуры.
2 минуты
213
15 марта 2022
Почему конвейер разработки ПО не срабатывает, и как это исправить
Для организации процесса современной ИТ-разработки в России принято использовать концепции и практики непрерывной интеграции и доставки (CI/CD). О ней говорят много, но, как часто бывает на практике, редко кто применяет правильно.
1 минута
80
31 января 2022
CustDev ИТ-компании: через тернии к успешному продукту
Термин Customer Development пришел из мира стартапов, но на сегодняшний день принципами проверки востребованности идей и клиентских продуктов пользуются и в зрелых предприятиях. Однако путь CustDev может существенно отличаться от компании к компании.
1 минута
180
28 декабря 2021
Для чего компании используют облака? Как изменились потребности клиентов за последние полгода
В конце года традиционно подводят итоги. Мы же решили проанализировать тренды, заметные в последние два квартала. Почему именно за этот период, а не за весь год? Начиная со второй половины 2021 г. усилилось влияние кризиса полупроводников фактически на все сегменты.
1 минута
157
scrollup