Любое решение стоит денег, а неправильное решение всегда выходит дороже. Поэтому выбор архитектуры для будущего IT-продукта требует учесть много нюансов.
Зачем бизнесу думать об архитектуре ИТ проекта заранее
Дом невозможно построить без проекта. Точно также невозможно создать любой IT-продукт без структуры будущего продукта, описания его функций и взаимосвязей компонентов. Архитектура ИТ продукта — это концепция разработки. Есть концепции, которые влияют на удобство разработки, задают паттерны проектирования. Есть те, которые отвечают за структуру и взаимодействие компонентов — они и важны бизнесу.
Выбор верной архитектуры позволяет:
- комфортно запустить проект в условиях с разным бюджетом: например, начать с небольшой сметы и постепенно ее увеличивать;
- протестировать гипотезы, связанные с продуктом и его функциями;
- при необходимости масштабировать продукт;
- увеличивать производительность продукта сообразно растущей нагрузке;
- развивать его с любой командой, а не только той, которая стояла у истоков разработки.
Архитектура влияет на многое: бюджет проекта, требования, планы на масштабирование, а также сервера, компьютеры, сайты, ПО.
Стандартно говорят о монолитной и микросервисной архитектуре, но специалисты IT-компании Riverstart выделяют три звена — монолитную, сервисную и микросервисную. Разберемся, что это такое и как сделать правильный выбор, чтобы у продукта было будущее.
Что такое монолитная архитектура
Монолитная архитектура ИТ продукта — это вариант моделирования ПО, где все элементы объединены в единый модуль внутри одной кодовой базы — приложение-монолит, которое не разделяется на субприложения.
Самый большой плюс монолита — возможность стартовать с небольшим бюджетом и быстро разработать mvp — приложение, на котором можно протестировать гипотезу о том, что пользователям нужно и интересно. Пример продукта на монолите из нашего опыта — сайт с интерактивной картой транспорта Нижегородского региона, который показывает перемены в связи с транспортной реформой. Сайт содержит карту, где пользователь может строить путь по точкам и видеть новые остановки и маршруты транспорта. Для такой функциональности не требуется делать что-то масштабнее монолита.
Плюсы монолитной архитектуры:
- Быстрая разработка в едином репозитории и едином стеке.
- Минимум проблем из-за связей между компонентами системы.
- Изменения обычно не требуют дополнительных ресурсов.
- Нужно мало разработчиков: пара специалистов могут работать над достаточно большим монолитом.
Риски и опасности:
- Если в одном модуле приложения случится критическая ошибка, всё приложение станет недоступно.
- Деплой приложения, то есть процесс его развертывания, возможен только целиком.
- Отдельные модули могут забирать на себя большую часть системных ресурсов, из-за чего приложение начнет медленнее работать.
- Переделки и доработки за низкоквалифицированными разработчиками могут добавить новые статьи расходов.
- Чаще приложения на монолите масштабируются вертикально — за счет добавления ресурсов на серверы. Могут возникать сложности при резком увеличении нагрузки.
- Если применять горизонтальное масштабирование, нужно будет создавать копию монолита, а значит наследовать все его проблемы.
Для каких проектов подходит монолит. Проекты с быстрым стартом, простые приложения, mvp, где мало пользователей и простые функции.
Что такое сервисная архитектура
Сервисная архитектура ИТ продукта или сервисно-ориентированная архитектура — это вариант разработки ПО на основе программных компонентов — сервисов со стандартизированным интерфейсом. Это уже не единое целое, сервисная архитектура больше похоже на пазл, где каждая деталь — сервис — отвечает за решение определенной бизнес-задачи.
«Принято выделять монолит и микросервис. Почему мы в Riverstart выделяем еще и сервисную архитектуру?
Мы рассматриваем виды архитектуры ИТ продукта как процесс эволюции. Сервисная архитектура — некий переходный вариант от монолита к микросервисам. При этом микросервисная — что-то вроде частного варианта сервисной. Правильно организованная монолитная архитектура позволяет перейти на сервисную архитектуру, чтобы масштабировать компоненты, нагрузка на которые увеличивается, а далее перейти на микросервисную, если появляются особые требования к производительности».
Андрей Никонов
СЕО IT-компании Riverstart
Возьмем приложение, в котором есть модуль обработки файлов. Он отвечает за загрузку, валидацию, генерацию и получение файлов. Мы легко можем вынести эту функциональность в отдельный сервис: он будет слабо связан с остальными компонентами приложения, будет запускаться на отдельных ресурсах и не мешать выполнению основного приложения.
Это удобно, когда сервис выполняет нагруженные задачи: обработку файлов, генерацию отчетов. Мы сможем написать необходимую связку между монолитом и сервисом с помощью любого удобного подхода и после этого будем запускать эти сервисы в нескольких экземплярах, где нам необходимо. Такой подход позволяет масштабировать те компоненты приложения, нагрузка на которые увеличивается.
К примеру, когда Riverstart создавали CRM для федерального агентства недвижимости «Монолит», нужно было автоматизировать рутинные задачи риэлторов, менеджеров по рекламе и других сотрудников. Под разные функции мы внедряли отдельные сервисы: модуль генерации изображений, модуль парсинга объявлений с Авито и Циан, модуль шахматки, модуль аналитики, колл-центр.
Для каких проектов подходит сервисная архитектура. Приложения сложнее, чем монолит: многофункциональные, с отдельными модулями, например, обработки видео, загрузки файлов.
Что такое микросервисная архитектура проекта
Микросервисная архитектура — модель разработки ПО, где система состоит из независимых модулей. Где каждый модуль — микросервис — отвечает за конкретную функцию и может иметь дубли для увеличения производительности. Проще говоря, это похоже на конструктор лего. Каждую деталь можно убрать или изменить, но при этом само приложение будет работать стабильно.
Чем хороша микросервисная архитектура:
- Можно добавлять новые функции, независимо обновлять, добавлять новые фичи в какие-то определенные компоненты, не меняя структуру продукта.
- Независимый деплой микросервисов. Выкатывать обновления можно незаметно для пользователя.
- В случае критической ошибки падение одного микросервиса не затронет всю систему. Остальная функциональность, кроме этого микросервиса, будет доступна.
- Легкое адаптивное масштабирование в зависимости от нагрузки в любой части приложения.
- Можно подключать разных разработчиков на разных стеках. Каждый занимается разработкой своего микросервиса. Мы можем эти стеки смешивать, заменять, выводить из эксплуатации.
Что важно учесть:
- Сложное начальное проектирование архитектуры.
- Сложный протокол обмена между микросервисами, его нужно поддерживать в актуальном состоянии.
- Необходимы дополнительные ресурсы на поддержку инфраструктуры каждого микросервиса.
- Есть неопределенно большие издержки на начальном этапе: на согласование всех протоколов взаимодействия, архитектуры и так далее.
Это более гибкий подход, который сделан специально для гибкой разработки огромных приложений. В том же примере с обработкой файлов нужно загрузить, провалидировать, сгенерировать и отдать файлы. Если в случае с сервисной архитектурой у нас был целый сервис, который этим занимается, то в микросервисной модели это четыре разных микросервиса.
Они будут отдельно запущены, при необходимости будут иметь свою базу данных и общаться по удобному протоколу. Такой подход позволяет масштабировать отдельные компоненты приложения, которые подвергаются большей нагрузке.
К примеру, мы использовали микросерсивную архитектуру, когда создавали веб-платформу OpticElastograph для онкологических исследований. Платформа анализирует томограммы, загруженные пользователем, и для экономии ресурсов мы реализовали динамическое управление нагрузкой. При появлении нагрузки используется больше микросервисов для задач, которые сворачиваются при ее отсутствии и не тратят на себя дополнительные ресурсы.
Для каких проектов подходит микросервисная архитектура. Сложные приложения, которые должны обладать высокой производительностью. Если требования к производительности будут расти, мы сможем адаптивно увеличивать количество наших микросервисов и распределять нагрузку.
Монолит, сервис, микросервис — как бизнесу выбрать архитектуру ИТ продукта на старте проекта
В первую очередь важно понимать, какие ресурсы есть у компании на этапе старта проекта, какие задачи нужно решить и какой срок есть на разработку.
Ресурсы на старте ограничены. Все зависит от бюджета клиента. Если на старте работ бюджет ограничен и заказчик постепенно получает доход от разных этапов своего бизнеса, то для начала нужен монолит — это быстро и относительно недорого. Далее мы сможем развивать монолит в сервис и при необходимости трансформировать в микросервис.
Клиенту нет необходимости вливать большой бюджет на старте проекта. Но потом нужно будет потратить средства на доработку архитектуры.
Такая эволюция значительно дольше по времени и дороже, чем просто стартовать с микросервиса. Но выбрать сразу микросервисную архитектуру может быть неразумно, если у клиента сразу нет большого потока пользователей.
Заведомо большое приложение с большим количеством пользователей. Если проект сложнее, то актуальна сервисная архитектура, тогда при появлении проблем с одним из сервисов само приложение будет работать.
Когда вы планируете заведомо большое сложное приложение с большим количеством людей, то выбирайте микросервисную архитектуру. Основная сложность состоит в управлении этими микросервисами, чтобы они взаимодействовали друг с другом. Кроме того, есть неопределенно большие издержки на начальном этапе: на согласование всех этих протоколов взаимодействия, архитектуры и так далее. Но проблем впоследствии намного меньше, чем если бы мы разрабатывали монолит.
Крупные компании, такие как Avito или Ozon, выбирают именно микросервисную архитектуру: у них большой штат разработки, сложные продукты.
Компании поменьше отдают предпочтение монолитной архитектуре: у них маленькая команда, которая сработалась, например, в рамках одного стека.
Мы советуем начинать с разработки правильной монолитной архитектуры с расчетом на то, чтобы при необходимости сделать из монолита сервисы и микросервисы. Это позволяет экономить средства и ресурсы и запускать фичи быстрее на начальном этапе.
Выбирайте архитектуру IT-продукта в соответствии с собственными ресурсами и бюджетом. Главное, чтобы все было сделано качественно — только на хорошем фундаменте можно построить крепкий дом.
Реальные предприниматели делятся опытом
- «Найдем инвестора — он отберет компанию». Сооснователь Restik о том, почему не получал прибыль четыре года
- С какими сложностями сталкиваются предприниматели: шесть историй
- «Терпела до последнего, а потом разом прощалась»: 4 истории про ошибки в найме
- Как остановить текучку кадров и справиться с внутренним кризисом в компании. Опыт Фикуса
- «Переключение контекста — одна из самых дорогих операций в голове». Герман Гаврилов об основах управления
А как вы выбираете архитектуру для своего IT-проекта?