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