Микросервисы обрели популярность в России около 5 лет назад. В это время компании начали активнее использовать технологические решения в конкурентной борьбе и на первый план вышла концепция «time-to-market» – скорость выпуска продуктов на рынок. Компании приступили к поиску решений и «фич», которые позволяют сделать качественный продукт быстро и (относительно) недорого. Добиться этих целей им помогают микросервисы.

Что такое микросервисная архитектура и чем она отличается от монолитной?

Микросервисная архитектура (microservice architecture, MSA) – это подход, при котором IT-продукт разрабатывается на основе небольших самостоятельных сервисов, каждый из которых взаимодействует с остальными используя легковесные механизмы, например – HTTP.

В свою очередь, монолитная архитектура (monolit architecture) – традиционный подход к созданию ПО. В его рамках формируется единый модуль, функционирующий автономно и независимо от других приложений. Теперь сравним монолитную и микросервисную архитектуру, и разберемся какая архитектура достойна внимания в современных реалиях.

Преимущества монолитной архитектуры

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

• Первый минус – проблемы с внедрением изменений. Для изменения даже незначительного компонента потребуется вручную отследить как ваша «правка» повлияет на другие компоненты, и исправить множество ошибок, которые могут возникнуть. Все это увеличивает время работы с сервисами и требует вовлечения большого количества специалистов.

• Проблемы с масштабированием. В монолитных архитектурах практически отсутствует возможность увеличить вычислительные мощности для конкретного сервиса, например, каталога или модуля, отвечающего за оплату покупок.

• Вероятность возникновения сбоев. Из-за сильной взаимосвязи между компонентами в таких структурах нередко происходят сбои, которые могут негативно повлиять на всю систему.

• Трудности с внедрением новых технологий. Если продукт был разработан с помощью высокоуровневых языков программирования, то перейти на другие технологии практически невозможно. Среди IT-специалистов такие структуры получили название «Legacy» (от англ. наследие). Их главная характеристика – статичная унаследованная инфраструктура.

Преимущества и недостатки микросервисов

Вокруг микросервисов ходят легенды об их универсальности. Однако на практике не все компании довольны, а некоторые даже жалеют о своем переходе на MSA. Разберемся, в чем преимущества и недостатки этого подхода и кому микросервисы вовсе не нужны.

• MSA меньше влияют на пользовательский интерфейс. В отличие от монолитных сервисов, связь между компонентами внутри подобной системы слабее и функционирует по другим правилам. Каждый сервис – это независимая составляющая, которая имеет свое хранилище, библиотеку и т. д. Для того, что MSA не изменяло пользовательский интерфейс, разрабатывают монолитное SPA-приложение (Monolithic Frontend) и относительно недавно стали популярны Micro frontend-ы.

• Простота и скорость развертывания/масштабирования. Из-за отсутствия прямых взаимосвязей между компонентами в микросервисную архитектуру легче и быстрее вносить изменения.

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

• В MSA решения можно использовать повторно. Микросервис, написанный когда-то, можно использовать для решения тех же проблем, но в других проектах. Благодаря этой особенности уменьшаются трудозатраты и количество рутинных операций, выполняемых IT-специалистом. Однако, стоит учесть, что повторное использование MSA зависит от способа декомпозиции проблемной области (Problem Space). В случае использования Domain-Driven Design повторное использование может быть затруднено.

"Минусы" микросервисной архитектуры:

• Трудности при миграции с монолитной архитектуры. Переход от одной архитектуры к другой – трудоемкий процесс, он может отнять много времени и других ресурсов.

• Большие трудозатраты на поддержку. Тяжело найти специалиста извне, способного качественно поддерживать монолитную архитектуру. Даже если вам удастся это сделать, он будет стоить дорого, поэтому единственный реальный вариант для малого и среднего бизнеса – вырастить такого специалиста изнутри.

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

Когда микросервисная архитектура не нужна?

Некоторые компании спешат реорганизовать свою структуру в пользу микросервисов. Но далеко не всем это действительно нужно. Если в рамках работы над проектом вы имеете дело с большим коллективом разработчиков, объемной и сложной архитектурой, продуктами, с резко меняющимся трафиком, приложениями, которые требуют частых обновлений то вам стоит задуматься над использованием MSA. Другими словами, использовать MSA нужно в случаях, если вы имеете дело со сложными предметными областями, частыми решениями (time-to-market) и гибким масштабированием (elastic scalability). Кроме того, без квалифицированной команды ничего не выйдет.

Микросервисы заслужили свою популярность – с их помощью компании решают те проблемы, которые раньше считались неразрешимыми: опыт Netflix, Uber, SoundCloud и Amazon подтверждает это.