Как выбрать правильную ИТ-архитектуру бизнес-приложений. Примеры из практики
Сравнивать разные подходы в построении архитектуры ИТ-решений, исходя из преимуществ или недостатков одного над другим, будет некорректно. Всё зависит от целей и задач, которые преследует бизнес, на каком этапе развития он находится, какие требования по развитию предъявляются к ИТ-решению.
Если нужно сделать быстро
Если бизнес не предъявляет особенных, многофункциональных требований к приложению, его отказоустойчивости и не планирует выводить его на массовую аудиторию, - в этом случае монолитная архитектура может быть предпочтительнее. Она позволит без дополнительной разработки, в рамках одного кода для всех компонентов приложения, быстро развернуть и в дальнейшем поддерживать цифровое решение.
Монолитные сервисы содержат в себе весь необходимый набор бизнес-логики, это "вещь в себе".
Монолитную архитектуру часто используют стартапы. Весь код приложения это единое целое, поэтому вся команда разработки должна придерживаться уже выбранных инструментов и методов.
Как только решение набирает популярность у внешнего клиента, собирает достаточный пул данных и постоянных пользователей, крупные ИТ-компании покупают их, перерабатывают, оставляя самое нужное для себя, а затем внедряют в свою экосистему сервисов. Все мы слышали о сделках такого характера.
Для больших и гибких
Микросервисная архитектура позволяет создавать более гибкие и масштабируемые системы, в сравнении с монолитными, которые легко адаптируются к изменениям и требованиям бизнеса. Ключевые слова здесь “требования бизнеса”. Когда бизнес понимает, что приложением будут пользоваться сотни тысяч или даже миллионов людей. Вместе с расширенными бизнес-возможностями, микросервисная архитектура требует более внимательного отношения со стороны организации безопасности и более высокой квалификации для поддержания системы.
Гибкость и масштабируемость микросервисному подходу обеспечивают множество маленьких независимых друг от друга сервисов, каждый из которых выполняет свою функцию и может быть развернут независимо от других. Такие сервисы создаются отдельными командами -Two pizza team, из 5-8 человек, которых можно накормить двумя пиццами. Так назвал их Джефф Безос, когда Amazon был еще стартапом.
Что в трендах сегодня
Спрос на микросервисы растет с каждым годом. Например, Kubernetes в качестве оркестратора входит в нашу жизнь и становится естественной его частью. Один из архитекторов крупной иностранной компании в недавнем интервью говорил, что их Windows Defender работает в оркестраторе и это построено на микросервисах. Дефендеру нужна большая производительность, т.к. у него миллионы пользователей, в каждом клиентской программе есть обращение к этому приложению безопасности. Уже сейчас оно полноценно “живет” в микросервисах, в контейнере и оркестраторе.
Современные тенденции в разработке сложных решений предпочитают чаще микросервисность, чем монолит. И если бизнес планирует развитие и нагрузка на приложение будет расти, то лучше изначально разрабатывать ит-решение на мироксервисах.
У нас в Irlix есть опыт работы в проектах с монолитными и микросервисными архитектурами, как в самостоятельной разработке, так и в составе инхаус-команды клиента. Есть опыт работы в переводе одного состояния архитектуры в другое, чаще изменяя монолитную на микросервисную. Мигрировать с “монолита” на микросервисы сложнее, чем разрабатывать его с нуля. Приходится части монолита отделять и переписывать под микросервисы и этот процесс может затянуться. Онбординг в команду по разработке “монолита” сложнее, погрузиться в задачи микросервиса гораздо проще, чем в монолитную команду из 30 человек, создающую и поддерживающую ит-решение.
Безопасность никто не отменял
Принципы организации безопасности едины для обеих систем, но микросервисы сложнее поддерживать. Один монолитный сервис развернуть гораздо проще, чем, допустим, 30 маленьких сервисов. Основной принцип безопасности — минимизировать attack surface за счёт разрешения взаимодействий только с теми компонентами, которые необходимы для корректной работы приложения. Иначе говоря: убираем все лишнее, оставляем только необходимое. Каждый сервис должен общаться с другими используя аутентификацию с помощью mTLS сертификатов безопасности.
В многомодульном “монолите” все связи происходят внутри: один модуль обращается к другому и их не нужно оберегать внутри. Весь приложение целиком защищается сертификатом безопасности.
Цели бизнеса определяют тип архитектуры приложений, а не наоборот
Микросервисная архитектура более гибкая и продвинутая. Но при этом нет смысла переделывать монолитную архитектуру ради какой-то мелочи.
Самый важный вопрос который должны задать менеджеры компании: “Каких целей хочет достигнуть компания изменяя подход в построении архитектуры? Как это повлияет на бизнес-показатели?”
Переписать монолитную архитектуру на микросервисную стоит больших денег и бизнес должен четко понимать, что этот переход ему даст и как скоро окупятся вложения. Необходимо провести аудит, взвесить все риски и, часто бывает так, что выгода от перехода на микросервисную архитектуру не покрывает затрат. И гораздо более выгодно, с точки зрения расходов, использовать другие способы достижения поставленных целей.
Опубликовано 01.05.2024
